Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: [PATCH] notifier: Make atomic_notifiers use raw_spinlock | Date | Mon, 23 Nov 2020 14:52:23 +0000 |
| |
On 23/11/20 14:14, Peter Zijlstra wrote: > On Sun, Nov 22, 2020 at 08:19:04PM +0000, Valentin Schneider wrote: [...] >> Two points worth noting: >> >> 1) That this is conceptually the same issue as pointed out in: >> 313c8c16ee62 ("PM / CPU: replace raw_notifier with atomic_notifier") >> 2) Only the _robust() variant of atomic_notifier callchains suffer from >> this >> >> AFAICT only the cpu_pm_notifier_chain really needs to be changed, but >> singling it out would mean introducing a new (truly) non-blocking API. At >> the same time, callers that are fine with any blocking within the call >> chain should use blocking notifiers, so patching up all atomic_notifier's >> doesn't seem *too* crazy to me. > > How long are these notifier chains?,
On said Juno I get:
gic_notifier() arch_timer_cpu_pm_notify() fpsimd_cpu_pm_notifier() cpu_pm_pmu_notify() x2 hyp_init_cpu_pm_notifier()
(I would take a guess that there's one PMU cb per cluster due to big.LITTLE faffery)
> and all this pcs_enter_idle_state() > is still horribly broken vs RCU, witness the RCU_NONIDLE() there and the > rcu_irq_enter_irqson() in the pm_notifier code. >
Hadn't paid attention to that, that's indeed... Interesting.
> That said, we're running these notifiers from the idle path with IRQs > disabled, so taking that spinlock isn't going to make it worse..
And it's already taken on !PREEMPT_RT.
| |