lkml.org 
[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -mm] swsusp: freeze user space processes first
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...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-10 21:39    [W:0.122 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site