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

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-11-13 09:32, Thomas Gleixner wrote:
> On Wed, Nov 11 2026 at 20:48, Mathieu Desnoyers wrote:
>> On Tue, Oct 20 2026 at 15:54, Thomas Gleixner wrote:
>> I have a reproducer for a lockup that starts from the stale state you
>> describe. It needs two more things: the execve() fails, and the task is
>> moved to another CPU during that execve().
> 
> That has been reported already privately to me and a few others and the
> reporter provided a similar patch as you.
> 
> While both variants seem simpler, I prefer the explicit
> re-initialization for the failed exec() case.
> 
> It's a NOOP for newly initialized MMs and avoids the pointless fixup
> dance for the last user in the common case.
I integrated your approach, tested it and wrote a commit message for
it. My reproducer passes with it, and so do my other mm_cid tests, on
guests with 2 to 64 CPUs.

Do you want to take care of it yourself, or should I route it through
an mm_cid fixes series I am preparing? If you want me to pick it up, I
need your Signed-off-by.

The series has four other fixes of mine, selftests for them, and
Weiming Shi's teardown fix.

One of those four was found by a Spin model of the per task / per CPU
state machine. I then confirmed it on a real kernel, with delays
inserted by hand in the window. The model is not part of the series. I
can send it if you want to look at it.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com