Patch "sched/numa: fix memory leak due to the overwritten vma->numab_state" has been added to the 6.6-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    sched/numa: fix memory leak due to the overwritten vma->numab_state

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     sched-numa-fix-memory-leak-due-to-the-overwritten-vm.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit c6f3fffef669e185df7ace84f9dded53ed049b8b
Author: Adrian Huang <ahuang12@xxxxxxxxxx>
Date:   Wed Nov 13 18:21:46 2024 +0800

    sched/numa: fix memory leak due to the overwritten vma->numab_state
    
    [ Upstream commit 5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075 ]
    
    [Problem Description]
    When running the hackbench program of LTP, the following memory leak is
    reported by kmemleak.
    
      # /opt/ltp/testcases/bin/hackbench 20 thread 1000
      Running with 20*40 (== 800) tasks.
    
      # dmesg | grep kmemleak
      ...
      kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
      kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    
      # cat /sys/kernel/debug/kmemleak
      unreferenced object 0xffff888cd8ca2c40 (size 64):
        comm "hackbench", pid 17142, jiffies 4299780315
        hex dump (first 32 bytes):
          ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00  .tI.....L.I.....
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace (crc bff18fd4):
          [<ffffffff81419a89>] __kmalloc_cache_noprof+0x2f9/0x3f0
          [<ffffffff8113f715>] task_numa_work+0x725/0xa00
          [<ffffffff8110f878>] task_work_run+0x58/0x90
          [<ffffffff81ddd9f8>] syscall_exit_to_user_mode+0x1c8/0x1e0
          [<ffffffff81dd78d5>] do_syscall_64+0x85/0x150
          [<ffffffff81e0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
      ...
    
    This issue can be consistently reproduced on three different servers:
      * a 448-core server
      * a 256-core server
      * a 192-core server
    
    [Root Cause]
    Since multiple threads are created by the hackbench program (along with
    the command argument 'thread'), a shared vma might be accessed by two or
    more cores simultaneously. When two or more cores observe that
    vma->numab_state is NULL at the same time, vma->numab_state will be
    overwritten.
    
    Although current code ensures that only one thread scans the VMAs in a
    single 'numa_scan_period', there might be a chance for another thread
    to enter in the next 'numa_scan_period' while we have not gotten till
    numab_state allocation [1].
    
    Note that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000`
    cannot the reproduce the issue. It is verified with 200+ test runs.
    
    [Solution]
    Use the cmpxchg atomic operation to ensure that only one thread executes
    the vma->numab_state assignment.
    
    [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@xxxxxxx/
    
    Link: https://lkml.kernel.org/r/20241113102146.2384-1-ahuang12@xxxxxxxxxx
    Fixes: ef6a22b70f6d ("sched/numa: apply the scan delay to every new vma")
    Signed-off-by: Adrian Huang <ahuang12@xxxxxxxxxx>
    Reported-by: Jiwei Sun <sunjw10@xxxxxxxxxx>
    Reviewed-by: Raghavendra K T <raghavendra.kt@xxxxxxx>
    Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx>
    Cc: Ben Segall <bsegall@xxxxxxxxxx>
    Cc: Dietmar Eggemann <dietmar.eggemann@xxxxxxx>
    Cc: Ingo Molnar <mingo@xxxxxxxxxx>
    Cc: Juri Lelli <juri.lelli@xxxxxxxxxx>
    Cc: Mel Gorman <mgorman@xxxxxxx>
    Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
    Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>
    Cc: Valentin Schneider <vschneid@xxxxxxxxxx>
    Cc: Vincent Guittot <vincent.guittot@xxxxxxxxxx>
    Cc: <stable@xxxxxxxxxxxxxxx>
    Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 934d6f198b073..ddab19e5bd637 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3344,10 +3344,16 @@ static void task_numa_work(struct callback_head *work)
 
 		/* Initialise new per-VMA NUMAB state. */
 		if (!vma->numab_state) {
-			vma->numab_state = kzalloc(sizeof(struct vma_numab_state),
-				GFP_KERNEL);
-			if (!vma->numab_state)
+			struct vma_numab_state *ptr;
+
+			ptr = kzalloc(sizeof(*ptr), GFP_KERNEL);
+			if (!ptr)
+				continue;
+
+			if (cmpxchg(&vma->numab_state, NULL, ptr)) {
+				kfree(ptr);
 				continue;
+			}
 
 			vma->numab_state->start_scan_seq = mm->numa_scan_seq;