On Thu, 25 May 2017, Masami Hiramatsu wrote: > On Wed, 24 May 2017 10:15:36 +0200 > Thomas Gleixner <t...@linutronix.de> wrote: > > > Converting the cpu hotplug locking to a percpu rwsem unearthed hidden lock > > ordering problems. > > > > There is a wide range of locks involved in this: kprobe_mutex, > > jump_label_mutex, ftrace_lock, text_mutex, event_mutex, > > func_hash->regex_lock and a gazillion of lock order permutations with > > nested get_online_cpus() calls. > > And module_mutex too ;-)
Indeed. > > Some of those permutations are potential deadlocks even with the current > > nesting hotplug locking scheme, but they can't be discovered by lockdep. > > > > The conversion of the hotplug locking to a percpu rwsem requires to prevent > > nested locking, so it's required to take the hotplug rwsem early in the > > call chain and establish a proper lock order. > > > > After quite some analysis and going down the wrong road severa times the > > following lock order has been chosen: > > > > kprobe_mutex -> cpus_rwsem -> jump_label_mutex -> text_mutex > > This seems only change the locking order of module_mutex and > cpus_rwsem. Previously module_mutex -> cpus_rwsem, now > cpus_rwsem -> module_mutex. and it seems OK to me. > (checked in module.c and other use cases of module_mutex) This also changes the jump label / text mutex interaction with hotplug locking if you look closely :)