Re: [PATCH v3 5/6] drm/gem-shmem: Track folio accessed/dirty status in mmap

[Boris Brezillon <boris.brezillon@collabora.com>]

On Thu, 28 May 2026 11:22:46 +0200
Thomas Zimmermann <tzimmermann@suse.de> wrote:

> Hi
> 
> Am 28.05.26 um 11:11 schrieb Boris Brezillon:
> > On Thu, 28 May 2026 09:20:16 +0200
> > Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >  
> >> Hi
> >>
> >> Am 27.05.26 um 12:18 schrieb Boris Brezillon:
> >> [...]  
> >>>> -			return ret;
> >>>> +			return vmf_insert_pfn_pmd(vmf, pfn,
> >>>> +						  vmf->flags & FAULT_FLAG_WRITE);  
> >>> I believe we can go back to
> >>>
> >>> 			return vmf_insert_pfn_pmd(vmf, pfn, false);
> >>>
> >>> if the mappings are no longer adjusted to catch write accesses.  
> >> If we don't install it as writable now, won't the kernel not split it up
> >> into 4KiB pages when the actual write happens?  
> > It will be installed as writeable right away, regardless of the write
> > parameter, because if pfn_mkwrite is not implemented, vma->vm_page_prot
> > won't be lowered to read-only in the first place, or at least that's
> > what I remember from the previous debugging session I've done.  
> 
> In insert_pmd(), the write parameter controls whether we run 
> maybe_pmd_mkwrite(), which sets the __PAGE_RW flag.
> 
> https://elixir.bootlin.com/linux/v7.1-rc5/source/mm/huge_memory.c#L1632
> https://elixir.bootlin.com/linux/v7.1-rc5/source/mm/huge_memory.c#L1655


This is not where the RW|SHARED -> READ_ONLY lowering happens though. If
the write argument was the only way to get writeable hugepage mappings,
it wouldn't have worked before your pfn_mkwrite addition.

> 
> That's at least how I understand the logic here. Performance-wise it 
> might be beneficial if we track the write flags as before.

It was working fine before pfn_mkwrite was added: huge pages were
mapped as PMDs even when they were writable.