linux-kernel - Re: [PATCH] perf bpf-filter: Support multiple events properly

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] [day] [month] [year] [list]

Message-ID: <ZrvtYf2BG1hQlLGM@google.com>
Date: Tue, 13 Aug 2024 16:33:53 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Ian Rogers <irogers@...gle.com>, Kan Liang <kan.liang@...ux.intel.com>,
	Jiri Olsa <jolsa@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
	linux-perf-users@...r.kernel.org, KP Singh <kpsingh@...nel.org>,
	Song Liu <song@...nel.org>, bpf@...r.kernel.org,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH] perf bpf-filter: Support multiple events properly

On Mon, Aug 05, 2024 at 02:12:01PM -0700, Namhyung Kim wrote:
> On Mon, Aug 05, 2024 at 04:31:34PM -0300, Arnaldo Carvalho de Melo wrote:
> > On Mon, Aug 05, 2024 at 11:56:56AM -0700, Namhyung Kim wrote:
> > > On Mon, Aug 05, 2024 at 12:03:14PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > On Fri, Aug 02, 2024 at 10:37:52AM -0700, Namhyung Kim wrote:
> > > > > + * The BPF program returns 1 to accept the sample or 0 to drop it.
> > > > > + * The 'dropped' map is to keep how many samples it dropped by the filter and
> > > > > + * it will be reported as lost samples.
> > > > 
> > > > I think there is value in reporting how many were filtered out, I'm just
> > > > unsure about reporting it as "lost" samples, as lost has another
> > > > semantic associated, i.e. ring buffer was full or couldn't process it
> > > > for some other resource starvation issue, no?
> > > 
> > > Then we need a way to save the information.  It could be a new record
> > > type (PERF_RECORD_DROPPED_SAMPLES), a new misc flag in the lost samples
> > 
> > I guess "PERF_RECORD_FILTERED_SAMPLES" would be better, more precise,
> > wdyt?
> > 
> > > record or a header field.  I prefer the misc flag.
> > 
> > I think we can have both filtered and lost samples, so I would prefer
> > the new record type.
> 
> I think we can have two LOST_SAMPLES records then - one with the new
> misc flag for BPF and the other (without the flag) for the usual lost
> samples.  This would require minimal changes IMHO.

I've realized that I already added PERF_RECORD_MISC_LOST_SAMPLES_BPF in
the commit 27c6f2455b29f ("perf record: Record dropped sample count"). :)

I'll add that to the event stats.

Thanks,
Namhyung