Re: [PATCH 8/6] signals: send_signal: factor out SIGNAL_GROUP_EXIT checks

[Oleg Nesterov <oleg@tv-sign.ru>]

On 03/10, Roland McGrath wrote:
>
> I don't really like dropping the signal on the floor.

To clarify: my opinion is quite opposite, but it is only based on the
"personal feeling", I don't have any "strong" arguments. If you still
think we shouldn't do this, please nack this change.

> If the posting says
> it succeeded (vs -ESRCH) then I'd like to see it appear later in the
> pending set of the zombie thread, when we look at /proc/pid/status at exit
> tracing or whatnot (and in core dumps).  Seeing those pending signal bits
> is sometimes a useful clue about how something died in a strange scenario.

As for core dumps. Suppose that the task has already started do_coredump()
and another signal comes. Why should fill_prstatus() report this new signal?
This doesn't look exactly right for me. The coredump should try to reflect
the state of the task which it had when it was killed.

Actually, the same for zombies. If the task sits in Z state, one can look
at /proc/pid/status to see what signals it had when exited. To me, it looks
just better if it is visible that a zombie doesn "accept" the new signals,
because it is dead. (offtopic: currently the single-threaded exit doesn't
set SIGNAL_GROUP_EXIT. This doesn't matter now, but I think it would be
nice to be more consistent here).

Now, suppose that due to some kernel bug the running thread/process doesn't
want to die despite of SIGNAL_GROUP_EXIT. In that case another kill() may help
because of additional wakeup, but this will hide the problem which won't be
reported.

But again, I see your point, thanks.

Oleg.