Mapping vmalloc pages to userspace

[Matthew Wilcox <willy@infradead.org>]

Today we have a very useful helper, remap_vmalloc_range() (and _partial())
which lets drivers call vmalloc(), then map that memory to userspace.
It does so using vm_insert_page() which ends up calling folio_get() and
folio_add_file_rmap_pte(), so jiggling both the refcount and the mapcount.

As you all know by now, we're looking to eliminate both mapcount and
refcount from struct page.  I have four options for consideration, some
of which I like more than others.

1. We could introduce a vmalloc memdesc that has a per-page mapcount and
refcount.  This seems like unnecessarily high overhead for a precision
of tracking that is, perhaps, not warranted.

2. We could do no tracking at all of vmalloc pages.  Insert the PFNs
of the allocated pages and rely on the driver to track everything
correctly, not freeing the vmalloc allocation until the mmap has been
torn down.  This implies not supporting GUP.  This option feels risky to
me; we're depending on device driver writers to get this right, and if
they get it wrong, it's quite the UAF hole; letting an attacker get
access to pages which could be allocated to any purpose.

3. Embed a refcount into struct vm_struct.  We can support GUP if we want.
Calling GUP bumps the refcount on the entire struct.  When the refcount
hits zero, we free the entire allocation.  There's no need for a mapcount
or pincount because we don't need to distinguish between temporary and
longterm gups.

4. Introduce an indirection structure between the page and vm_struct which
contains the refcount.


I'm most in favour of #3, but there's probably ramifications I haven't
considered.