Re: [PATCH v3 21/26] mm/page_alloc: implement FREETYPE_UNMAPPED allocations

> > There are some functional requirements for flipping a block:
> >
> >  - Unmapping requires a TLB shootdown, meaning IRQs must be enabled.
> >
> >  - Updating the pagetables might require allocating a pagetable to break
> >    down a huge page. This would deadlock if the zone lock was held.
>
> We also need to zero unmapped/sensitive pages before mapping them again,
> but seems like the current approach is to differ this to the caller,
> which makes sense.

Correction: we don't defer this to the caller. We zero the pageblocks
when we switch from unmapped to mapped.

> The only annoying part is that
> want_init_on_{free/alloc}() now silently skip the zeroing for those
> pages.
>
> We should document somewhere that the users of ALLOC_UNMAPPED are
> responsible for zeroing memory before freeing it?

This is still true in a way. want_init_on_alloc() is always satisfied
with the current scheme, but it's not a documented requirement.
want_init_on_free() is ignored for unmapped pages AFAICT, at least
until they are converted to mapped pages (if ever).

[..]

> > +     if (want_mapped) {
> > +             /* Exposing formerly-protected data; scrub it. */
> > +             clear_highpages_kasan_tagged(page, nr_pageblocks << pageblock_order);
>
> Shouldn't all unmapped memory be zeroed on free? If we solidify this
> assumption we can probably drop this here (and maybe replace it with an
> assertion)?

Also wrong, I assumed that AS_NO_DIRECT_MAP always zero the memory on
free but that's only when ALLOC_UNMAPPED is *not* used, so yeah this
is needed.