[PATCH] Revert "mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge"

[Will Deacon]

On Mon, Jul 19, 2021 at 06:58:43PM +0200, Christophe Leroy wrote:
> Ard Biesheuvel <ardb at kernel.org> a écrit :
> > On Mon, 19 Jul 2021 at 17:45, Christophe Leroy
> > <christophe.leroy at csgroup.eu> wrote:
> > > Ard Biesheuvel <ardb at kernel.org> a écrit :
> > > > On Mon, 19 Jul 2021 at 15:58, Ard Biesheuvel <ardb at kernel.org> wrote:
> > > >> On Mon, 19 Jul 2021 at 12:49, Will Deacon <will at kernel.org> wrote:
> > > >> > For 4k pages with 3 levels of walk, we want to be able to use
> > > 1GB mappings
> > > >> > at level 1 (pgd), 2MB mappings at level 2 (pmd) as well as the usual 4k
> > > >> > page mappings at level 3 (pte).
> > > >> >
> > > >>
> > > >> Yes, we appear to use PUDs for 4k pages kernel regardless of whether
> > > >> they are folded into PGDs to refer to level 1/1GB block mappings.
> > > 
> > > And that's probably the source of the misunderstanding, because a 3
> > > level architecture is supposed to only have pgd, pmd and pud.
> > > 
> > 
> > Is this requirement documented somewhere? Having folded PUDs does not
> > necessarily mean that PUDs don't exist, but simply that PUDs and PGDs
> > are the same.
> 
> If you look at linux/pgtable.h you can see that p4d_set_huge and
> p4d_clear_huge are only for 5 level MMUs. Why shouldn't the same principle
> apply to PUD and PMD ?

Prior to your patch, you could make the opposite argument. Why are
p4x_{set_clear}_huge() guarded? Those were introduced after the others
as well.

Reverting looks easiest for now. Let's do that so we can figure this ou
properly without breaking mainline in the meantime. That also means you
can enjoy your holiday without looking at email on your phone!

Will