current bk goes BUG on ia64 when dumping core

current bk goes BUG on ia64 when dumping core

[Andrew Morton]

When running the latest LTP code, it dies in the new coredump code.

I'm afraid I won't have time to work on this for a week or so.

The ia64 oops code should report current->comm btw.  It is often useful.



kernel BUG at fs/binfmt_elf.c:1366!
abort01[9605]: bugcheck! 0 [1]

Pid: 9605, CPU 2, comm:              abort01
psr : 0000101008026018 ifs : 8000000000001028 ip  : [<a000000100183640>]    Not tainted
ip is at elf_core_dump+0xf20/0x14c0
unat: 0000000000000000 pfs : 0000000000001028 rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr  : a65a5a6aae69a957
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0  : a000000100183640 b6  : a00000010001a5c0 b7  : a000000100086cc0
f6  : 1003e0fc0fc0fc0fc0fc1 f7  : 0ffd9a200000000000000
f8  : 1003e0000000000000240 f9  : 1003e0000000000002490
f10 : 1003e000000000ea00000 f11 : 1003e00000000367b7ad0
r1  : a000000100980000 r2  : 0000000000004000 r3  : 0000000000004000
r8  : 0000000000000024 r9  : 0000000000000000 r10 : 00000000000c0180
r11 : 000000000000c018 r12 : e00000000c55fcb0 r13 : e00000000c558000
r14 : e00000000c55fc50 r15 : a00000010079baa8 r16 : 00000000000000fd
r17 : 0000000000000000 r18 : 00000000000000fd r19 : 0000000000000003
r20 : a0000001008fea50 r21 : a0000001008e5a10 r22 : a0000001008fea50
r23 : e000000004974dd0 r24 : e00000003d180038 r25 : e00000003c7e0f00
r26 : 0000000000000000 r27 : 0000000000000000 r28 : 0000000000000000
r29 : 0000000000000000 r30 : 0000000000000000 r31 : 0000000000000000

Call Trace:
 [<a000000100018f00>] show_stack+0x80/0xa0
                                spà0000000c55f880 bspà0000000c559320
 [<a00000010003ba20>] die+0x180/0x220
                                spà0000000c55fa50 bspà0000000c5592e8
 [<a00000010003bd40>] ia64_bad_break+0x220/0x340
                                spà0000000c55fa50 bspà0000000c5592c0
 [<a0000001000120c0>] ia64_leave_kernel+0x0/0x260
                                spà0000000c55fae0 bspà0000000c5592c0
 [<a000000100183640>] elf_core_dump+0xf20/0x14c0
                                spà0000000c55fcb0 bspà0000000c559178
 [<a000000100139860>] do_coredump+0x4e0/0x560
                                spà0000000c55fd50 bspà0000000c559118
 [<a0000001000afdd0>] get_signal_to_deliver+0x6b0/0x900
                                spà0000000c55fda0 bspà0000000c5590b8
 [<a000000100039820>] ia64_do_signal+0x120/0x460
                                spà0000000c55fda0 bspà0000000c559038
 [<a000000100019830>] do_notify_resume_user+0xb0/0x100
                                spà0000000c55fe20 bspà0000000c559008
 [<a000000100012560>] notify_resume_user+0x40/0x60
                                spà0000000c55fe20 bspà0000000c558fb0
 [<a000000100012490>] skip_rbs_switch+0xb0/0xc0
                                spà0000000c55fe30 bspà0000000c558fb0
 

Re: current bk goes BUG on ia64 when dumping core

[Andrew Morton]

Andrew Morton <akpm@osdl.org> wrote:
>
>  kernel BUG at fs/binfmt_elf.c:1366!

This is inside the ELF_CORE_WRITE_EXTRA_PHDRS macro btw.

Re: current bk goes BUG on ia64 when dumping core

[Roland McGrath]

> When running the latest LTP code, it dies in the new coredump code.

This is what I predicted when I sent the second ia64 version of the patch.
Please refer to that message for complete testing instructions to verify
the core format is correct (assuming it doesn't crash any more with the new
patch).  I've made another cosmetic change to avoid using "vsyscall" in
variable names, and here is that version of the patch relative to the
current 2.6 tree.


Thanks,
Roland


