[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210219211427.GA27750@amd>
Date: Fri, 19 Feb 2021 22:14:27 +0100
From: Pavel Machek <pavel@....cz>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Daniel Lezcano <daniel.lezcano@...aro.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Russell King <rmk+kernel@...linux.org.uk>,
Tony Lindgren <tony@...mide.com>,
Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.10 020/104] ARM: OMAP2+: Fix suspcious RCU usage splats
for omap_enter_idle_coupled
Hi!
> [ Upstream commit 06862d789ddde8a99c1e579e934ca17c15a84755 ]
>
> We get suspcious RCU usage splats with cpuidle in several places in
> omap_enter_idle_coupled() with the kernel debug options enabled:
>
> RCU used illegally from extended quiescent state!
> ...
> (_raw_spin_lock_irqsave)
> (omap_enter_idle_coupled+0x17c/0x2d8)
> (omap_enter_idle_coupled)
> (cpuidle_enter_state)
> (cpuidle_enter_state_coupled)
> (cpuidle_enter)
>
> Let's use RCU_NONIDLE to suppress these splats. Things got changed around
> with commit 1098582a0f6c ("sched,idle,rcu: Push rcu_idle deeper into the
> idle path") that started triggering these warnings.
I just wanted to check... AFAICT RCU_NONIDLE puts some quite heavy
instrumentation around each statement; does it makes sense to group
the statements into one in cases like this?
Best regards,
Pavel
> @@ -194,9 +194,9 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
> mpuss_can_lose_context)
> gic_dist_disable();
>
> - clkdm_deny_idle(cpu_clkdm[1]);
> - omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
> - clkdm_allow_idle(cpu_clkdm[1]);
> + RCU_NONIDLE(clkdm_deny_idle(cpu_clkdm[1]));
> + RCU_NONIDLE(omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON));
> + RCU_NONIDLE(clkdm_allow_idle(cpu_clkdm[1]));
>
> if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD) &&
> mpuss_can_lose_context) {
--
http://www.livejournal.com/~pavelmachek
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists