On Sun, Jul 20, 2025 at 11:29:14AM -0700, Andrew Morton wrote:

On Sun, 20 Jul 2025 12:04:42 +0100 Lorenzo Stoakes [off-list ref] wrote:

quoted

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.

Thanks, all looks good to me!