[PATCH 2/6] ARM: move vmalloc() lazy-page table population
Sebastian Andrzej Siewior
bigeasy at linutronix.de
Mon Mar 2 03:00:55 PST 2026
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.
> > > + * no problem, we'll just copy the same data twice.
> > > + *
> > > + * Returns false on failure.
> > > + */
> > > +static bool __kprobes __maybe_unused vmalloc_fault(unsigned long addr)
> >
> > Maybe handle_vmalloc_fault().
>
> x86:
>
> static noinline int vmalloc_fault(unsigned long address)
> {
> ...
>
> I prefer to keep the name the same.
Okay.
Sebastian
More information about the linux-arm-kernel
mailing list