On Mon, Sep 28, 2026 at 02:08:51PM +0200, David Hildenbrand (Arm) wrote: > On 9/28/26 13:10, Jose A. Perez de Azpillaga wrote: > > MREMAP_DONTUNMAP keeps the source VMA in place, but clears its mlock flags > > for the whole VMA while setting them on the destination VMA. Two cases > > leak mm->locked_vm as a result: > > > > - an unfaulted mlock-on-fault VMA moved behind itself self-merges, so the > > single resulting VMA loses the flags without the accounting being > > dropped; > > > > - a partial mremap() moves only part of the range, leaving the pages which > > are not moved accounted as locked in a VMA whose flags were cleared. > > > > Add three cases to the MREMAP_DONTUNMAP selftest which mlock() the source > > VMA, with and without MLOCK_ONFAULT, perform the operation and check that > > VmLck comes back to zero once everything is unmapped. Each case runs in > > its own process, so it starts from a clean mm with VmLck at zero and a > > failure cannot propagate to the cases which follow. > > > > Verified on x86_64: the three cases fail on v7.3-rc5 and pass on > > mm-unstable with the fixes from the "mm/mremap: fix two issues with > > MREMAP_DONTUNMAP" series applied. > > > > Signed-off-by: Jose A. Perez de Azpillaga <[email protected]> > > --- > > tools/testing/selftests/mm/mremap_dontunmap.c | 273 +++++++++++++++++- > > @Lorenzo, could something like this also be implemented (maybe with less > churn) > in the vma.c selftests?
if the size is the concern, most of it is the per case process and error handling, and I could try folding that into one helper if you would prefer a smaller patch. -- cheers, jose a. p-a
