From nobody Mon Feb 9 04:29:34 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E959933D6D8 for ; Thu, 29 Jan 2026 21:20:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769721656; cv=none; b=jQwP4bF32Ksg+nlY0krgcPoTMS5oOJx5ULBReTzypHR+BBzyhf2PWn1NqzCYcj0yIMIHdLRn1TyimUkUJaFrGKC8p0cOwC7qUuSBtcvO6NJAINq14Yl8BpBNF4+ROtPFCTg2tFSj/dBkUgBsh7qw+pk/Lxlyb/jypt7pq7bMS8o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769721656; c=relaxed/simple; bh=iM6OE3jhQxSWCmFJa+G2jc2rFVnXGm3qo+xxC8AhxAE=; h=Date:Message-ID:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=O1ry/IkhLeV6i7Pms2d2guJBUmx9g7FYuF5gTKVLRlXOwkypTdzj8cpQfHjz8b0UXuHO/QU5sTHcYBY7hjYXAyOzpyF/YHcFS1wkVaLV/d9iSqU79P60LTY0/+UeUPVjhZHY30Fwrqxit6AWByU0U8vC0DTMbvs1OUWT++Qu9bo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=kernel.org; spf=pass smtp.mailfrom=linutronix.de; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Date: Thu, 29 Jan 2026 22:20:52 +0100 Message-ID: <20260129211557.815063341@kernel.org> From: Thomas Gleixner To: LKML Cc: Ihor Solodrai , Shrikanth Hegde , Peter Zijlstra , Mathieu Desnoyers , Michael Jeanson Subject: [patch 3/4] sched/mmcid: Drop per CPU CID immediately when switching to per task mode References: <20260129210219.452851594@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When a exiting task initiates the switch from per CPU back to per task mode, it has already dropped it's CID and marked itself inactive. But a leftover from an earlier iteration of the rework then reassigns the per CPU CID to the exiting task with the transition bit set. That's wrong as the task is already marked CID inactive, which means it is inconsistent state. It's harmless because the CID is marked in transit and therefore dropped back into the pool when the exiting task schedules out either through preemption or the final schedule(). Simply drop the per CPU CID when the exiting task triggered the transition. Fixes: fbd0e71dc370 ("sched/mmcid: Provide CID ownership mode fixup functio= ns") Signed-off-by: Thomas Gleixner Reviewed-by: Mathieu Desnoyers --- kernel/sched/core.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -10713,8 +10713,14 @@ void sched_mm_cid_exit(struct task_struc scoped_guard(raw_spinlock_irq, &mm->mm_cid.lock) { if (!__sched_mm_cid_exit(t)) return; - /* Mode change required. Transfer currents CID */ - mm_cid_transit_to_task(current, this_cpu_ptr(mm->mm_cid.pcpu)); + /* + * Mode change. The task has the CID unset + * already. The CPU CID is still valid and + * does not have MM_CID_TRANSIT set as the + * mode change has just taken effect under + * mm::mm_cid::lock. Drop it. + */ + mm_drop_cid_on_cpu(mm, this_cpu_ptr(mm->mm_cid.pcpu)); } mm_cid_fixup_cpus_to_tasks(mm); return;