On 02/06/2014 06:41 AM, NeilBrown wrote: > On Thu, 06 Feb 2014 03:42:45 +0530 "Srivatsa S. Bhat" > <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote: > >> From: Oleg Nesterov <oleg@xxxxxxxxxx> >> >> Subsystems that want to register CPU hotplug callbacks, as well as perform >> initialization for the CPUs that are already online, often do it as shown >> below: >> >> get_online_cpus(); >> >> for_each_online_cpu(cpu) >> init_cpu(cpu); >> >> register_cpu_notifier(&foobar_cpu_notifier); >> >> put_online_cpus(); >> >> This is wrong, since it is prone to ABBA deadlocks involving the >> cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently >> with CPU hotplug operations). >> >> Interestingly, the raid5 code can actually prevent double initialization and >> hence can use the following simplified form of callback registration: >> >> register_cpu_notifier(&foobar_cpu_notifier); >> >> get_online_cpus(); >> >> for_each_online_cpu(cpu) >> init_cpu(cpu); >> >> put_online_cpus(); >> >> A hotplug operation that occurs between registering the notifier and calling >> get_online_cpus(), won't disrupt anything, because the code takes care to >> perform the memory allocations only once. >> >> So reorganize the code in raid5 this way to fix the deadlock with callback >> registration. >> >> Cc: Neil Brown <neilb@xxxxxxx> >> Cc: linux-raid@xxxxxxxxxxxxxxx >> Cc: stable@xxxxxxxxxxxxxxx >> [Srivatsa: Fixed the unregister_cpu_notifier() deadlock, added the >> free_scratch_buffer() helper to condense code further and wrote the changelog.] >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> >> --- [...] > > > Looks good, thanks. > Shall I wait for a signed-of-by from Oleg, then queue it through my md tree? > Sure, that sounds great, since this patch doesn't have any dependency. Thanks a lot! Oleg, it would be great if you could kindly add your S-O-B to this patch. Thanks! Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
