On Wed, 2 Sep 2020 at 14:14, <peterz@xxxxxxxxxxxxx> wrote: > > On Wed, Sep 02, 2020 at 09:03:37AM +0200, Ulf Hansson wrote: > > Lots of cpuidle drivers are using CPU_PM notifiers (grep for > > cpu_pm_enter and you will see) from their idlestates ->enter() > > callbacks. And for those we are already calling > > rcu_irq_enter_irqson|off() in cpu_pm_notify() when firing them. > > Yeah, that particular trainwreck is on my todo list already ... then > again, that list is forever overflowing. > > I'm thinking cpu_pm_unregister_notifier() is not a common thing? The few > I looked at seem to suggest 'never' is a good approximation. The trend is that drivers are turning into regular modules that may also need to manage "->remove()", which may mean unregistering the notifier. Of course, I don't know for sure whether that becomes a problem, but it seems quite limiting. > > It would be fairly trivial to replace the atomic_notifier usage with a > raw_notifier a lock and either stop-machine or IPIs. Better still would > be if we can get rid of it entirely, but I can't tell in a hurry if that > is possible. Okay, let's see. In any case, I was thinking that the patch with CPU idle flag, for letting CPU idle drivers deal with RCU, that you proposed, seems like a good first step. At least it should enable us to solve the problem for runtime PM in psci_enter_domain_idle_state(). Let me update the patch and send it out, then we can continue the discussion over there. Kind regards Uffe
