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

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

[Bill Nottingham]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

David Mosberger (davidm@hpl.hp.com) said: 
> 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

[-- Attachment #2: linux-2.4.0-test12-ia64-idesym.patch --]
[-- Type: text/plain, Size: 401 bytes --]

--- linux/arch/ia64/kernel/ia64_ksyms.c.foo	Thu Dec 14 18:54:41 2000
+++ linux/arch/ia64/kernel/ia64_ksyms.c	Thu Dec 14 18:55:20 2000
@@ -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); */

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

[Bill Nottingham]

David Mosberger (davidm@hpl.hp.com) said: 
> 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


> 
> 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
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

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

[Bill Nottingham]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Keith Owens (kaos@melbourne.sgi.com) said: 
> 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

[-- Attachment #2: linux-2.4.3-ia64-compile.patch --]
[-- Type: text/plain, Size: 616 bytes --]

--- linux/drivers/scsi/scsi_ioctl.c.foo	Tue May 29 12:59:24 2001
+++ linux/drivers/scsi/scsi_ioctl.c	Tue May 29 12:58:01 2001
@@ -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;
 
 	/*

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

[Bill Nottingham]

Andreas Schwab (schwab@suse.de) said: 
> 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

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

[Andreas Schwab]

Bill Nottingham <notting@redhat.com> writes:

|> Andreas Schwab (schwab@suse.de) 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.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

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

[David Mosberger]

>>>>> On Wed, 26 Sep 2001 17:59:11 -0400, Bill Nottingham <notting@redhat.com> said:

  Bill> David Mosberger (davidm@hpl.hp.com) said:
  >> 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

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

[Bill Nottingham]

David Mosberger (davidm@hpl.hp.com) said: 
>   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

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

[Bill Nottingham]

Bill Nottingham (notting@redhat.com) said: 
> 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

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

[David Mosberger]

>>>>> On Fri, 28 Sep 2001 11:32:05 -0400, Bill Nottingham <notting@redhat.com> said:

  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

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

[Bill Nottingham]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

Bill Nottingham (notting@redhat.com) said: 
> 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

[-- Attachment #2: linux-2.4.10-ia64-pcidrm.patch --]
[-- Type: text/plain, Size: 846 bytes --]

--- linux/drivers/char/drm/r128_cce.c.foo	Fri Sep 28 14:26:06 2001
+++ linux/drivers/char/drm/r128_cce.c	Fri Sep 28 14:26:17 2001
@@ -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;
 
--- linux-2.4.9-0.15/drivers/char/drm/radeon_cp.c.foo	Fri Sep 28 14:46:11 2001
+++ linux-2.4.9-0.15/drivers/char/drm/radeon_cp.c	Fri Sep 28 14:47:23 2001
@@ -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;
 

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

[Chris Ahna]

On Fri, Sep 28, 2001 at 09:13:24AM -0700, David Mosberger wrote:
> 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


--- linux-2.4.10-ia64-010924-pristine/drivers/char/drm/drm_vm.h	Wed Sep 26 09:16:03 2001
+++ linux-2.4.10-ia64-010924-dev/drivers/char/drm/drm_vm.h	Fri Sep 28 18:40:01 2001
@@ -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;
 		}

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

[Bill Nottingham]

Chris Ahna (christopher.j.ahna@intel.com) said: 
> 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

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

[David Mosberger]

>>>>> On Mon, 1 Oct 2001 14:14:06 -0400, Bill Nottingham <notting@redhat.com> said:

  Bill> Chris Ahna (christopher.j.ahna@intel.com) said:
  >> 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

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

[Xavier Bru]

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

-- 

 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:Xavier.Bru@bull.net
addr: BULL, 1 rue de Provence, BP 208, 38432 Echirolles Cedex, FRANCE
_____________________________________________________________________

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

[David Mosberger]

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

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

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

[David Mosberger]

>>>>> 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;
 

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

[Chen, Kenneth W]

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:davidm@napali.hpl.hp.com]
Sent: Friday, June 28, 2002 12:42 PM
To: Xavier Bru
Cc: linux-ia64@linuxia64.org
Subject: [Linux-ia64] Re: kernel update (relative to 2.4.18)


>>>>> 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;
 

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

[Xavier Bru]

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;
 >  

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

[Chen, 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


-----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;
 >  

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

[David Mosberger]

Ken,

>>>>> On Wed, 3 Jul 2002 09:33:35 -0700 , "Chen, Kenneth W" <kenneth.w.chen@intel.com> said:

  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

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

[Xavier Bru]

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(Jacky.Malcles@bull.net).
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");
}
------------------------------------------------------------------

David Mosberger writes:
 > Ken,
 > 
 > >>>>> On Wed, 3 Jul 2002 09:33:35 -0700 , "Chen, Kenneth W" <kenneth.w.chen@intel.com> said:
 > 
 >   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

Chen, Kenneth W writes:
 > 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
 

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

[Chen, Kenneth W]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

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:Xavier.Bru@bull.net]
Sent: Thursday, July 04, 2002 6:42 AM
To: davidm@hpl.hp.com; Chen, Kenneth W
Cc: Jacky.Malcles@bull.net; linux-ia64@linuxia64.org
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(Jacky.Malcles@bull.net).
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");
}
------------------------------------------------------------------


[-- Attachment #2: cu.fix.diff --]
[-- Type: application/octet-stream, Size: 3378 bytes --]

--- arch/ia64/lib/memcpy_mck.orig.S	Wed Jul 10 10:54:15 2002
+++ arch/ia64/lib/memcpy_mck.S	Wed Jul 10 10:54:23 2002
@@ -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

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

[Xavier Bru]

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

Chen, Kenneth W writes:
 > 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
 >