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] [day] [month] [year] [list]

Message-ID: <df993304-d4f3-484a-81da-6aff3f14764f@suse.cz>
Date: Mon, 1 Sep 2025 11:14:50 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: yangshiguang <yangshiguang1011@....com>
Cc: David Rientjes <rientjes@...gle.com>, 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 11:00, yangshiguang wrote:
> 
> 
> At 2025-09-01 16:46:13, "Vlastimil Babka" <vbabka@...e.cz> wrote:
>>On 9/1/25 10:29, yangshiguang wrote:
>>> 
>>> 
>>> At 2025-09-01 16:15:04, "Vlastimil Babka" <vbabka@...e.cz> wrote:
>>>>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.
>>> 
>>> 
>>> Sry. Should be __GFP_DIRECT_RECLAIM. I will resend the patch.
>>
>>I have adjusted it locally already. Also moved the masking of
>>__GFP_DIRECT_RECLAIM to ___slab_alloc itself as that's where
>>the preemption is disabled so it's more obvious.
>>
>>Does the result look good to you?
> 
> This looks good.
> Currently only ___slab_alloc disables preemption context calls to set_track. 
> In the future, not all callers will disable preemption. 

Great, added to slab/for-next-fixes. Thanks!