linux-kernel - Re: [PATCH v4] mm: slub: avoid wake up kswapd in set_track

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]

Message-ID: <7f30ddd1-c6f7-4b2b-a2b9-875844092e28@suse.cz>
Date: Mon, 1 Sep 2025 10:15:04 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: David Rientjes <rientjes@...gle.com>, yangshiguang1011@....com
Cc: harry.yoo@...cle.com, akpm@...ux-foundation.org, cl@...two.org,
 roman.gushchin@...ux.dev, glittao@...il.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, yangshiguang <yangshiguang@...omi.com>,
 stable@...r.kernel.org
Subject: Re: [PATCH v4] mm: slub: avoid wake up kswapd in set_track_prepare

On 9/1/25 09:50, David Rientjes wrote:
> On Sat, 30 Aug 2025, yangshiguang1011@....com wrote:
> 
>> From: yangshiguang <yangshiguang@...omi.com>
>> 
>> From: yangshiguang <yangshiguang@...omi.com>
>> 
> 
> Duplicate lines.
> 
>> set_track_prepare() can incur lock recursion.
>> The issue is that it is called from hrtimer_start_range_ns
>> holding the per_cpu(hrtimer_bases)[n].lock, but when enabled
>> CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,
>> and try to hold the per_cpu(hrtimer_bases)[n].lock.
>> 
>> Avoid deadlock caused by implicitly waking up kswapd by
>> passing in allocation flags. And the slab caller context has
>> preemption disabled, so __GFP_KSWAPD_RECLAIM must not appear in gfp_flags.
>> 
> 
> This mentions __GFP_KSWAPD_RECLAIM, but the patch actually masks off 
> __GFP_DIRECT_RECLAIM which would be a heavierweight operation.  Disabling 
> direct reclaim does not necessarily imply that kswapd will be disabled as 
> well.

Yeah I think the changelog should say __GFP_DIRECT_RECLAIM.

> Are you meaning to clear __GFP_RECLAIM in set_track_prepare()?

No because if the context context (e.g. the hrtimers) can't support
__GFP_KSWAPD_RECLAIM it won't have it in gfp_flags and we now pass them to
set_track_prepare() so it already won't be there.