On Sun, Jul 20, 2025 at 11:29:14AM -0700, Andrew Morton wrote: > 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. Thanks, all looks good to me!
