On Sunday, 18 February 2007 17:19, Oleg Nesterov wrote: > On 02/18, Rafael J. Wysocki wrote: > > > > On Sunday, 18 February 2007 15:52, Oleg Nesterov wrote: > > > > > > And now another problem: exec. de_thread() sleeps in TASK_UNINTERRUPTIBLE > > > waiting for all sub-threads to die, and we have the same "deadlock" if > > > one of them is frozen. This is nasty. Probably we can change the ->state > > > to TASK_INTERRUPTIBLE and add try_to_freeze(), or play with the new PF_ > > > flag, but I am not sure it is safe to freeze() the task which is deep > > > in the exec() path. > > > > Hm, I haven't been aware of this case. > > > > Well, probably we can do something like in the patch that I've just sent: > > the > > child that enters the refrigerator should know that the parent is > > uninterruptible and will wait for it to exit. Thus it can either mark the > > parent as frozen or just exit the refrigerator without freezing itself. > > Sub-thread could already sleep in refrigerator when another thread does exec. > So we have no choice but somehow freeze the execer. But again, I don't know > if it is safe to freeze it here, at de_thread() stage. It is called from > load_xxx_binary(), we may hold some important locks...
So it probably isn't safe. Rafael - 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/
