From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) (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 61F7739A809 for ; Sun, 24 May 2026 15:42:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779637366; cv=none; b=uynGDHEhyTIFpqDZCgQ3jVsJz8DR07lx/XlKbb9407ZjGX/WMILD9Oo9CTCq1hzBM6HdPX4e/uUqafGZFFcucxY3B3QWAfdLqgsBQFv9VSNX5lqxFQKPSP4kWqEzNYeHlQzcc9StRogfhWhk/W9iNgS6kMF449OfD2IyJTv83Yo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779637366; c=relaxed/simple; bh=T1EHQq6Q+iPHBDBi5QW7SmR5JtCFbl3lZPW99ikp4kQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aAih5ri9QsxXjmiAxaY8fzC2KyxqWhe14c75oN4tbuwhf8fIDqkdUaORIRTK8vdjBPX3hmj7pc33mBRRgv2isU1NT1hRCeyylMNmxbbEgx8S0V2bMfSW+0mDqdPGB6AHbXo/powbE2JWuTwpvcoFATr5DHtgoBEEF9JRCrs8f2I= 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=fxav4Bth; arc=none smtp.client-ip=209.85.216.45 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="fxav4Bth" Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-367cbac9c37so5079033a91.2 for ; Sun, 24 May 2026 08:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779637365; x=1780242165; 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=LM3LpCBe1/njTqEFIo5zYNSwmDEp0EgGwQLLh4EuYBI=; b=fxav4BthOMkdt+ZYssBYsKzXNCtL4tBNeT+qkPOg4IGdYDbWUY4DYLWF8f6u6DZwTs jPHJNpsBkOilptlfz46ikGfcijcY2jMYTIy3fuBzQtvRWziaUOQQR5WxUbanBcuD5dTU vPkA46KNDR9wfRjiOH0iVVozvy0fBcrQneFDdsmuJXGUHi4XrzQWZK+WyX40HFGA7Y6q lT0m0uOmM3LdApQ5przHosdl0jVi5zPz05BLa4cN2sMag1tj59VJY5+KkzlQBLKEVPSe bHDX82LeniEAKKhTdiKZyCN9Ba+uYVqy7NwW4qNqCkHIdQwGrVQ9ElwXP7ozIBoZqt7m tgqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779637365; x=1780242165; 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=LM3LpCBe1/njTqEFIo5zYNSwmDEp0EgGwQLLh4EuYBI=; b=bezL/5ByKetaB5AQ7mY2Qw2ug2V7MKKrh1Eel1m2J1F0VnHAa5dFDkpSYcylAkeZU0 vAaacIKkDS/+ITiUqDOwS0dF0gFR6f7qLnCFkdYNty76xMVQncukQNE/2cGUV1Levrtb 3iM2R4vIPzkAYZGXxXWIg41WZmj0lcOKEg5ehPj0poetAGJ2/S+XVSPlODQNlYcfDzCW i2gmTd+XQ8WO5piZlQ5vXLyokyOs++EpuWZYn2A1adveRbvR8a1aKv+Mw9hXosMr561i Fan4gx887H1bENyXh6ouPczSMJRW+5MurPhICHN0m5G1buarDs4f7uVkEj5cBW8zy7GC CjZw== X-Forwarded-Encrypted: i=1; AFNElJ+2JUYU8V4xol0tx6oksuC/+fwS2HSa8EgRWDPPCyconcA8HpeSaNFB4LKeXOJxK/ZkKdOQQEudHaG23FU=@vger.kernel.org X-Gm-Message-State: AOJu0Yzy19/xyes8zOmIxyODXqQBHloDD31j0vJ31fR3t25Dg2bz0jZ8 bFYdCVwtNquHD5N9MPSwwGJ1kQgCCeyQ9AiS+XmHxG5y9w1Tyc8b5guj X-Gm-Gg: Acq92OEXZNAVlf1THN4YSF+czkSU2w73KRp17/LVJk/q5XkZvfKZymdYn0HVUIGaUzE RkTaycQvAW35fpI/5tjNlPis2y8dHqB5HJ/Mlhr+NtDwFOgVtx7g78IHJ7LNF7A7Ekx1FY5RC+X yw0g+vR2A15s0DnQHaV1JCi8VjCr4ONgj+PSXjAcv6VtWw3oa8zCjfT2Cx7oDC1c4fNcHmi/8Ss W1br3uEh4o8ETD/n2g5qBFPWgGb0FWyPB/x6kT12VFl6kqSiNVJi0skkjSo9EHNY3SiIHt28fif Oa0rlVdEOIEL4YvWwnMKJX32pNFqzs282ghkUdpJLcTg6IqsmQa8Fi+XKvV1ehqGPXg4Tg6zoy7 b6ZCJjqDb8pxlpm4ouwYsn/6vMqj1sZ6agTkRevzBZE7lgpzKRmkvXJqiaLtR5pydNuhNyXqI/0 flxX6W94Pbk+tR3ElDlDFQHlTa5j59g6x/Qa8NAE0= X-Received: by 2002:a17:90b:4d0a:b0:368:f0a:1c48 with SMTP id 98e67ed59e1d1-36a671e2735mr10585390a91.0.1779637364483; Sun, 24 May 2026 08:42:44 -0700 (PDT) Received: from udknight.localhost ([120.36.203.36]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36a71d944c4sm6914751a91.1.2026.05.24.08.42.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 May 2026 08:42:43 -0700 (PDT) Received: from udknight.localhost (localhost [127.0.0.1]) by udknight.localhost (8.14.9/8.14.4) with ESMTP id 64OFUlMj008301; Sun, 24 May 2026 23:30:47 +0800 Received: (from root@localhost) by udknight.localhost (8.14.9/8.14.9/Submit) id 64OFUhEd008296; Sun, 24 May 2026 23:30:43 +0800 Date: Sun, 24 May 2026 23:30:43 +0800 From: Wang YanQing To: torvalds@linux-foundation.org Cc: "Russell King (Oracle)" , 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: <20260524153043.GB7031@udknight> Mail-Followup-To: Wang YanQing , torvalds@linux-foundation.org, "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> <20260503155432.GA18098@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: <20260503155432.GA18098@udknight> User-Agent: Mutt/1.7.1 (2016-10-04) On Sun, May 03, 2026 at 11:54:32PM +0800, Wang YanQing wrote: > 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 Hi Linus and all Non-atomic LPAE page table update issue on arm32 SOC that run linux kernel on hight address has caused strange mmu related problem, we meet strange unhandled prefetch abort issue due to the no-atomic update when we run arm32 linux on Sigmastar CA55 SoC that uses 0x10_0000_0000 as the start address of DRAM (We do the same thing as keystone SOC, use 0x2000_0000 as start address of dram, then switch to high address) I haven't get any respone from Russell King in last three months, the full history could be see at: https://lkml.org/lkml/2026/3/15/38, I don't know why. I think make the page table update become atomic is a proper solution for the problem according to ARM Architecture Reference Manual. Because the mainline tipcode still has the problem, so I want to try again to make this patch become merged, if someone don't like it, please tell me what is the better solution for mainline kernel. Thanks.