All of lore.kernel.org
 help / color / mirror / Atom feed
* [patch] UML kernels on {i386,x86_64} produce bad coredumps
@ 2011-01-25 23:14 Paul Pluzhnikov
  2011-01-26  4:29 ` WANG Cong
  0 siblings, 1 reply; 2+ messages in thread
From: Paul Pluzhnikov @ 2011-01-25 23:14 UTC (permalink / raw)
  To: user-mode-linux-devel; +Cc: ppluzhnikov, linux-kernel, Jeff Dike, Andrew Morton

Greetings,

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}.

Thanks,
--
Paul Pluzhnikov

P.S. Google has blanket FSF copyright assignment.


Signed-off-by: Paul Pluzhnikov <ppluzhnikov@google.com>


diff --git a/arch/um/sys-i386/asm/elf.h b/arch/um/sys-i386/asm/elf.h
index a979a22..d964a41 100644
--- a/arch/um/sys-i386/asm/elf.h
+++ b/arch/um/sys-i386/asm/elf.h
@@ -75,6 +75,8 @@ typedef struct user_i387_struct elf_fpregset_t;
 	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 --git a/arch/um/sys-x86_64/asm/elf.h b/arch/um/sys-x86_64/asm/elf.h
index d760967f..d6d5af3 100644
--- a/arch/um/sys-x86_64/asm/elf.h
+++ b/arch/um/sys-x86_64/asm/elf.h
@@ -95,6 +95,8 @@ typedef struct user_i387_struct elf_fpregset_t;
 	(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);

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [patch] UML kernels on {i386,x86_64} produce bad coredumps
  2011-01-25 23:14 [patch] UML kernels on {i386,x86_64} produce bad coredumps Paul Pluzhnikov
@ 2011-01-26  4:29 ` WANG Cong
  0 siblings, 0 replies; 2+ messages in thread
From: WANG Cong @ 2011-01-26  4:29 UTC (permalink / raw)
  To: linux-kernel; +Cc: user-mode-linux-devel

On Tue, 25 Jan 2011 15:14:33 -0800, Paul Pluzhnikov wrote:
...
> 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.


I think this was missed due to some cleanups of the core elf
change, UML is one of the part overlooked by people. :-/

> 
> Attached patch fixes this for SUBARCH={x86_64,i386}.
> 
> Thanks,
> --
> Paul Pluzhnikov
> 
> P.S. Google has blanket FSF copyright assignment.
> 
> 
> Signed-off-by: Paul Pluzhnikov <ppluzhnikov@google.com>
> 

Acked-by: WANG Cong <xiyou.wangcong@gmail.com>

Thanks.



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-01-26  4:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-25 23:14 [patch] UML kernels on {i386,x86_64} produce bad coredumps Paul Pluzhnikov
2011-01-26  4:29 ` WANG Cong

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.