LTP testing

LTP testing

[Carsten Langgaard]

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

The next LTP failure is:
mprotect01    1  FAIL  :  unexpected error - 14 : Bad address - expected
12

This has been fixed in the 2.4.19-pre4 patch.
But here is a local patch that solve the above problem, so we can have
this fixed before we have merged with kernel.org.

/Carsten


--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com



[-- Attachment #2: mprotect.patch --]
[-- Type: text/plain, Size: 661 bytes --]

Index: mm/mprotect.c
===================================================================
RCS file: /home/repository/sw/linux-2.4.18/mm/mprotect.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 mprotect.c
--- mm/mprotect.c	4 Mar 2002 11:13:35 -0000	1.1.1.1
+++ mm/mprotect.c	25 Jun 2002 07:00:55 -0000
@@ -284,7 +284,7 @@
 	down_write(&current->mm->mmap_sem);
 
 	vma = find_vma_prev(current->mm, start, &prev);
-	error = -EFAULT;
+	error = -ENOMEM;
 	if (!vma || vma->vm_start > start)
 		goto out;
 
@@ -317,7 +317,7 @@
 		nstart = tmp;
 		vma = next;
 		if (!vma || vma->vm_start != nstart) {
-			error = -EFAULT;
+			error = -ENOMEM;
 			goto out;
 		}
 	}

LTP testing

[Carsten Langgaard]

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

The LTP test fails with:
msgctl01    1  FAIL  :  qs_buf.msg_qbytes did not change
msgctl02    1  FAIL  :  qs_buf.msg_qbytes value is not expected
msgsnd01    1  FAIL  :  queue bytes != MSGSIZE
msgsnd01    2  FAIL  :  queue message != 1

All the above failures is fixed by the attached patch.
The msgbuf.h file is now a copy from i386, instead of alpha.
I guess the fix goes for 64-bit kernel as well.

/Carsten



--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com



[-- Attachment #2: msgbuf.patch --]
[-- Type: text/plain, Size: 1491 bytes --]

Index: include/asm-mips/msgbuf.h
===================================================================
RCS file: /home/repository/sw/linux-2.4.18/include/asm-mips/msgbuf.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 msgbuf.h
--- include/asm-mips/msgbuf.h	4 Mar 2002 11:13:24 -0000	1.1.1.1
+++ include/asm-mips/msgbuf.h	25 Jun 2002 09:30:03 -0000
@@ -2,26 +2,30 @@
 #define _ASM_MSGBUF_H
 
 /* 
- * The msqid64_ds structure for alpha architecture.
+ * The msqid64_ds structure for i386 architecture.
  * Note extra padding because this structure is passed back and forth
  * between kernel and user space.
  *
  * Pad space is left for:
- * - 2 miscellaneous 64-bit values
+ * - 64-bit time_t to solve y2038 problem
+ * - 2 miscellaneous 32-bit values
  */
 
 struct msqid64_ds {
 	struct ipc64_perm msg_perm;
 	__kernel_time_t msg_stime;	/* last msgsnd time */
+	unsigned long	__unused1;
 	__kernel_time_t msg_rtime;	/* last msgrcv time */
+	unsigned long	__unused2;
 	__kernel_time_t msg_ctime;	/* last change time */
+	unsigned long	__unused3;
 	unsigned long  msg_cbytes;	/* current number of bytes on queue */
 	unsigned long  msg_qnum;	/* number of messages in queue */
 	unsigned long  msg_qbytes;	/* max number of bytes on queue */
 	__kernel_pid_t msg_lspid;	/* pid of last msgsnd */
 	__kernel_pid_t msg_lrpid;	/* last receive pid */
-	unsigned long  __unused1;
-	unsigned long  __unused2;
+	unsigned long  __unused4;
+	unsigned long  __unused5;
 };
 
 #endif /* _ASM_MSGBUF_H */

LTP testing

[Carsten Langgaard]

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

The next LTP failure is:
msync05     1  FAIL  :  msync() fails, unexpected errno:14, expected:
ENOMEM

This has also been fixed in the 2.4.19-pre4 patch.
See the attached patch below.

/Carsten



--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com



[-- Attachment #2: filemap.patch --]
[-- Type: text/plain, Size: 902 bytes --]

Index: mm/filemap.c
===================================================================
RCS file: /home/repository/sw/linux-2.4.18/mm/filemap.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 filemap.c
--- mm/filemap.c	4 Mar 2002 11:13:34 -0000	1.1.1.1
+++ mm/filemap.c	25 Jun 2002 10:36:12 -0000
@@ -2179,18 +2179,18 @@
 		goto out;
 	/*
 	 * If the interval [start,end) covers some unmapped address ranges,
-	 * just ignore them, but return -EFAULT at the end.
+	 * just ignore them, but return -ENOMEM at the end.
 	 */
 	vma = find_vma(current->mm, start);
 	unmapped_error = 0;
 	for (;;) {
 		/* Still start < end. */
-		error = -EFAULT;
+		error = -ENOMEM;
 		if (!vma)
 			goto out;
 		/* Here start < vma->vm_end. */
 		if (start < vma->vm_start) {
-			unmapped_error = -EFAULT;
+			unmapped_error = -ENOMEM;
 			start = vma->vm_start;
 		}
 		/* Here vma->vm_start <= start < vma->vm_end. */

Re: LTP testing

[Maciej W. Rozycki]

On Tue, 25 Jun 2002, Carsten Langgaard wrote:

> The msgbuf.h file is now a copy from i386, instead of alpha.
> I guess the fix goes for 64-bit kernel as well.

 I guess not, as long is 64-bit there, thus the Alpha version is more
appropriate. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

LTP testing

[Carsten Langgaard]

The next LTP failure line is:
pipe05      1  BROK  :  Unexpected signal 11 received.

For this one I haven't got a fix, because the failure is due to the way
the pipe syscall is implemented for MIPS (so we need a fix in both the
kernel and glibc).

The glibc code look like this
SYSCALL__ (pipe, 1)
        /* Plop in the two descriptors.  */
        sw v0, 0(a0)
        sw v1, 4(a0)

        /* Go out with a clean status.  */
        move v0, zero
        j ra
        .end __pipe

The problem is that the code is called with $a0 = 0. So the 'sw v0,
0(a0)' after the syscall generates a segmentation fault.
Why are the pipe syscall implemented this way, where we return the two
descriptors in v0 and v1 ?
Why doesn't the kernel do these stores (this way we can do an access
check, like i386 does) ?

/Carsten


--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: LTP testing

[Maciej W. Rozycki]

On Tue, 25 Jun 2002, Carsten Langgaard wrote:

> The next LTP failure line is:
> pipe05      1  BROK  :  Unexpected signal 11 received.
> 
> For this one I haven't got a fix, because the failure is due to the way
> the pipe syscall is implemented for MIPS (so we need a fix in both the
> kernel and glibc).
> 
> The glibc code look like this
> SYSCALL__ (pipe, 1)
>         /* Plop in the two descriptors.  */
>         sw v0, 0(a0)
>         sw v1, 4(a0)
> 
>         /* Go out with a clean status.  */
>         move v0, zero
>         j ra
>         .end __pipe
> 
> The problem is that the code is called with $a0 = 0. So the 'sw v0,
> 0(a0)' after the syscall generates a segmentation fault.

 The test is broken and it's what should be fixed, instead -- several
Linux platforms do it this way, e.g. Alpha and IA-64.  A SIGSEGV is a
valid response for an invalid address.  Remember you test pipe(3) and not
pipe(2). 

> Why are the pipe syscall implemented this way, where we return the two
> descriptors in v0 and v1 ?

 For performance reasons.  Also it's safer to do such actions from the
userland.

> Why doesn't the kernel do these stores (this way we can do an access
> check, like i386 does) ?

 I suppose i386 does these stores in the kernel due to historical reasons. 
There is also the problem of a permanent lack of registers in i386 -- I
haven't investigated it, but it may simply be unable to afford a second
result register.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: LTP testing

[Ralf Baechle]

On Tue, Jun 25, 2002 at 09:15:36AM +0200, Carsten Langgaard wrote:

> The next LTP failure is:
> mprotect01    1  FAIL  :  unexpected error - 14 : Bad address - expected
> 12
> 
> This has been fixed in the 2.4.19-pre4 patch.
> But here is a local patch that solve the above problem, so we can have
> this fixed before we have merged with kernel.org.

I'm going to merge with -rc1 asap.

  Ralf

Re: LTP testing

[Carsten Langgaard]

"Maciej W. Rozycki" wrote:

> On Tue, 25 Jun 2002, Carsten Langgaard wrote:
>
> > The next LTP failure line is:
> > pipe05      1  BROK  :  Unexpected signal 11 received.
> >
> > For this one I haven't got a fix, because the failure is due to the way
> > the pipe syscall is implemented for MIPS (so we need a fix in both the
> > kernel and glibc).
> >
> > The glibc code look like this
> > SYSCALL__ (pipe, 1)
> >         /* Plop in the two descriptors.  */
> >         sw v0, 0(a0)
> >         sw v1, 4(a0)
> >
> >         /* Go out with a clean status.  */
> >         move v0, zero
> >         j ra
> >         .end __pipe
> >
> > The problem is that the code is called with $a0 = 0. So the 'sw v0,
> > 0(a0)' after the syscall generates a segmentation fault.
>
>  The test is broken and it's what should be fixed, instead -- several
> Linux platforms do it this way, e.g. Alpha and IA-64.  A SIGSEGV is a
> valid response for an invalid address.  Remember you test pipe(3) and not
> pipe(2).

I'm not sure that you mean by pipe(2) and pipe(3), but according to my man
page, pipe should return with EFAULT in this case.

ERRORS
       EMFILE Too  many  file  descriptors are in use by the pro­
              cess.
       ENFILE The system file table is full.
       EFAULT filedes is not valid.

>
>
> > Why are the pipe syscall implemented this way, where we return the two
> > descriptors in v0 and v1 ?
>
>  For performance reasons.  Also it's safer to do such actions from the
> userland.
>
> > Why doesn't the kernel do these stores (this way we can do an access
> > check, like i386 does) ?
>
>  I suppose i386 does these stores in the kernel due to historical reasons.
> There is also the problem of a permanent lack of registers in i386 -- I
> haven't investigated it, but it may simply be unable to afford a second
> result register.
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: LTP testing

