Messages in this thread | | | From | Marco Elver <> | Date | Fri, 21 Aug 2020 10:58:02 +0200 | Subject | Re: [PATCH] random32: Use rcuidle variant for tracepoint |
| |
On Fri, 21 Aug 2020 at 08:30, Marco Elver <elver@google.com> wrote: > With KCSAN enabled, prandom_u32() may be called from any context, > including idle CPUs. > > Therefore, switch to using trace_prandom_u32_rcuidle(), to avoid various > issues due to recursion and lockdep warnings when KCSAN and tracing is > enabled. > > Fixes: 94c7eb54c4b8 ("random32: add a tracepoint for prandom_u32()") > Link: https://lkml.kernel.org/r/20200820155923.3d5c4873@oasis.local.home > Suggested-by: Steven Rostedt <rostedt@goodmis.org> > Signed-off-by: Marco Elver <elver@google.com> > Cc: Eric Dumazet <edumazet@google.com> > Cc: Peter Zijlstra <peterz@infradead.org> > --- > lib/random32.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/random32.c b/lib/random32.c > index 932345323af0..1c5607a411d4 100644 > --- a/lib/random32.c > +++ b/lib/random32.c > @@ -83,7 +83,7 @@ u32 prandom_u32(void) > u32 res; > > res = prandom_u32_state(state); > - trace_prandom_u32(res); > + trace_prandom_u32_rcuidle(res); > put_cpu_var(net_rand_state); >
Note that, for KCSAN's use, there is still a small chance this will mess things up. So, as a short-term fix, I'd appreciate if this patch will be applied to 5.9, assuming it doesn't mess with the original usecase.
Longer-term, I think I need to switch KCSAN to use either prandom_u32_state() or open-code its own prandom function, as the trace-rcuidle code calls into srcu, which might have other weird effects if KCSAN instruments that. Still working on the longer-term fix.
Thanks, -- Marco
| |