Re: [PATCH v2] perf/core: fix user->locked_vm leak on secondary mmap()

[Geyslan Gregório]

On Mon, 21 Sep 2026 00:33:06 +0000, Hui Peng wrote:
> Fix this by only calling perf_mmap_account() when allocating a new ring
> buffer in perf_mmap_rb() or a new AUX buffer in perf_mmap_aux().

Same thing I found reading perf_mmap_rb(), and I tested your patch. It
applies to current mainline (0fcb05b72344) and I confirmed the leak and
the fix there.

Instead of reading it off an EPERM I measured user->locked_vm directly:
io_uring buffer registration charges the same counter against
RLIMIT_MEMLOCK, so the largest buffer that still registers gives the page
count. x86_64 defconfig under KVM, 2 and 4 vCPUs, each case on its own
uid. Mapping a buffer three more times and unmapping all of them, pages
left charged after the last munmap(), before -> after:

  ring, one process           195 -> 0
  ring, fd handed to workers   195 -> 0
  AUX area                     192 -> 0

The charge follows the event fd, not the mm, so a supervisor that opens
per-CPU events and lets a worker map them leaks the buffer size on every
worker restart.

Your reproducer covers the ring buffer, so I ran the AUX path too. With
no PT/SPE/CoreSight here I used a throwaway test-only PMU (just
setup_aux/free_aux, enough to drive the accounting); same leak, same fix.

Tested-by: Geyslan Gregório <gg@xxxxxxxxxxx>

Worth noting this is independent of Lorenzo's "track the perf mlock gift
separately" [1]: that keeps perf from starving the other locked_vm users,
this kills the per-buffer double charge. Both are needed.

The reproducer and test harness were LLM-assisted; the measurements and
this report are mine.

[1] https://lore.kernel.org/all/20261003-perf-locked-vm-fix-v1-1-d214dcaf0d76@xxxxxxxxxx/

Thanks,
Geyslan