[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201028212350.jj4mbnbk6hdcbymo@ast-mbp.dhcp.thefacebook.com>
Date: Wed, 28 Oct 2020 14:23:50 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Michael Jeanson <mjeanson@...icios.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Alexei Starovoitov <ast@...nel.org>,
Yonghong Song <yhs@...com>, paulmck <paulmck@...nel.org>,
Ingo Molnar <mingo@...hat.com>, acme <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
"Joel Fernandes, Google" <joel@...lfernandes.org>,
bpf <bpf@...r.kernel.org>
Subject: Re: [RFC PATCH 1/6] tracing: introduce sleepable tracepoints
On Tue, Oct 27, 2020 at 09:37:08AM -0400, Mathieu Desnoyers wrote:
>
> ----- On Oct 26, 2020, at 6:43 PM, Alexei Starovoitov alexei.starovoitov@...il.com wrote:
>
> > On Fri, Oct 23, 2020 at 03:53:47PM -0400, Michael Jeanson wrote:
> >> -#define __DO_TRACE(tp, proto, args, cond, rcuidle) \
> >> +#define __DO_TRACE(tp, proto, args, cond, rcuidle, tp_flags) \
> >> do { \
> >> struct tracepoint_func *it_func_ptr; \
> >> void *it_func; \
> >> void *__data; \
> >> int __maybe_unused __idx = 0; \
> >> + bool maysleep = (tp_flags) & TRACEPOINT_MAYSLEEP; \
> >> \
> >> if (!(cond)) \
> >> return; \
> >> @@ -170,8 +178,13 @@ static inline struct tracepoint
> >> *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> >> /* srcu can't be used from NMI */ \
> >> WARN_ON_ONCE(rcuidle && in_nmi()); \
> >> \
> >> - /* keep srcu and sched-rcu usage consistent */ \
> >> - preempt_disable_notrace(); \
> >> + if (maysleep) { \
> >> + might_sleep(); \
> >
> > The main purpose of the patch set is to access user memory in tracepoints,
> > right?
>
> Yes, exactly.
>
> > In such case I suggest to use stronger might_fault() here.
> > We used might_sleep() in sleepable bpf and it wasn't enough to catch
> > a combination where sleepable hook was invoked while mm->mmap_lock was
> > taken which may cause a deadlock.
>
> Good point! We will do that for the next round.
>
> By the way, we named this "sleepable" tracepoint (with flag TRACEPOINT_MAYSLEEP),
> but we are open to a better name. Would TRACEPOINT_MAYFAULT be more descriptive ?
> (a "faultable" tracepoint sounds weird though)
bpf kept 'sleepable' as a name. 'faultable' is too misleading.
Powered by blists - more mailing lists