On 12/20/2011 02:22 AM, Al Viro wrote: > 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? > Oh, right, that has to be handled as well... Hmmm... How about registering a CPU hotplug notifier callback during lock init time, and then for every cpu that gets onlined (after we took a copy of the cpu_online_mask to work with), we see if that cpu is different from the ones we have already locked, and if it is, we lock it in the callback handler and update the locked_cpu_mask appropriately (so that we release the locks properly during the unlock operation). Handling the newly introduced race between the callback handler and lock-unlock code must not be difficult, I believe.. Any loopholes in this approach? Or is the additional complexity just not worth it here? 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
