Re: [PATCH] sched/mmcid: Fix affinity-triggered switch back to per-task mode

[Thomas Gleixner <tglx@kernel.org>]

On Tue, Sep 15 2026 at 12:10, Mathieu Desnoyers wrote:
> On 2026-09-15 11:59, Hui Su wrote:
>> MM CID switches to per-CPU ownership when the number of users of an
>> mm exceeds the maximum number of CIDs. When the affinity union grows,
>> the per-CPU threshold is recalculated and the MM can switch back to
>> per-task ownership through deferred work.
>> 
>> mm_cid_calc_pcpu_thrs() incorrectly uses
>> min(nr_cpus_allowed, users) to calculate that switch-back threshold.
>> This makes pcpu_thrs no larger than users, so the
>> users < pcpu_thrs check in mm_update_cpus_allowed() can never succeed.
>> 
>> For example, with three users restricted to two CPUs, the MM enters
>> per-CPU mode. On an eight-CPU system, widening the affinity union to
>> all eight CPUs should produce a threshold of four, but the old
>> calculation produces three and returns early. The MM therefore remains
>> in per-CPU mode even though the widened CPU set makes per-task
>> ownership preferable.
>> 
>> Calculate pcpu_thrs from nr_cpus_allowed directly. The users bound in
>> __mm_update_max_cids() still controls when per-CPU mode is entered, so
>> this does not change the threshold calculated when switching from
>> per-task to per-CPU ownership.
>> 
>> Tested with an x86_64 QEMU reproducer using three users, an initial
>> two-CPU affinity, and an eight-CPU affinity expansion. The baseline
>> did not invoke mm_cid_work_fn() after the affinity expansion. The
>> fixed kernel invoked the deferred work once and completed the switch
>> back to per-task mode.
>
> I think you're onto something.
>
> We should cover those scenarios with selftests in
> tools/testing/selftests/rseq/.
>
> Thomas, I recall you had tests for those state transitions when
> rewriting rseq mm_cid. Were those local or did they make it upstream ?

They were local. I thought I had a test for that affinity widening part,
but it looks like I only tested the affinity shrinking.

But yes, the patch makes sense. I'll pick it up.