Matthiue and Jiri reported CPU stalls where a CPU git stuck in mm_get_cid():

 https://lore.kernel.org/b24ffcb3-09d5-4e48-9070-0b69bc654281@kernel.org

After some tedious debugging it turned out to be another subtle (or not so
subtle) ownership mode change issue.

The logic handling vfork()'ed tasks in sched_mmcid_fixup_tasks_to_cpus() is
broken. It is invoked when the number of tasks associated to a process is
smaller than the number of MMCID users. It then walks the task list to find
the vfork()'ed task, but accounts all the already processed tasks as well.

If that double processing brings the number of to be handled tasks to 0,
the walk stops and the vfork()'ed task's CID is not fixed up. As a
consequence a subsequent schedule in fails to acquire a (transitional) CID
and the machine stalls.

Peter and me discovered also that there is a yet unreported issue
vs. concurrent forks. Jiri noticed it independently.

The following series fixes those issues. It applies on top of Linus tree.

Thanks a lot to Matthieu and Jiri for providing valuable debug
information and running the debug patches!

Thanks,

	tglx
---
 include/linux/rseq_types.h |    6 ++-
 include/linux/sched.h      |    2 -
 kernel/fork.c              |    3 -
 kernel/sched/core.c        |   79 +++++++++++++++------------------------------
 4 files changed, 34 insertions(+), 56 deletions(-)

Hi Thomas,

On 10/03/2026 21:28, Thomas Gleixner wrote:
> Matthiue and Jiri reported CPU stalls where a CPU git stuck in mm_get_cid():
> 
>  https://lore.kernel.org/b24ffcb3-09d5-4e48-9070-0b69bc654281@kernel.org
> 
> After some tedious debugging it turned out to be another subtle (or not so
> subtle) ownership mode change issue.
> 
> The logic handling vfork()'ed tasks in sched_mmcid_fixup_tasks_to_cpus() is
> broken. It is invoked when the number of tasks associated to a process is
> smaller than the number of MMCID users. It then walks the task list to find
> the vfork()'ed task, but accounts all the already processed tasks as well.
> 
> If that double processing brings the number of to be handled tasks to 0,
> the walk stops and the vfork()'ed task's CID is not fixed up. As a
> consequence a subsequent schedule in fails to acquire a (transitional) CID
> and the machine stalls.
> 
> Peter and me discovered also that there is a yet unreported issue
> vs. concurrent forks. Jiri noticed it independently.
> 
> The following series fixes those issues. It applies on top of Linus tree.

Thank you for this series!

My CI also complained about the missing "#ifdef CONFIG_SCHED_MM_CID"
with "make tinyconfig", but for the rest, I didn't have any issues to
boot 200 times! Just in case you need this tag:

Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.