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.
