From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 200EA19DFAB for ; Sun, 15 Mar 2026 01:12:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773537156; cv=none; b=Uv5ZZAVJ34dW7roqgNXc/cS2hZeQu04u956Z3oDI3NwltEjFtmH4lzrWIW8NEQrobyMweNxkHcWQg5ZxvEmc5v24A8vpjO7PKeL6++DAO08uHqaNctlttlKVbj37BhX0CZ0j3Bm/HBUdHKNadUWZvD7i2bjNuskjOrE9j1u01ro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773537156; c=relaxed/simple; bh=mlEKgICe1um+XmAHkHfZ1+uXUKhR5t7GbvUi5Jy/Ni4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K3K11VVAFBWVicR8xlNExCdwqsQpq6yaN3lx6K/4JJb9JG1dw3b72I4iOPk1sThbdeoVgkbIL1MV3i0F+w7Ds0QZl0ZQrxZ9ntuHS5Sq2h1zg575SMrn9iZ8WymX5icisGxBmKwGJGCxHUaPrC9hjVJTPNznhFpswONs5lorGZE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=pjpnLmDa; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="pjpnLmDa" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NHWtqktMIOo37em4YwD/PDiKJfQIMjgsRq+RsF1wqo0=; b=pjpnLmDaHgJQs+YRKwonoExL6j sVcUb7sEYxqnRh08TRhYvmzIaUCQMKmdkgkDGizDEnt+kultOucqwELPOR/Jl1j3RVYBCN+pJdu5M eNwfNp/GaBzchZI0OGZXtayHwmWUMtq+kTtfT/5chHWmYYqcCkYpTylSTm2rYB+SZZYB2GN/Ffn92 TbiGfLo+wzno5FT3bzD2BegeHyAVDTx8vveT9SI40cKUxYQKs6lvOC17pkJZuaD9ZGikhxxttc1WI PNkElmsGyVvJlHlsuWFpCKF0aaxN5C5dNR8UBkdP7ZgOe6aBjmks9s5HVCilYDpYgzeEcmk/SH0dt +kzkpu9g==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:41320) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w1a1u-000000002YB-1xTA; Sun, 15 Mar 2026 01:12:30 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1w1a1s-000000001Ic-3W1n; Sun, 15 Mar 2026 01:12:28 +0000 Date: Sun, 15 Mar 2026 01:12:28 +0000 From: "Russell King (Oracle)" To: Wang YanQing 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: 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: <20260315004746.GA32062@udknight> Sender: Russell King (Oracle) 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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!