Messages in this thread | | | Date | Fri, 10 Feb 2006 21:36:37 +0100 | From | Pavel Machek <> | Subject | Re: [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/
| |