Skip to contentSkip to conversation

kernel update (relative to 2.4.0-test12)

Linux-ia64 Bill Nottingham 7 participants 23 messages Dec 15, 2000 – Jul 11, 2002

Subsystems (2)
SCSI Char and misc drivers
lore
Share & tools
lore

Bill Nottingham

author
#0 lore raw
Quoted 5 lines · David Mosberger

The latest IA-64 patch is now available at:

ftp://ftp.kernel.org/pub/linux/kernel/port/pub/linux/kernel/ports/ia64/

in files linux-2.4.0-test12-ia64-001214.diff*

Patch attached; fixes an undefined symbol if IDE is built modular.

Bill

arch/ia64/kernel/ia64_ksyms.c renamed from arch/ia64/kernel/ia64_ksyms.c.foo +3 -0
@@ -28,6 +28,9 @@
 EXPORT_SYMBOL(pci_alloc_consistent);
 EXPORT_SYMBOL(pci_free_consistent);
 
+#include <asm/hw_irq.h>
+EXPORT_SYMBOL(isa_irq_to_vector_map);
+
 #include <linux/in6.h>
 #include <asm/checksum.h>
 /* not coded yet?? EXPORT_SYMBOL(csum_ipv6_magic); */
author
#1 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.4)

Quoted 7 lines · David Mosberger

The latest IA-64 patch is (finally) available at:

ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/

in file linux-2.4.4-ia64-010508.diff*. Thanks to Johannes Erdfelt, USB is working again and I hope this kernel will be quite stable for everybody (famous last words...).

Any chance that more of this stuff that hasn't been merged into the main tree in the past will get merged (460GX agpgart, EFI GUID partition tables, etc)?

Bill

Quoted 74 lines

What's changed:

