CC Oleg CC Ingo on 2010-4-15 5:10, Paul Menage wrote: > Looks like select_fallback_rq() shouldn't be calling > cpuset_cpus_allowed_locked(), which does a task_lock(), which isn't > IRQ safe. Also, according to its comments that should only be held > with the cpuset callback_mutex held, which seems unlikely from a > softirq handler. > > Also, calling cpuset_cpus_allowed_locked(p, &p->cpus_allowed) stomps > on state in p without (AFAICS) synchronization. > > The description of commit e76bd8d9850c2296a7e8e24c9dce9b5e6b55fe2f > includes the phrase " I'm fairly sure this works, but there might be a > deadlock hiding" although I think that the lockdep-reported problem is > different than what Rusty had in mind. This problem have been fixed by Oleg Nesterov, and the patchset was merged into tip tree, but it's scheduled for .35 ... http://lkml.org/lkml/2010/3/15/73 Thanks! Miao _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
