linux-kernel - Re: [RFC PATCH 09/17] perf: Use shmemfs pages for userspace-only per-thread detached events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 06 Oct 2017 14:52:26 +0300
From:   Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        acme@...hat.com, kirill.shutemov@...ux.intel.com,
        Borislav Petkov <bp@...en8.de>, rric@...nel.org
Subject: Re: [RFC PATCH 09/17] perf: Use shmemfs pages for userspace-only per-thread detached events

Peter Zijlstra <peterz@...radead.org> writes:

> On Tue, Sep 05, 2017 at 04:30:18PM +0300, Alexander Shishkin wrote:
>> In order to work around the problem of using up mlocked memory for the
>> detached events, we can pin the ring buffer pages only while they are
>> in use (that is, the event is ACTIVE), and unpin them for the rest of
>> the time. When not pinned in, these pages can be swapped out. This way,
>> one user can have at most mlock_limit*nr_cpus kB of memory pinned at
>> any given moment, however many events they actually have.
>> 
>> This enforces a constraint: pinning and unpinning may sleep and thus
>> can't be done in the event scheduling path. Instead, we use a task
>> work to do this, which this pattern us to userspace-only events.
>> Also, since one userspace thread only needs one buffer (for whatever
>> CPU it's running on at any given moment), we only do this for per-thread
>> events.
>> 
>> The source for such swappable pages is shmemfs. This patch allows
>> allocating perf ring buffer pages from an shmemfs file if the above
>> constraints are met.
>
> Right, so why still allow that previous icky thing? What cases do we
> need that for?

8/17..12/17 are really one patch split into smaller chunks. The first
one does the icky thing and then we get to what we actually want.

The idea is that you won't be able to enable inheritance for detached
events unless they are shmem-backed.

Regards,
--
Alex