Linux userland API discussions
 help / color / mirror / Atom feed
* [PATCH RESEND 0/3] mm/mlock: make zero length requests a no-op and reject wrapping ranges
@ 2026-11-02  7:43 Jose A. Perez de Azpillaga
  2026-11-02  7:43 ` [PATCH RESEND 1/3] mm/mlock: make a zero length request a no-op whatever the alignment Jose A. Perez de Azpillaga
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Jose A. Perez de Azpillaga @ 2026-11-02  7:43 UTC (permalink / raw)
  To: Andrew Morton, Liam R. Howlett, Lorenzo Stoakes,
	David Hildenbrand, Shuah Khan
  Cc: Vlastimil Babka, Jann Horn, Pedro Falcato, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, linux-mm, linux-kernel,
	linux-kselftest, ts930, alx, linux-api, linux-man,
	Jose A. Perez de Azpillaga

No changes, rebased on mm-new, Cc fixed.

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.

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/179066531783.50175.13377521828379196177@dgu.ac.kr/

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: afb4eea28037fa55c4560313ecbd8a1e1da8369a
-- 
2.56.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-11-02  7:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-02  7:43 [PATCH RESEND 0/3] mm/mlock: make zero length requests a no-op and reject wrapping ranges Jose A. Perez de Azpillaga
2026-11-02  7:43 ` [PATCH RESEND 1/3] mm/mlock: make a zero length request a no-op whatever the alignment Jose A. Perez de Azpillaga
2026-11-02  7:44 ` [PATCH RESEND 2/3] mm/mlock: reject ranges that cannot be represented Jose A. Perez de Azpillaga
2026-11-02  7:44 ` [PATCH RESEND 3/3] selftests/mm: test mlock() and munlock() range normalisation Jose A. Perez de Azpillaga

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox