From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (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 D898A38C2D7 for ; Sun, 3 May 2026 15:57:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777823845; cv=none; b=UivHUZhcXRIWp41iMQkala+aLmFjWa1NxSh6Hxr8DA1qfIxgLoUlB9Dtt9Dj5ViKJXjnSnAeNeGKp26fcDf0rMVClzj+BncfuRC8L9Up01iEco/LsLvI/Fg2d2BD5Ez4NuPTp8ozdZmEkbut6N+hPM5gg2e9j2KIjGgxBxJHMxI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777823845; c=relaxed/simple; bh=1JC4eNoBiZNv+hDljTU8vpNWdVGJsZCRYlKhZ03DNaA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mcSMDOSv3XjZ9fW2dZ3S5XxS2PHwxNhDoIekAO8k8DSR7q0Eb1VQGvcJ6dH7hA8A/bLs1W8gmwdk8t+nUtkJ8ytkjGLKKx1WjQ8ph6xYacM84qMpr918BW72SHpwB2kWwGNMZzmByuJuRRlonkURlZEVEkenubfJxjuYxUo2WAU= 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=oomaeZtm; arc=none smtp.client-ip=209.85.210.181 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="oomaeZtm" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-837c09d2268so4830b3a.0 for ; Sun, 03 May 2026 08:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777823843; x=1778428643; 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=3Dekv3tI4SAkRrEMgiD3ZmjSX8tBUo5iiLFe1Kp62is=; b=oomaeZtmNpY1smiglj+0ak+Tw0o/u34q/pOTJA9wJk1olN3T6i9xrlRBcqyqRPLFVl gtxKe1wgkYuc4qdf3YTv1dnicITq6VLqzPf8e2XbcWQYePcQX8fowa39WmMo6xrqjxHT qVv93c7wkUv0MK4e4Zfo1P+WXDDxoWiySW9HqZVV94lJ8/FQrztJpbWjHMI9BCS6O72e +4EB5Mwr0ir64CBHJxlV6aWmATBD02ercQllQI/KtJiZt+NYsA+i6aiPhKbcbChfPZ1u x1aN11jVfGnGpM6FBd+05pZRz89U3QF/TnL5SC5O3piEKOH/wLu/HdS3vnH29gxJG+SF hxdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777823843; x=1778428643; 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=3Dekv3tI4SAkRrEMgiD3ZmjSX8tBUo5iiLFe1Kp62is=; b=N7FLHTmFQs5RKvtEcPo0GUrGyeGzcfRq3kWN9SPAaGKxDKfaxvVsmWwDV3GJTgNHUm Wql7d0fIVBqyek4TcWpTPT7Xh6CCzfFParZ+Ygf70/0lzLXWZgZ5wCnFPGLIzK5Pqzio +0QXrvlQTjVFeZTq5Ch/DL7sVvSCWOa4iO/gRx1DrOoblIb/AyzcgeV+NUJtSpwAYPBY J1EbPt8DNozHd+HgwLqTcQ7LeCWuzrTdbvUvT0eTTpclP83XcHfVbkScp0+2gMN++YDV 71n/1QUZUL7xZaQDFyPhRLb6Z0Xq4O/7SAFv/nkryE7tQT4zZ8Iu0OmA2nMC6yfWDvkA wDaQ== X-Forwarded-Encrypted: i=1; AFNElJ9BDkPvM5zhsbmWV0av4nEjyb8bgrYZ5WoUlNcv0NTfYX6e5lvSqLi10L9OBuB1AXHdoulOfI56RFpWaZE=@vger.kernel.org X-Gm-Message-State: AOJu0YxtvZHUolYNKNZFa+QVgh46LCPiUT0bsK+MSLrreMw98UaCqJZ9 yzGWpwsU9XATZOBGiW6z3kdGWhP69L8/wW3A2W0R+gtT9/FTfVf4HwqQIxtAmexQnCA= X-Gm-Gg: AeBDieuZNqOnxbT8o2eg0PBjdpkQxPKPR+mi8ueaCLJ17vyhM7P9LzTBFC67TYuEbK9 C8YnQqnOQ+l9qEqWjOvNsXNbj8eM/yHvEvj9iH8EwlFufgmJX0e9zJPD/CqGpP3aQRUBKxPTI84 fEvaJRTRiL69gCz7rgGX2vU68nyTfzTJh8VzIkWzknjQvWG0fPb3CAt2c308kkvfPl/L1ra1pRx 1H527onTfVQeRDoN5w7Rh4iWoYdbaCyFb2y1HAl182e6WaK7eJEaUh5UF+13F6nqCBiqx6ZzSGQ E0GlkbNtnT0KxsTf5M+VlNcaeobt6O4dv/oso8ahvWGsE1CUmuoKqRNNEQOuEpwMFpX7m27DnBn jdltQ0CmwlJuupJCTF+gxEAhatMHgqjHOz6rbVVUfBh3rJeCF80UhsLUG6xpE+onIrN88kbuw7Q ruZg7u2uVSu5dHzMKIh4qBYKYxAyyQAi0tmNM0pLO5r7PmSSwXsw== X-Received: by 2002:a05:6a00:4c15:b0:82a:6852:559e with SMTP id d2e1a72fcca58-8352d1f7175mr5950625b3a.12.1777823842767; Sun, 03 May 2026 08:57:22 -0700 (PDT) Received: from udknight.localhost ([110.87.76.109]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-835158a26d3sm8671335b3a.19.2026.05.03.08.57.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2026 08:57:21 -0700 (PDT) Received: from udknight.localhost (localhost [127.0.0.1]) by udknight.localhost (8.14.9/8.14.4) with ESMTP id 643Fsddo019172; Sun, 3 May 2026 23:54:40 +0800 Received: (from root@localhost) by udknight.localhost (8.14.9/8.14.9/Submit) id 643FsY8J019166; Sun, 3 May 2026 23:54:35 +0800 Date: Sun, 3 May 2026 23:54:34 +0800 From: Wang YanQing To: "Russell King (Oracle)" Cc: akpm@linux-foundation.org, willy@infradead.org, torvalds@linux-foundation.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: <20260503155432.GA18098@udknight> Mail-Followup-To: Wang YanQing , "Russell King (Oracle)" , akpm@linux-foundation.org, willy@infradead.org, torvalds@linux-foundation.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) 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: > > The ARM Architecture Reference Manual explicitly dictates that writes of 64-bit > > translation table descriptors must be single-copy atomic: > > ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition (https://developer.arm.com/documentation/ddi0406/latest) > > " > > ... > > A3.5.3 Atomicity in the ARM architecture > > ... > > In an implementation that includes the Large Physical Address Extension, LDRD, and STRD accesses to 64-bit aligned > > locations are 64-bit single-copy atomic as seen by translation table walks and accesses to translation tables. > > Note > > The Large Physical Address Extension adds this requirement to avoid the need for complex measures to avoid > > atomicity issues when changing translation table entries, without creating a requirement that all locations in the > > memory system are 64-bit single-copy atomic. > > 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. Dear Russell and all ARM Cortex-A cores (cortex-a7, cortex-a32, cortex-a55) all have "walk cache ram", according to cortex_a32_trm_100241_0100_00_en.pdf (https://documentation-service.arm.com/static/5e7dca43cbfe76649ba52835) " ... The walk cache RAM holds the result of a stage 1 translation up to but not including the last level ... " The walk cache ram will cache translation result of L1/L2 page table walk, so the non-atomic pmd entry update issue describe in the patch will cause partial updated 64-bit entry to be cached in the walk cache ram. On SoCs like TI keystone and Sigmastar SoCs which will run arm32 linux kernel on high address, the physical address of page table will be 64-bit and will meet the issue described in the patch. I think it is right to make page table entry update become atomic according to ARM Architecture Reference Manual. Thanks > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!