Re: [PATCH] signals: do_tkill: don't use tasklist_lock

[Roland McGrath]

> > This is the big problem with exec that I've cited before.  It can even
> > happen with group-wide signals that should be fatal, but avoided the
> > __group_complete_signal special fatal case.  (e.g. the thread racing with
> > the exec thread just now unblocked the signal and dequeued it.)  IIRC it
> > was the biggest reason we wanted to revisit the whole MT exec plan.
> 
> Oh. Could you clarify? Afaics, currently exec() can't miss the fatal group
> signal?

It's a while since I thought hard about the exec stuff.  Just now I was
thinking of one particular scenario.  Perhaps it can't really happen.
Here it is:

Threads A and B both block SIGTERM.  An outside process sends SIGTERM,
so it is queued in shared_pending but noone wakes.

A starts an exec.		

B unblocks SIGTERM.  
B enters get_signal_to_deliver, locks, dequeues SIGTERM, unlocks.
Now B is e.g. just before "current->flags |= PF_SIGNALED;".

A locks.  No group-exit is in yet progress.  
A does zap_other_threads, and unlocks.

B enters do_group_exit.  A group-exit is in progress, so it just exits.
SIGTERM is lost.

So I think it really can happen.  Anyway, this is just one example.
It's not so hard to think of ways to address this one (though it gets
nontrivial quick with the coredump case).  But for me it is just an
example of why we still need to step back and think over the whole
exec picture.  

As I said, let's not conflate all that with this thread about a
relatively conservative cleanup.  We can discuss that separately.
(But I think it might need to wait for a breather and time for
other dust to settle.)


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/