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.