[Johannes Stezenbach]

On Tue, Jun 25, 2002 at 03:53:25PM +0200, Maciej W. Rozycki wrote:
> On Tue, 25 Jun 2002, Carsten Langgaard wrote:
> 
> > The next LTP failure line is:
> > pipe05      1  BROK  :  Unexpected signal 11 received.
> > 
> > For this one I haven't got a fix, because the failure is due to the way
> > the pipe syscall is implemented for MIPS (so we need a fix in both the
> > kernel and glibc).
> > 
> > The glibc code look like this
> > SYSCALL__ (pipe, 1)
> >         /* Plop in the two descriptors.  */
> >         sw v0, 0(a0)
> >         sw v1, 4(a0)
> > 
> >         /* Go out with a clean status.  */
> >         move v0, zero
> >         j ra
> >         .end __pipe
> > 
> > The problem is that the code is called with $a0 = 0. So the 'sw v0,
> > 0(a0)' after the syscall generates a segmentation fault.
> 
>  The test is broken and it's what should be fixed, instead -- several
> Linux platforms do it this way, e.g. Alpha and IA-64.  A SIGSEGV is a
> valid response for an invalid address.  Remember you test pipe(3) and not
> pipe(2). 

The question is what API spec is relevant for Linux. My pipe(2) man page
says (there is no pipe(3) man page):

  int pipe(int filedes[2]);
  ...
  ERRORS
    ...
    EFAULT filedes is not valid.

whereas The Single UNIX ® Specification, Version 2
(http://www.opengroup.org/onlinepubs/007908799/xsh/pipe.html)
implies the SIGSEGV is OK.

Maybe the LTP folks can shed a light on this.


Regards,
Johannes

Re: LTP testing

[Ralf Baechle]

On Tue, Jun 25, 2002 at 03:21:58PM +0200, Carsten Langgaard wrote:

> The problem is that the code is called with $a0 = 0. So the 'sw v0,
> 0(a0)' after the syscall generates a segmentation fault.
> Why are the pipe syscall implemented this way, where we return the two
> descriptors in v0 and v1 ?
> Why doesn't the kernel do these stores (this way we can do an access
> check, like i386 does) ?

Because the interface we're using here is even lighter, even faster.  Note
that by the time when I decieded to use this interface this was potencially
a huge difference as verify_area() was searching the mm AVL trees, so this
interface was potenciall much faster by that time.

  Ralf

Re: LTP testing

