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: <20170906162414.djyec6rlu2ktzdag@pd.tnic>
Date:   Wed, 6 Sep 2017 18:24:14 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>
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
Subject: Re: [RFC PATCH 00/17] perf: Detached events

On Tue, Sep 05, 2017 at 04:30:09PM +0300, Alexander Shishkin wrote:
> Detached events: a new flag to the perf syscall makes a 'detached' event,
> which exists after its file descriptor is released. Not all detached events
> are per-thread AUX events: this tries to take into account the need for
> system-wide persistent events too.

Nice, thanks!

> (2) Need to be able to kill those events, so they need to be accessible
> after they are created.
> Event files: detached events exist as files in tracefs (at the moment), can
> be opened/mmaped/read/removed.

I guess I'll see when I continue reading but I remember us doing ioctls
on the event fd.

> (6) Ring buffer memory accounting needs to take this new arrangement into
> account: one user can use up at most NR_CPUS * buffer_size memory at any
> given point in time.
> Only account the first such event and undo the accounting when the last
> event is gone.

... and I guess we probably shouldn't allow the user to create too many
events and shoot herself in the OOM-foot.

> (7) We'll also need to supply all the things that the [PT] decoder normally
> finds out via sysfs attributes, like clock ratios, capabilities, etc so that
> it also finds its way into the core dump file.
> "PMU info" structure is appended to the user page.
> 
> I've also hack the perf tool to support all this, all these things can be
> found at [1]. I'm not posting the tooling patches though, them being
> thoroughly ugly and proof-of-concept. In short, perf record will create
> detached events with '--detached' and afterwards will open detached events
> via their path in tracefs.

Sounds nice. I'd need to test all that just so I can be able to create
detached RAS events (which are tracepoints) with it.

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