> Alternatively, we could just fix utrace_stop() to always check > fatal_signal_pending() before return.
I don't think it makes sense to roll in the check and have a return value for it unless either it's doing important synchronization there, or every caller needs the check. Oh, but it does retake the siglock before return. So it might as well roll it in and return the __fatal_signal_pending() result taken while it held the lock for recalc_sigpending(). But then you seem to think it can check it lockless. If that's kosher then can't these other checks use it lockless too (i.e. __fatal_signal_pending where you used fatal_signal_pending)? > But personally I think that report->killed buys nothing, but adds > some complexity to the code. If the siglock has to be taken at all, we should roll it into where utrace_stop takes it anyway for recalc_sigpending(). Then the return value, and even report.killed makes some sense, saving us this extra lock overhead. But if it's really OK to use __fatal_signal_pending() lockless in all the utrace.c places, then we can do it your way. > Perhaps, utrace_stop() should return true if we really stopped > (like do_signal_stop() does). This looks more useful to me. I don't see any purpose to such a return value for utrace_stop. Thanks, Roland
