Messages in this thread | | | From | Roland McGrath <> | Subject | Re: [PATCH] signals: do_tkill: don't use tasklist_lock | Date | Fri, 7 Mar 2008 13:51:34 -0800 (PST) |
| |
> > 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
| |