From mboxrd@z Thu Jan 1 00:00:00 1970 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: 8bit The uniprocessor flush_tlb_page() has the same defect the previous patch fixed for SMP: if (mm == 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/tlbflush.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 = vma->vm_mm; - if (mm == 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 == current->mm) flush_tlb_current_page(mm, vma, addr); else flush_tlb_other(mm); -- 2.53.0