Re: [PATCH] sched/numa: Fix NULL pointer access to mm_struct durng task swap
From: Chen, Yu C
Date: Thu Jul 03 2025 - 05:25:24 EST
Hi Andrew,
On 7/3/2025 5:08 AM, Andrew Morton wrote:
On Thu, 3 Jul 2025 00:32:47 +0800 Chen Yu <yu.c.chen@xxxxxxxxx> wrote:
It was reported that after Commit ad6b26b6a0a7
("sched/numa: add statistics of numa balance task"),
a NULL pointer exception[1] occurs when accessing
p->mm. The following race condition was found to
trigger this bug: After a swap task candidate is
chosen during NUMA balancing, its mm_struct is
released due to task exit. Later, when the task
swapping is performed, p->mm is NULL, which causes
the problem:
CPU0 CPU1
:
...
task_numa_migrate
task_numa_find_cpu
task_numa_compare
# a normal task p is chosen
env->best_task = p
# p exit:
exit_signals(p);
p->flags |= PF_EXITING
exit_mm
p->mm = NULL;
migrate_swap_stop
__migrate_swap_task((arg->src_task, arg->dst_cpu)
count_memcg_event_mm(p->mm, NUMA_TASK_SWAP)# p->mm is NULL
Fix this issue by checking if the task has the PF_EXITING
flag set in migrate_swap_stop(). If it does, skip updating
the memcg events. Additionally, log a warning if p->mm is
NULL to facilitate future debugging.
...
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3364,7 +3364,14 @@ static void __migrate_swap_task(struct task_struct *p, int cpu)
{
__schedstat_inc(p->stats.numa_task_swapped);
count_vm_numa_event(NUMA_TASK_SWAP);
- count_memcg_event_mm(p->mm, NUMA_TASK_SWAP);
+ /* exiting task has NULL mm */
+ if (!(p->flags & PF_EXITING)) {
+ WARN_ONCE(!p->mm, "swap task %d %s %x has no mm\n",
+ p->pid, p->comm, p->flags);
+
+ if (p->mm)
+ count_memcg_event_mm(p->mm, NUMA_TASK_SWAP);
+ }
I don't think we should warn on a condition which is known to occur and
which we successfully handle. What action can anyone take upon that
warning?
Which means the change might as well become
+ /* comment goes here */
+ if (p->mm)
+ count_memcg_event_mm(p->mm, NUMA_TASK_SWAP);
But is that a real fix? Can the other thread call exit(), set
PF_EXITING and null its p->mm right between the above two lines? After
the p->mm test and before the count_memcg_event_mm() call?
Thank you for the scenario description. Right, there is still a race
condition although the p->pi_lock is hold when reaching here, the
p->alloc_lock should be hold to access p->mm.
IOW, there needs to be some locking in place to stabilize p->mm
throughout the p->mm test and the count_memcg_event_mm() call?
Yes, Michal and Peter have given some feedback on how to do this.
thanks,
Chenyu