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
