Messages in this thread | | | From | Song Liu <> | Subject | Re: [PATCH] perf/core: fix mlock accounting in perf_mmap() | Date | Thu, 23 Jan 2020 17:24:11 +0000 |
| |
> On Jan 23, 2020, at 1:19 AM, Alexander Shishkin <alexander.shishkin@linux.intel.com> wrote: > > Song Liu <songliubraving@fb.com> writes: > >>> On Jan 20, 2020, at 12:24 AM, Alexander Shishkin <alexander.shishkin@linux.intel.com> wrote: >>> >>> Song Liu <songliubraving@fb.com> writes: >>> >>>> sysctl_perf_event_mlock and user->locked_vm can change value >>>> independently, so we can't guarantee: >>>> >>>> user->locked_vm <= user_lock_limit >>> >>> This means: if the sysctl got sufficiently decreased, so that the >>> existing locked_vm exceeds it, we need to deal with the overflow, right? >> >> Reducing sysctl is one way to generate the overflow. Another way is to >> call setrlimit() from user space to allow bigger user->locked_vm. > > You mean RLIMIT_MEMLOCK? That's a limit on mm->pinned_vm. Doesn't affect > user->locked_vm.
This depends. For example, bpf_charge_memlock() uses RLIMIT_MEMLOCK as the limit for user->locked_vm. This makes sense, because the bpf map created by a process may stay longer than the process.
Thanks, Song
| |