[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <DE0F33E7-79BD-4817-ABD6-7D8E57074802@fb.com>
Date: Thu, 23 Jan 2020 17:24:11 +0000
From: Song Liu <songliubraving@...com>
To: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
CC: linux-kernel <linux-kernel@...r.kernel.org>,
Kernel Team <Kernel-team@...com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Jiri Olsa <jolsa@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] perf/core: fix mlock accounting in perf_mmap()
> On Jan 23, 2020, at 1:19 AM, Alexander Shishkin <alexander.shishkin@...ux.intel.com> wrote:
>
> Song Liu <songliubraving@...com> writes:
>
>>> On Jan 20, 2020, at 12:24 AM, Alexander Shishkin <alexander.shishkin@...ux.intel.com> wrote:
>>>
>>> Song Liu <songliubraving@...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
Powered by blists - more mailing lists