lkml.org 
[lkml]   [2020]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] perf/core: fix mlock accounting in perf_mmap()
Date


> 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

\
 
 \ /
  Last update: 2020-01-23 18:24    [W:0.048 / U:1.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site