On 12/20/2011 07:36 PM, Al Viro wrote: > On Tue, Dec 20, 2011 at 06:20:44PM +0530, Srivatsa S. Bhat wrote: > >>> Hey, actually there is a simple solution: just nip it (or rather delay it) >>> in the bud ;) That is, we watch out for CPU_UP_PREPARE event and lock it >>> up there itself using our spinlock.. that way, that cpu will not come up >>> until we are done executing br_write_unlock(). In fact, we can even fail >>> the onlining of that cpu by returning appropriate value from our callback, >>> but that would be too harsh.. so we can settle for delaying the cpu online > > Eeeek... Are you serious about leaving a spinlock grabbed by notifier > callback and not released until another callback call? That would be one > hell of a constraint on what these notifiers can do - _nothing_ between > these calls (including other notifier callbacks, etc.) would be allowed > to block. > > That sounds extremely brittle... > Sorry but I didn't quite get your point... No two cpu hotplug operations can race because of the cpu_hotplug lock they use. Hence, if a cpu online operation begins, it has to succeed or fail eventually. No other cpu hotplug operation can intervene. Ditto for cpu offline operations. Hence a CPU_UP_PREPARE event *will* be followed by a corresponding CPU_UP_CANCELED or CPU_ONLINE event for the same cpu. (And we ignore the CPU_STARTING event that comes in between, on purpose, so as to avoid the race with cpu_online_mask). Similar is the story for offline operation. And if the notifier grabs the spinlock and keeps it locked between these 2 points of a cpu hotplug operation, it ensures that our br locks will spin, instead of block till the cpu hotplug operation is complete. Isn't this what we desired all along? "A non-blocking way to sync br locks with cpu hotplug"? Or am I missing something? Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
