[PATCH v6 19/26] proc/task_mmu: Mark devdax and fsdax pages as always unpinned

[Alistair Popple]

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
>