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

[Wang YanQing]

On Sun, Mar 15, 2026 at 11:29:50AM +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: 
> > 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.
> 

Hi Russell King, what is the status about this patch?

On some SoC, Texas Instruments Keystone etc, it will run arm32 linux kernel on
high address (KEYSTONE_HIGH_PHYS_START = 0x800000000ULL), then all the physical
address of page table will be 64-bit and will meet the issue described in the
patch

Thanks