[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89i+1MQRCSRVg-af758en5e9nwQBes3aBSjQ6BY1pV5+HdQ@mail.gmail.com>
Date: Fri, 21 Aug 2020 08:06:49 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Marco Elver <elver@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
netdev <netdev@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] random32: Use rcuidle variant for tracepoint
On Fri, Aug 21, 2020 at 1:59 AM <peterz@...radead.org> 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 to using trace_prandom_u32_rcuidle(), to avoid various
> > issues due to recursion and lockdep warnings when KCSAN and tracing is
> > enabled.
>
> At some point we're going to have to introduce noinstr to idle as well.
> But until that time this should indeed cure things.
I do not understand what the issue is. This _rcuidle() is kind of opaque ;)
Would this alternative patch work, or is it something more fundamental ?
Thanks !
diff --git a/lib/random32.c b/lib/random32.c
index 932345323af092a93fc2690b0ebbf4f7485ae4f3..17af2d1631e5ab6e02ad1e9288af7e007bed6d5f
100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -83,9 +83,10 @@ u32 prandom_u32(void)
u32 res;
res = prandom_u32_state(state);
- trace_prandom_u32(res);
put_cpu_var(net_rand_state);
+ trace_prandom_u32(res);
+
return res;
}
EXPORT_SYMBOL(prandom_u32);
Powered by blists - more mailing lists