Re: [PATCH] sched/mmcid: Bound the CID allocation busy wait

[Thomas Gleixner]

On Fri, Sep 18 2026 at 12:43, Peter Zijlstra wrote:
>> This also prevents an exhausted allocation from feeding MM_CID_UNSET
>> into the transition bit handling, which would later hand MM_CID_UNSET
>> as bit number to clear_bit().
>
> This all sounds horribly wrong. It fails to explain why the transition
> isn't happening, nor does it explain how it doesn't utterly
> violate/break user space.

Correct. Going back to user space without a CID is broken.

Looking at the stall splat the scenario is:

CPU1 runs a jump label update and is stuck in csd_lock_wait(), which is
invoked from on_each_cpu_cond_mask(), smp_text_poke_sync_each_cpu().
That does not make progress because CPU0 is looping in mm_get_cid() with
interrupts disabled.

CPU0 runs an execve() and loops in mm_get_cid(), which is invoked from
sched_mm_cid_fork(), sched_mm_cid_after_execve().

RIP: 0010:mm_get_cid 		linux-7.1.13/kernel/sched/sched.h:3880 [inline]
RIP: 0010:sched_mm_cid_fork     linux-7.1.13/kernel/sched/core.c:10970

So yes, that's 7.1.13, which is EOL, but it has all the mmcid fixes and
the same issue should reproduce on 7.3-rc7...

Jiakai, can you please provide the reproducer for this issue and
validate that it still persists on the lastest upstream kernel (7.3-rc7)?

The stall makes no sense because mm_get_cid() is invoked from:

  10967                 /* First user ? */
  10968                 if (!mm->mm_cid.users) {
  10969                         sched_mm_cid_add_user(t, mm);
  10970                         t->mm_cid.cid = mm_get_cid(mm);

which means this is the first CID user on the MM. So how can the bitmap
be exhausted?

I have a suspicion but it does not add up (yet).

This is a two CPU VM. Assume that the process which invokes execve() has
more than two threads. That means the MMCID of the process is in per CPU
mode. sched_mm_cid_exit() ignores a mode change when the last user goes
away and with two CPUs the threshold to switch back is when the user
count goes below _ONE_. So there is probably stale state there, but the
last outgoing task should have reclaimed the per CPU CID and dropped it,
but the other CPU still has it assigned to it. So that first allocation
should succeed...

I'll try to write a trivial test program tomorrow which creates enough
threads and does an execve().

Thanks,

        tglx