Re: [PATCH v4] mm: slub: avoid wake up kswapd in set_track_prepare

[Vlastimil Babka <vbabka@suse.cz>]

On 9/1/25 11:00, yangshiguang wrote:
> 
> 
> At 2025-09-01 16:46:13, "Vlastimil Babka" <vbabka@suse.cz> wrote:
>>On 9/1/25 10:29, yangshiguang wrote:
>>> 
>>> 
>>> At 2025-09-01 16:15:04, "Vlastimil Babka" <vbabka@suse.cz> wrote:
>>>>On 9/1/25 09:50, David Rientjes wrote:
>>>>> On Sat, 30 Aug 2025, yangshiguang1011@163.com wrote:
>>>>> 
>>>>>> From: yangshiguang <yangshiguang@xiaomi.com>
>>>>>> 
>>>>>> From: yangshiguang <yangshiguang@xiaomi.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!