[ Late reply, due to Plumbers followed by a much needed vacation and
then drowning in 3 weeks of unread email! ]
On Fri, 21 Aug 2020 17:35:32 +0200
Marco Elver wrote:
> So, if the _rcuidle() variant here doesn't break your usecase, there
> should be no harm in using the _rcuidle() variant. T
On Fri, Aug 21, 2020 at 11:41:41AM -0400, Steven Rostedt wrote:
> On Fri, 21 Aug 2020 11:38:31 -0400
> Steven Rostedt wrote:
>
> > > > At some point we're going to have to introduce noinstr to idle as well.
> > > > But until that time this should indeed cure things.
> > >
>
> What the above
On Fri, 21 Aug 2020 11:38:31 -0400
Steven Rostedt wrote:
> > > At some point we're going to have to introduce noinstr to idle as well.
> > > But until that time this should indeed cure things.
> >
What the above means, is that ideally we will get rid of all
tracepoints and kasan checks from
On Fri, 21 Aug 2020 08:06:49 -0700
Eric Dumazet wrote:
> On Fri, Aug 21, 2020 at 1:59 AM wrote:
> >
> > On Fri, Aug 21, 2020 at 08:30:43AM +0200, Marco Elver wrote:
> > > With KCSAN enabled, prandom_u32() may be called from any context,
> > > including idle CPUs.
> > >
> > > Therefore, switch
On Fri, Aug 21, 2020 at 08:30:43AM +0200, Marco Elver 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
