Re: LTP testing

[Johannes Stezenbach <js@convergence.de>]

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