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.