From nobody Tue Sep 29 09:46:52 2026 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB6E5245008 for ; Sun, 9 Aug 2026 18:06:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786298771; cv=none; b=BBKYSJK7CoL6+H0lo8jGQXcw9WOAh60sHjoESzE1FeJYrbYQG8f01tDxcMzgQ+ZtLhDKAsfdg4bSyHVmMcEN26Fw8mp29aAw8yQfndpXOVpqRsei+tWSiJlYT+0eGWg1TePLygpgyBvbAZ4XyAbC2kHzGgJzxyNehYyvbiZw0dc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786298771; c=relaxed/simple; bh=ygtPFvVKAAIRpeVXqjezR0QVVhkK39na1q/DNvL1udk=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=LV09KK5QHXj5Zb/mplClPQhI8yKVd95Vv+XC5DfIoRxtKk09DJEQ9Ky/Lo+2xhoyshNWlEacFMmCxBCb/oLywhznk9GMhHj916+PaJrN71lNvcnouMgmD5miJ/IcFZ8DNTfqWMvwMAz4K1NHaUfbh1mhOBB1EzTOyTKydfJ4rTQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hQ+dFNwy; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hQ+dFNwy" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-47f7872abb6so520685f8f.3 for ; Sun, 09 Aug 2026 11:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786298768; x=1786903568; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=YhvKoEmbzO9xRY347E/hep7IU+OetLnrtlwgXtGEXas=; b=hQ+dFNwy2Fje25JCUgsH539YF9yVMuQ0YZPKZT/UB/qon+wwmGRVQDvyg9bO+xCct4 kV/9J5ZrZehbbwyb2Riboqe8Wj8uX8Uz7cLXPdSsBKUMFv5wyLmS21sjoWOuPFezGfTV IPgeFqiGGPgrrDpuu9Gryd1v71LzamnXCLJV01ESAESIcDmkv+FYJ23ynpLj7uY/6CO7 40l4mbLYW7mRgHBYuEtUpCwppAHxQIzIoARun1ce4Hidngik97rjNbuqj6setk8TeTN8 fnqzbf6MPJ2NqvwaP4wdTbgmekPSiDIkAh1sEmKkOaUUM/5NGuuGp+12FY7+Y+ANdcnZ OXVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786298768; x=1786903568; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=YhvKoEmbzO9xRY347E/hep7IU+OetLnrtlwgXtGEXas=; b=jLP67Yn+zRkZcIGg0IALfoAJFtS1Wtzo5wcG8LrOQn6HY8iESjV0WBZ+9WXVmdmZzZ 2uzS/6GKsLbxS9uctrnDflzdu5yvseQWib8KpwSSIqYVytYPsLEornBNQATpPPG35BVU /PAhXuhK8A0qS/hKgz9y92abSTpZzSyI25DUhWKffpZUKuvpIIO8kE88P3rPFfpEzRon WpG0Bb9nZNDLYEIUPiywf65GXfwOVt1hOINAHMjwxuvFRq0yCkxb7a6VBz26yBb/KtUl vwAJ8wYilvQPnncxyqgZc3+fdxZIz/keSl9rNJJhvEk/JjOJQP2hL6vLvmDchxj1UYgG zhSw== X-Forwarded-Encrypted: i=1; AHgh+Rprbo2hMrVfe/iIPI6S+eOVSd+xxt/MdDxRVHZLFlL2HPi/i5Skxlxd/gp9E/93l53m0ILro6Zf+06WXZs=@vger.kernel.org X-Gm-Message-State: AOJu0YyT1KmLKCnSIUbpvrQmnmoLSJ73IsQgYY2IIxHLCkJOgE/F077R l6y5EuWC+TzLC1wVG4ZLijz65heAM36O+5UJ5/dFY2S3KQCkivYk+4Wm X-Gm-Gg: AR+sD11peDkduYWGRPV+t3MEMK7xAkzRhiA3HoWJO1eh1EDJg/6ASJpgWJNUNNOcfj1 WhOnvmGJyKs0J31XaM8KoSitigyzXEuri12vsktPF+PHnoXWLqKXyzqBiGJlshExJNevCGv3/j1 UQzZEv+fwXaPZTyVGmO9QlOPX45Pz6hRsgsKF0XOhd2a4+uZJVsKQlt8lVJHOUt75VZpzLIqlKq oTNktD3I3rs9ulRkBe2NMnd1zYPwy2GsXdRU7plN+39Tl5yco5AY8eRq2DXx4sw2tEH0Whug4g5 oTxOU7wZ00iFKN9EJMEnOlh5vcy6EAXKQRG0MfpVvXDJjgV4B7qZcA8FigcYkEBX9nu/7uOUqQu wlW4MwoOueS97W3vu0TLR6idy9GcWZNpkJXP1DuIQAJjUDvw4xLyy1x5zP0Jxy3vLamuuK8X1MK uElcGiFNBHa10zPWkVnQMbDXzBMFGv5qdujPvI9tGy782V34hOWpKlL0S530UO+NkkEb7/GYJL5 AUChVv0igYTbB83IwhACUiRi8Bd/xlFZlxB+EGYMhHJA8yjNaPBMoflzDKd1MpX8SXyyNoeGoAO FzJotR6qfAxvx7SIk+tIIDM0mJxJE51NHyrtwRKx6CkhoQO/ojnF0n+HnsiWiLe/Uu0GXeexrFC 5lcBP/VrH+uPfCP6cPIxkAo8= X-Received: by 2002:a05:6000:4615:b0:47f:81c4:36b4 with SMTP id ffacd0b85a97d-47ffd91871fmr38818849f8f.14.1786298767462; Sun, 09 Aug 2026 11:06:07 -0700 (PDT) Received: from MacBook-Pro-von-Karl.localdomain (dynamic-2a02-3100-ac88-a501-9c5c-9666-3a00-3cdb.310.pool.telefonica.de. [2a02:3100:ac88:a501:9c5c:9666:3a00:3cdb]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-480021e8d50sm25089629f8f.24.2026.08.09.11.06.06 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 09 Aug 2026 11:06:06 -0700 (PDT) From: Karl Mehltretter To: Russell King Cc: Karl Mehltretter , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] ARM: asid: Do not replace active_asids if already 0 Date: Sun, 9 Aug 2026 20:06:00 +0200 Message-Id: <20260809180600.6049-1-kmehltretter@gmail.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) 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" From: Catalin Marinas Under some uncommon timing conditions, a generation check and xchg(active_asids, A1) in check_and_switch_context() on P1 can race with an ASID roll-over on P2. If P2 has not seen the update to active_asids[P1], it can re-allocate A1 to a new task T2 on P2. P1 ends up waiting on the spinlock since the xchg() returned 0 while P2 can go through a second ASID roll-over with (T2,A1,G2) active on P2. This roll-over copies active_asids[P1] =3D=3D A1,G1 into reserved_asids[P1] and active_asids[P2] =3D=3D A1,G2 into reserved_asids[P2]. A subsequent scheduling of T1 on P1 and T2 on P2 would match reserved_asids and get their generation bumped to G3: P1 P2 -- -- TTBR0.BADDR =3D T0 TTBR0.ASID =3D A0 asid_generation =3D G1 check_and_switch_context(T1,A1,G1) generation match check_and_switch_context(T2,A0,G0) new_context() ASID roll-over asid_generation =3D G2 flush_context() active_asids[P1] =3D 0 asid_map[A1] =3D 0 reserved_asids[P1] =3D A0,G0 xchg(active_asids, A1) active_asids[P1] =3D A1,G1 xchg returns 0 spin_lock_irqsave() allocated ASID (T2,A1,G2) asid_map[A1] =3D 1 active_asids[P2] =3D A1,G2 ... check_and_switch_context(T3,A0,G0) new_context() ASID roll-over asid_generation =3D G3 flush_context() active_asids[P1] =3D 0 asid_map[A1] =3D 1 reserved_asids[P1] =3D A1,G1 reserved_asids[P2] =3D A1,G2 allocated ASID (T3,A2,G3) asid_map[A2] =3D 1 active_asids[P2] =3D A2,G3 new_context() check_update_reserved_asid(A1,G1) matches reserved_asid[P1] reserved_asid[P1] =3D A1,G3 updated T1 ASID to (T1,A1,G3) check_and_switch_context(T2,A1,G2) new_context() check_update_reserved_asid(A1,G2) matches reserved_asids[P2] reserved_asids[P2] =3D A1,G3 updated T2 ASID to (T2,A1,G3) At this point, we have two tasks, T1 and T2 both using ASID A1 with the latest generation G3. Any of them is allowed to be scheduled on the other CPU leading to two different tasks with the same ASID on the same CPU. This patch changes the xchg to cmpxchg so that the active_asids is only updated if non-zero to avoid a race with an ASID roll-over on a different CPU. Cc: Russell King Cc: Will Deacon Signed-off-by: Catalin Marinas Tested-by: Karl Mehltretter Signed-off-by: Karl Mehltretter --- This is similar to the arm64 patch [1], with the difference that non-relaxed (cmp)xchg is used as in the existing ARM code. This is a resubmission of Catalin Marinas' original 2018 patch. The original submission was not merged, and the ARM32 equivalent of the arm64 ASID rollover fix remains missing. Changes in v2: - Rebased onto v7.2-rc6-429-ga7c7074b58d2. - Corrected the function name in the commit message's race diagram: check_update_reserved_asid(), called by new_context(). - Added my Tested-by and Signed-off-by trailers. Tested with vexpress_defconfig on QEMU vexpress-a9 using four Cortex-A9 CPUs and four batches of 320 processes to exercise repeated ASID roll-overs. v1: https://lore.kernel.org/r/20180104180405.37596-1-catalin.marinas@arm.co= m/ [1] https://lore.kernel.org/r/20180104111721.33834-1-catalin.marinas@arm.co= m/ arch/arm/mm/context.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c index 4204ffa2d104..7c4e1e4ba77b 100644 --- a/arch/arm/mm/context.c +++ b/arch/arm/mm/context.c @@ -238,7 +238,7 @@ void check_and_switch_context(struct mm_struct *mm, str= uct task_struct *tsk) { unsigned long flags; unsigned int cpu =3D smp_processor_id(); - u64 asid; + u64 asid, old_active_asid; =20 check_vmalloc_seq(mm); =20 @@ -250,8 +250,17 @@ void check_and_switch_context(struct mm_struct *mm, st= ruct task_struct *tsk) cpu_set_reserved_ttbr0(); =20 asid =3D atomic64_read(&mm->context.id); - if (!((asid ^ atomic64_read(&asid_generation)) >> ASID_BITS) - && atomic64_xchg(&per_cpu(active_asids, cpu), asid)) + + /* + * If our active_asids is zero, we are racing with an ASID roll-over + * on a different CPU, so skip the update (using cmpxchg if non-zero) + * and take the slow path. + */ + old_active_asid =3D atomic64_read(&per_cpu(active_asids, cpu)); + if (old_active_asid && + !((asid ^ atomic64_read(&asid_generation)) >> ASID_BITS) && + atomic64_cmpxchg(&per_cpu(active_asids, cpu), + old_active_asid, asid)) goto switch_mm_fastpath; =20 raw_spin_lock_irqsave(&cpu_asid_lock, flags); --=20 2.39.5 (Apple Git-154)