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

[Vlastimil Babka <vbabka@suse.cz>]

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.