On Wed, Dec 02, 2020 at 11:08:54AM +0100, Christoph Hellwig wrote: > On Fri, Nov 20, 2020 at 04:01:33PM -0400, Jason Gunthorpe wrote: > > On Wed, Nov 11, 2020 at 03:38:42PM -0800, Ralph Campbell wrote: > > > > > MEMORY_DEVICE_GENERIC: > > > Struct pages are created in dev_dax_probe() and represent non-volatile memory. > > > The device can be mmap()'ed which calls dax_mmap() which sets > > > vma->vm_flags | VM_HUGEPAGE. > > > A CPU page fault will result in a PTE, PMD, or PUD sized page > > > (but not compound) to be inserted by vmf_insert_mixed() which will call either > > > insert_pfn() or insert_page(). > > > Neither insert_pfn() nor insert_page() increments the page reference > > > count. > > > > But why was this done? It seems very strange to put a pfn with a > > struct page into a VMA and then deliberately not take the refcount for > > the duration of that pfn being in the VMA? > > > > What prevents memunmap_pages() from progressing while VMAs still point > > at the memory? > > Agreed. Adding Roger who added MEMORY_DEVICE_GENERIC and the only > user. MEMORY_DEVICE_GENERIC is just a rename of the previous MEMORY_DEVICE_DEVDAX, and seems to be used by the DAX device apart from Xen? It's main purpose is to be able to allocate unused physical memory ranges and have a baking struct page for them, so they can be used to map foreign memory when running on Xen. I'm currently on leave and won't be back until the end of the month, could you please Cc the Xen maintainers if you modify the logic here in order to make sure it will work for Xen? Thanks, Roger.
