Re: [PATCH] perf/core: track the perf mlock gift separately

[Peter Zijlstra]

On Sat, Oct 03, 2026 at 05:29:07PM +0100, Lorenzo Stoakes (ARM) wrote:
> The locked_vm field in struct user_struct was originally introduced by
> commit 789f90fcf6b0 ("perf_counter: per user mlock gift") to provide an
> mlock-like budget for perf measured against mm->pinned_vm (since 2011).
> 
> perf grants each user a 'gift' of perf_event_mlock_kb * online CPUs of
> buffer pages which is charged to user->locked_vm without any RLIMIT_MEMLOCK
> check.
> 
> Only pages beyond the gift are checked against RLIMIT_MEMLOCK, per-mm, via
> mm->pinned_vm, which makes it different from the standard mlock() check,
> which is per-mm and made against RLIMIT_MEMLOCK.
> 
> However, since this was introduced, a number of other components have
> utilised this field where a shared resource needed to be limited against
> RLIMIT_MEMLOCK.
> 
> The other users are currently MSG_ZEROCOPY, io_uring, AF_XDP, iommufd,
> s390 KVM zPCI and most recently, secretmem in commit 97d34aa65c29
> ("mm/secretmem: properly account locked pages").
> 
> This field is shared between all of these, but because the gift is not
> checked against RLIMIT_MEMLOCK, user->locked_vm alone can exceed it - 16
> CPUs * 516 KiB is already more than the default 8 MiB - after which every
> other user of the field fails unconditionally.
> 
> This was reported by a user who saw secretmem failing while running a
> simultaneous perf record.
> 
> Resolve the issue by simply giving perf its own field separate from the
> rest.

So I'm a little confused by all this -- perf introduced this field,
others jumped on and shit broke, so we fix perf instead of the others?

> BPF used user->locked_vm up until commit 80ee81e0403c ("bpf: Eliminate
> rlimit-based memory accounting infra for bpf maps") which landed in 5.11.
> 
> Thus also eliminate the now-defunct ifdef for CONFIG_BPF_SYSCALL for
> user->locked_vm.
> 
> This issue exists between all of the components which use user->locked_vm
> and perf, however secretmem is the first user who has caused a report over
> many years and has been backported, so target the fix at that.
> 
> Fixes: 97d34aa65c29 ("mm/secretmem: properly account locked pages")
> Reported-by: Ameer Hamza <ameer.hamza@xxxxxxxxxxx>
> Closes: https://lore.kernel.org/20261002175651.811343-1-ameer.hamza@xxxxxxxxxxx
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>

Anyway, patch seems straight forward enough; and you added comment to
the fields, which I suppose does clarify things some.

I'll take it. Thanks!