On Mon, Nov 11, 2024 at 10:20:59PM +0100, Jann Horn wrote: > On Mon, Aug 12, 2024 at 8:12 PM Peter Xu <peterx@xxxxxxxxxx> wrote: > > Dax supports pud pages for a while, but mprotect on puds was missing since > > the start. This series tries to fix that by providing pud handling in > > mprotect(). The goal is to add more types of pud mappings like hugetlb or > > pfnmaps. This series paves way for it by fixing known pud entries. > > Do people actually use hardware where they can use PUD THP mappings > for DAX? I thought that was just some esoteric feature that isn't > actually usable on almost any system. > Was I wrong about that? I did run it with a qemu emulated nvdimm device. Though in reality I've no idea on how many people are using it.. > > I think another example that probably doesn't play entirely nice with > PUD THP mappings is mremap()'s move_page_tables(). If > dax_get_unmapped_area() allows creating a VMA at an unaligned start > address (which I think it does?), move_page_tables() can probably end > up copying from an aligned address mapped with a huge PUD entry to an > unaligned address that needs to be mapped at the PTE level, and I > think that will probably cause it to call into get_old_pmd() while a > huge PUD entry is still present, which will probably get us a > pud_bad() error or such? I think you're probably right, that we have other places that may not work well with pud mappings. I also wonder whether dax_get_unmapped_area() needs to properly handle MAP_FIXED, even for PMD mappings. It looks like it always fallbacks to the default mm_get_unmapped_area() with FIXED, which have no idea on dax->alignment so it'll always allow it.. The issue is I'm not sure dax pmd can be split at all, while I think split-able is needed when mremap from a pmd-aligned address to a !pmd-aligned address. Thanks, -- Peter Xu
