On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote: > On 02/18, Oleg Nesterov wrote: > > > > On 02/17, Rafael J. Wysocki wrote: > > > > > > Alternatively, we can move the check into refrigerator(), like this: > > > > > > --- linux-2.6.20-git13.orig/kernel/power/process.c > > > +++ linux-2.6.20-git13/kernel/power/process.c > > > @@ -39,6 +39,11 @@ void refrigerator(void) > > > /* Hmm, should we be allowed to suspend when there are realtime > > > processes around? */ > > > long save; > > > + > > > + /* Freeze the task unless there is a vfork completion pending */ > > > + if (current->vfork_done) > > > + return; > > > + > > > > This means that "current" returns to user space (get_signal_to_deliver > > will clear TIF_SIGPENDING) and runs. While try_to_freeze_tasks() thinks > > it is frozen. > > Ah, sorry. I am wrong, current has no PF_FROZEN yet. > > However, this means that sys_vfork() makes impossible to freeze processes > until child exits/execs. Not good.
Yes, but this also is the current behavior. I think the real solution would be to use an interruptible completion in the vfork code. It was discussed some time ago and, IIRC, Ingo had an experimental patch that implemented it. Still, for the suspend this really is not an issue in practice, so it wasn't merged. It may be a good time to solve this problem now. :-) Greetings, 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/
