linux-kernel - Re: WARNING: suspicious RCU usage - sdhci-pltfm: SDHCI platform and OF driver helper

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: <CAPDyKFqAAjCDSSJ56V+cdy6t0F01sXj_AkNxdXRtAKegf8DDsQ@mail.gmail.com>
Date:   Wed, 2 Sep 2020 18:07:05 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Saravana Kannan <saravanak@...gle.com>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        lkft-triage@...ts.linaro.org, rcu@...r.kernel.org,
        Linux PM <linux-pm@...r.kernel.org>,
        Anders Roxell <anders.roxell@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        John Stultz <john.stultz@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Lars Povlsen <lars.povlsen@...rochip.com>,
        madhuparnabhowmik10@...il.com,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        peterz@...rdead.org, Lina Iyer <ilina@...eaurora.org>
Subject: Re: WARNING: suspicious RCU usage - sdhci-pltfm: SDHCI platform and
 OF driver helper

On Wed, 2 Sep 2020 at 15:52, Paul E. McKenney <paulmck@...nel.org> wrote:
>
> On Wed, Sep 02, 2020 at 08:49:11AM +0200, Ulf Hansson wrote:
> > On Tue, 1 Sep 2020 at 17:00, Paul E. McKenney <paulmck@...nel.org> wrote:
>
> [ . . . ]
>
> > > Here is the list, though it is early in the morning here:
> > >
> > > 1.      RCU_NONIDLE().
> > >
> > > 2.      Peter's patch, if it turns out to hoist your code out of what
> > >         RCU considers to be the idle loop.
> > >
> > > 3.      If the problem is trace events, use the _rcuidle() variant of the
> > >         trace event.  Instead of trace_blah(), use trace_blah_rcuidle().
> > >
> > > 4.      Switch from RCU (as in rcu_read_lock()) to SRCU (as in
> > >         srcu_read_lock()).
> > >
> > > 5.      Take Peter's patch a step further, moving the rcu_idle_enter()
> > >         and rcu_idle_exit() calls as needed.  But please keep in mind
> > >         that these two functions require that irqs be disabled by their
> > >         callers.
> > >
> > > 6.      If RCU_NONIDLE() in inconvenient due to early exits and such,
> > >         you could use the rcu_irq_enter_irqson() and rcu_irq_exit_irqson()
> > >         functions that it calls.
> > >
> > > Do any of those help?
> >
> > Yes, they will, in one way or the other. Thanks for providing me with
> > all the available options.
> >
> > BTW, I still don't get what good rcu_idle_enter|exit() does, but I am
> > assuming those need to be called at some point before the CPU goes to
> > sleep.
>
> These functions allow RCU to leave idle CPUs undisturbed.  If they
> were not invoked, RCU would periodically IPI idle CPUs to verify that
> there were no RCU readers running on them.  This would be quite bad for
> battery lifetime, among other things.  So the call to rcu_idle_enter()
> tells RCU that it may safely completely ignore this CPU until its next
> call to rcu_idle_exit().

Alright, thanks for explaining this, much appreciated.

So in one way, we would also like to call rcu_idle_enter(), as soon as
we know there is no need for the RCU to be active. To prevent
unnecessary IPIs I mean. :-)

Kind regards
Uffe