[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLUMnjAYdnTBNHmzjw3L8qfeZb8UVVaenzxtwN3UxNcWJg@mail.gmail.com>
Date: Wed, 15 Apr 2020 15:07:42 -0700
From: John Stultz <john.stultz@...aro.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: paulmck@...nel.org, Josh Triplett <josh@...htriplett.org>,
lkml <linux-kernel@...r.kernel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Saravana Kannan <saravanak@...gle.com>,
Todd Kjos <tkjos@...gle.com>, Stephen Boyd <sboyd@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: On trace_*_rcuidle functions in modules
On Wed, Apr 15, 2020 at 2:49 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Wed, 15 Apr 2020 14:02:04 -0700
> John Stultz <john.stultz@...aro.org> wrote:
>
> >
> > So in my case your concerns may not be a problem, but I guess
> > generally it might. Though I'd hope the callback would be unregistered
> > (and whatever waiting for the grace period to complete be done) before
> > the module removal is complete. But maybe I'm still missing your
> > point?
>
> Hmm, you may have just brought up a problem here...
>
> You're saying that cpu_pm_register_notifier() callers are called from non
> RCU watching context? If that's the case, we have this:
Wait? what? I don't think I'm saying that. :) I'm just trying to fix
a build issue that prevents a driver from being a module since it has
a trace_*_rcuidle call in it.
Honestly, I really don't know much about how the cpu pm notifiers
interact with rcu. It's just this recent change, which seems
necessary, now seemingly prevents the driver from being built as a
module:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=efde2659b0fe835732047357b2902cca14f054d9
Maybe there's a better solution than using trace_*_rcuidle?
thanks
-john
Powered by blists - more mailing lists