linux-kernel - Should vmap() work on pages or folios?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <ZUOcb1YwUEDT/r3K@casper.infradead.org>
Date:   Thu, 2 Nov 2023 12:56:15 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Should vmap() work on pages or folios?

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?