Hello, On Thu, Apr 17, 2014 at 11:05:53AM +0800, Li Zhong wrote: > It seems to me cpu_add_remove_lock is always taken after > device_hotplug_lock. > > So if cpu_add_remove_lock has been acquired by device removing process, > then it means the other online/offline process couldn't successfully try > lock device_hotplug_lock, and will release s_active with a restart > syscall error; > > if cpu_add_remove_lock has been acquired by online/offline process, then > it should already hold device_hotlug_lock, and keeps the device removing > process waiting at device_hotplug_lock. So online/offline process could > release the lock, and finally release s_active soon.
I see. That's kinda nasty tho and lockdep of course doesn't know about it and generates spurious warnings. > But after some further thinking, I seem to understand your point. > s_active has lock order problem with the other series of hotplug related > locks, so it's better to take s_active out of the dependency chain, > rather than the first of the other series of locks? like you suggested > below. Yeah, I think that'd be the right thing to do and we can revert the previous convolution. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
