The patch titled uml: kernels on {i386,x86_64} produce bad coredumps has been added to the -mm tree. Its filename is uml-kernels-on-i386x86_64-produce-bad-coredumps.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ ------------------------------------------------------ Subject: uml: kernels on {i386,x86_64} produce bad coredumps From: ppluzhnikov@xxxxxxxxxx (Paul Pluzhnikov) 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@xxxxxxxxxx> Cc: Jeff Dike <jdike@xxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- arch/um/sys-i386/asm/elf.h | 2 ++ arch/um/sys-x86_64/asm/elf.h | 2 ++ 2 files changed, 4 insertions(+) diff -puN arch/um/sys-i386/asm/elf.h~uml-kernels-on-i386x86_64-produce-bad-coredumps arch/um/sys-i386/asm/elf.h --- a/arch/um/sys-i386/asm/elf.h~uml-kernels-on-i386x86_64-produce-bad-coredumps +++ a/arch/um/sys-i386/asm/elf.h @@ -75,6 +75,8 @@ typedef struct user_i387_struct elf_fpre pr_reg[16] = PT_REGS_SS(regs); \ } while (0); +#define task_pt_regs(t) (&(t)->thread.regs) + struct task_struct; extern int elf_core_copy_fpregs(struct task_struct *t, elf_fpregset_t *fpu); diff -puN arch/um/sys-x86_64/asm/elf.h~uml-kernels-on-i386x86_64-produce-bad-coredumps arch/um/sys-x86_64/asm/elf.h --- a/arch/um/sys-x86_64/asm/elf.h~uml-kernels-on-i386x86_64-produce-bad-coredumps +++ a/arch/um/sys-x86_64/asm/elf.h @@ -95,6 +95,8 @@ typedef struct user_i387_struct elf_fpre (pr_reg)[25] = 0; \ (pr_reg)[26] = 0; +#define task_pt_regs(t) (&(t)->thread.regs) + struct task_struct; extern int elf_core_copy_fpregs(struct task_struct *t, elf_fpregset_t *fpu); _ Patches currently in -mm which might be from ppluzhnikov@xxxxxxxxxx are uml-kernels-on-i386x86_64-produce-bad-coredumps.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html