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: <20200902135202.GG29330@paulmck-ThinkPad-P72>
Date:   Wed, 2 Sep 2020 06:52:02 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Ulf Hansson <ulf.hansson@...aro.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, 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().

							Thanx, Paul