- clean up boot parameter passing between elilo and kernel (Stephane Eranian)
- optimized do_csum() some more (Jun Nakajima)
- AGP GART update (Chris Ahna)
- fix pci-pool routines to work on 64-bit platforms (Johannes Erdfelt)
- more IA-32 updates (Don Dugger, me)
- make machine_halt() do nothing instead of rebooting the machine; this has the desirable effect that "shutdown -h" will really halt instead of rebooting the machine; the machine does *not* power off, however (I don't think the current firmware/hw supports this)
- use KERNEL_PG_* constants instead of hardcoding the page size used in the kernel's identity mapped regions (Tony Luck)
- added getunwind() system call as a means to get unwind info for the gate page (signal handler trampoline for now; light-weight syscall stubs in the future) and add unwind info to signal trampoline
- move EFI vars from /proc/efi to /proc/efi/vars/ (Matt Domsch)
- for MP machines, sync cycle counter register (ar.itc) of each CPU with the time keeper CPU on boot up & exploit this to provide fine-grained time in gettimeofday()
- clean up & fix coredump creation
- clean up debug messages in cs4281 drivers to avoid compiler warnings
- make the register backing store of a newly execve()'d process start at a nicely aligned address again
- fix spin_unlock() to do barrier() in correct place (Jack Steiner)
- add a couple of spare longs to sigcontext structure to provide room for future extensibility

Some notes: I didn't apply Jes's qla1280 clean up patch yet. I'd very much like to do that, but since qlogic is maintaing this driver, I'm waiting until they've had a chance to review it.

If you look at the cycle counter sync'ing code, you'll see that it's very different from what has been proposed in the past. There is a good reason for this: the new code allows arbitrary pairs of CPUs to sync at any point in time. At this point, the only time the syncing is actually done is at boot time, but in the future we'll want to support online replacement of CPUs and with a pair-wise syncing approach, this is trivial to support. Also, the new code uses a close loop to sync the counters. This ensures that there are no unaccounted-for error sources. The syncing tends to work quite well in pratice: usually, we seem to get a pair of CPUs to within <10 cycles of each other (assuming that the interconnect between the two CPUs has symmetric latencies). However, I'm also quite sure that someone with a better memory of control theory could optimize the current code for faster convergence (and perhaps more stable behavior in the presence of large amounts of noise). Please feel free to take this as a challenge! ;-)

BIG CAVEAT: even though the kernel currently is syncing the cycle counters, application code MUST NOT rely on this. Instead, if an application needs fine-grained and light-weight timestamps, it should use the POSIX *clock* routines that Uli added recently to libc. I can almost guarantee you that future machines will NOT have synchronized clocks (and we'll also want to support systems where different CPUs have different clock speeds) and because of this, the *clock* routines and gettimeofday() are the recommended and RELIABLE way for obtaining fine-grained timestamps.

Enjoy,

	--david

_______________________________________________
Linux-IA64 mailing list
[email protected]
http://lists.linuxia64.org/lists/listinfo/linux-ia64

author
#2 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.7)

In reply to Bill Nottingham
Quoted 7 lines · Keith Owens

The new __get_user code breaks older versions of gcc for IA64.
gcc version 2.96-ia64-000717 snap 001117
scsi_ioctl.c: In function `scsi_ioctl_send_command':
scsi_ioctl.c:366: Internal compiler error in `rws_access_regno', at config/ia64/ia64.c:3671
ia64-unknown-linux-gcc: Internal compiler error: program cpp got fatal signal 13

Time to upgrade gcc. Workaround for old versions.

Oh, yeah, I noticed that. Here's what we used; it's similar. It works fine in gcc3, so that's why I didn't report it earlier.

Bill

drivers/scsi/scsi_ioctl.c renamed from drivers/scsi/scsi_ioctl.c.foo +5 -2
@@ -200,6 +200,7 @@
 	unsigned int needed, buf_needed;
 	int timeout, retries, result;
 	int data_direction;
+	int foo;
 
 	if (!sic)
 		return -EINVAL;

@@ -209,10 +210,12 @@
 	if (verify_area(VERIFY_READ, sic, sizeof(Scsi_Ioctl_Command)))
 		return -EFAULT;
 
-	if(__get_user(inlen, &sic->inlen))
+	foo = __get_user(inlen, &sic->inlen);
+	if (foo)
 		return -EFAULT;
 		
-	if(__get_user(outlen, &sic->outlen))
+	foo = __get_user(outlen, &sic->outlen);
+	if (foo)
 		return -EFAULT;
 
 	/*
author
#3 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.7)

In reply to Bill Nottingham
Quoted 1 line · Andreas Schwab

Did you try out the UP kernel? It hangs in ksoftirqd.

Are you seeing this right after the EFI variables startup message, or someplace else?

Bill

#4 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.7)

In reply to Bill Nottingham

Bill Nottingham <[email protected]> writes:

|> Andreas Schwab ([email protected]) said: 
|> > Did you try out the UP kernel?  It hangs in ksoftirqd.
|> 
|> Are you seeing this right after the EFI variables startup message,

Yes.

Andreas.

Signature · 5 lines
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
[email protected]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
#5 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.10)

In reply to Bill Nottingham
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Bill Nottingham
Quoted 4 lines · Bill> David Mosberger ([email protected]) said:
Quoted 4 lines

with these fixes in place, I'm able to successfully run the ia32 versions of realplay, OpenOffice, mozilla, netscape, acrobat, strace, Intel compilers, etc. But as usual, your mileage may vary.

Bill> Did you try wine? :)

I hadn't.

Bill> Seriously, I tried this previously, and it didn't really work Bill> at all. At the time, I wasn't even sure if it could be *made* Bill> to work, and I haven't looked since.

I wasn't sure either. I looked at the docs a bit and there doesn't seem to be anything that would stop it from working in principle. 16-bit apps might be harder, as those require vm86() which I know nothing about (I'm sure it could be implemented by someone more knowledge of x86).

Encouraged by this, I tried the wine RPM from Red Hat. After fixing the ia32 sendmsg()/recvmsg() implementations, I am now able to run "wordpad.exe" and "mspaint.exe". I had never seen wine in a working state, so I was quite amazed to see a windows-looking application pop up! As far as I can tell, these two apps work perfectly fine.

However, I didn't get much else to work (e.g., acrobat and the HP printing software both died after the splash screen...). Even with "wordpad.exe" I get some worrisome warning messages:

err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufW) imported from shell32.dll, setting to 0xdeadbeef FIXME:pthread_rwlock_rdlock
FIXME:pthread_rwlock_unlock

I think the first two errors are real problems. Not sure about the pthread-related messages. I suppose if someone is serious about this, all of these could be fixed.

Oh, to get this to work, I had to switch to 4KB page size.

	--david
author
#6 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.10)

In reply to Bill Nottingham
Quoted 3 lines · David Mosberger

Andreas> This patch is needed to get the DRM code to compile:

Thanks.

Speaking of which, are people having success with the DRM code and XFree86 4.1? On my r128 (AGP), it loads and runs OK, but the rendering is rather broken.

Bill

author
#7 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.10)

In reply to Bill Nottingham
Quoted 3 lines · Bill Nottingham

Speaking of which, are people having success with the DRM code and XFree86 4.1? On my r128 (AGP), it loads and runs OK, but the rendering is rather broken.

FWIW, PCI r128 seemed to work fine, at least until the machine check. :(

Bill

#8 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.10)

In reply to Bill Nottingham
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Bill Nottingham

Bill> Speaking of which, are people having success with the DRM code Bill> and XFree86 4.1? On my r128 (AGP), it loads and runs OK, but Bill> the rendering is rather broken.

It's entirely possible that I made a mistake when merging the DRM/AGP patches in 2.4.10. There were a bunch of conflicts which I resolved as best as I could. But I can't do much testing myself: the only AGP-enabled card I have is a quadro pro but the nVidia beta driver reboots the machine instantly with more recent kernels (I suspect this has to do with the DRM cleanups that went in a while ago; it works fine with a 2.4.3 kernel).

Chris do you have any updates pending?

	--david
author
#9 lore raw

[Linux-ia64] Re: kernel update (relative to 2.4.10)

In reply to Bill Nottingham
Quoted 2 lines · Bill Nottingham

FWIW, PCI r128 seemed to work fine, at least until the machine check. :(

Attached is a patch for PCI that fixes a definite oops in r128 and presumably the same one in the radeon driver. Dunno if this was related to the hard lockup/machine check I saw or not.

Bill

drivers/char/drm/r128_cce.c renamed from drivers/char/drm/r128_cce.c.foo +1 -1
@@ -681,7 +681,7 @@
 		/*
 		 * Free the page we grabbed for RPTR_ADDR
 		 */
-		if( dev->agp->agp_info.chipset == INTEL_460GX ) {
+		if( !dev_priv->is_pci && dev->agp->agp_info.chipset == INTEL_460GX ) {
 			unsigned long alt_rh_off =
 				(unsigned long) dev_priv->ring.head;
drivers/char/drm/radeon_cp.c renamed from drivers/char/drm/radeon_cp.c.foo +1 -1
@@ -1026,7 +1026,7 @@
 		/*
 		 * Free the page we grabbed for RPTR_ADDR
 		 */
-		if( dev->agp->agp_info.chipset == INTEL_460GX ) {
+		if( !dev_priv->is_pci && dev->agp->agp_info.chipset == INTEL_460GX ) {
 			unsigned long alt_rh_off =
 				(unsigned long) dev_priv->ring.head;
#10 lore raw

Re: [Linux-ia64] Re: kernel update (relative to 2.4.10)

In reply to Bill Nottingham
Quoted 1 line · David Mosberger

Chris do you have any updates pending?

Well, I do now :-) On ia64 we want to map even AGP memory as writecombined. The appended patch should fix the rendering problems Bill reported earlier.

Chris

drivers/char/drm/drm_vm.h +1 -2
@@ -524,8 +524,8 @@
                 	 */
                 	vma->vm_ops = &DRM(vm_ops);
 #if defined(__ia64__)
-			if (map->type != _DRM_AGP)
-				vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+			vma->vm_page_prot +			                pgprot_writecombine(vma->vm_page_prot);
 #endif
 			goto mapswitch_out;
 		}
author
#11 lore raw

Re: [Linux-ia64] Re: kernel update (relative to 2.4.10)

In reply to Bill Nottingham
Quoted 3 lines · Chris Ahna

Well, I do now :-) On ia64 we want to map even AGP memory as writecombined. The appended patch should fix the rendering problems Bill reported earlier.

Yup, works great. Running ia32 glxinfo appears to crash the X server, though...

Bill

#12 lore raw

Re: [Linux-ia64] Re: kernel update (relative to 2.4.10)

In reply to Bill Nottingham
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Bill Nottingham
Quoted 3 lines · Bill> Chris Ahna ([email protected]) said:
Quoted 3 lines

Well, I do now :-) On ia64 we want to map even AGP memory as writecombined. The appended patch should fix the rendering problems Bill reported earlier.

Bill> Yup, works great. Running ia32 glxinfo appears to crash the X Bill> server, though...

Speaking of the X server: I recently tried the stuff in the "rawhide" directory (XFree 4.1.0). The X server *still* easily crashes the machine when switching back between the X server and the virtual consoles. This is very painful. I hope someone can find some time to look into this. (By "crash" I mean "instant reboot".)

	--david
#13 lore raw

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

In reply to Bill Nottingham
Quoted 2 lines

- Install NaT-page at address zero to speed up speculation across NULL pointers (Ken Chen).

Hi Dave,

It seems that null pointers passed as argument to syscalls by wrong user code now generate a Oops, and enter kdb if enabled.

This is not a big problem, as typing "go" the wrong process exits and everyting goes well.

for example:

quotaon[163]: NaT consumption 17179869216

Pid: 163, comm: quotaon
psr : 0000101008026018 ifs : 8000000000000183 ip : [<e000000004767e00>] Not tainted
unat: 0000000000000000 pfs : 0000000000000288 rsc : 0000000000000003
rnat: 0000101008026018 bsps: e000000004402f00 pr : 0000000056609617
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f b0 : e0000000044d8e50 b6 : e000000004402f60 b7 : e0000000045f6300 f6 : 1003e0000000000000001 f7 : 1003e0000000000000001 f8 : 1003e0000000000000170 f9 : 10005c200000000000000 r1 : e000000004cbe970 r2 : 0000000000000288 r3 : e000000004abfb88 r8 : 0000000000000000 r9 : 0000000000000000 r10 : 0000000000001000 r11 : 00000fffffffbfff r12 : e00000003f21fe30 r13 : e00000003f218000 r14 : 9fffffffffffffff r15 : 0000000000000000 r16 : 0000000000000000 r17 : e00000003fc13418 r18 : e00000003fc13368 r19 : 0000000000000001 r20 : 0000000000000001 r21 : 0000000000004000 r22 : e00000003fcd08d8 r23 : e00000003fcd08d0 r24 : 0000000000000010 r25 : 0000000000000002 r26 : e00000003f2184c8 r27 : 60000fffffffba60 r28 : 0000000000000100 r29 : 0000000000000000 r30 : 0000000000000100 r31 : e00000003f218008

Call Trace: [<e00000000440fea0>] sp=0xe00000003f21f9d0 bsp=0xe00000003f219178

[<e000000004427c40>] sp=0xe00000003f21fb90 bsp=0xe00000003f219150 [<e000000004428c10>] sp=0xe00000003f21fb90 bsp=0xe00000003f219118 [<e000000004409fa0>] sp=0xe00000003f21fc90 bsp=0xe00000003f219118 [<e000000004767e00>] sp=0xe00000003f21fe30 bsp=0xe00000003f219100 [<e0000000044d8e50>] sp=0xe00000003f21fe30 bsp=0xe00000003f2190d8 [<e0000000044dc400>] sp=0xe00000003f21fe30 bsp=0xe00000003f2190b0 [<e000000004506cc0>] sp=0xe00000003f21fe30 bsp=0xe00000003f219018 [<e000000004409f80>] sp=0xe00000003f21fe60 bsp=0xe00000003f219018

Entering kdb (current=0xe00000003f218000, pid 163) on processor 1 Oops: <NULL> due to oops @ 0xe000000004767e00
psr: 0x0000101008026018 ifs: 0x8000000000000183 ip: 0xe000000004767e00
unat: 0x0000000000000000 pfs: 0x0000000000000288 rsc: 0x0000000000000003
rnat: 0x0000101008026018 bsps: 0xe000000004402f00 pr: 0x0000000056609617
ldrs: 0x0000000000000000 ccv: 0x0000000000000000 fpsr: 0x0009804c0270033f

  b0: 0xe0000000044d8e50    b6: 0xe000000004402f60    b7: 0xe0000000045f6300  
  r1: 0xe000000004cbe970    r2: 0x0000000000000288    r3: 0xe000000004abfb88  
  r8: 0x0000000000000000    r9: 0x0000000000000000   r10: 0x0000000000001000  
 r11: 0x00000fffffffbfff   r12: 0xe00000003f21fe30   r13: 0xe00000003f218000  
 r14: 0x9fffffffffffffff   r15: 0x0000000000000000   r16: 0x0000000000000000  
 r17: 0xe00000003fc13418   r18: 0xe00000003fc13368   r19: 0x0000000000000001  
 r20: 0x0000000000000001   r21: 0x0000000000004000   r22: 0xe00000003fcd08d8  
 r23: 0xe00000003fcd08d0   r24: 0x0000000000000010   r25: 0x0000000000000002  
 r26: 0xe00000003f2184c8   r27: 0x60000fffffffba60   r28: 0x0000000000000100  
 r29: 0x0000000000000000   r30: 0x0000000000000100   r31: 0xe00000003f218008  
&regs = e00000003f21fca0
[1]kdb> bt
0xe000000004767e00 __strncpy_from_user+0x20
        args (0xe00000003fb41000, 0x0, 0x1000)
        kernel .text 0xe000000004400000 0xe000000004767de0 0xe000000004767e40
0xe0000000044d8e50 getname+0x170
        args (0x0, 0x1000, 0xe00000003fb41000, 0xe0000000044dc400, 0x288)
        kernel .text 0xe000000004400000 0xe0000000044d8ce0 0xe0000000044d8ec0
0xe0000000044dc400 __user_walk+0x20
        args (0x0, 0x9, 0xe00000003f21fe40, 0xe000000004506cc0, 0x998)
        kernel .text 0xe000000004400000 0xe0000000044dc3e0 0xe0000000044dc4e0
0xe000000004506cc0 sys_quotactl+0x1c0
        args (0x110000, 0x0, 0x0, 0x60000fffffffbc30, 0x40000000000084d0)
        kernel .text 0xe000000004400000 0xe000000004506b00 0xe0000000045071a0
0xe000000004409f80 ia64_ret_from_syscall
        args (0x110000, 0x0, 0x0, 0x60000fffffffbc30, 0x40000000000084d0)
        kernel .text 0xe000000004400000 0xe000000004409f80 0xe000000004409fa0
Signature · 8 lines
 Sincères salutations.
_____________________________________________________________________
 
Xavier BRU                 BULL ISD/R&D/INTEL office:     FREC B1-422
tel : +33 (0)4 76 29 77 45                    http://www-frec.bull.fr
fax : +33 (0)4 76 29 77 70                 mailto:[email protected]
addr: BULL, 1 rue de Provence, BP 208, 38432 Echirolles Cedex, FRANCE
_____________________________________________________________________
#14 lore raw

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

In reply to Bill Nottingham
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Xavier Bru

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.

Good point. The signal handler path needs to check whether the fault occurred inside a code range with an associated exception handler and report it as a user fault, if so. We already do this for the unaligned handler.

	--david
#15 lore raw

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

In reply to Bill Nottingham
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Xavier Bru

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
arch/ia64/kernel/traps.c renamed from arch/ia64/kernel/traps.c~ +2 -1
@@ -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;
#16 lore raw

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

In reply to Bill Nottingham

I wasn't on the mailing list so this came to my attention a bit late. Prior to nat page, a fault like this would route to the associated exception handler via page fault handler since there is no mapping of virtual address
0. Now with nat page, there is a mapping of address 0, but non-speculative read/write is not allowed on that page. Since fault routing is not there, a segfault would occur. The fix that David provided would fix the problem as I already tested out. Thanks.

- Ken

-----Original Message-----
From: David Mosberger [mailto:[email protected]]
Sent: Friday, June 28, 2002 12:42 PM
To: Xavier Bru
Cc: [email protected]
Subject: [Linux-ia64] Re: kernel update (relative to 2.4.18)

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

On Wed, 26 Jun 2002 19:30:48 +0200 (DFT), Xavier Bru

<[email protected]> 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
arch/ia64/kernel/traps.c renamed from arch/ia64/kernel/traps.c~ +2 -1
@@ -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;
#17 lore raw

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

In reply to Bill Nottingham

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:

arch/ia64/lib/memcpy_mck.S +2 -2
@@ -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

Quoted 25 lines · David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Xavier Bru

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
arch/ia64/kernel/traps.c renamed from arch/ia64/kernel/traps.c~ +2 -1
@@ -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;
#18 lore raw

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

In reply to Bill Nottingham

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:[email protected]]
Sent: Wednesday, July 03, 2002 6:28 AM
To: [email protected]; Chen, Kenneth W
Cc: [email protected]; [email protected]
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:

arch/ia64/lib/memcpy_mck.S +1 -1
@@ -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

Quoted 1 line · David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

On Wed, 26 Jun 2002 19:30:48 +0200 (DFT), Xavier Bru

Quoted 6 lines · <[email protected]> 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...

Quoted 18 lines

Please test heavily and let me know how it goes.

Thanks,

	--david
arch/ia64/kernel/traps.c renamed from arch/ia64/kernel/traps.c~ +2 -1
@@ -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;
#19 lore raw

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

In reply to Bill Nottingham

Ken,

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Kenneth W

Ken> Xavier, Wondering if you can extract the test cases out of your Ken> test suite and send to me? The first one is intended not to Ken> expand the exception marcro due to instruction bundling issue.

Note that with gcc3, tags instead of labels are used to delineate exception regions. Thus, you shouldn't have to worry about bundling any longer.

	--david
#20 lore raw

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

In reply to Bill Nottingham

Thanks for your answers.

Kernel is compiled with gcc 3.1 (that should explain the problem of missing ex-handler in the bundle).

If you need more infos about ltp test suite, you can ask Jacky Malcles([email protected]). Thanks
Xavier
------------------------------------------------------------------
test for Problem 1 (missing EX handler)

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/signal.h>
#include <sys/ioctl.h>
#include <errno.h>

main()
{
int s, sinlen;
s = socket(PF_INET, SOCK_STREAM, 0);
if (s <0)

    perror("socket");

getsockname(s, (struct sockaddr *)0, &sinlen);
perror("getsockname");
}
------------------------------------------------------------------
test for Problem 2(recursive call to __copy_user)

# include <sys/types.h>
# include <sys/ipc.h>
# include <sys/sem.h>
main()
{
  int rc, semid;
  if ((semid=semget(IPC_PRIVATE, 10, IPC_CREAT | IPC_EXCL | 0600 )) = -1) {
    perror("semget");
    exit(2);

}
rc=semctl(semid, 0x0, 0xd, 0xffffffffUL);
perror("semctl");
}
------------------------------------------------------------------

Quoted 13 lines · David Mosberger

Ken,

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Kenneth W

Ken> Xavier, Wondering if you can extract the test cases out of your Ken> test suite and send to me? The first one is intended not to Ken> expand the exception marcro due to instruction bundling issue.

Note that with gcc3, tags instead of labels are used to delineate exception regions. Thus, you shouldn't have to worry about bundling any longer.

	--david
Quoted 7 lines · Kenneth W

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

#21 lore raw

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

In reply to Bill Nottingham

This patch fixes some critical bugs in copy_user exception handler found by Xavier. The fixes are all in the exception handler and there are no changes in the main "copy" body. I have tested with both gcc2.96 and gcc3.1 compiler. Please report issues to me if there are any. Thanks.

- Ken

-----Original Message-----
From: Xavier Bru [mailto:[email protected]]
Sent: Thursday, July 04, 2002 6:42 AM
To: [email protected]; Chen, Kenneth W
Cc: [email protected]; [email protected]
Subject: RE: kernel update (relative to 2.4.18)

Thanks for your answers.

Kernel is compiled with gcc 3.1 (that should explain the problem of missing ex-handler in the bundle).

If you need more infos about ltp test suite, you can ask Jacky Malcles([email protected]).
Thanks
Xavier
------------------------------------------------------------------
test for Problem 1 (missing EX handler)

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/signal.h>
#include <sys/ioctl.h>
#include <errno.h>

main()
{
int s, sinlen;
s = socket(PF_INET, SOCK_STREAM, 0);
if (s <0)

    perror("socket");

getsockname(s, (struct sockaddr *)0, &sinlen);
perror("getsockname");
}
------------------------------------------------------------------
test for Problem 2(recursive call to __copy_user)

# include <sys/types.h>
# include <sys/ipc.h>
# include <sys/sem.h>
main()
{
  int rc, semid;
  if ((semid=semget(IPC_PRIVATE, 10, IPC_CREAT | IPC_EXCL | 0600 )) == -1) {
    perror("semget");
    exit(2);

}
rc=semctl(semid, 0x0, 0xd, 0xffffffffUL);
perror("semctl");
}
------------------------------------------------------------------

ia64/lib/memcpy_mck.S renamed from ia64/lib/memcpy_mck.orig.S +37 -20
@@ -15,7 +15,11 @@
 #include <asm/asmmacro.h>
 #include <asm/page.h>
 
-#define EK(y,x...)  x
+#if __GNUC__ >= 3
+# define EK(y...) EX(y)
+#else
+# define EK(y,x...)  x
+#endif
 
 GLOBAL_ENTRY(bcopy)
 	.regstk 3,0,0,0

@@ -173,14 +177,14 @@
 EX(.ex_handler, (p6)	ld8	t1=[src0])
 	mov	ar.lc=saved_lc
 	mov	ar.pfs=saved_pfs
-EX(.ex_handler, (p7)	ld8	t2=[src1],8)
+EX(.ex_hndlr_s, (p7)	ld8	t2=[src1],8)
 	cmp.le	p8,p0=24,tmp
 	and	r21=-8,tmp
 	;;
-EX(.ex_handler, (p8)	ld8	t3=[src1])
-EK(.ex_handler, (p6)	st8	[dst0]=t1)	// store byte 1
+EX(.ex_hndlr_s, (p8)	ld8	t3=[src1])
+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
+EX(.ex_hndlr_d, (p7)	st8	[dst1]=t2,8)	// store byte 2
 	add	src0=src0,r21	// setting up src pointer
 	add	dst0=dst0,r21	// setting up dest pointer
 	;;

@@ -214,8 +218,8 @@
 	add cnt = -(2*PREFETCH_DIST) - 1, cnt
 	// 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_hndlr_lcpy_1, (p[A])	ld8 v[A] = [src_pre_mem], 128)		// M0
+EK(.ex_hndlr_lcpy_1, (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

@@ -356,7 +360,7 @@
 // that the loop produces.
 .noloop:
 EX(.ex_handler, (p6)	ld8	r37=[src1],8)
-	nop.m	0
+	add	src0=8,src0
 (p6)	shl	r25=r30,3
 	;;
 EX(.ex_handler, (p6)	ld8	r27=[src1])

@@ -568,18 +572,31 @@
 #define saved_rtlink	loc1
 #define saved_pfs_stack	loc2
 
+.ex_hndlr_s:
+	add	src0=8,src0
+	br.sptk .ex_handler
+	;;
+.ex_hndlr_d:
+	add	dst0=8,dst0
+	br.sptk .ex_handler
+	;;
+.ex_hndlr_lcpy_1:
+	mov	src1=src_pre_mem
+	mov	dst1=dst_pre_mem
+	cmp.gtu	p10,p11=src_pre_mem,saved_in1
+	cmp.gtu	p12,p13=dst_pre_mem,saved_in0
+	;;
+(p10)	add	src0=8,saved_in1
+(p11)	mov	src0=saved_in1
+(p12)	add	dst0=8,saved_in0
+(p13)	mov	dst0=saved_in0
+	br.sptk	.ex_handler
 .ex_handler_lcpy:
-	// in long copy block, the preload addresses should always ahead
-	// of the other two src/det pointers.  Furthermore, src1/dst1 should
+	// in line_copy block, the preload addresses should always ahead
+	// of the other two src/dst pointers.  Furthermore, src1/dst1 should
 	// always ahead of src0/dst0.
-	cmp.ltu	p10,p11=src_pre_l2,src_pre_mem
-	cmp.ltu	p12,p13=dst_pre_l2,dst_pre_mem
-	;;
-(p10)	mov	src1=src_pre_mem
-(p11)	mov	src1=src_pre_l2
-(p12)	mov	dst1=dst_pre_mem
-(p13)	mov	dst1=dst_pre_l2
-	;;
+	mov	src1=src_pre_mem
+	mov	dst1=dst_pre_mem
 .ex_handler:
 	mov	pr=saved_pr,-1		// first restore pr, lc, and pfs
 	mov	ar.lc=saved_lc

@@ -599,8 +616,8 @@
 (p6)	dep	F = r0,dst1,0,PAGE_SHIFT // usr dst round down to page boundary
 (p7)	dep	F = r0,src1,0,PAGE_SHIFT // usr src round down to page boundary
 	;;
-(p6)	cmp.le	p14,p0=F,saved_in0	// bad address to start with
-(p7)	cmp.le	p14,p0=F,saved_in1	// here too
+(p6)	cmp.le	p14,p0=dst0,saved_in0	// no progress has been made on store
+(p7)	cmp.le	p14,p0=src0,saved_in1	// no progress has been made on load
 	mov	retval=saved_in2
 (p8)	ld1	tmp=[src1]		// force an oops for memcpy call
 (p8)	st1	[dst1]=r0		// force an oops for memcpy call
#22 lore raw

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

In reply to Bill Nottingham

Chen
I installed your patch and could run the ltp suite without any oops or sytem hang.
Thanks !
Xavier

Quoted 7 lines · Kenneth W

This patch fixes some critical bugs in copy_user exception handler found by Xavier. The fixes are all in the exception handler and there are no changes in the main "copy" body. I have tested with both gcc2.96 and gcc3.1 compiler. Please report issues to me if there are any. Thanks.

- Ken