[Maciej W. Rozycki]

On Tue, 25 Jun 2002, Carsten Langgaard wrote:

> > Linux platforms do it this way, e.g. Alpha and IA-64.  A SIGSEGV is a
> > valid response for an invalid address.  Remember you test pipe(3) and not
> > pipe(2).
> 
> I'm not sure that you mean by pipe(2) and pipe(3), but according to my man
> page, pipe should return with EFAULT in this case.

 pipe(2) is a syscall, while pipe(3) is a library call (see `man 2 intro'
and `man 3 intro', respectively).  You rarely access syscalls directly --
the system library usually does this for you.  Depending on a system
certain library functions may be trivial syscall wrappers, invoke a number
of syscalls (see e.g. the stat() family) or be implemented entirely in the
userland. 

> ERRORS
>        EMFILE Too  many  file  descriptors are in use by the pro­
>               cess.
>        ENFILE The system file table is full.
>        EFAULT filedes is not valid.

 Yep, this denotes such an error is possible and under what conditions.  I
don't think it actually mandates it, at least it's not expressed
explicitly.  Anyway, it's valid for i386 and possibly nothing else.  Look
at the system version it refers to -- my version is: "Linux 0.99.11 23
July 1993".

 A brief search of the web for "EFAULT pipe" reveals confirms others agree
with me -- the error is not mandatory (the EFAULT vs SIGSEGV issue was
discussed a few times at least in various contexts -- go search the web). 

 I believe a SIGSEGV is saner, too -- this way it's harder for an error
resulting from passing an invalid pointer to remain unnoticed (consider
some code that passes a pointer to read-only memory and fails to check a
result of pipe()).

 If still in doubt, you may try to discuss the LTP result at
<linux-kernel@vger.kernel.org>.  I don't think anybody wants to rewrite
pipe(2) for all the platforms that handle it our way. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: LTP testing

[Carsten Langgaard]

Ok, you have convinced me, as long as the man page and the LTP get fixed.

/Carsten

"Maciej W. Rozycki" wrote:

> On Tue, 25 Jun 2002, Carsten Langgaard wrote:
>
> > > Linux platforms do it this way, e.g. Alpha and IA-64.  A SIGSEGV is a
> > > valid response for an invalid address.  Remember you test pipe(3) and not
> > > pipe(2).
> >
> > I'm not sure that you mean by pipe(2) and pipe(3), but according to my man
> > page, pipe should return with EFAULT in this case.
>
>  pipe(2) is a syscall, while pipe(3) is a library call (see `man 2 intro'
> and `man 3 intro', respectively).  You rarely access syscalls directly --
> the system library usually does this for you.  Depending on a system
> certain library functions may be trivial syscall wrappers, invoke a number
> of syscalls (see e.g. the stat() family) or be implemented entirely in the
> userland.
>
> > ERRORS
> >        EMFILE Too  many  file  descriptors are in use by the pro­
> >               cess.
> >        ENFILE The system file table is full.
> >        EFAULT filedes is not valid.
>
>  Yep, this denotes such an error is possible and under what conditions.  I
> don't think it actually mandates it, at least it's not expressed
> explicitly.  Anyway, it's valid for i386 and possibly nothing else.  Look
> at the system version it refers to -- my version is: "Linux 0.99.11 23
> July 1993".
>
>  A brief search of the web for "EFAULT pipe" reveals confirms others agree
> with me -- the error is not mandatory (the EFAULT vs SIGSEGV issue was
> discussed a few times at least in various contexts -- go search the web).
>
>  I believe a SIGSEGV is saner, too -- this way it's harder for an error
> resulting from passing an invalid pointer to remain unnoticed (consider
> some code that passes a pointer to read-only memory and fails to check a
> result of pipe()).
>
>  If still in doubt, you may try to discuss the LTP result at
> <linux-kernel@vger.kernel.org>.  I don't think anybody wants to rewrite
> pipe(2) for all the platforms that handle it our way.
>
>   Maciej
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: LTP testing

[Ralf Baechle]

On Tue, Jun 25, 2002 at 05:06:39PM +0200, Carsten Langgaard wrote:

> Ok, you have convinced me, as long as the man page and the LTP get fixed.

Linux man pages traditionally are just a rough approximation; the official
X-Open, SysV ABI etc. standards documents should be consulted instead.

  Ralf