Re: [PATCH v2] arm: lpae: fix non-atomic page table entry update issue

[Wang YanQing]

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!