linux-kernel - Re: On trace_*_rcuidle functions in modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALAqxLW6jqr38bk8pp-Hom2=MLm3coTmzCP8MMfrDvMfx388=Q@mail.gmail.com>
Date:   Wed, 15 Apr 2020 14:02:04 -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 1:41 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Wed, 15 Apr 2020 13:17:53 -0700
> John Stultz <john.stultz@...aro.org> wrote:
>
> > > Hmm, isn't module code itself synchronized via RCU. Then having module code
> > > being called without RCU "watching" could be dangerous?
> >
> > I'm not sure I'm following you here. Could you explain more?
>
> So how does this code get registered to be called as a module?

The driver is registered via standard platform_driver_register()
called via module_initcall. The callback is then registered via
cpu_pm_register_notifier() in the driver's probe function.

> And if it is
> registered, I'm guessing it needs to be unregistered too. How would that be
> synchronized? Usually, calling synchronize_rcu() is done after
> unregistering, but if that code is called without RCU watching, it is
> possible synchronize_rcu() can finish before that code is released.

So I'm actually trying to enable the driver to be loaded as a
permanent module, so there's no remove hook (so much depends on the
driver that you couldn't remove it and have anything work - we just
want it to be modularly loaded so all devices don't have to pay the
cost of including the driver).

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?

thanks
-john