Alistair Popple wrote: > I was initially concerned about these cases because I was wondering if > folio subpages could ever get different mappings and the shared case > implied they could. But it seems that's xfs specific and there is a > separate mechanism to deal with looking up ->mapping/index for that. So > I guess we should still be able to safely store this on the folio > head. I will double check and update this change. > I think there is path to store this information only on the folio head. However, ugh, I think this is potentially another "head" of the pmd_devmap() hydra. pmd_devmap() taught the core-mm to treat dax_pmds indentically to thp_pmds *except* for the __split_huge_pmd() case: 5c7fb56e5e3f mm, dax: dax-pmd vs thp-pmd vs hugetlbfs-pmd Later on pmd migration entries joined pmd_devmap() in skipping splits: 84c3fc4e9c56 mm: thp: check pmd migration entry in common path Unfortunately, pmd_devmap() stopped being considered for skipping splits here: 7f7609175ff2 mm/huge_memory: remove stale locking logic from __split_huge_pmd() Likely __split_huge_pmd_locked() grew support for pmd migration handling and forgot about the pmd_devmap() case. So now Linux has been allowing FSDAX pmd splits since v5.18... but with no reports of any issues. Likely this is benefiting from the fact that the preconditions for splitting are rarely if ever satisfied because FSDAX mappings are never anon, and establishing the mapping in the first place requires a 2MB aligned file extent and that is likely never fractured. Same for device-dax where the fracturing *should* not be allowed, but I will feel better with focus tests to go after mremap() cases that would attempt to split the page.
