From mboxrd@z Thu Jan 1 00:00:00 1970 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: 8bit 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 = x; struct mm_struct * mm = data->mm; - if (mm == 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 == current->mm && !asn_locked()) flush_tlb_current_page(mm, data->vma, data->addr); else flush_tlb_other(mm); -- 2.53.0