[6.6] [Bugfix] Fix slab memory leak in cgroup wmark reclaim when MGLRU is enabled · Pull Request !6224 · anolis/cloud-kernel

bugzilla: https://bugzilla.openanolis.cn/show_bug.cgi?id=28271

A memory leak occurs in cgroup wmark reclaim when Multi-Gen LRU
(MGLRU) is enabled. The leak originates from the following call path:

kmalloc_trace+124
  set_mm_walk+100
  try_to_inc_max_seq.isra.0+82
  try_to_shrink_lruvec+553
  lru_gen_shrink_lruvec+71
  shrink_node_memcgs+386
  shrink_node+390
  shrink_zones.constprop.0+133
  do_try_to_free_pages+157
  try_to_free_mem_cgroup_pages+263
  wmark_work_func+153
  process_one_work+397
  worker_thread+631
  kthread+228
  ret_from_fork+48
  ret_from_fork_asm+27

Root cause:
MGLRU uses different allocation strategies for the `walk` structure:
- Direct reclaim: allocates via kzalloc() in set_mm_walk(), frees in
  clear_mm_walk()
- kswapd context: uses static allocation, no free needed

Cgroup wmark reclaim invokes direct reclaim from a kswapd context,
causing set_mm_walk() to allocate memory via kzalloc() while
clear_mm_walk() skips freeing when current_is_kswapd() is true.

Fix:
Prevent set_mm_walk() from calling kzalloc() when in kswapd context,
matching the allocation strategy expected by clear_mm_walk().

Side effect:
With this fix, MGLRU generation aging will fall back to rmap-based
scanning in cgroup wmark reclaim contexts, which may have a minor
performance impact but prevents the memory leak.

Benchmark:
Following ac35a4902374 ("mm: multi-gen LRU: minimal implementation"),
there is no significant regression introduced by this patch.
  fio (buffered I/O): [-1.05, +1.07]%
                     IOPS        BW
    Before patch:    287.8k      10.98GiB/s
    After patch:     290.9k      11.09GiB/s

类型	指派人员	状态
审查	xunlei zhongjiang vxuyu baolin.wang kun-llfl	已完成 (0/0人)
测试	小龙已测试通过	已完成 (1/1人)

GVPanolis/cloud-kernel

搜索帮助

GVP anolis/cloud-kernel