Re: [Bug 200447] infinite loop in fork syscall

[Oleg Nesterov]

On 07/10, Eric W. Biederman wrote:
>
> > 2. To simplify, lets suppose we add the new PF_INFORK flag. Yes, this is bad,
> >    we can do better. I think we can simply add "struct hlist_head forking_threads"
> >    into signal_struct, so complete_signal() can just do hlist_for_each_entry()
> >    rather than for_each_thread() + PF_INFORK check. We don't even need a new
> >    member in task_struct.
>
> We still need the distinction between multi-process signals and single
> process signals (which is the hard part).  For good performance of
> signal delivery to multi-threaded tasks we still need a new member in
> signal_struct.  Plus it is a bit more work to update the list or even
> walk the list than a sequence counter.
>
> So I think adding a sequence counter to let us know about multiprocess
> signals is the local optimum.

But we can not rely on on a sequence counter, there are other reasons why
fork() should fail even if fatal_signal_pending() == F and the counter was
not changed (no multi-process signals).

> > 3. copy_process() can simply block/unblock all signals (except KILL/STOP), see
> >    the "patch" below.
>
> All signals are effectively blocked for the duration of the fork for the
> calling task.    Where we get into trouble and where we need a fix for
> correctness is that another thread can dequeue the signal.   Blocking
> signals of the forking task does not change that.

See my reply to Linus. Please look at the change in complete_signal().

> I think that reveals another bug in our current logic.  For blocked
> multi-process signals we don't ensure they get delivered to both the
> parent and the child if the signal logically comes in after the fork.

I thougth thought this too. I simply do not know if this is right or not.

For now I assume that this is correct and by design, iow if fork() is called
with (say) SIGTERM blocked, then we do not care if kill_pgrp(SIGTERM) misses
the new child.

If we want to change this, I think this needs another discussion.

Oleg.