Re: [LSF/MM/BPF TOPIC] MM: Mapcount Madness

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Jan 29, 2024 at 01:49:30PM +0000, Matthew Wilcox wrote:

> What do VM_PFNMAP and VM_MIXEDMAP really imply?  The documentation here
> is a little sparse.  And that's sad, because I think we expect device
> driver writers to use them, and without clear documentation of what
> they actually do, they're going to be misused.

In many common driver cases the vm_* core code does set them when
installing pfns into a VMA..

PFNMAP means every PTE in a VMA is pure physical address and there is
no struct page refcount connected. In many, but not all, cases there
is no struct page at all.

MIXEDMAP means some PTEs are struct-pageless and others are not, but
if it has a struct page the the struct page is used.

I've had the feeling this is primarily to support arches that lack the
"special" bit CONFIG_ARCH_HAS_PTE_SPECIAL (badly named, but it means
the PTE does not have a struct page) and these flags help trigger some
guessing to fix it up.

The clearest documentation I've seen is in vm_normal_page().

In the majority of cases drivers want PFNMAP. MIXEDMAP is the weird
thing.

IIRC drivers get forced into MIXMAP if they want to prepopulate a VMA
instead of using the fault path, which is unfortunate if drivers are
actually working 100% with struct page backed memory (eg why does
binder set mixedmap? Does it work with struct-page-less PFNs, where
would it even get them from?). 

I believe this is due to missing driver facing APIs not anything
fundamental. Although I seem to recall there was some race inside mmap
if you try to prepopulate during the vma mmap op.. With zap, I think.

Jason