On Fri, 21 Aug 2020 at 14:31, Marco Elver <[email protected]> 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/[email protected]
> Link: https://lkml.kernel.org/r/[email protected]
> Signed-off-by: Marco Elver <[email protected]>
> ---
> Applies to latest -rcu/dev only.
>
> Let's wait a bit to see what happens with
> https://lkml.kernel.org/r/[email protected],
> 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.
Thanks,
-- Marco
On Wed, Aug 26, 2020 at 02:17:57PM +0200, Marco Elver wrote:
> On Fri, 21 Aug 2020 at 14:31, Marco Elver <[email protected]> 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/[email protected]
> > Link: https://lkml.kernel.org/r/[email protected]
> > Signed-off-by: Marco Elver <[email protected]>
> > ---
> > Applies to latest -rcu/dev only.
> >
> > Let's wait a bit to see what happens with
> > https://lkml.kernel.org/r/[email protected],
> > 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