[PATCH v2 7/7] ARM: implement support for vmap'ed stacks

[Nicolas Pitre]

On Mon, 18 Oct 2021, Ard Biesheuvel wrote:

> On Mon, 18 Oct 2021 at 17:34, Nicolas Pitre <nico at fluxnic.net> wrote:
> >
> > On Mon, 18 Oct 2021, Ard Biesheuvel wrote:
> >
> > > +void arch_sync_kernel_mappings(unsigned long start, unsigned long end)
> > > +{
> > > +     if (start > VMALLOC_END || end < VMALLOC_START)
> > > +             return;
> > > +
> > > +     /*
> > > +      * This hooks into the core vmalloc code to receive notifications of
> > > +      * any PMD level changes that have been made to the kernel page tables.
> > > +      * This means it should only be triggered once for every MiB worth of
> > > +      * vmalloc space, given that we don't support huge vmalloc/vmap on ARM,
> > > +      * and that kernel PMD level table entries are rarely (if ever)
> > > +      * updated.
> > > +      *
> > > +      * This means that the counter is going to max out at ~250 for the
> > > +      * typical case. If it overflows, something entirely unexpected has
> > > +      * occurred so let's throw a warning if that happens.
> > > +      */
> > > +     WARN_ON(++init_mm.context.vmalloc_seq == UINT_MAX);
> >
> > I don't understand the logic here. Yes, changes are not that frequent
> > and this is pretty unlikely to ever wrap. But given an infinite run
> > time, it could wrap and that woule be OK.
> >
> 
> Each PMD entry covers 1 MB of space (assuming short descriptors), and
> is either invalid or points to a page table containing page entries
> for every 4k block in that 1 MB of space.
> 
> My reasoning was that, given that we don't have huge vmaps on ARM, and
> that we never free those lower level page tables once they are
> allocated and linked into the tree, the only transition such a PMD
> entry can make is from invalid to valid table entry.

We never free those? OK then.

> Did I miss anything?

Incidentally, that vmalloc_seq is my own creation, but that was a long 
long time ago. My memory is fading a bit.  ;-)


Nicolas