Re: [PATCH v4 06/10] mm/mremap: check remap conditions earlier
From: Andrew Morton
Date: Sun Jul 20 2025 - 14:29:29 EST
On Sun, 20 Jul 2025 12:04:42 +0100 Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote:
> Hi Andrew,
>
> It turns out there's some undocumented, unusual behaviour in mremap()
> around shrinking of a range which was previously missed, but an LTP test
> flagged up (seemingly by accident).
>
> Basically, if you specify an input range that spans multiple VMAs, this is
> in nearly all cases rejected (this is the point of this series, after all,
> for VMA moves).
>
> However, it turns out if you a. shrink a range and b. the new size spans
> only a single VMA in the original range - then this requirement is entirely
> dropped.
>
> So I need to slightly adjust the logic to account for this. I will also be
> documenting this in the man page as it appears the man page contradicts
> this or is at least very unclear.
>
> I attach a fix-patch, however there's some very trivial conflicts caused
> due to code being moved around.
>
OK, I applied this as a -fix.
Moved the two new hunks into check_prep_vma().
Made sure the "We are expanding and the VMA .." hunk landed properly in
check_prep_vma().
I've pushed out the result, please check current mm-unstable.