Follow-up to Park Tae-sun's patch [1], which was dropped. David asked which of the cases it raised can actually be triggered, and for selftests that show them. Two can.
Patch 1 makes a zero length mlock()/munlock() a no-op before the address is rounded. Today mlock(addr + 5, 0) locks a page and munlock(addr + 5, 0) unlocks one. Patch 2 rejects ranges where start + len overflows, or where the end overflows when rounded to a page. Today these get a silent success, act on a single page, or get -ENOMEM/-EINVAL depending on CAP_IPC_LOCK. Patch 3 adds both cases to mlock2-tests. I could not find the commit that introduced either behaviour in the git history. Both are already present in the earliest history I could find, so they may predate the imported git history. There is therefore no commit to use for a Fixes tag. I have not added Cc: stable since these changes intentionally alter UAPI-visible behaviour. A man-pages patch for the zero length case will follow. The mlock-random-test failure CI reported on [1] came from that patch, not the test: it assigned 0 to do_mlock()'s error, which has to stay -ENOMEM for the over-limit case, so mlock() over RLIMIT_MEMLOCK without CAP_IPC_LOCK returned 0 without locking anything. With [1] applied the test fails 40 runs out of 40; with error set back to -ENOMEM after the check_mlock_range() call it passes all 40, as it does with this series. Tested on x86_64 (KASAN, lockdep) in QEMU: mlock2-tests 31/31 as root and as nobody, 24/31 and 23/31 on mm-unstable; mlock-random-test and on-fault-limit pass. [1] https://lore.kernel.org/all/[email protected]/ Jose A. Perez de Azpillaga (3): mm/mlock: make a zero length request a no-op whatever the alignment mm/mlock: reject ranges that cannot be represented selftests/mm: test mlock() and munlock() range normalisation mm/mlock.c | 29 +++- tools/testing/selftests/mm/mlock2-tests.c | 191 +++++++++++++++++++++- 2 files changed, 215 insertions(+), 5 deletions(-) base-commit: 33eb75fed9eef7a57e3f77c37c160d3e9ec55f2e -- 2.55.0
