From nobody Wed Sep 30 12:08:25 2026 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (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 211FC3B5E15 for ; Sun, 9 Aug 2026 08:55:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265731; cv=none; b=fENyKYAKUo7KKv6jBatJUtxAS26esFIZQIgTANyTEe1RL91TKkuIaWMedpCwkZdSKmnrD2sr0mbr8rFCYexs4PrP6nmc7U3oPcI8jWWCKABYy0gWGv+mqmBmpwebxPr/zhI3H4/9wNPaLBPgYKhqAF2dHzQw6c81CV+0wINHIwk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265731; c=relaxed/simple; bh=YaFajEc++EZydpQQWr/F6blWM6a4+OFkGgPACbvd+fE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f5gcV7i1NjzCRbEYC4ackY5Dfz3aUL4i3EDytCnLfbIIx/UajaVa0YIKrWU3FDM7EKLp1bUhMssd6eGAPyj+QCniP6Pp0Pl3wGdv1fNE3kqUHaBsRIGwv+ngfO7dtI7+cKEzBNc8X2MsJH0gMN/i2vS66mUOWC5Yy5benpopBNc= 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=nsxcW32o; arc=none smtp.client-ip=209.85.208.44 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="nsxcW32o" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-6a0a4aa99bdso957838a12.1 for ; Sun, 09 Aug 2026 01:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786265728; x=1786870528; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=tIXrb9knWmO6iHNuE9igc2E6FtJyIXy1wsmdNsvGwYc=; b=nsxcW32oKPHK9ROnGGURXxVr3B0EQ/33BJRcHRl8mCSzymgDaOToTP806WwnO2ASnJ SmP7747l7gSC4KmBjUnvdSHYTXUc/pXJI4zt68rBzCeZulZ51wIQm4XFlR1SGWnnhNIu j+grzKjWkAQRb3XZr2GgrT5XAOVj70Nfe+l0G4Lg4SOT9XUMa5pBSfpVi/UXmBfrGo+J Wq2Ek5eCNgWSmw9vTlNca9NfbLsgBNaYwCjXNmdEFMOisHloxNzxDfMwC9cep1+rl/kf dBY1zDdcB9soToX/QPcVGok5TkD8uJKk3jHw7tesXxJzPixR6i2UsveSBZ9ThTy/kCXd xvcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786265728; x=1786870528; h=content-transfer-encoding:mime-version:references:in-reply-to :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=tIXrb9knWmO6iHNuE9igc2E6FtJyIXy1wsmdNsvGwYc=; b=R7N0DlmpQScfTnkdEfZ/HBJdeW86uv28Z+fhTA0aHmlHzhXCvxAFbufD9kD9ihUCof QNbviat9sI3GR/qDMe3vY0yE2epftHLvxeT74OUlIon03fy5z3hgk+pz1DSGVJ7U3iif N9TOWtDI97wNsoKiUiU41yTSjy+OHQagnd+UQ0fqXrLLr3pA5FKdus/CBEGhuNLYdgSS GkXlumnQ2gC4/Cl8yj8P1aB4hgdW/qT0PKemgUYVFxn/e9JkPN6GQL+2z+n9DwaSB50h lZ+Hr/yrLrqyJC6MUN9PxkW/3i0eGf5n+NG6kdFGszKIEe0oC9Sk5lju89iromqJEPjK Wxww== X-Forwarded-Encrypted: i=1; AHgh+RqWfukwUKkfd6PzcCqfRQAWqfvdIDcPeXw8icSgMVUt+UIlM2a4MNe3/hbnVHP13Hisz/fz1PZRtCfmCRA=@vger.kernel.org X-Gm-Message-State: AOJu0YyNEfc4BCfIIUHI7al+bt2VdqwlGMVW+C/lFgmRGGc6pHe3vnbp 2xP173UyVprek03NBSWrEbHgJqKaKPwvtUhQMpzsfM+SxYne91VCw3Ai X-Gm-Gg: AR+sD13EWiaTM/H/x25hhKaeX5tmfwc7Ug5HW5o2UWQnSiYaC0g/kY673VGwC1YmOg4 YHi2scR9OCZ3Nd7ccrJHUcW69SRoZTbzGo9Jcn3aVyzyPFf9vtXAKoHItI2hd0kRq1JEsAVyQgK p/t6LcNgXqc2PlCobWUdFk10xvsgm/AxyrWID7/0YVfp2xm0+l1bIMIYhFlVpl5XncYBwtTlepQ IFbMbdPK1/voYJemWty4aQt7xxgXcrqzWFHfXzMvIUHW6+TAE5z55wi8bSMzvhfcq39mGb44x6B gVCmFL7qOR4ey/JEh4Xs0QMoftfbapl4IFZyDyYPM7vpUhpLNABdAB6SnSc6BFY9HWj3Hv4bg/X JSvK2UrcjkS2FdS6wKiCdp3arEvSaeYrkjdNKM0ZCqvQj6UbJh2vvv4FfFERirXBKM+xW2bFtZj DVLA8YqKBsCrOck76ErR0BT7N4mseQEy+zDfQrSpLHh+pDAqWPiOfeP/7n/DEzEshNaITTCtrYG l9649nFPQHN3zOv+ZbJq0PnhwT6ceA= X-Received: by 2002:a05:6402:11d0:b0:6a1:b515:c3c1 with SMTP id 4fb4d7f45d1cf-6a1b515c6a2mr9877208a12.4.1786265728373; Sun, 09 Aug 2026 01:55:28 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a1f630a4afsm1606681a12.3.2026.08.09.01.55.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2026 01:55:27 -0700 (PDT) From: Magnus Lindholm To: richard.henderson@linaro.org, mattst88@gmail.com, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org Cc: glaubitz@physik.fu-berlin.de, mcree@orcon.net.nz, ink@unseen.parts, macro@orcam.me.uk, Magnus Lindholm Subject: [PATCH 1/6] alpha: run check_mmu_context() from finish_arch_post_lock_switch() Date: Sun, 9 Aug 2026 10:49:33 +0200 Message-ID: <20260809085208.3262799-2-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260809085208.3262799-1-linmag7@gmail.com> References: <20260809085208.3262799-1-linmag7@gmail.com> 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" check_mmu_context() clears asn_lock and acts on need_new_asn, but it runs only as the tail of switch_to(), after alpha_switch_to() returns. A newly forked task never gets there: its first context switch resumes at ret_from_fork, which goes to schedule_tail() and then to user space rather than returning to the code following alpha_switch_to(). A new kernel thread reaches schedule_tail() the same way, through ret_from_kernel_thread(). asn_lock is left set on that CPU, so the forked task runs user space with it set and interrupts enabled. A TLB shootdown IPI arriving in that window takes the deferred path, and the need_new_asn handshake meant to cover that never runs. finish_task_switch() calls finish_arch_post_lock_switch() with preemption disabled, on the CPU that ran switch_mm(), so hooking check_mmu_context() there completes the deferred-ASN bookkeeping for both. Running it when switch_to() has already done the work is harmless: check_mmu_context() clears need_new_asn as it goes. The same hook is also called from kthread_use_mm() and sched_force_init_mm(), outside the scheduler's preemption-disabled switch tail. check_mmu_context() acts on per-CPU state, so it can only complete this bookkeeping while still on the CPU that ran switch_mm(). Testing preemptible() expresses that condition directly rather than naming callers: where those paths leave preemption enabled the CPU may already have changed and nothing is done, and where preemption is disabled across the switch, or not configured at all, no migration is possible and running it is correct. Signed-off-by: Magnus Lindholm --- arch/alpha/include/asm/mmu_context.h | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/arch/alpha/include/asm/mmu_context.h b/arch/alpha/include/asm/= mmu_context.h index eee8fe836a59..f7afc64ca8dd 100644 --- a/arch/alpha/include/asm/mmu_context.h +++ b/arch/alpha/include/asm/mmu_context.h @@ -181,6 +181,34 @@ do { \ #define check_mmu_context() do { } while(0) #endif =20 +/* + * check_mmu_context() clears asn_lock and acts on need_new_asn, but it ru= ns + * only as the tail of switch_to(), which a newly forked task never reache= s: + * it resumes at ret_from_fork instead. asn_lock is left set and the task + * goes on to run user space with it set and interrupts enabled, so a + * shootdown IPI arriving in that window takes the deferred path and the + * need_new_asn handshake meant to cover it never runs. + * + * finish_task_switch() calls this hook with preemption disabled on the CPU + * that ran switch_mm(), which covers that case. Running it when switch_t= o() + * has already done the work is harmless: check_mmu_context() clears + * need_new_asn as it goes. + * + * kthread_use_mm() and sched_force_init_mm() also call this hook, outside + * the scheduler's preemption-disabled switch tail. check_mmu_context() a= cts + * on per-CPU state, so it can only complete this bookkeeping while still = on + * the CPU that ran switch_mm(); preemptible() tests that directly. Where + * those paths leave preemption enabled the CPU may already have changed a= nd + * nothing is done; where preemption is disabled across the switch, or not + * configured at all, no migration is possible and running it is correct. + */ +#define finish_arch_post_lock_switch finish_arch_post_lock_switch +static inline void finish_arch_post_lock_switch(void) +{ + if (!preemptible()) + check_mmu_context(); +} + __EXTERN_INLINE void ev5_activate_mm(struct mm_struct *prev_mm, struct mm_struct *next_mm) { --=20 2.53.0 From nobody Wed Sep 30 12:08:25 2026 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (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 91F6F3B6367 for ; Sun, 9 Aug 2026 08:55:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265733; cv=none; b=N0Rde41u+6WZER2ugGyMuJ7nmqVoD6tc/XEjzAD5nGzoAm7krvWULrPZsqniYaKV0U8TFnzHnbxR4laRh56t1NdPIuHz42lPKLcMqZnIoEoHQxTHfvxlLefbyiInj1HeXzI63wkvOrbqFuIJ1VadU0JaK0Tq0/TlZpBQpBOEaiI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265733; c=relaxed/simple; bh=i3uCb971qBsXhOjlS4VI5Z1LyED20fQEVi2SdG/BSsk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MqdSE1TEctzevCbJ5nbF1PTw2Q2RhzuhLaGXZHqJz2kf8PeFcQFmEwFPns82lX6Up7dn4v9D2dU4Kq+9vcNYC4MeG3loh0UPaJy0a6Tk2k+6IKqvfXpu7Rp0oL4q2uIflUescB3mkawF1nlIdKaIg4/bENJ82EzA6/lN9+VrV8Q= 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=VK48gBw3; arc=none smtp.client-ip=209.85.208.49 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="VK48gBw3" Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-6a10d02ff43so1312064a12.0 for ; Sun, 09 Aug 2026 01:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786265730; x=1786870530; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=TtG+LSzX5pGhXF98AP6Y+JUcMCLF755yYvd2Fbb8syg=; b=VK48gBw3RB1BN3oSHPhZRFQAHCETyEwxlZtJ4pIFo6TTgm8SsQ0Q5qa9241R8PJZMW KnWJWgzWgAJjrNpEeGXv+DuEP1K+o4Ca8+wYzGv21940KBR/SjeW6kINGEJ2PoYAt8da DoVQl6LXSsKphtgdqP52f6u4WqIcJAxyONkZjf93tdS52gVNA6CcOVRvTBWZnaas3qhn VXw4IAlSILNWGoZ65b20gZhQ8vHdk1V0uD9oexS+w+gfr8Fi8EfH7415XWckDp1pOsIp VcKXveG7dMA4PO6hxX0/Ng2W+oM03D6MGxFlVXld+W5gi+qi1NGeduJd0JxjHZnkwwIS T1aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786265730; x=1786870530; h=content-transfer-encoding:mime-version:references:in-reply-to :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=TtG+LSzX5pGhXF98AP6Y+JUcMCLF755yYvd2Fbb8syg=; b=Xt28xb0tfINeX925C6foSYzSm7BgtvQTW0zpd7sgHhhzmv7Hy4muS6GqTB5eKgTgcV E9zaukS2mMesiFPfeW1dWqcTN2IL1oray8uPG3OvXb5JdNeB4/xCTZBgpIAZi8IfFFXA Upy0I/TZ7fuVBYqfEWt67QcF1e/AHgF4KASzF0kca4J0EXRAotFvXimFfHqajRmzoAQk mRxZjgNl7D6KWpKtJAGoN294ydUyqHcgfXc8SBDnkaFojVsBdhq/RVtZKy7WrLuPAPIY I6IfaftQ7XnsRVb9lOtLSV1nFT1Vw9LJHoPgfOVvyXai22/KEMzlt4NKxUwPhu5W3plt rBBw== X-Forwarded-Encrypted: i=1; AHgh+RoMnTKiVaeGBMnDKUN8w7zHLAaelPoSzuK4l4GlAa4XfH08Gm/tigY6aHxtKgITadl7PFrZnXKg9lp4X1o=@vger.kernel.org X-Gm-Message-State: AOJu0YwiJKJxigGSPuFQI3kyz3RITyzSl/cJzjfvTyx8LrXoPYAwLfGg njRJJcfEj2duyHhgCfnWQmUX2g9fj+37GIYViNS9b0LtkWrvl++1oDK2 X-Gm-Gg: AR+sD10hxrq+K93+14d5M/YMibpXzbRD+PbYocmrviw3mcrOFrUnDrFVJ4BDM97tkjm craqIEvEGpwYxnlqFg4WByBG4dYAAVBcnzWhqKvHw8whB9qt3qR16ftvlj3RA7LH1DtEiVpH99l qzRPDGkYaVU1LdXQR9hRpzZ3uftad2XL1H9PSQn1w0W4f9AiOv0jDDqYl3n/Ouvoyvye7aSvVEV j2GdgCQ8dWqlTMvzLy4p0gjRJ30AmFRZheiuIQZb5PIpinR8zDGVag03AinQtx8WU7iG7CuUOc7 WJOa+wkh1BpmY+g/ovvIMtQEzwXBHxJ9QDPiz/9g9oVQBn3ZJ0nqk/rm6aXuG9h6uP59y+B/tWJ FqR33SgyQsPJDg2dQ5wNpdQngO4kB6LPNFVal5M61YvovdUYVNbq9ZbKy1O1btR38U02MZxlart aPXG1W0vqOhAXU4dOe1TAbJLpSL3FvWpAWF35bcTKbXsDJmyX9twYiVeQxHsvnvtYW4bnlwkC5C XTVW8teG+J0YnqjPrSpODrhghp/Tjg= X-Received: by 2002:a05:6402:5515:b0:6a1:f95b:8ced with SMTP id 4fb4d7f45d1cf-6a1f95b8e6fmr3310458a12.4.1786265729760; Sun, 09 Aug 2026 01:55:29 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a1f630a4afsm1606681a12.3.2026.08.09.01.55.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2026 01:55:29 -0700 (PDT) From: Magnus Lindholm To: richard.henderson@linaro.org, mattst88@gmail.com, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org Cc: glaubitz@physik.fu-berlin.de, mcree@orcon.net.nz, ink@unseen.parts, macro@orcam.me.uk, Magnus Lindholm Subject: [PATCH 2/6] alpha: only use a targeted tbi() when the target mm is really current Date: Sun, 9 Aug 2026 10:49:34 +0200 Message-ID: <20260809085208.3262799-3-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260809085208.3262799-1-linmag7@gmail.com> References: <20260809085208.3262799-1-linmag7@gmail.com> 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" A copy-on-write fault replaces the page and calls ptep_clear_flush(), which ends up in flush_tlb_page(). For a non-executable vma the remote IPI handler issues a targeted tbi(2, addr). tbi() acts on the address space context currently loaded on that CPU, so it means something only when that context belongs to the target mm. current->active_mm is the wrong test: under lazy TLB an idle or kernel task keeps the mm as its active_mm while a different ASN is loaded in the PCB - enter_lazy_tlb() updates only the borrowing task's page table base, not its ASN. The tbi() then invalidates the wrong context and the stale translation survives. Nothing forces the old ASN to be retired afterwards either, because mm->context[cpu] is still valid, so the resuming thread can reuse it along with the stale entry. Use current->mm instead. When no thread of the mm is current, fall back to the deferred invalidation, which forces a fresh ASN at the next switch and is correct whatever is loaded now. This does not make current->mm a guarantee that the mm's context is loaded: kthread_use_mm() sets current->mm and reaches switch_mm_irqs_off() directly, which on alpha only prepares the incoming PCB. That is a separate problem in the switch path rather than in this handler, and it is not addressed here. Signed-off-by: Magnus Lindholm --- arch/alpha/kernel/smp.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c index ed06367ece57..0dfe29b59039 100644 --- a/arch/alpha/kernel/smp.c +++ b/arch/alpha/kernel/smp.c @@ -669,7 +669,20 @@ ipi_flush_tlb_page(void *x) struct flush_tlb_page_struct *data =3D x; struct mm_struct * mm =3D data->mm; =20 - if (mm =3D=3D current->active_mm && !asn_locked()) + /* + * tbi() acts on the address space context currently loaded on this + * CPU, so it reaches MM's translations only when a thread of MM is + * really running here. current->active_mm is not sufficient: under + * lazy TLB an idle or kernel task keeps MM as its active_mm while a + * different ASN is loaded in the PCB, so the tbi() invalidates the + * wrong context and the stale entry survives. Nothing forces the + * old ASN to be retired afterwards either, mm->context[cpu] still + * being valid, so the resuming thread can reuse it. + * + * Otherwise fall back to invalidating the context, which forces a + * fresh ASN at the next switch whatever is loaded now. + */ + if (mm =3D=3D current->mm && !asn_locked()) flush_tlb_current_page(mm, data->vma, data->addr); else flush_tlb_other(mm); --=20 2.53.0 From nobody Wed Sep 30 12:08:25 2026 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (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 C8A2D3B71A6 for ; Sun, 9 Aug 2026 08:55:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.47 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265734; cv=none; b=F6XdoQN5QhAbl1dJNTgtnt9l3SBgPUx9jNi5giqS8bfu64zlvunvdXEqGCU0uZw5ozoS+CgZnZIwLmQ6iiH0CZ3thIE2mNSCpfoWNMuahH/98/C+CUOdi1K/odODVBc5gvXVBFTmCMvnOyiQGfiLBlmrtgZBMdQBYitvyJbFDbQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265734; c=relaxed/simple; bh=XJ13sZxBIJ6krRBf+heB4Ni/k1z+s8+IsLQT7eImPz4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=muXRduyTn8F1wDjS6ms7/s/PTqb6IileQ9fFxBqbq/7NCfRdUO/JOGUEq0YYjOz3hPFjamVNkUQ7ny9Pj108bFpCIVfUrfnG/LQAsnYbRLoX3NCV6YbJ5lU3ucB8kMdIP02K3qxPJQYofGTmaaB4FaxPre9lvflW2L4qfrc2OOg= 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=e1PF3dSc; arc=none smtp.client-ip=209.85.208.47 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="e1PF3dSc" Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-6a156627e22so4885900a12.1 for ; Sun, 09 Aug 2026 01:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786265731; x=1786870531; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ApQfFv154paetM9TgIxQj41acxDPs1l/KeCboEHJf9A=; b=e1PF3dScL8aEvRZaPq6bnJvKfkXtuWLvhUpzYMfBcunM/oVLwPRGorm8OSL9KNhH1u NY0o5HTc/uCyklcOr9HmxFkcCditPBIbqA63iF/F7kHM020USljw14b8FLntjPk6Zl8z w/O/gubdkTVhWqdNZci04jl+g4WXnG7gYAFkgTh96BTt11Sa3quOzRSYLPkqtLTMuBEI H8Qe/TI4iNEvLfFL82mioaJWMQjnCYak+5mmyWUHL6LNcVdu3HbBG8jN0DLf37Lk8nv9 Dr+NKWxazAj4HOu/6VHwYuuBIgADL7B46vX/PExUVTuR/+n+kwTBIYU49LVMLPW1rh6I Qudw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786265731; x=1786870531; h=content-transfer-encoding:mime-version:references:in-reply-to :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=ApQfFv154paetM9TgIxQj41acxDPs1l/KeCboEHJf9A=; b=ba1tZ3TGYpPVyg7JaKTXsrqlDPf+/uYiL0MGr2nUsiIYkUcfWyUc8HQWLtmQj/VDaV 4p4tdI/wQRAt+V9D9b5eGiVDqp7vX0NG1CKe/HlZ4eGcQXQyPcRxcnoax7nOwuorCUKC vZ/Mvl686yGiL8jGAcMV+68Sj00hanKO9CiNYfGkHglWs5xaxlqOWyp8Dww+U5gOcvHV vK56qkpaJlhzUIuI7kDtbtvqZTDu2VKAuNHcmpSj0BxpEuJ0/mfz9hOrxzhRoKXEe0nH W1VQKO9HC6upiJcADplN8Bs7S4xLQSp41l9gAJMuEZHGnPlM03+0ngMPPc078zTLahXR 9FVQ== X-Forwarded-Encrypted: i=1; AHgh+RqvK/SnNQQyFKYwgS9l2MXQQLIl09P3WHOfcLvyqYJrHrefj+qBcwqT2Cm81mUnBMHciiCAS49tSGgIxDM=@vger.kernel.org X-Gm-Message-State: AOJu0Yxgh2qozFL4PNxYBVDKxQSj2uJCQ5PRJo//NBJtR+5T1FwEbeVy GxZ407C9kdkxtILgRz3j3ltgGjEgNeJfHDgYip3/1EzMjt2k+Yva+e6T X-Gm-Gg: AR+sD13eNZKtUeSRA9E6U9LhglExev3Hb+miMA8++5z9pvKalm6/bFiW+bo87fV1Vkb Ic4uvc8cUtndXCl7MiOTqkbm6hg5vXo0Qa4iz80c+jBUQxoHbE89LD/lYnA0DbnhR2mLQvlauKI w/7WAyFYU33sB/Hqc0h0EO9kXgOv/CMsnT6Wc3238xEjJ7EDFUSetPjuC2A0XL+M9QIqv0wM6JS GlUG9TV/vL5PaGDa36N3rReMS4wch1KIOtOjhnsQfWphJZkEs1RnvsRIgf/y8lLe2q0eqecb5WI VSzNdX8m36LEKhKFx8fwUC6gyBCxWwvorqp4poJFOko95P+phb1qL+76X8Ci5pio145eWVPvQ1b XaG1oDnsOjRReEAJPUzhsitZYACXGvomdzUgksdOA0tTbwLcWulennFyHSmFO/nmCjsmjf4wDbT aLvWzY4VWZyO3h9a+NtMsz6dryDk+cjQ/68iwOTaeiFyTgZ67xFnqb3nfLEdE2v+vYaO9zNalno a1ryAimVXYYeH1d5lzd0vLLBHZ0IdQ= X-Received: by 2002:a17:907:ea8a:b0:c12:49d6:3c5b with SMTP id a640c23a62f3a-c208d3f294dmr456032766b.8.1786265730821; Sun, 09 Aug 2026 01:55:30 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a1f630a4afsm1606681a12.3.2026.08.09.01.55.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2026 01:55:30 -0700 (PDT) From: Magnus Lindholm To: richard.henderson@linaro.org, mattst88@gmail.com, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org Cc: glaubitz@physik.fu-berlin.de, mcree@orcon.net.nz, ink@unseen.parts, macro@orcam.me.uk, Magnus Lindholm Subject: [PATCH 3/6] alpha: fix the local TLB invalidate in flush_tlb_page() Date: Sun, 9 Aug 2026 10:49:35 +0200 Message-ID: <20260809085208.3262799-4-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260809085208.3262799-1-linmag7@gmail.com> References: <20260809085208.3262799-1-linmag7@gmail.com> 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" flush_tlb_page() invalidates the calling CPU itself before asking the others, and gates that on current->active_mm. For a non-executable vma that means a targeted tbi(2, addr), which acts on the context currently loaded, so as in the IPI handler it reaches nothing when only active_mm names the mm, and nothing forces the old ASN to be retired afterwards. Test current->mm instead. When no thread of the mm is current, clear mm->context[cpu] so a fresh ASN is taken at the next switch. That also covers the case where the mm is not this CPU's active_mm at all: the CPU may still hold translations for it, and smp_call_function() does not call back into the caller. Reached in practice by folio_mkclean() from the writeback flusher kworker, which has no mm of its own: about half the calls during writeback of a shared mapping, and none at all on anonymous memory. flush_tlb_mm() does not need the same active_mm to current->mm change, because its active_mm path loads a new context rather than issuing a targeted tbi(). It does have the separate caller-CPU omission when the target mm is not active_mm; that is fixed in the following patch. Signed-off-by: Magnus Lindholm --- arch/alpha/kernel/smp.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c index 0dfe29b59039..d167b3ba1303 100644 --- a/arch/alpha/kernel/smp.c +++ b/arch/alpha/kernel/smp.c @@ -696,7 +696,15 @@ flush_tlb_page(struct vm_area_struct *vma, unsigned lo= ng addr) =20 preempt_disable(); =20 - if (mm =3D=3D current->active_mm) { + /* + * As in ipi_flush_tlb_page(): the targeted tbi() reaches MM's + * translations only when a thread of MM is current, so test + * current->mm. Otherwise - lazily borrowing MM, or not running it + * at all - clear mm->context[cpu] so a fresh ASN is taken at the + * next switch. smp_call_function() below does not call back into + * this CPU, so this is the only chance to retire what it holds. + */ + if (mm =3D=3D current->mm) { flush_tlb_current_page(mm, vma, addr); if (atomic_read(&mm->mm_users) <=3D 1) { int cpu, this_cpu =3D smp_processor_id(); @@ -709,6 +717,8 @@ flush_tlb_page(struct vm_area_struct *vma, unsigned lon= g addr) preempt_enable(); return; } + } else { + flush_tlb_other(mm); } =20 data.vma =3D vma; --=20 2.53.0 From nobody Wed Sep 30 12:08:25 2026 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 D62AD3B6BFD for ; Sun, 9 Aug 2026 08:55:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265738; cv=none; b=hmBTAzcbgpimbQBauGEQbNIeDVvtDOex/JP0cinSH6V6Js7uL/fZK30OYSOmmLgfPvAxZy1gl+on2cQz11EGBtCqug+Eg/2XyW/Hz2XZF8Njlm1q+sHL4fXGjyPWBhZ0+bMDOHjSSzrddOzqdFRcWRtcSyN308FLq87SxKZI3Qk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265738; c=relaxed/simple; bh=uy/JgEKOMWzoHDf2mqKMd6Dn+BTDC04z+to1rJnyr3E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G02b6vAuEYQkNMbCjM3X+q/ATqgmOF0NRVG2slrbv3OAVk7+M/ddj5dnxEXx6p7uWs6g5dkl4F4dOmhRzNWPFwzEqlbDpooTCJ3Yd7qFY9thowRIzrchwh41HxxKBZyzfCgcw8aJYkGZfFmhtfV73TlbzCz2SIkk5FUERFBtCEU= 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=lDaTt//Y; arc=none smtp.client-ip=209.85.208.51 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="lDaTt//Y" Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6a0a4a18180so1295289a12.0 for ; Sun, 09 Aug 2026 01:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786265732; x=1786870532; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sehBMnNKu3HPbwKfQMPjHU1mwRo2NHUpCC+rEDi4C9g=; b=lDaTt//YxP12tp8RGMyciuTm6a7HMkok5wNxal3Y9Q8pjA+7ZjO5hnPeft2dKNjV63 6KrS8pG2XZGTcNgHMVt2JURKwcIoSXu3mkNONVFiqw8Y+PeDBE3t6Ff8apST9ROAy3gs aphgYul4dpcgXsZt3a0MGAkhF3cFjXXpZv74R3Zobbli5OHL+fJJPCWwJQzodA+jfJv4 TbF2WGw1ZkEoy1j/3higWHJD7NTGrdfsLUcSj+1OgCTag/ZVzZGOksqG9P16REOe5m/U JnyXLXGXU0LPxdMeELGoz3leeftLUHhLYtm51abUzg7hYpA8n+XbyVCIpvUc9vPiOQMC aMtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786265732; x=1786870532; h=content-transfer-encoding:mime-version:references:in-reply-to :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=sehBMnNKu3HPbwKfQMPjHU1mwRo2NHUpCC+rEDi4C9g=; b=W3+qY0QRRkUvosf/SeXI2x1D+0Wnobz9B4PgRV1oLKlROtaFwfZ11el0FU/4A4yms6 mdcgGD2LfuQlWwXKhcPyWMQicdvIps7RiNq5/cEne0zSmN2uyxpy+E9K7u5wzgu+U1LD vXJb1HikOg0kkAHCF6FvCZ3NzxWEn7CUbWC1XWqAAQbIK/XiIv1LhtSMAKjRwUT1u4gv fotY5iPil0ZgcsS3a51PMAVyGQ0l+O0mxXDSnKIQQYtsmz8a+sdJEVcNOCh/PGATq6dn jXUFhkMz5jJ0wsWls8C2m5AvEd6FiuX2Ee5KN0wv1l/6G8OZ+TDhgF24TFpzohJyyYEq LXXQ== X-Forwarded-Encrypted: i=1; AHgh+RpspkVQnZJ2kFNsqaKmCdM9lSEy2i95McFvOiafF0HpI1zno4cpkIDqI1yL0cAyKjxio8eoyKzy9yKZIjk=@vger.kernel.org X-Gm-Message-State: AOJu0YwVCvNFjy0lKEFKZx18kbbQTEYwMyD6fePuEfmULHju+ZKzjjgA SR+9343xHuN95Vxe356rwD5lqk9Bv4W+najwLhwhO45Lz5Z/eOsy6OCK X-Gm-Gg: AR+sD11GEgMCXgv87H3r3RrFnXxijZQ5/DP54qs5izFe0oWJo4kUovcM/cDbMFMyWck Je4nHA0h+JpJSbJURBGa0tgeH4AflCo2qjcgeR7edPAm/okNvZoMKFRGSo73/rgaAxmsNcJsgX8 Ka3zB7x9sFe/quyr4XiYwnVK9MJtVJbJajwivIZlimLdpApGPwt5OiwKZb1r1x4v154Q+tox41D eyU1nBHDhhLty+F7kpTuMFEd53QLwpG+Ob/7tgYA0vWl9wxSwuBgUbmdnZTbrG1k0kV/rIK05rs hptVTqwa3Wud+h6Corw4jWScEykTEoqFHmyHCl3YBlBIBnyRpVNfAv+n1yxA/hspzz2rB67K2sh hT2XbgDSvxQjzu4fvBxQ4ScxWHncZ256XqOqWkcmSQDAoyovdV7ZwZPKsPQfphJWs9Dp5sEy+J0 +cHyb109uz2RGYzkPuPai3CQpXpMWxIcyM9jDNk0OL3i7X7xMcr1XPnPPwNX+FuTcx2ZgVlYv9/ 4YsZ8229QeTeUt6F1winoI63DaE7ea7+GZ0gHLn1g== X-Received: by 2002:a05:6402:a5c7:10b0:6a1:f7cf:642d with SMTP id 4fb4d7f45d1cf-6a1f7cf674emr2763843a12.17.1786265731942; Sun, 09 Aug 2026 01:55:31 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a1f630a4afsm1606681a12.3.2026.08.09.01.55.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2026 01:55:31 -0700 (PDT) From: Magnus Lindholm To: richard.henderson@linaro.org, mattst88@gmail.com, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org Cc: glaubitz@physik.fu-berlin.de, mcree@orcon.net.nz, ink@unseen.parts, macro@orcam.me.uk, Magnus Lindholm Subject: [PATCH 4/6] alpha: only use a targeted tbi() when the target mm is really current (UP) Date: Sun, 9 Aug 2026 10:49:36 +0200 Message-ID: <20260809085208.3262799-5-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260809085208.3262799-1-linmag7@gmail.com> References: <20260809085208.3262799-1-linmag7@gmail.com> 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" The uniprocessor flush_tlb_page() has the same defect the previous patch fixed for SMP: if (mm =3D=3D current->active_mm) flush_tlb_current_page(mm, vma, addr); else flush_tlb_other(mm); For a non-executable vma flush_tlb_current_page() issues tbi(2, addr), which acts on the address space context currently loaded, so it reaches the mm's translations only when that context belongs to it. Under lazy TLB an idle or kernel task keeps the mm as its active_mm while a different ASN is loaded, so the tbi() invalidates the wrong context and the stale translation survives. Use current->mm instead, as for SMP. This is not theoretical on a uniprocessor. folio_mkclean() runs in the writeback flusher kworker, which borrows the mm, and with one CPU that kworker necessarily shares it with the thread holding the translation. A test that writes a small MAP_SHARED file while background writeback cleans it loses data on every round: the mapping holds one value and the file another. flush_tlb_mm() and flush_icache_user_page() need no equivalent change here. Both use __load_new_mm_context(), which allocates and loads a fresh context rather than relying on a targeted tbi() against whatever ASN happened to be loaded. Signed-off-by: Magnus Lindholm --- arch/alpha/include/asm/tlbflush.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/alpha/include/asm/tlbflush.h b/arch/alpha/include/asm/tlb= flush.h index 0c8529997f54..6593a64090f1 100644 --- a/arch/alpha/include/asm/tlbflush.h +++ b/arch/alpha/include/asm/tlbflush.h @@ -87,7 +87,14 @@ flush_tlb_page(struct vm_area_struct *vma, unsigned long= addr) { struct mm_struct *mm =3D vma->vm_mm; =20 - if (mm =3D=3D current->active_mm) + /* + * tbi() acts on the address space context currently loaded, so it + * reaches MM's translations only when a thread of MM is current. + * Under lazy TLB an idle or kernel task keeps MM as its active_mm + * with a different ASN loaded, and a targeted tbi() would then + * invalidate the wrong context. + */ + if (mm =3D=3D current->mm) flush_tlb_current_page(mm, vma, addr); else flush_tlb_other(mm); --=20 2.53.0 From nobody Wed Sep 30 12:08:25 2026 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 0F80A3B71DC for ; Sun, 9 Aug 2026 08:55:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265736; cv=none; b=hkZpZaCZtnheN4t23J202woildm1B4bnAsbtQblAgq1ZR1eG8/NyGuO1VIHdeFBx//VFC9UEZ9i/G6bzLk1ixgMxaoJhR17EXRMB+0AKsF/g7gO08DVwLnyzWb372ISlrlKf9BuImXS4VXJZayZsh1MQVdn1Wpj32rACTLtp6CA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265736; c=relaxed/simple; bh=OLtwvEZhh/H9sdbvrxT5KViQxXMRD5pB2TH7wole/jk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KXrmiijEuz0nyoX/eyOdehcwThcIVSxRxPJJ9+8co5XECU/yTx/+VG6tEkkO5tmKsHalRsBToJcaVvnm+9dEIAY2tlaBl7T4XX5HsMrcGKxvY3nVU9DA0Digd6FqrW4et7/17hJd37X+CNQOlHtaJKKKf+QcE5UdxwrW65/XkEU= 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=RYNGnY23; arc=none smtp.client-ip=209.85.208.51 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="RYNGnY23" Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6a1995ac437so1603489a12.0 for ; Sun, 09 Aug 2026 01:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786265733; x=1786870533; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Im1M3BLw7bmxcZcAK4CCU6quas0ztWTFGLp+A3NEnA0=; b=RYNGnY23uFdfzFxfyojAQA/YVEkNCVMmi/EYE8uQiLtb8Z5t037CDVRa9wnLEipqeE g7+a7P9pJ+mkb45NfxHG0KKRfxXMGNPC+vwvyzterZN8rQxi3BcWpn6xnqpMrOdhL9HW 0cIe6EGuBPSpQTXVqpk1tpzv3b5dG85ddVPYy0Z7/C/FUTFHYwS6vnufI7lNAty71tOB OnYGqaQv6o6JLpzKYNgFt3NKJHKc16rJ3/l8TRw+WwKYBYGEPhTSVdDThgTQmpNk6fND Y5ttXWUaIxoS3JRvJvM9llAkch97y/so70qStmQYVVooye7zn/16E5KpdfQKmw6B96Ee QjgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786265733; x=1786870533; h=content-transfer-encoding:mime-version:references:in-reply-to :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=Im1M3BLw7bmxcZcAK4CCU6quas0ztWTFGLp+A3NEnA0=; b=k2STYA8qvfexqiN4bCBdibYAb7T478d7BzB7mzRx1xpjzXXJq9ZKI06/3HQCQNCdCO 2TMrbl7k7wbAODE5OOvFi6RmnCDNZpiksLqKpY5ULy09pnh0AFrSuBMELyNYBlA9YsM8 A629gItKzs42MyEdRa8qLiO2FuRjYmCQxu1NBocvVXIpukcEWk+dudmdRqptD5474hq0 XDwFOGoywWVxPGJKupMJrReCjUbS40d4ukQqRXdQRnrvbUwZ+vQy/zTle8hI+02Kn7zs mKjnsVeWqJSJQ7Ckg/YpVMa7o70AtTzhPwoDcilJxBV9qrX6p8UUQw1Ha0KJXg9o4xTF o9eQ== X-Forwarded-Encrypted: i=1; AHgh+RqfBNiywsZ5tqzz0VjUTtJH+ZbbJixMK38/nVzuT7oG+UJwN1MrQGUfI68ZfIp0ZXk3drmO5knXExZixog=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1x1cxBELnNewcZxZvY/pHgp1ozb3tSV0gQ4a/923UtuxeUy7F MJGQhnl8AvnfDWfLw/IqjGl5N1/yVVQw8EYIAhMam7Y9SqJqYz2fCq7t X-Gm-Gg: AR+sD11ZgIoI1po5Vm79PRAmIMyru18un9Czs9GQPmO5IaSrBTxpBDjOnHhOG606jIh WINzA8RBT31Lh7jC95T1PBcuxMFrOJssvYoLxVuKoqRZROrlKS5DjoIMtVvLFTAkcL0pM1W31IB 6/0b6iylLZJbGbEUpsmAAeFzCtsxmWCmle0W5RA5P4kKx5BxSL+lvXrZQznzD5HGmbtWdc/5dfB KdYQpKs02AjJtHslShTzHAZTusHDW1Sn2+DpQlBOjQUtg070VYcDtXwEzx5AQo32dn+D/ZJ4t7+ QSOwshEjZmAsuivU2VIOmHZgCIV1J5sph61h/PlPYPKb9fa8HpBtls2kD2oiRbL/ObFGqd6wHFy lGHweXrSl+9PqH5QytGJwM7P8Ebf4Fm6WGyuHHwk9QSpxH8p4P2sM2VXmwFjgIwGJBNKWYRsPA3 firAAsC76NdUYM4bM1cjxPBeYgxb38guuAlrdXouqRzePGd6DJ4KJR5OVGv6MTDCETqnDql/7r8 66FRrd4hyRtzEXe42DNa0qjWfknhng= X-Received: by 2002:a05:6402:44da:b0:69e:14ab:5966 with SMTP id 4fb4d7f45d1cf-6a1f4e32f44mr3820453a12.8.1786265733291; Sun, 09 Aug 2026 01:55:33 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a1f630a4afsm1606681a12.3.2026.08.09.01.55.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2026 01:55:32 -0700 (PDT) From: Magnus Lindholm To: richard.henderson@linaro.org, mattst88@gmail.com, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org Cc: glaubitz@physik.fu-berlin.de, mcree@orcon.net.nz, ink@unseen.parts, macro@orcam.me.uk, Magnus Lindholm Subject: [PATCH 5/6] alpha: invalidate the local context in flush_tlb_mm() Date: Sun, 9 Aug 2026 10:49:37 +0200 Message-ID: <20260809085208.3262799-6-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260809085208.3262799-1-linmag7@gmail.com> References: <20260809085208.3262799-1-linmag7@gmail.com> 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" The SMP flush_tlb_mm() only touches the calling CPU when the mm is its active_mm: if (mm =3D=3D current->active_mm) { flush_tlb_current(mm); ... } smp_call_function(ipi_flush_tlb_mm, mm, 1); If it is not, nothing happens locally at all: smp_call_function() does not call back into the caller. mm->context[cpu] is left valid, so this CPU may later reuse the old ASN, and any translations it still holds for MM stay usable. Callers reach this regularly - counting the branch gave 2934 such calls over a fork-heavy workload and 632 while otherwise idle. Add the missing else. The UP implementation in asm/tlbflush.h already has exactly this shape: if (mm =3D=3D current->active_mm) flush_tlb_current(mm); else flush_tlb_other(mm); Unlike flush_tlb_page(), the active_mm test itself is valid here: flush_tlb_current() calls __load_new_mm_context(), which allocates and loads a fresh context rather than relying on a targeted tbi() to operate on whatever ASN happened to be loaded beforehand. Signed-off-by: Magnus Lindholm --- arch/alpha/kernel/smp.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c index d167b3ba1303..f501a91001cc 100644 --- a/arch/alpha/kernel/smp.c +++ b/arch/alpha/kernel/smp.c @@ -649,6 +649,13 @@ flush_tlb_mm(struct mm_struct *mm) preempt_enable(); return; } + } else { + /* + * smp_call_function() below does not call back into this + * CPU, so this is the only chance to retire what it holds + * for MM. The UP implementation already does this. + */ + flush_tlb_other(mm); } =20 smp_call_function(ipi_flush_tlb_mm, mm, 1); --=20 2.53.0 From nobody Wed Sep 30 12:08:25 2026 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (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 4A19D3B5319 for ; Sun, 9 Aug 2026 08:55:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265743; cv=none; b=the8p7tyPqHcoEfxUeVrRnyuXXLyuoSuRmnDmV6zp3CpRe8pvu+8tmSePNVBMdArjkwOXZxSk/SCA4dG0LugnFGVLJ+EUnvzHIh+XHS427BkYW2FSUt2bUCR2OC3QFzLGCLfrTKjotMgrKs7B3CtczHw86czg7vFhS5amYXYIjY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265743; c=relaxed/simple; bh=jNdVta5xUXSTjnpylN4yxJ+wUC0ZRwFWI3FqxiileXU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MAfOkThj3xRJ0F/UfoBwm04npc8pD3l0++ps9HXWj6ASPSRkJVOUVX8Ed9OvyoK4Wyik90x9nkXg3KG8y1yk1wx/O6KLBiJ9bVVE/4bNNZLWZzjRUcKo7vS1SYyCzzLRbV45Q93wdR4A2obxnX2Ev1TstNA1gTz9oBRVyzRipPs= 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=dNJgQH49; arc=none smtp.client-ip=209.85.208.48 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="dNJgQH49" Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-6a205b0df35so424189a12.1 for ; Sun, 09 Aug 2026 01:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786265734; x=1786870534; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4JHbNy7t36m8QFac0Mb9Mig7FuHxoP3xq252YSUXqrc=; b=dNJgQH49l6zbKr9imy/1OjgiiDsdZZY1E5GhanIdp0IWxmjWJ4fkNiJJylr8W7r7sY SenOYRGaGn6tFgEFINSycr36O9giQx9PFwrTXrBVIzV9+bvYVhlboSTS5YgKxhx7dkXO 8gj5xZEg24GTLBP51E2JVYGPb3utVR6M0yL09igzyeGWgUyeGkmfCTQX+iIUWE+aRDVj 7sJTRvZVCjT9w43qcmqtvLq4M7STuK3XZMefF38+Hw515VKpYfaRJFKinbUZEIxczZ2Y zuYOUm/ogSSKAd2c6LXLgGARwk1/IMIOMgQyIilyWNDCIWBzwfZMZ3JvWW5T3o7DrOob uIkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786265734; x=1786870534; h=content-transfer-encoding:mime-version:references:in-reply-to :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=4JHbNy7t36m8QFac0Mb9Mig7FuHxoP3xq252YSUXqrc=; b=FslF0crHOsgnR0FQXnurn3AqNw/2on26PGoKig95Szjqx4biAvJNdw8lPbhAQ2cW44 NFVSlnWNHeD37NVVWhVa8b4dfNrYJR4JRX79gX1RcHPfR8hUzUFfj8p+PamasRgaDNdh tzSq5oETLkQIl3Lh/tz3XiG5TF0785w7orDa2K4FOUBEKLWkkW9C6z7xMNBFW+KTo+Zc rPLmOguWDAkofezZZUr8p0xxiyaKvHUGvg/DCucj8Yzh3YCxKuf2CyJCnNhoMpuwMGrQ +U57Jjl/dXhVwy5Ig5FQUUUbLmwk/lhav4eqrsCUaCmBcxdxdQ9/7BFIYFiZKcc/mJas 6Z2w== X-Forwarded-Encrypted: i=1; AHgh+RqDJyzqYHH1QW+wmsMmvocVNeiAmAFv7n2bdx1fkUec7xCAbkBw7st9alODmXjo6bckxBs24rQknTcJw98=@vger.kernel.org X-Gm-Message-State: AOJu0Yzf/u8XusjxnMsp9e86BZVP5f/ub6HbGXDd3mmXhN/6HN6T2Ec2 d99H1DQUcaCEechfTlW7DV2KzP64IpDvf5f+H6WzrtXjtJxPZXYaqXx3 X-Gm-Gg: AR+sD13V+oAe5A5ALZrmsnxmiX2cqYd/lyvCRtFpd/q//bERGSQGgPkxOjMht9JFoQo AbCRrTVEzvD8YGDv/xS6Bfa6nuGAE3IVqTEzgEtSo+06qkqYz5YoqopbzkFAO1RYvL1kER3rjLz zPiQDvLptbPVoNpTYbzEz9JuJkA8MfQpmD+G57ZP1fL8uW7VeM+8C8PZjNXbx13WIEl1KwCTIDW 9nECAAYyvNmvlM9+t/Zk9uqs8JLIt6Qtbg8KYasrrTRjMw2jNSXKdytVtdH0Y4Ns3YIif51gISN jdxvyQAhwKIq54Y0lVaHcx0/X0mwVzlp1OBTY16YKj48oblSIwlNd1P/YDZeSD8HT1/JxFI/WQ/ PMq5czuTc8NLVQu0OJ+3Vr9hEj0VoYZI69xYKkIjBp5ZF+CDyUHHelaGYo9gF3oEikmewlViiCQ axSiWScTVWePHjDwnS9q664K6h0ujOURGDW8310YaVW9suE7+2mnnwBKIPL+70sbos8I8vCR9U2 ZitXdVJasvd+MsSxbR4CYz82/ka2+I= X-Received: by 2002:a05:6402:2344:b0:6a0:c763:89e5 with SMTP id 4fb4d7f45d1cf-6a14f2576f8mr16999516a12.19.1786265734380; Sun, 09 Aug 2026 01:55:34 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a1f630a4afsm1606681a12.3.2026.08.09.01.55.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2026 01:55:34 -0700 (PDT) From: Magnus Lindholm To: richard.henderson@linaro.org, mattst88@gmail.com, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org Cc: glaubitz@physik.fu-berlin.de, mcree@orcon.net.nz, ink@unseen.parts, macro@orcam.me.uk, Magnus Lindholm Subject: [PATCH 6/6] alpha: invalidate the local context in flush_icache_user_page() Date: Sun, 9 Aug 2026 10:49:38 +0200 Message-ID: <20260809085208.3262799-7-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260809085208.3262799-1-linmag7@gmail.com> References: <20260809085208.3262799-1-linmag7@gmail.com> 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" flush_icache_user_page() has the same caller-CPU omission that the previous patch fixed in flush_tlb_mm(): if (mm =3D=3D current->active_mm) { __load_new_mm_context(mm); ... } smp_call_function(ipi_flush_icache_page, mm, 1); When the target mm is not the calling CPU's active_mm nothing happens locally, and smp_call_function() handles only the other CPUs, so this CPU may later reuse the old ASN together with the translations it still holds. This matters here in particular because the function exists for operating on another process's mappings: the comment above it describes setting breakpoints through ptrace, and access_remote_vm() reaches it through copy_to_user_page(). The calling CPU is therefore often running something other than the target mm. As in flush_tlb_mm(), the UP implementation in asm/cacheflush.h already has the missing case: if (current->active_mm =3D=3D mm) __load_new_mm_context(mm); else mm->context[smp_processor_id()] =3D 0; Signed-off-by: Magnus Lindholm --- arch/alpha/kernel/smp.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c index f501a91001cc..13b86f7224de 100644 --- a/arch/alpha/kernel/smp.c +++ b/arch/alpha/kernel/smp.c @@ -780,6 +780,13 @@ flush_icache_user_page(struct vm_area_struct *vma, str= uct page *page, preempt_enable(); return; } + } else { + /* + * As in flush_tlb_mm(): smp_call_function() does not call + * back into this CPU, and this function is used precisely + * when operating on another process's mappings. + */ + flush_tlb_other(mm); } =20 smp_call_function(ipi_flush_icache_page, mm, 1); --=20 2.53.0