Messages in this thread | | | Date | Wed, 11 May 2005 15:26:48 -0500 | From | Nathan Lynch <> | Subject | Re: [Lse-tech] [PATCH] cpusets+hotplug+preepmt broken |
| |
On Wed, May 11, 2005 at 12:55:08PM -0700, Paul Jackson wrote: > pj wrote: > > Could you explain why this is -- what is the deadlock? > > On further reading, I see it. You're right. > > Deep in the bowels of the hotplug code, when removing a dead cpu, while > holding the runqueue lock (task_rq_lock), the hotplug code might need to > walk up the cpuset hierarchy, to find the nearest enclosing cpuset that > still has online cpus, as part of figuring where to run a task that is > being kicked off the dead cpu. The runqueue lock is atomic, but getting > the cpuset_sem (needed to walk up the cpuset hierarchy) can sleep. So > you need to get the cpuset_sem before calling task_rq_lock, so as to > avoid the "scheduling while atomic" oops that you reported. Therefore > the hotplug code, and anyone else calling cpuset_cpus_allowed(), which > means sched_setaffinity(), needs to first grab cpuset_sem, so that they > can grab any atomic locks needed, after getting cpuset_sem, not before.
Won't holding cpuset_sem while calling cpuset_cpus_allowed cause a deadlock?
Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |