[lkml]   [2018]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Bug 200447] infinite loop in fork syscall
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.


 \ /
  Last update: 2018-07-11 14:09    [W:0.028 / U:20.592 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site