* Re: [LTP] Re: LTP testing
@ 2002-06-25 17:19 Robert Williamson
2002-06-26 11:22 ` Carsten Langgaard
0 siblings, 1 reply; 2+ messages in thread
From: Robert Williamson @ 2002-06-25 17:19 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Carsten Langgaard, linux-mips, ltp-list, ltp-list-admin,
Maciej W. Rozycki, Ralf Baechle
We actually try to stick to the Single Unix Specification whenever
possible. I agree that the test should handle the SIGSEGV call. We
actually have had other tests with the same scenario and have fixed them.
These tests were ported from OS's with strict guidelines on what to expect
that matched the manpages....this is obviously not the case with Linux.
We'll take a look at it and hopefully have a fixed version by the July
release...if not a patch will be supplied on the LTP mailing list
<ltp-list@lists.sf.net>
- Robbie
Robert V. Williamson <robbiew@us.ibm.com>
Linux Test Project
IBM Linux Technology Center
Phone: (512) 838-9295 T/L: 638-9295
http://ltp.sourceforge.net
Johannes Stezenbach
<js@convergence.de> To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Sent by: cc: Carsten Langgaard <carstenl@mips.com>, Ralf Baechle
ltp-list-admin@lists.sour <ralf@oss.sgi.com>, linux-mips@oss.sgi.com,
ceforge.net ltp-list@lists.sourceforge.net
Subject: [LTP] Re: LTP testing
06/25/2002 09:28 AM
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
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [LTP] Re: LTP testing
2002-06-25 17:19 [LTP] Re: LTP testing Robert Williamson
@ 2002-06-26 11:22 ` Carsten Langgaard
0 siblings, 0 replies; 2+ messages in thread
From: Carsten Langgaard @ 2002-06-26 11:22 UTC (permalink / raw)
To: Robert Williamson
Cc: Johannes Stezenbach, linux-mips, ltp-list, ltp-list-admin,
Maciej W. Rozycki, Ralf Baechle
The setgroup03 test also fails:
setgroups03 1 FAIL : setgroups() fails, Size is > NGROUPS, errno=1, expected errno=22
Is this a kernel failure or a LTP failure ?
The kernel do the following check in sys_setgroups:
if (!capable(CAP_SETGID))
return -EPERM;
if ((unsigned) gidsetsize > NGROUPS)
return -EINVAL;
If I changes the kernel, so it does the size check first, then the test passes.
But one could also changes the LTP, so it makes sure that one is super user when making the size check test.
So my question is, should this be fixed in the kernel or in LTP ?
/Carsten
Robert Williamson wrote:
> We actually try to stick to the Single Unix Specification whenever
> possible. I agree that the test should handle the SIGSEGV call. We
> actually have had other tests with the same scenario and have fixed them.
> These tests were ported from OS's with strict guidelines on what to expect
> that matched the manpages....this is obviously not the case with Linux.
> We'll take a look at it and hopefully have a fixed version by the July
> release...if not a patch will be supplied on the LTP mailing list
> <ltp-list@lists.sf.net>
>
> - Robbie
>
> Robert V. Williamson <robbiew@us.ibm.com>
> Linux Test Project
> IBM Linux Technology Center
> Phone: (512) 838-9295 T/L: 638-9295
> http://ltp.sourceforge.net
>
>
> Johannes Stezenbach
> <js@convergence.de> To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
> Sent by: cc: Carsten Langgaard <carstenl@mips.com>, Ralf Baechle
> ltp-list-admin@lists.sour <ralf@oss.sgi.com>, linux-mips@oss.sgi.com,
> ceforge.net ltp-list@lists.sourceforge.net
> Subject: [LTP] Re: LTP testing
>
> 06/25/2002 09:28 AM
>
>
>
> 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
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
--
_ _ ____ ___ 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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-06-26 11:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-06-25 17:19 [LTP] Re: LTP testing Robert Williamson
2002-06-26 11:22 ` Carsten Langgaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox