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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>