[Linux-ia64] RE: kernel update (relative to 2.4.18)

Chen, Kenneth W
2002-07-03T16:33:35Z

Xavier,
Wondering if you can extract the test cases out of your test suite and send
to me? The first one is intended not to expand the exception marcro due to
instruction bundling issue. The exception handler suppose to catch the
fault. I would like to see a test case that make it fail. Thanks.

- Ken

-----Original Message-----
From: Xavier Bru [mailto:Xavier.Bru@bull.net]
Sent: Wednesday, July 03, 2002 6:28 AM
To: davidm@hpl.hp.com; Chen, Kenneth W
Cc: linux-ia64@linuxia64.org; Jacky.Malcles@bull.net
Subject: Re: kernel update (relative to 2.4.18)

David, Ken

Thanks for the patch that fixed this one :-)
unfortunately, we have other problems with the Itanium-2 based new memcopy
routines, and new Ooops running the ltp test suite (test system calls
with wrong arguments :-).
I identified problems due to missing static exception handler
definitions. A potential patch could be:

--- l.ref/arch/ia64/lib/memcpy_mck.S Tue Jun 25 11:52:22 2002
+++ l/arch/ia64/lib/memcpy_mck.S Wed Jul 3 09:21:15 2002
@@ -178,7 +178,7 @@
and r21=-8,tmp
;;
EX(.ex_handler, (p8) ld8 t3=[src1])
-EK(.ex_handler, (p6) st8 [dst0]=t1) // store byte 1
+EX(.ex_handler, (p6) st8 [dst0]=t1) // store byte 1
and in2=7,tmp // remaining length
EX(.ex_handler, (p7) st8 [dst1]=t2,8) // store byte 2
add src0=src0,r21 // setting up src pointer
@@ -215,7 +215,7 @@
// same as .line_copy loop, but with all predicated-off instructions
removed:
.prefetch_loop:
EX(.ex_handler_lcpy, (p[A]) ld8 v[A] = [src_pre_mem], 128) //
M0
-EK(.ex_handler_lcpy, (p[B]) st8 [dst_pre_mem] = v[B], 128) //
M2
+EX(.ex_handler_lcpy, (p[B]) st8 [dst_pre_mem] = v[B], 128) //
M2
br.ctop.sptk .prefetch_loop
;;
cmp.eq p16, p0 = r0, r0 // reset p16 to 1

But this seems not sufficient: we also are facing recursive calls to
__copy_user due to exeception management when running the
ex_handler_short path.

Herafter some traces:

Problem 1 (missing EX handler, fixed by patch).
-----------------------------------------------
Entering kdb (current=0xe000000012df8000, pid 2742) on processor 0 Oops:
<NULL>
due to oops @ 0xe00000000489d1a1
psr: 0x0000121008026018 ifs: 0x800000000000cc18 ip: 0xe00000000489d1a0

unat: 0x0000000000000000 pfs: 0x000000000000038a rsc: 0x0000000000000003

rnat: 0x0000000000000000 bsps: 0x0000000000000000 pr: 0x00000000000105e9

ldrs: 0x0000000000000000 ccv: 0x0000000000000000 fpsr: 0x0009804c0270033f

b0: 0xe000000004425a40 b6: 0xe000000004401370 b7: 0x0000000000000000

r1: 0xe000000004e50450 r2: 0xe000000012dffec8 r3: 0xe000000012dffed8

r8: 0x0000000000000000 r9: 0xffffffffffffffff r10: 0x0000000000000000

r11: 0x00000000000005e9 r12: 0xe000000012dffd50 r13: 0xe000000012df8000

r14: 0x60000fffff7fb510 r15: 0xe000000012dffec8 r16: 0x0000000000000018

r17: 0x60000fffff7fb510 r18: 0x60000fffff7fb518 r19: 0xe000000012dfff48

r20: 0x60000fffff7fb590 r21: 0x0000000000000018 r22: 0x60000fffff7fb4a8

r23: 0x600000000000f458 r24: 0xc000000000000692 r25: 0x60000fffff7fdb50

r26: 0xfffffffffffffff2 r27: 0x60000fffff7fb500 r28: 0x0000000000000000

r29: 0x0000000000000000 r30: 0x0000000000000018 r31: 0x000000000000038a

