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. > > I think just leaving the page reference count at one is better than trying > > to use the mmu_interval_notifier or changing vmf_insert_mixed() and > > invalidations of pfn_t_devmap(pfn) to adjust the page reference count. > > Why so? The entire point of getting struct page's for this stuff was > to be able to follow the struct page flow. I never did learn a reason > why there is devmap stuff all over the place in the page table code... Exactly.