From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (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 6B64A3594A for ; Sun, 15 Mar 2026 04:49:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773550162; cv=none; b=fmBDwpRFWpNVw/kiMvxilHj+1z7wGlMqbWw7kkYvItmx2juIeM3RreDJehx2TqYzqsOtby3eryn79Br26xRH/oP21eQf8DuCFUUNyn6SIrUtlMVmyEY1XcAqSU6eWK6K91ILHhclbkx1eOV1wpVvkiOdgbu+d0P0cRUGNpeYh0s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773550162; c=relaxed/simple; bh=aSqnTdkTIhJd5fGmFMhHMDkbOMjj6EBdrCBcEIfyUss=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=S7ygOotn9iSytBmBil1oLmpb1l7Hf2CKsRV8/ACVTOzn1ouLVcOU9Fdlkt4J4KNZ6odaZFg9EwckWLBrUmLzDK6mL/bXK20TBJ1aVKm2CVkS4H45DDWr7aMAELt0MLGHbuRXgIg/2fvmHdoy5o4y7P1JywWRg5Fclm1p1R3ExzE= 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=fUEh88bb; arc=none smtp.client-ip=209.85.215.176 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="fUEh88bb" Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-c7381c4345cso1426056a12.1 for ; Sat, 14 Mar 2026 21:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773550161; x=1774154961; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=sV9v+jPbtmnRcN75rXeHCeWgYNiYpovxidx9kjy7dAQ=; b=fUEh88bb8/P+JYCEFEhV5CaszPosg3e8iswWBUcRM9Hf0GdjXJhDoIic43xxXgev9H ym+9ICVdm5+CgwkagnS0H5eswk5m1YJQ3MLYlpjvLrZtRLzSWmJgLKDadr3WoVqwDYBT Ay+h80fFxknu7Iln2Qbh+y4vj2PvEJ271VGp5fcH2aeOHHOeM6leI1bLjNaD0HrEmkzQ RIRddGNTW/Eb1NBLzPOJMivkmTinT4nk0MjuVWvDgQV2y/Q/Mz9ejzq87gExlj+uhVt5 aDu9s0VOBy+b5IsS70wniF1fMaEekvyjkA7GfZEPB1AE9ai+4zN6jRL2aUkXZ2Cz4Wxa gIaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773550161; x=1774154961; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sV9v+jPbtmnRcN75rXeHCeWgYNiYpovxidx9kjy7dAQ=; b=g0avdp28NnBXD7+q2eXS7DXbvYGXPQ0IcUBHSy8LIeysQz6ubzvGH9ahGAwXGSjOEf qgVnZWKGuZD7DKySCwyPpDra31oLXwJjz3nMCYRA90h8c4RJIrQMLmBdzYM0RJ1ZrpSD rLshXkND1uzpi9sjZ/QGbXajQC6GlLfPS6sVvDIAYrmoIDAcBF6fkwBQntxeVVKCQvmZ A34HW0Ovh+JTH0Fk2MbF1F7jUR8lixTNl7STaEmNYaqP1jEhl3Jp9XmHuqlOu/fnXypP rttMmFywcr9vxYerFebZH/Rbzn2kSxPpcDc08ENNpGCpGsgYks1mg6nVTCtlGnaDuaTe nF7Q== X-Forwarded-Encrypted: i=1; AJvYcCUngNVZe3UzQN8ejltX+WbnRsphFaHcgF7z6rDCAngoQT/U36889Xg0GK1cwAwgGtgLCFKjTMCmjnX3rQ0=@vger.kernel.org X-Gm-Message-State: AOJu0YwynRb3JHKCXB5hAUxBJQ4BaUfRj/s5KJIVQujUsWNb/mGWgAYD C+nx2e33gVojhKb5c/XfWp3/KLIsEU0t2iHBtve9ivEoacQeI3IqUQ4L X-Gm-Gg: ATEYQzxCai/ko7TDEEBVw75eE21+eKU6zAaNSm/CGMlVnhYvQ5MzGlJVFX6buyBV74e xKxnAiKJ9JS2WWZtSa6P0Yw2LFgsTG+mH2ShTor8FtC2FpHcK5ioV4XyOH84bl+E+niYj/rjHhl x0mV7Ef3TGjGcr1ZGQ1VPHX7t0sicr68zmcanBEkCoKVjgFvUsESiE1O865fEtCz2T/9O7TKOTc 0maR9HRl8ycAYJZEEU3nqbdwbEFd7RQIHJwSUcB7m+4yDEdHtGkMZxwAnwsoheDTR3nhxM/NV+J 5HOrqDiGI3ywNp6fVofp1nFpavjomxye/v4eDfIPHm2jA9tRxyrM8J5eJAMMC/Po7EJqc9QaWxS vovCBLm7kZwqoPRd+dUhCGBQwYeeQb0uL9YR8Dhb7IVwNav1SRMFYZPfJIOfUqBPKTFywwpGPlC GwoysI5LmAh3sNxO48TqrJBPYBqQ0+q4DPHRKubWWC X-Received: by 2002:a05:6a20:3d86:b0:394:4d99:ff56 with SMTP id adf61e73a8af0-398eb0195a1mr8085594637.11.1773550160737; Sat, 14 Mar 2026 21:49:20 -0700 (PDT) Received: from udknight.localhost ([120.36.202.188]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c73eb97b41dsm5538237a12.5.2026.03.14.21.49.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2026 21:49:20 -0700 (PDT) Received: from udknight.localhost (localhost [127.0.0.1]) by udknight.localhost (8.14.9/8.14.4) with ESMTP id 62F3Tuap007594; Sun, 15 Mar 2026 11:29:56 +0800 Received: (from root@localhost) by udknight.localhost (8.14.9/8.14.9/Submit) id 62F3Tos6007591; Sun, 15 Mar 2026 11:29:50 +0800 Date: Sun, 15 Mar 2026 11:29:50 +0800 From: Wang YanQing To: "Russell King (Oracle)" Cc: akpm@linux-foundation.org, willy@infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] arm: lpae: fix non-atomic page table entry update issue Message-ID: <20260315032950.GA5618@udknight> Mail-Followup-To: Wang YanQing , "Russell King (Oracle)" , akpm@linux-foundation.org, willy@infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260315004746.GA32062@udknight> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Hi! Russell On Sun, Mar 15, 2026 at 01:12:28AM +0000, Russell King (Oracle) wrote: > On Sun, Mar 15, 2026 at 08:47:46AM +0800, Wang YanQing wrote: > Thanks. Now, please locate where the need for the updates to the page > tables needs to be done atomically, bearing in mind that we program > SCTLR.AFE=1 and SCTLR.HA=0, meaning the hardware won't write-back to > the page tables to e.g. update the access flag. When LPAE is enabled and in the 3G/1G userspace & kernel space config, we use ttbr0 for address space 0-3G, and use ttbr1 for top 1G kernel space, but wait a moment, the module space is in ttbr0 instead of ttbr1, because module space is belong to 0-3G. Then we don't switch ttbr0 to the same value as ttbr1 in task switch, so when we switch from normal userspace thread to kernel thread, we use the do_translation_fault() to fault in the module space for the kernel thread when it accesses the module space. Now please think a situation that userspace repeats create new short-lived processes (run shell cmds, etc), we will use do_translation_fault() to fault in the PMD entries repeatly when switch from new created process to running kernel thread, we need to update pmd entry automatically here, hw is allowed to do data/instruction preload and trigger page table walker to see the partial update pmd entry, page table walker will cache it, and it will cause translation fault, because it doesn't see the upper 32-bit. When the userspace process is a multi-threads process, in smp environment, other cpus could use the same pgd for their according kernel thread, all the page table walker of the smp cpus have the chance to cache the partial update entry. Thanks > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!