Messages in this thread | | | Date | Fri, 26 May 2017 09:47:00 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [patch V3 25/32] kprobes: Cure hotplug lock ordering issues |
| |
On Thu, 25 May 2017, Masami Hiramatsu wrote: > On Wed, 24 May 2017 10:15:36 +0200 > Thomas Gleixner <tglx@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 :)
| |