Re: [PATCH -mm] swsusp: freeze user space processes first

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > then i'd suggest to change the vfork implementation to make this code 
> > > freezable. Nothing that userspace does should cause freezing to fail.  
> > > If it does, we've designed things incorrectly on the kernel side.
> > 
> > Does that also mean we have bugs with signal delivery? If vfork(); 
> > sleep(100000); causes process to be uninterruptible for few days, it 
> > will not be killable and increase load average...
> 
> "half-done" vforks are indeed in uninterruptible sleep. They are not 
> directly killable, but they are killable indirectly through their 
> parent. But yes, in theory it would be cleaner if the vfork code used 
> wait_for_completion_interruptible(). It has to be done carefully though, 
> for two reasons:
> 
> - implementational: use task_lock()/task_unlock() to protect
>   p->vfork_done in mm_release() and in do_fork().
> 
> - semantical: signals to a vfork-ing parent are defined to be delayed
>   to after the child has released the parent/MM.

We could still deliver sigkill and stopping for the freezer, no?

> the (untested) patch below handles issue #1, but doesnt handle issue #2: 
> this patch opens up a vfork parent to get interrupted early, with any 
> signal.

It seems to fix D state for me, and does not seem to have any ill
effects.

							Pavel

-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...