[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190128083123.GB28467@hirez.programming.kicks-ass.net>
Date: Mon, 28 Jan 2019 09:31:23 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Alexei Starovoitov <ast@...nel.org>, davem@...emloft.net,
daniel@...earbox.net, jakub.kicinski@...ronome.com,
netdev@...r.kernel.org, kernel-team@...com, mingo@...hat.com,
will.deacon@....com, Paul McKenney <paulmck@...ux.vnet.ibm.com>,
jannh@...gle.com
Subject: Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> > > nmi checks for bpf_prog_active==0. See bpf_overflow_handler.
> > yuck yuck yuck.. That's horrific :-( That means the whole BPF crud is
> > unreliable and events can go randomly missing.
>
> bpf_prog_active is the mechanism to workaround non-reentrant pieces of the kernel.
'the kernel' or 'bpf' ?
perf has a recursion counter per context (task,softirq,hardirq,nmi) and
that ensures that perf doesn't recurse in on itself while allowing the
nesting of these contexts.
But if BPF itself is not able to deal with such nesting that won't work
of course.
Powered by blists - more mailing lists