Hi Alex,
I've had a better look - the per-cpu driver interface doesn't use locking at all so any potential deadlock will of course not occur.
The reason I used cpuidle_driver_ref was to ensure that driver data did not go away while I was reading it, as there isn't any notification for driver changes.
Hi,
theoretically nothing prevent the user to unload the module. In practice, that does not happen because the drivers are usually compiled in. But I wouldn't rely on that.
I saw a call chain: cpu_idle_loop -> cpu_idle_poll -> cpuidle_get_cpu_driver() So looks nohz is don't worry on this point too.
Also, in the code path, the different idle states are inspected to find the one fitting the ns_delay. On some architecture (eg. x86), one or several idle states can be removed at runtime if they switch to battery<->AC [1]
yes, it is a another concern on other architecture. but since hmp is just on arm now...
But the bug you are facing is probably coming from the same cpu is taking the same lock twice because of an interrupt.
yes, the patch is ok for this scenario.