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
