On Tue, Jan 14, 2025 at 05:45:46PM +0100, David Hildenbrand wrote: > On 14.01.25 03:28, Dan Williams wrote: > > Alistair Popple wrote: > > > The procfs mmu files such as smaps and pagemap currently ignore devdax and > > > fsdax pages because these pages are considered special. A future change > > > will start treating these as normal pages, meaning they can be exposed via > > > smaps and pagemap. > > > > > > The only difference is that devdax and fsdax pages can never be pinned for > > > DMA via FOLL_LONGTERM, so add an explicit check in pte_is_pinned() to > > > reflect that. > > > > I don't understand this patch. > > > This whole pte_is_pinned() should likely be ripped out (and I have a patch > here to do that for a long time). Agreed. > But that's a different discussion. > > > > > pin_user_pages() is also used for Direct-I/O page pinning, so the > > comment about FOLL_LONGTERM is wrong, and I otherwise do not understand > > what goes wrong if the only pte_is_pinned() user correctly detects the > > pin state? > > Yes, this patch should likely just be dropped. Yeah, I think I was just being overly cautious about the change to vm_normal_page(). Agree this can be dropped. Looking at task_mmu.c there is one other user of vm_normal_page() - clear_refs_pte_range(). We will start clearing access/referenced bits on DAX PTEs there. But I think that's actually the right thing to do given we do currently clear them for PMD mapped DAX pages. > Even if folio_maybe_dma_pinned() == true because of "false positives", it > will behave just like other order-0 pages with false positives, and only > affect soft-dirty tracking ... which nobody should be caring about here at > all. > > We would always detect the PTE as soft-dirty because we we never > pte_wrprotect(old_pte) > > Yes, nobody should care. > > -- > Cheers, > > David / dhildenb >
