Messages in this thread | | | Date | Wed, 26 Aug 2020 14:21:30 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] kcsan: Use tracing-safe version of prandom |
| |
On Wed, Aug 26, 2020 at 02:17:57PM +0200, Marco Elver wrote: > On Fri, 21 Aug 2020 at 14:31, Marco Elver <elver@google.com> wrote: > > In the core runtime, we must minimize any calls to external library > > functions to avoid any kind of recursion. This can happen even though > > instrumentation is disabled for called functions, but tracing is > > enabled. > > > > Most recently, prandom_u32() added a tracepoint, which can cause > > problems for KCSAN even if the rcuidle variant is used. For example: > > kcsan -> prandom_u32() -> trace_prandom_u32_rcuidle -> > > srcu_read_lock_notrace -> __srcu_read_lock -> kcsan ... > > > > While we could disable KCSAN in kcsan_setup_watchpoint(), this does not > > solve other unexpected behaviour we may get due recursing into functions > > that may not be tolerant to such recursion: > > __srcu_read_lock -> kcsan -> ... -> __srcu_read_lock > > > > Therefore, switch to using prandom_u32_state(), which is uninstrumented, > > and does not have a tracepoint. > > > > Link: https://lkml.kernel.org/r/20200821063043.1949509-1-elver@google.com > > Link: https://lkml.kernel.org/r/20200820172046.GA177701@elver.google.com > > Signed-off-by: Marco Elver <elver@google.com> > > --- > > Applies to latest -rcu/dev only. > > > > Let's wait a bit to see what happens with > > https://lkml.kernel.org/r/20200821063043.1949509-1-elver@google.com, > > just in case there's a better solution that might make this patch redundant. > > Paul, feel free to pick this up. > > I wanted to wait until after plumbers to see what happens, but maybe > it's better to give the heads-up now, so this is in time for the next > pull-request. It seems that prandom_u32() will keep its tracepoint, > which means we definitely need this to make KCSAN compatible with > tracing again.
Queued and pushed, thank you!
Thanx, Paul
| |