For various reasons, I started looking at converting vm_struct.pages
to be vm_struct.folios. But vmap() has me wondering because it
contains:
if (flags & VM_MAP_PUT_PAGES) {
area->pages = pages;
area->nr_pages = count;
}
In principle, then, we could call vmap() with an array of pages that
includes tail pages. However, I think if we do that today, things
will go badly wrong. You see, despite the name of the flag, we don't
actually call put_page(). Instead, we call __free_page() which calls
__free_pages(page, 0), which calls put_page_testzero(). Since tail
pages have a refcount of 0, it'll hit the VM_BUG_ON_PAGE().
>From this, I can conclude nobody does this today. But people might be
calling vmap() with tail pages and VM_MAP_PUT_PAGES _not_ set. And
it's not necessarily a stupid thing to want to stitch together some
tail pages (from different folios) into a virtually contiguous block.
I thibk the primary usecase is order-0 allocations being stuck together
into a virtually contiguous block, but I haven't audited every caller
of vmap.
So what's our intent here? Should we fix vmap() to actually work with
tail pages? Should we require vmap() to only work on order-0 pages?
