linux-kernel - Re: [PATCH 8/6] signals: send_signal: factor out SIGNAL_GROUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Mar 2008 20:51:22 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Roland McGrath <roland@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Pavel Emelyanov <xemul@...nvz.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 8/6] signals: send_signal: factor out SIGNAL_GROUP_EXIT checks

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.

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