On Fri, Jul 04, 2025 at 03:22:28PM +0200, David Hildenbrand wrote: > On 25.06.25 11:03, David Hildenbrand wrote: > > On 24.06.25 03:16, Alistair Popple wrote: > > > On Tue, Jun 17, 2025 at 05:43:38PM +0200, David Hildenbrand wrote: > > > > Let's convert to vmf_insert_folio_pmd(). > > > > > > > > In the unlikely case there is already something mapped, we'll now still > > > > call trace_dax_pmd_load_hole() and return VM_FAULT_NOPAGE. > > > > > > > > That should probably be fine, no need to add special cases for that. > > > > > > I'm not sure about that. Consider dax_iomap_pmd_fault() -> > > > dax_fault_iter() -> > > > dax_pmd_load_hole(). It calls split_huge_pmd() in response to > > > VM_FAULT_FALLBACK > > > which will no longer happen, what makes that ok? > > > > My reasoning was that this is the exact same behavior other > > vmf_insert_folio_pmd() users here would result in. > > > > But let me dig into the details. > > Okay, trying to figure out what to do here. > > Assume dax_pmd_load_hole() is called and there is already something. We > would have returned VM_FAULT_FALLBACK, now we would return VM_FAULT_NO_PAGE. > > That obviously only happens when we have not a write fault (otherwise, the > shared zeropage does not apply). > > In dax_iomap_pmd_fault(), we would indeed split_huge_pmd(). In the DAX case > (!anon vma), that would simply zap whatever is already mapped there. > > I guess we would then return VM_FAULT_FALLBACK from huge_fault-> ... -> > dax_iomap_fault() and core MM code would fallback to handle_pte_fault() etc. > and ... load a single PTE mapping the shared zeropage. > > BUT > > why is this case handled differently than everything else?
Hmm. Good question, I will have a bit more of a think about it, but your conclusion below is probably correct. > E.g., > > (1) when we try inserting the shared zeropage through > dax_load_hole()->vmf_insert_page_mkwrite() and there is already something > ... we return VM_FAULT_NOPAGE. > > (2) when we try inserting a PTE mapping an ordinary folio through > dax_fault_iter()->vmf_insert_page_mkwrite() and there is already something > ... we return VM_FAULT_NOPAGE. > > (3) when we try inserting a PMD mapping an ordinary folio through > dax_fault_iter()->vmf_insert_folio_pmd() and there is already something ... > we return VM_FAULT_NOPAGE. > > > So that makes me think ... the VM_FAULT_FALLBACK right now is probably ... > wrong? And probably cannot be triggered? I suspect that's true. At least I just did a full run of xfstest on a XFS DAX filesystem and was unable to trigger this path, so it's certainly not easy to trigger. > If there is already the huge zerofolio mapped, all good. > > Anything else is really not expected I would assume? > > -- > Cheers, > > David / dhildenb >