&regs = e000000012dffbc0
[0]kdb> bt
0xe00000000489d1a0 __copy_user+0x160
args (0x60000fffff7fb510, 0xe000000012dffec8, 0x18, 0x80000000f,
0x80200000000)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe000000004425a40 setup_sigcontext+0x320
args (0x60000fffff7fb440, 0x60000fffff7fb4a0, 0xe000000012dffe60,
0xfffffffffffffff2, 0xe000000012dffe70)
kernel .text 0xe000000004400000 0xe000000004425720
0xe000000004425b00
0xe000000004425e10 setup_frame+0x310
args (0xb, 0xe00000001219b878, 0xfffffffffffffff2,
0xe000000012df8f00, 0xe000000012dffe60)
kernel .text 0xe000000004400000 0xe000000004425b00
0xe000000004425f40
0xe000000004426170 handle_signal+0x230
args (0xb, 0xe00000001219b878, 0xe000000012dffde0,
0xe000000012df8f00, 0xe000000012dffe60)
kernel .text 0xe000000004400000 0xe000000004425f40
0xe000000004426180
0xe000000004426560 ia64_do_signal+0x3e0
args (0xe000000012df8f00, 0xe000000012dffe60, 0x0, 0xb,
0xe00000001219b878)
kernel .text 0xe000000004400000 0xe000000004426180
0xe000000004426a40
0xe00000000440a350 handle_signal_delivery+0x30
args (0x80000000f, 0xa0200000000, 0xe000000012dffde4, 0x800000004,
0xe000000012dffdfc)
kernel .text 0xe000000004400000 0xe00000000440a320
0xe00000000440a380
0xe000000004409f90 ia64_leave_kernel+0x70
args (0x80000000f, 0xa0200000000, 0xe000000012dffde4)
kernel .text 0xe000000004400000 0xe000000004409f20
0xe00000000440a1b0

Problem 2(recursive call to __copy_user)
---------
[0]kdb> bt
0xe00000000489d840 __copy_user+0x800
args (0xffffffff, 0xe0000000143f7c10, 0x14, 0xe0000000045dfec0)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe0000000045e06e0 semctl_main+0x9c0
args (0xe00000001bdf6ad8, 0xfffffffbfff, 0xe000000004c839a0,
0xe000000004c83970, 0xffffffff)
kernel .text 0xe000000004400000 0xe0000000045dfd20
0xe0000000045e0780
0xe0000000045e0f00 sys_semctl+0x1c0
args (0x8001, 0x0, 0xd, 0xffffffff, 0x80100)
XXXXXXXXXXX
kernel .text 0xe000000004400000 0xe0000000045e0d40
0xe0000000045e0f20
0xe000000004409f00 ia64_ret_from_syscall
args (0x8001, 0x0, 0xd, 0xffffffff)
kernel .text 0xe000000004400000 0xe000000004409f00
0xe000000004409f20
[0]kdb> go
...

[0]kdb> bt
0xe00000000489d840 __copy_user+0x800
args (0xffffffff, 0xe0000000143f7c10, 0x1)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe00000000489d900 __copy_user+0x8c0
args (0x100000000, 0x0, 0x1, 0x0, 0xe00000000489d900)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe00000000489d900 __copy_user+0x8c0
args (0x100000000, 0x0, 0x14, 0x13, 0xe0000000045e06e0)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe00000000489d900 __copy_user+0x8c0
args (0xa, 0xa, 0xe0000000143f7c10, 0xe0000000045e0f00, 0x794)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe00000000489d900 __copy_user+0x8c0
args (0xfffffffbfff, 0xe000000004c839a0, 0xe000000004c83970,
0xffffffff, 0x0)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe00000000489d900 __copy_user+0x8c0
args (0x0, 0xffffffff, 0x1, 0xe000000004409f00, 0x4)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe00000000489d900 __copy_user+0x8c0
args (0x80100, 0xe0000000143f7cd0, 0xe000000004409f20, 0x2, 0x8001)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
0xe00000000489d900 __copy_user+0x8c0
[0]more>
args (0xc00000000000050d, 0x60000fffffffb9c0, 0x8001, 0x0, 0xd)
kernel .text 0xe000000004400000 0xe00000000489d040
0xe00000000489d940
[0]kdb>

Thanks for your help...
Xavier

David Mosberger writes:
> >>>>> On Wed, 26 Jun 2002 19:30:48 +0200 (DFT), Xavier Bru
<Xavier.Bru@bull.net> said:
>
> Xavier> It seems that null pointers passed as argument to syscalls
> Xavier> by wrong user code now generate a Oops, and enter kdb if
> Xavier> enabled.
>
> I haven't seen a fix from Ken yet, so the patch below comes live from
OLS...
> Please test heavily and let me know how it goes.
>
> Thanks,
>
> --david
>
> --- lia64-2.4/arch/ia64/kernel/traps.c~ Thu Jun 20 18:56:08 2002
> +++ lia64-2.4/arch/ia64/kernel/traps.c Fri Jun 28 12:15:58 2002
> @@ -497,7 +497,8 @@
> siginfo.si_isr = isr;
> force_sig_info(sig, &siginfo, current);
> return;
> - }
> + } else if (done_with_exception(regs))
> + return;
> sprintf(buf, "NaT consumption");
> break;
>