linux-kernel - Re: [PATCH] gpu/drm/ttm: Use mutex_lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 May 2014 00:30:34 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	dchinner@...hat.com
Cc:	airlied@...ux.ie, glommer@...nvz.org, mgorman@...e.de,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.

Tetsuo Handa wrote:
> From e314a1a1583e585d062dfc30c8aad8bf5380510b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> Date: Mon, 19 May 2014 18:43:21 +0900
> Subject: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.
> 
> I can observe that RHEL7 environment stalls with 100% CPU usage when a
> certain type of memory pressure is given. While the shrinker functions
> are called by shrink_slab() before the OOM killer is triggered, the stall
> lasts for many minutes.
> 
> I added debug printk() and observed that many threads are blocked for more
> than 10 seconds at ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan()
> functions. Since the kswapd can call these functions later, the current
> thread can return from these functions as soon as chosen by the OOM killer.
> 
> This patch changes "mutex_lock();" to "if (mutex_lock_killable()) return ...;"
> so that any threads can promptly give up. (By the way, as far as I tested,
> changing to "if (!mutex_trylock()) return ...;" likely shortens the duration
> of stall. Maybe we don't need to wait for mutex if someone is already calling
> these functions.)
> 

While discussing about XFS problem, I got a question. Is it OK (from point
of view of reentrant) to use mutex_lock() or mutex_lock_killable() inside
shrinker's entry point functions? Can senario shown below possible?

(1) kswapd is doing memory reclaim which does not need to hold mutex.

(2) Someone in GFP_KERNEL context (not kswapd) calls
    ttm_dma_pool_shrink_count() and then calls ttm_dma_pool_shrink_scan()
    from direct reclaim path.

(3) Inside ttm_dma_pool_shrink_scan(), GFP_KERNEL allocation is issued
    while mutex is held by the someone.

(4) GFP_KERNEL allocation cannot be completed immediately due to memory
    pressure.

(5) kswapd calls ttm_dma_pool_shrink_count() which need to hold mutex.

(6) Inside ttm_dma_pool_shrink_count(), kswapd is blocked waiting for
    mutex held by the someone, and the someone is waiting for GFP_KERNEL
    allocation to complete, but GFP_KERNEL allocation cannot be completed
    until mutex held by the someone is released?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/