linux-kernel - Re: [BUG] Kernel panic in __migrate_swap_task() on 6.16-rc2 (NULL pointer dereference)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE4VaGBoRNSGcfK-_Mnd+fgs11MzkLPdQV9xKs_iwCgaqxE7NQ@mail.gmail.com>
Date: Tue, 1 Jul 2025 17:10:09 +0200
From: Jirka Hladky <jhladky@...hat.com>
To: "Chen, Yu C" <yu.c.chen@...el.com>
Cc: Libo Chen <libo.chen@...cle.com>, Abhigyan ghosh <zscript.team.zs@...il.com>, 
	linux-kernel@...r.kernel.org, Chen Yu <yu.chen.surf@...mail.com>
Subject: Re: [BUG] Kernel panic in __migrate_swap_task() on 6.16-rc2 (NULL
 pointer dereference)

Hi Chenyu and Libo,

I agree, let's wait for the results. Hopefully, we can fix the root
cause based on the debug messages.

There was a problem with the infrastructure over the weekend, so I had
to restart the jobs yesterday. I should have results tomorrow.

Stay tuned.
Jirka


On Tue, Jul 1, 2025 at 4:59 PM Chen, Yu C <yu.c.chen@...el.com> wrote:
>
> Hi Libo,
>
> On 7/1/2025 3:32 PM, Libo Chen wrote:
> > Hi Chenyu,
> >
> > On 6/27/25 00:33, Chen, Yu C wrote:
> >> On 6/27/2025 3:16 PM, Chen, Yu C wrote:
> >>> Hi Jirka,
> >>>
> >>> On 6/27/2025 5:46 AM, Jirka Hladky wrote:
> >>>> Hi Chen and all,
> >>>>
> >>>> we have now verified that the following commit causes a kernel panic
> >>>> discussed in this thread:
> >>>>
> >>>> ad6b26b6a0a79 sched/numa: add statistics of numa balance task
> >>>>
> >>>> Reverting this commit fixes the issue.
> >>>>
> >>>> I'm happy to help debug this further or test a proposed fix.
> >>>>
> >>>
> >>> Thanks very much for your report, it seems that there is a
> >>> race condition that when the swap task candidate was chosen,
> >>> but its mm_struct get released due to task exit, then later
> >>> when doing the task swaping, the p->mm is NULL which caused
> >>> 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
> >>>
> >>> Could you please help check if the following debug patch works,
> >>
> >> Attached the patch:
> >>
> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >> index 8988d38d46a3..82fc966b390c 100644
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -3364,7 +3364,12 @@ 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);
> >> +    if (unlikely(!p->mm)) {
> >
> > I am starting to wonder if we should keep this check and add a big fat warning
> > like  "there is a bug here, please report it!" rather than brick the kernel.
> > A kernel panic, for sure, helps catch bugs like this more than a line of dmesg,
> > so it's a tradeoff I guess. What do you think?
> >
>
> I agree with you that adding something like WARN_ON_ONCE()
> could help, and it seems that the kernel panic is not expected
> in this scenario because this feature is a statistic calculation
> rather than the critical logic. Maybe waiting for Jirka's feedback
> to decide the next step.
>
> thanks,
> Chenyu
>
>
>
> >
> > Thanks,
> > Libo
> >
> >> +        trace_printk("!! (%d %s) flags=%lx\n", p->pid, p->comm,
> >> +                p->flags);
> >> +    } else {
> >> +        count_memcg_event_mm(p->mm, NUMA_TASK_SWAP);
> >> +    }
> >>
> >>       if (task_on_rq_queued(p)) {
> >>           struct rq *src_rq, *dst_rq;
> >
>


-- 
-Jirka