On Mon, May 14, 2007 at 11:48:46AM +0530, Srivatsa Vaddagiri wrote: > On Sun, May 13, 2007 at 09:33:41AM -0700, Linus Torvalds wrote: > > On Sun, 13 May 2007, Gautham R Shenoy wrote: > > > RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the > > > well known refcounting model. > > > > Yes. And usign the "preempt count" as a refcount is fairly natural, no? > > We do already depend on that in many code-paths. > > > Tackling that requires some state bit in task_struct to educate > read_lock to be a no-op if write lock is already held by the thread. > > In summary, get/put_hot_cpu() will need to be (slightly) more complex than > something like get/put_cpu(). Perhaps this complexity was what put off > Andrew when he suggested the use of freezer > (http://lkml.org/lkml/2006/11/1/400)
Atleast with get_hot_cpu()/put_hot_cpu(), complexity is limited to the implementation of those interfaces and not all over the kernel. Having worked on CPU hotplug in the past, I have no doubt that this is the most simple *locking model* for cpu hotplug events. > > For example, since all users of cpu_online_map should be pure *readers* > > (apart from a couple of cases that actually bring up a CPU), you can do > > things like > > > > #define cpu_online_map check_cpu_online_map() > > > > static inline cpumask_t check_cpu_online_map(void) > > { > > WARN_ON(!preempt_safe()); /* or whatever lock we decide on */ > > return __real_cpu_online_map; > > } > > I remember Rusty had a similar function to check for unsafe references > to cpu_online_map way back when cpu hotplug was being developed. It will > be a good idea to reintroduce that back. One possibility is to have a generation counter for all cpu events and save it in cpumask_t (or some debug version of it) every time we snapshot the online cpu mask. We can then put checks in places where we access them whether the generation counter matches the current generation or not. If it doesn't it would indicate that saved cpumask not being "updated" during cpu hotplug events. In the cpu hotplug event handlers, we can force all saved online cpumasks to be "updated". Such debug code may help detect the locking violators. Thanks Dipankar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/