On Wed, 2 Sep 2020 at 14:14, email@example.com 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