[PATCH v5 0/7] mm/mprotect: Fix dax puds

[Peter Xu]

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 at redhat.com> 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