2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-28 07:04:00 +08:00
linux-next/arch/um/sys-x86_64
Paul Pluzhnikov 13e165baf6 uml: kernels on {i386,x86_64} produce bad coredumps
One of our users reported that when a user-level program SIGSEGVs under
UML kernel, the resulting core dump is not very usable.

I have reproduced that with the latest kernel:

  make ARCH=um defconfig; make ARCH=um

Run the resulting kernel, then "inside" run this program:

#include <pthread.h>

void *fn(void *p)
{
 abort();
}

int main()
{
 pthread_t tid;
 pthread_create(&tid, 0, fn, 0);
 pthread_join(tid, 0);
 return 0;
}

Analyze the coredump with GDB. Here is what you'll see:

sudo gdb -q -ex 'set solib-absolute-prefix ../root_fs' -ex 'file ../root_fs/var/tmp/mt-abort' -ex 'core ../root_fs/var/tmp/core.762'
Reading symbols from /usr/local/google/root_fs/var/tmp/mt-abort...done.
[New Thread 763]
[New Thread 762]
Core was generated by `./mt-abort'.
Program terminated with signal 6, Aborted.
#0  0x0000000040255250 in raise () from ../root_fs/lib64/libc.so.6
(gdb) info thread
  2 Thread 762  0x0000000000000000 in ?? ()
* 1 Thread 763  0x0000000040255250 in raise () from ../root_fs/lib64/libc.so.6

Note that thread#2 looks funny.

(gdb) thread 2
[Switching to thread 2 (Thread 762)]#0  0x0000000000000000 in ?? ()
(gdb) info reg
rax            0x0      0
rbx            0x0      0
rcx            0x0      0
rdx            0x0      0
rsi            0x0      0
rdi            0x0      0
rbp            0x0      0x0
rsp            0x0      0x0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0x0      0
eflags         0x0      [ ]
cs             0x0      0
ss             0x0      0
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0

Examining the core shows that NT_PRSTATUS notes for all threads other than
the one that crashed are zeroed out.

I believe this is happening because neither ELF_CORE_COPY_TASK_REGS nor
task_pt_regs are defined under ARCH=um, and so elf_core_copy_task_regs()
becomes a no-op.

Attached patch fixes this for SUBARCH={x86_64,i386}.

Signed-off-by: Paul Pluzhnikov <ppluzhnikov@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22 17:44:09 -07:00
..
asm uml: kernels on {i386,x86_64} produce bad coredumps 2011-03-22 17:44:09 -07:00
shared/sysdep x86, um: get rid of excessive includes of uml-config.h 2008-10-22 22:55:22 -07:00
bug.c uml: style fixes in arch/um/sys-x86_64 2008-02-05 09:44:31 -08:00
bugs.c uml: further bugs.c tidying 2008-02-05 09:44:25 -08:00
delay.c [PATCH] uml: fix unreasonably long udelay 2007-04-02 10:06:08 -07:00
fault.c uml: style fixes pass 3 2007-10-16 09:43:05 -07:00
ksyms.c uml: memcpy export needs to follow host declaration 2008-06-06 11:29:10 -07:00
Makefile x86: Fix breakage of UML from the changes in the rwsem system 2010-01-17 21:51:29 -08:00
mem.c uml: remove useless comments 2009-04-01 08:59:17 -07:00
ptrace_user.c uml: style fixes in arch/um/sys-x86_64 2008-02-05 09:44:31 -08:00
ptrace.c ptrace: cleanup arch_ptrace() on um 2010-10-27 18:03:12 -07:00
setjmp.S [PATCH] uml: Use klibc setjmp/longjmp 2006-09-26 08:49:05 -07:00
signal.c UML: add kernel.h include to signal.c 2010-04-20 17:47:24 +02:00
stub_segv.c uml: simplify SIGSEGV handling 2008-02-05 09:44:28 -08:00
stub.S uml: fix a section warning 2009-06-16 19:47:47 -07:00
syscall_table.c improve sys_newuname() for compat architectures 2010-03-12 15:52:32 -08:00
syscalls.c improve sys_newuname() for compat architectures 2010-03-12 15:52:32 -08:00
sysrq.c uml: style fixes in arch/um/sys-x86_64 2008-02-05 09:44:31 -08:00
tls.c uml: rename pt_regs general-purpose register file 2007-10-16 09:43:06 -07:00
user-offsets.c uml: tidy ptrace interface 2008-05-13 08:02:21 -07:00