summaryrefslogtreecommitdiffstats
path: root/mm/memcontrol.c
diff options
context:
space:
mode:
authorOleg Nesterov <oleg@redhat.com>2010-03-05 13:44:14 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2010-03-06 11:26:46 -0800
commit5c99cbf49a6e1a1efd25b11f4604c65c455e1612 (patch)
treee2a3451cc87f83b15f23a0472339be81770e12da /mm/memcontrol.c
parent30736a4d43f4af7f1a7836d6a266be17082195c4 (diff)
coredump: set ->group_exit_code for other CLONE_VM tasks too
User visible change. do_coredump() kills all threads which share the same ->mm but only the coredumping process gets the proper exit_code. Other tasks which share the same ->mm die "silently" and return status == 0 to parent. This is historical behaviour, not actually a bug. But I think Frank Heckenbach rightly dislikes the current behaviour. Simple test-case: #include <stdio.h> #include <unistd.h> #include <signal.h> #include <sys/wait.h> int main(void) { int stat; if (!fork()) { if (!vfork()) kill(getpid(), SIGQUIT); } wait(&stat); printf("stat=%x\n", stat); return 0; } Before this patch it prints "stat=0" despite the fact the child was killed by SIGQUIT. After this patch the output is "stat=3" which obviously makes more sense. Even with this patch, only the task which originates the coredumping gets "|= 0x80" if the core was actually dumped, but at least the coredumping signal is visible to do_wait/etc. Reported-by: Frank Heckenbach <f.heckenbach@fh-soft.de> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: WANG Cong <xiyou.wangcong@gmail.com> Cc: Roland McGrath <roland@redhat.com> Cc: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/memcontrol.c')
0 files changed, 0 insertions, 0 deletions