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? -- Cheers, David
