Re: [PATCH 2/6] ARM: move vmalloc() lazy-page table population

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Mar 02, 2026 at 12:00:55PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-03-02 10:57:03 [+0000], Russell King (Oracle) wrote:
> > > > --- a/arch/arm/mm/fault.c
> > > > +++ b/arch/arm/mm/fault.c
> > > > @@ -261,6 +261,70 @@ static inline bool ttbr0_usermode_access_allowed(struct pt_regs *regs)
> > > >  }
> > > >  #endif
> > > >  
> > > > +/*
> > > > + * Handle a vmalloc fault, copying the non-leaf page table entries from
> > > > + * init_mm.pgd. Any kernel context can trigger this, so we must not sleep
> > > > + * or enable interrupts. Having two CPUs execute this for the same page is
> > > 
> > > "unconditionally enable interrupts."? It wouldn't be wrong to enable
> > > them if the calling context had them enabled, right?
> > 
> > I don't know where you got "unconditionally enable interrupts" from the
> > comment - it says the exact opposite.
> 
> My point. You could enable the interrupts if the parent context had them
> enabled. It is not that you must keep them disabled because a second
> fault/ interrupt would overwrite your CPU state.

We've gone from the code always having interrupts disabled, to your
review response that always wants them to be enabled (which is what
*un*conditionally enable interrupts means) to now conditionally enable
interrupts.

We are reading the CPU's page table pointer (the one programmed in
hardware) here, and we don't want that changing while we're fixing
the fault. So, interrupts need to stay disabled. x86 doesn't enable
interrupts in this path either, and we shouldn't be having differing
behaviour without good reason.

There are two places where x86 enables interrupts in its fault
handling. One of them is while handling a user address fault in
do_user_addr_fault(). The other is __bad_area_nosemaphore() where we
also know that we've come from user mode. All other fault handling
happens with interrupts disabled.

In any case, we've always had interrupts disabled in this path. Any
change to that would need to be a separate patch.

So, the comment in the patch is 100% correct.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!