linux-kernel - Re: [PATCH] perf/core: Emit PERF_RECORD

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:   Mon, 18 Jan 2021 13:56:49 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Stephane Eranian <eranian@...gle.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Ian Rogers <irogers@...gle.com>,
        Alexey Alexandrov <aalexand@...gle.com>
Subject: Re: [PATCH] perf/core: Emit PERF_RECORD_LOST for pinned events

On Mon, Jan 18, 2021 at 08:44:20PM +0900, Namhyung Kim wrote:
> Hi Peter,
> 
> On Mon, Jan 18, 2021 at 7:11 PM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > On Mon, Jan 18, 2021 at 12:43:23PM +0900, Namhyung Kim wrote:
> > > As of now we silently ignore pinned events when it's failed to be
> > > scheduled and make it error state not try to schedule it again.
> > > That means we won't get any samples for the event.
> > >
> > > But there's no way for users to notice and respond to it.  Let's
> > > emit a lost event with a new misc bit to indicate this situation.
> >
> > Users should get a read(2) error IIRC, does that not work?
> 
> Ah, right.  maybe I'm too specific to perf record's perspective.
> 
> In perf record, it doesn't use read(2) so I thought it should
> have the information in the stream of sample data.

perf-record could of course do a read() at the end, to detect this.

I don't think I object to having an even in the stream, but your LOST
event is unfortunate in that it itself can get lost when there's no
space in the buffer (which arguably is unlikely, but still).

So from that point of view, I think overloading LOST is not so very nice
for this.