linux-kernel - Re: [RFC PATCH 05/17] perf: Introduce 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]

Message-ID: <87tvzctt9k.fsf@ashishki-desk.ger.corp.intel.com>
Date:   Fri, 06 Oct 2017 14:23:03 +0300
From:   Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        acme@...hat.com, kirill.shutemov@...ux.intel.com, rric@...nel.org,
        alexander.shishkin@...ux.intel.com
Subject: Re: [RFC PATCH 05/17] perf: Introduce detached events

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

> So I'm not opposed to the idea of creating events that live independent
> from of file descriptors. And stuffing them in a filesystem makes sense.
> However I'm not entire convinced on the details.
>
> The above has a number of problems:
>
>  - there's a filesystem race; two concurrent syscalls can try and create
>    the same file. In that case the error most certainly is not -ENOMEM.

Indeed.

>  - there's a hash collision, similar issue.
>
>  - there's some asymmetry in the create/destroy; that is you create the
>    file with sys_perf_event_open() and remove it with unlink().

There is also an ioctl() to turn it into a normal event fd that can then
be closed.

>  - the actual name is very opaque and hard to use; how would a tool find
>    the right event to open?

They can readlink("/proc/self/fd/$fd"), something that I hacked into the
perf tool as well, although, truth be told I didn't actually need it for
anything, partly because it's not a useful name. One use case that I
could think of would be a task that's inherited a detached event wanting
to get rid of it. They can scan their /proc/$pid/maps, find the vma by
name and use that to locate the file.

> Would it instead make sense to allow the user to creat() their own files
> in this filesystem (with whatever descriptive name they need) and then
> pass that fd like:
>
>   sys_perf_event_open(.group_fd=fd, .flags=PERF_FLAG_FD_DETACH);
>
> or something to associate the file with the event. Of course, that makes
> it very hard to create detached cgroup events :/

Yes, I like the idea of moving the burden of naming to the userspace,
but then we have a problem with inheritance, which would still produce
new events w/o user's input.

Maybe use a directory for the 'parent' event? Then the above would still
work.

Regards,
--
Alex