Messages in this thread | | | From | Roland McGrath <> | Subject | Re: [PATCH 1/1] signal: make group kill signal fatal | Date | Tue, 2 Jun 2009 18:52:15 -0700 (PDT) |
| |
> > > Heh. In this case you have another (long-standing) issue, please note > > > the "if (p->flags & PF_EXITING)" check in wants_signal().
Hmm. wants_signal():
if (p->flags & PF_EXITING) return 0; if (sig == SIGKILL) return 1;
Perhaps we should reverse the order of those two?
But also I'm now reminded that complete_signal() short-circuits for the single-threaded case and never does the sig_fatal() case.
This means a single-threaded process will have SIGKILL in shared_pending but not in its own pending so __fatal_signal_pending() will be false, no?
I'm also now wondering if in some of our recent signals discussions we have been assuming that SIGNAL_GROUP_EXIT is set when a fatal signal is pending. We might be leaving some other unintended hole since that's not really true.
Probably we should just fiddle complete_signal() to do that stuff for the single-threaded case too. (That obviates the wants_signal change above.)
> Yes, if a thread exits with the pending signal, then of course interruptible > wait doesn work.
Along the same lines of the recent core dump discussion, I think it would be proper to fix this so TIF_SIGPENDING isn't left set (nor is newly set) by a signal that won't affect it later.
> We can clear TIF_SIGPENDING, and we can change recalc_sigpending_xxx() > to take PF_EXITING into account (or change their callers), but this > needs changes. And I am not sure this will right.
I think we want recalc_sigpending_tsk to be consistent with wants_signal and the other conditions controlling signal_wake_up calls. But indeed we need to think through any ramifications carefully.
Thanks, Roland
| |