Re: [PATCH 0/3] coredump: fix the ancient signal problems

From: Mandeep Singh Baines
Date: Tue Feb 19 2013 - 20:29:52 EST

On Sun, Feb 17, 2013 at 11:18 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
> Hello.
> These problems are really annoying. I reported and tried to fix
> them in 2008 (see
> but nobody was interested.
> Since then I had a lot of (to some degree contradictory) bug reports:
> we do not want the interrupted coredumps (this is what the current code
> tries to achieve but the logic is very wrong), but at the same time some
> people blame the coredump because it is not interruptible.
> And every time the discussion was confusing, it is not clear what should
> we actually do to make everyone happy.
> Linus, et al, could you please ack/nack the intent? Of course I will
> appreciate if you can review the code, but what I am actually worried
> about is the user-visible change: the coredumping becomes killable but
> only by the _explicit_ SIGKILL, other fatal signals are "ignored".
> The changes were not tested at all, I'll try to recheck everything and
> test this tomorrow. I am sending this series right now because I strongly
> believe that the recent -mm patches in this area are not right and should
> be dropped, and I also disagree with the pending v2.
> Mandeep, just in case please note that 1/3 alone should fix the problems
> with non-fatal signals and wait_dump_helper(). As for the freezer, afaics
> we are almost ready for the (slightly modified) fix proposed in
> Oleg.

For the whole series:

Tested-by: Mandeep Singh Baines <msb@xxxxxxxxxxxx>

This was an important issue for us so I'm in the process of merging
these into the ChromiumOS kernel tree.


> fs/coredump.c | 33 +++++++++++++++++++--------------
> include/linux/sched.h | 1 +
> kernel/signal.c | 6 ++++--
> 3 files changed, 24 insertions(+), 16 deletions(-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at