Re: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug

[Rafael J. Wysocki]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/