Index: linux-2.5/include/asm-ia64/elf.h
=================================RCS file: /home/cvs/linux-2.5/include/asm-ia64/elf.h,v
retrieving revision 1.11
diff -u -b -p -r1.11 elf.h
--- linux-2.5/include/asm-ia64/elf.h 3 Oct 2003 22:45:47 -0000 1.11
+++ linux-2.5/include/asm-ia64/elf.h 6 Oct 2003 04:53:23 -0000
@@ -218,20 +218,23 @@ do {										\
 #define ELF_CORE_EXTRA_PHDRS		(GATE_EHDR->e_phnum)
 #define ELF_CORE_WRITE_EXTRA_PHDRS						\
 do {										\
-	const struct elf_phdr *const vsyscall_phdrs =			      \
+	const struct elf_phdr *const gate_phdrs =			      \
 		(const struct elf_phdr *) (GATE_ADDR + GATE_EHDR->e_phoff);   \
 	int i;									\
-	Elf32_Off ofs = 0;						      \
+	Elf64_Off ofs = 0;						      \
 	for (i = 0; i < GATE_EHDR->e_phnum; ++i) {				\
-		struct elf_phdr phdr = vsyscall_phdrs[i];		      \
+		struct elf_phdr phdr = gate_phdrs[i];			      \
 		if (phdr.p_type = PT_LOAD) {					\
-			BUG_ON(ofs != 0);				      \
-			ofs = phdr.p_offset = offset;				\
 			phdr.p_memsz = PAGE_ALIGN(phdr.p_memsz);	      \
 			phdr.p_filesz = phdr.p_memsz;			      \
+			if (ofs = 0) {					      \
+				ofs = phdr.p_offset = offset;		      \
 			offset += phdr.p_filesz;				\
 		}							      \
 		else							      \
+				phdr.p_offset = ofs;			      \
+		}							      \
+		else							      \
 			phdr.p_offset += ofs;					\
 		phdr.p_paddr = 0; /* match other core phdrs */			\
 		DUMP_WRITE(&phdr, sizeof(phdr));				\
@@ -239,13 +242,15 @@ do {										\
 } while (0)
 #define ELF_CORE_WRITE_EXTRA_DATA					\
 do {									\
-	const struct elf_phdr *const vsyscall_phdrs =			      \
+	const struct elf_phdr *const gate_phdrs =			      \
 		(const struct elf_phdr *) (GATE_ADDR + GATE_EHDR->e_phoff);   \
 	int i;								\
 	for (i = 0; i < GATE_EHDR->e_phnum; ++i) {			\
-		if (vsyscall_phdrs[i].p_type = PT_LOAD)		      \
-			DUMP_WRITE((void *) vsyscall_phdrs[i].p_vaddr,	      \
-				   PAGE_ALIGN(vsyscall_phdrs[i].p_memsz));    \
+		if (gate_phdrs[i].p_type = PT_LOAD) {			      \
+			DUMP_WRITE((void *) gate_phdrs[i].p_vaddr,	      \
+				   PAGE_ALIGN(gate_phdrs[i].p_memsz));	      \
+			break;						      \
+		}							      \
 	}								\
 } while (0)
 

Re: current bk goes BUG on ia64 when dumping core

[Andrew Morton]

Roland McGrath <roland@redhat.com> wrote:
>
> > When running the latest LTP code, it dies in the new coredump code.
> 
> This is what I predicted when I sent the second ia64 version of the patch.
> Please refer to that message for complete testing instructions to verify
> the core format is correct (assuming it doesn't crash any more with the new
> patch).  I've made another cosmetic change to avoid using "vsyscall" in
> variable names, and here is that version of the patch relative to the
> current 2.6 tree.

OK, thanks.

Now, Linus is trying to get a good 2.6.0-test7 out the door early this week
and it's not helpful that ia64 goes BUG every time it wants to dump core!

I am in Tokyo and am not able to test your patch.  Could someone please
apply Roland's patch to current -bk, then run Linux Test Project (it BUGged
in two seconds for me) and then send the patch to Linus fairly promptly?

Thanks.

Re: current bk goes BUG on ia64 when dumping core; FIXED, PATCH

[Peter Chubb]

>>>>> "Andrew" = Andrew Morton <akpm@osdl.org> writes:

Andrew> Roland McGrath <roland@redhat.com> wrote:
>> > When running the latest LTP code, it dies in the new coredump
>> code.
>> 
>> This is what I predicted when I sent the second ia64 version of the
>> patch.  Please refer to that message for complete testing
>> instructions to verify the core format is correct (assuming it
>> doesn't crash any more with the new patch).  I've made another
>> cosmetic change to avoid using "vsyscall" in variable names, and
>> here is that version of the patch relative to the current 2.6 tree.


The new version doesn't BUG.  I couldn't find the message you were
referring to, Roland ... However, gdb understands the core dump; and
objdump shows a .auxv section that looks the right size etc.

Andrew> I am in Tokyo and am not able to test your patch.  Could
Andrew> someone please apply Roland's patch to current -bk, then run
Andrew> Linux Test Project (it BUGged in two seconds for me) and then
Andrew> send the patch to Linus fairly promptly?

And the patch, repeated from Roland McGrath's message.

Index: linux-2.5/include/asm-ia64/elf.h
=================================RCS file: /home/cvs/linux-2.5/include/asm-ia64/elf.h,v
retrieving revision 1.11
diff -u -b -p -r1.11 elf.h
--- linux-2.5/include/asm-ia64/elf.h 3 Oct 2003 22:45:47 -0000 1.11
+++ linux-2.5/include/asm-ia64/elf.h 6 Oct 2003 04:53:23 -0000
@@ -218,20 +218,23 @@ do {										\
 #define ELF_CORE_EXTRA_PHDRS		(GATE_EHDR->e_phnum)
 #define ELF_CORE_WRITE_EXTRA_PHDRS						\
 do {										\
-	const struct elf_phdr *const vsyscall_phdrs =			      \
+	const struct elf_phdr *const gate_phdrs =			      \
 		(const struct elf_phdr *) (GATE_ADDR + GATE_EHDR->e_phoff);   \
 	int i;									\
-	Elf32_Off ofs = 0;						      \
+	Elf64_Off ofs = 0;						      \
 	for (i = 0; i < GATE_EHDR->e_phnum; ++i) {				\
-		struct elf_phdr phdr = vsyscall_phdrs[i];		      \
+		struct elf_phdr phdr = gate_phdrs[i];			      \
 		if (phdr.p_type = PT_LOAD) {					\
-			BUG_ON(ofs != 0);				      \
-			ofs = phdr.p_offset = offset;				\
 			phdr.p_memsz = PAGE_ALIGN(phdr.p_memsz);	      \
 			phdr.p_filesz = phdr.p_memsz;			      \
+			if (ofs = 0) {					      \
+				ofs = phdr.p_offset = offset;		      \
 			offset += phdr.p_filesz;				\
 		}							      \
 		else							      \
+				phdr.p_offset = ofs;			      \
+		}							      \
+		else							      \
 			phdr.p_offset += ofs;					\
 		phdr.p_paddr = 0; /* match other core phdrs */			\
 		DUMP_WRITE(&phdr, sizeof(phdr));				\
@@ -239,13 +242,15 @@ do {										\
 } while (0)
 #define ELF_CORE_WRITE_EXTRA_DATA					\
 do {									\
-	const struct elf_phdr *const vsyscall_phdrs =			      \
+	const struct elf_phdr *const gate_phdrs =			      \
 		(const struct elf_phdr *) (GATE_ADDR + GATE_EHDR->e_phoff);   \
 	int i;								\
 	for (i = 0; i < GATE_EHDR->e_phnum; ++i) {			\
-		if (vsyscall_phdrs[i].p_type = PT_LOAD)		      \
-			DUMP_WRITE((void *) vsyscall_phdrs[i].p_vaddr,	      \
-				   PAGE_ALIGN(vsyscall_phdrs[i].p_memsz));    \
+		if (gate_phdrs[i].p_type = PT_LOAD) {			      \
+			DUMP_WRITE((void *) gate_phdrs[i].p_vaddr,	      \
+				   PAGE_ALIGN(gate_phdrs[i].p_memsz));	      \
+			break;						      \
+		}							      \
 	}								\
 } while (0)
 
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: current bk goes BUG on ia64 when dumping core; FIXED, PATCH

[Roland McGrath]

> The new version doesn't BUG.  I couldn't find the message you were
> referring to, Roland ... However, gdb understands the core dump; and
> objdump shows a .auxv section that looks the right size etc.

Thanks for testing this!  This change is not related to the NT_AUXV note in
fact (both just happened the same week).  What you should be looking for is
the readelf -l (objdump -p) output from the core file, for the segment with
vaddr 0xa000000000010000 (GATE_ADDR).  Check that its size is PAGE_SIZE.
You can also verify it in gdb while looking at the core file by checking
that e.g. "p (char *) 0xa000000000010000" shows "ELF\177" and that
"x/w 0xa000000000010000+PAGE_SIZE-8" (substituting the right PAGE_SIZE value)
works (and shows you zeros).


Thanks,
Roland

Re: current bk goes BUG on ia64 when dumping core; FIXED, PATCH

[Peter Chubb]

>>>>> "Roland" = Roland McGrath <roland@redhat.com> writes:

>> The new version doesn't BUG.  I couldn't find the message you were
>> referring to, Roland ... However, gdb understands the core dump;
>> and objdump shows a .auxv section that looks the right size etc.

Roland> Thanks for testing this!  This change is not related to the
Roland> NT_AUXV note in fact (both just happened the same week).  What
Roland> you should be looking for is the readelf -l (objdump -p)
Roland> output from the core file, for the segment with vaddr
Roland> 0xa000000000010000 (GATE_ADDR).  Check that its size is
Roland> PAGE_SIZE.  You can also verify it in gdb while looking at the
Roland> core file by checking that e.g. "p (char *)
Roland> 0xa000000000010000" shows "ELF\177" and that "x/w
Roland> 0xa000000000010000+PAGE_SIZE-8" (substituting the right
Roland> PAGE_SIZE value) works (and shows you zeros).

All those tests pass.

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories,   all slightly different.