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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
