On Tue, Dec 20, 2011 at 01:53:42AM +0530, Srivatsa S. Bhat wrote: > If this new definition of our requirement is acceptable (correct me if I am > wrong), then we can do something like the following patch, while still > retaining br locks as non-blocking. > > We make a copy of the current cpu_online_mask, and lock the per-cpu locks of > all those cpus. Then while unlocking, we unlock the per-cpu locks of these cpus > (by using that temporary copy of cpu_online_mask we created earlier), without > caring about the cpus actually online at that moment. > IOW, we do lock-unlock on the same set of cpus, and that too, without missing > the complete lock-unlock sequence in any of them. Guaranteed. And what's to stop a process on a newly added CPU from _not_ spinning in br_read_lock(), even though br_write_unlock() hadn't been done yet? -- 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
