On Thu, 28 May 2026 11:22:46 +0200 Thomas Zimmermann <[email protected]> wrote:
> Hi > > Am 28.05.26 um 11:11 schrieb Boris Brezillon: > > On Thu, 28 May 2026 09:20:16 +0200 > > Thomas Zimmermann <[email protected]> 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.
