[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y3eyOpVg1dgP1Gjv@FVFF77S0Q05N.cambridge.arm.com>
Date: Fri, 18 Nov 2022 16:26:34 +0000
From: Mark Rutland <mark.rutland@....com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
Florent Revest <revest@...omium.org>,
bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
KP Singh <kpsingh@...nel.org>,
Brendan Jackman <jackmanb@...gle.com>, markowsky@...gle.com,
Steven Rostedt <rostedt@...dmis.org>,
Xu Kuohai <xukuohai@...wei.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 0/1] BPF tracing for arm64 using fprobe
Hi Alexei,
On Thu, Nov 17, 2022 at 08:50:12AM -0800, Alexei Starovoitov wrote:
> There might not be a task available where bpf trampoline is running.
I'm not sure what you mean by "there might not be a task available"; do you
mean that there might not be space in the per-task shadow stack, or that the
BPF program can be invoked inan IRQ context?
> rcu protection might not be there either.
We've spent a lot of time reworking entry/idle sequences with noinstr, so any
time BPF can be invoked, we should have a regular kernel environment available,
with RCU watching (but not necessarily in an RCU read-side critical section).
If BPF is being invoked without RCU watching, that is a bug that needs to be
fixed.
Do you have a specific example in mind?
Thanks,
Mark.
Powered by blists - more mailing lists