Re: [PATCH 6.17 1/3] mm/mremap: allow multi-VMA move when filesystem uses thp_get_unmapped_area

[Vlastimil Babka <vbabka@suse.cz>]

On 8/3/25 13:11, Lorenzo Stoakes wrote:
> We currently restrict multi-VMA move to avoid filesystems or drivers which
> provide a custom f_op->get_unmapped_area handler unless it is known to
> correctly handle MREMAP_FIXED.
> 
> We do this so we do not get unexpected result when moving from one area to
> another (for instance, if the handler would align things resulting in the
> moved VMAs having different gaps than the original mapping).
> 
> More and more filesystems are moving to using large folios, and typically
> do so (in part) by setting f_op->get_unmapped_area to
> thp_get_unmapped_area.
> 
> When mremap() invokes the file system's get_unmapped MREMAP_FIXED, it does
> so via get_unmapped_area(), called in vrm_set_new_addr(). In order to do
> so, it converts the MREMAP_FIXED flag to a MAP_FIXED flag and passes this
> to the unmapped area handler.
> 
> The __get_unmapped_area() function (called by get_unmapped_area()) in turn
> invokes the filesystem or driver's f_op->get_unmapped_area() handler.
> 
> Therefore this is a point at which thp_get_unmapped_area() may be called
> (also, this is the case for anonymous mappings where the size is huge page
> aligned).
> 
> thp_get_unmapped_area() calls thp_get_unmapped_area_vmflags() and
> __thp_get_unmapped_area() in turn (falling back to
> mm_get_unmapped_area_vm_flags() which is known to handle MAP_FIXED
> correctly).
> 
> The __thp_get_unmapped_area() function in turn does nothing to change the
> address hint, nor the MAP_FIXED flag, only adjusting alignment
> parameters. It hten calls mm_get_unmapped_area_vmflags(), and in turn
> arch-specific unmapped area functions, all of which honour MAP_FIXED
> correctly.
> 
> Therefore, we can safely add thp_get_unmapped_area to the known-good
> handlers.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>