lkml.org 
[lkml]   [2022]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 15/36] cpuidle,cpu_pm: Remove RCU fiddling from cpu_pm_{enter,exit}()
On Tue, Jun 14, 2022 at 05:13:16PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:38PM +0200, Peter Zijlstra wrote:
> > All callers should still have RCU enabled.
>
> IIUC with that true we should be able to drop the RCU_NONIDLE() from
> drivers/perf/arm_pmu.c, as we only needed that for an invocation via a pm
> notifier.
>
> I should be able to give that a spin on some hardware.
>
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> > kernel/cpu_pm.c | 9 ---------
> > 1 file changed, 9 deletions(-)
> >
> > --- a/kernel/cpu_pm.c
> > +++ b/kernel/cpu_pm.c
> > @@ -30,16 +30,9 @@ static int cpu_pm_notify(enum cpu_pm_eve
> > {
> > int ret;
> >
> > - /*
> > - * This introduces a RCU read critical section, which could be
> > - * disfunctional in cpu idle. Copy RCU_NONIDLE code to let RCU know
> > - * this.
> > - */
> > - rcu_irq_enter_irqson();
> > rcu_read_lock();
> > ret = raw_notifier_call_chain(&cpu_pm_notifier.chain, event, NULL);
> > rcu_read_unlock();
> > - rcu_irq_exit_irqson();
>
> To make this easier to debug, is it worth adding an assertion that RCU is
> watching here? e.g.
>
> RCU_LOCKDEP_WARN(!rcu_is_watching(),
> "cpu_pm_notify() used illegally from EQS");
>

My understanding is that rcu_read_lock() implies something along those
lines when PROVE_RCU.

\
 
 \ /
  Last update: 2022-06-14 18:44    [W:0.090 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site