[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201117075334.GJ3121392@hirez.programming.kicks-ass.net>
Date: Tue, 17 Nov 2020 08:53:34 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Martin KaFai Lau <kafai@...com>
Cc: Florian Lehner <dev@...-flo.net>, bpf@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
john.fastabend@...il.com, mingo@...hat.com, acme@...nel.org
Subject: Re: [FIX bpf,perf] bpf,perf: return EOPNOTSUPP for bpf handler on
PERF_COUNT_SW_DUMMY
On Mon, Nov 16, 2020 at 01:02:09PM -0800, Martin KaFai Lau wrote:
> On Mon, Nov 16, 2020 at 07:37:52PM +0100, Florian Lehner wrote:
> > bpf handlers for perf events other than tracepoints, kprobes or uprobes
> > are attached to the overflow_handler of the perf event.
> >
> > Perf events of type software/dummy are placeholder events. So when
> > attaching a bpf handle to an overflow_handler of such an event, the bpf
> > handler will not be triggered.
> >
> > This fix returns the error EOPNOTSUPP to indicate that attaching a bpf
> > handler to a perf event of type software/dummy is not supported.
> >
> > Signed-off-by: Florian Lehner <dev@...-flo.net>
> It is missing a Fixes tag.
I don't think it actually fixes anything. worse it could break things.
Atatching a bpf filter to a dummy event is pointless, but harmless. We
allow it now, disallowing it will break whatever programs out there are
doing harmless silly things.
I really don't see the point of this patch. It grows the kernel code for
absolutely no distinguishable benefit.
Powered by blists - more mailing lists