Recent changes in LTP test results

Recent changes in LTP test results

[Bryce Harrington]

Here is a listing of LTP results for the linux kernel.  For the 2.6.x
series LTP results have been pretty constant, but they've gotten
interesting lately:

Patch Name           TestReq#     CPU  PASS  FAIL  WARN  BROK  RunTime
----------------------------------------------------------------------
patch-2.4.27-rc2       294321  2-way  7226     6     3     6    69.0
linux-2.6.7            294027  2-way  7225     6     3     6    46.0
linux-2.6.7            294004  1-way  7225     6     3     6    42.2
patch-2.6.7-bk1        294069  2-way  7224     7     3     6    45.9
patch-2.6.7-bk2        294081  2-way  7224     7     3     6    45.9
patch-2.6.7-bk3        294103  2-way  7224     7     3     6    46.4
patch-2.6.7-bk4        294165  2-way  7187     7     3     6    48.7
patch-2.6.7-bk5        294181  2-way  7181     7     3     6    45.5
patch-2.6.7-bk6        294204  2-way  7224     7     3     6    47.1
patch-2.6.7-bk7        294228  2-way  7224     7     3     6    49.0
patch-2.6.7-bk8        294304  2-way  7223    10     3     7    47.5
patch-2.6.7-bk9        294333  2-way  7224     7     3     6    46.1
patch-2.6.7-bk10       294403  2-way  7223    10     3     7    42.9
patch-2.6.7-bk11       294423  2-way  7178    46     3     6    47.8
2.6.7-mm1              294146  2-way  7185    46     3     6    59.1
2.6.7-mm1              294126  1-way  7185    46     3     6    52.9
2.6.7-mm2              294271  2-way  7181    47     3     6    44.9
2.6.7-mm3              294363  1-way  7185    46     3     6    41.0
2.6.7-rc3-mm2          293949  2-way  7223     8     3     6    46.5

We usually always see 6-7 fails on the 2.6.x kernels, so the increase is
unusual.

I've generated some detailed LTP test result reports on a few of the
above runs, with specifics about the test runs and failures.  These are
available here:

    http://developer.osdl.org/bryce/ltp/

HTH,
Bryce

Re: Recent changes in LTP test results

[Andrew Morton]

Bryce Harrington <bryce@osdl.org> wrote:
>
>  Here is a listing of LTP results for the linux kernel.  For the 2.6.x
>  series LTP results have been pretty constant, but they've gotten
>  interesting lately:
> 
>  Patch Name           TestReq#     CPU  PASS  FAIL  WARN  BROK  RunTime
>  ----------------------------------------------------------------------
>  patch-2.4.27-rc2       294321  2-way  7226     6     3     6    69.0
>  linux-2.6.7            294027  2-way  7225     6     3     6    46.0
>  linux-2.6.7            294004  1-way  7225     6     3     6    42.2
>  patch-2.6.7-bk1        294069  2-way  7224     7     3     6    45.9
>  patch-2.6.7-bk2        294081  2-way  7224     7     3     6    45.9
>  patch-2.6.7-bk3        294103  2-way  7224     7     3     6    46.4
>  patch-2.6.7-bk4        294165  2-way  7187     7     3     6    48.7
>  patch-2.6.7-bk5        294181  2-way  7181     7     3     6    45.5
>  patch-2.6.7-bk6        294204  2-way  7224     7     3     6    47.1
>  patch-2.6.7-bk7        294228  2-way  7224     7     3     6    49.0
>  patch-2.6.7-bk8        294304  2-way  7223    10     3     7    47.5
>  patch-2.6.7-bk9        294333  2-way  7224     7     3     6    46.1
>  patch-2.6.7-bk10       294403  2-way  7223    10     3     7    42.9
>  patch-2.6.7-bk11       294423  2-way  7178    46     3     6    47.8
>  2.6.7-mm1              294146  2-way  7185    46     3     6    59.1
>  2.6.7-mm1              294126  1-way  7185    46     3     6    52.9
>  2.6.7-mm2              294271  2-way  7181    47     3     6    44.9
>  2.6.7-mm3              294363  1-way  7185    46     3     6    41.0
>  2.6.7-rc3-mm2          293949  2-way  7223     8     3     6    46.5
> 
>  We usually always see 6-7 fails on the 2.6.x kernels, so the increase is
>  unusual.
> 
>  I've generated some detailed LTP test result reports on a few of the
>  above runs, with specifics about the test runs and failures.  These are
>  available here:
> 
>      http://developer.osdl.org/bryce/ltp/

Seems that the new failures are all related to failing to return -EFAULT
when passing a bad filename address into filesystem syscalls.

Perhaps this was fixed recently - they work OK here.

vmm:/usr/src/ltp-full-20031002# ./testcases/kernel/syscalls/access/access03       
access03    1  PASS  :  access((char *)-1,R_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    2  PASS  :  access((char *)-1,W_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    3  PASS  :  access((char*)-1,X_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    4  PASS  :  access((char*)-1,F_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    5  PASS  :  access((char*)sbrk(0)+1,R_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    6  PASS  :  access((char*)sbrk(0)+1,W_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    7  PASS  :  access(high_address,X_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    8  PASS  :  access((char*)sbrk(0)+1,F_OK) failed as expected with errno 14 (EFAULT) : Bad address
vmm:/usr/src/ltp-full-20031002# ./testcases/kernel/syscalls/access/access05
access05    1  PASS  :  access() fails, Read Access denied on file, errno:13
access05    2  PASS  :  access() fails, Write Access denied on file, errno:13
access05    3  PASS  :  access() fails, Execute Access denied on file, errno:13
access05    4  PASS  :  access() fails, Access mode invalid, errno:22
access05    5  PASS  :  access() fails, Address beyond address space, errno:14
access05    6  PASS  :  access() fails, Negative address, errno:14
access05    7  PASS  :  access() fails, Pathname is empty, errno:2
access05    8  PASS  :  access() fails, Pathname too long, errno:36
vmm:/usr/src/ltp-full-20031002# ./testcases/kernel/syscalls/chdir/chdir04  
chdir04     1  PASS  :  expected failure - errno = 36 : File name too long
chdir04     2  PASS  :  expected failure - errno = 2 : No such file or directory
chdir04     3  PASS  :  expected failure - errno = 14 : Bad address

Re: Recent changes in LTP test results

[Bryce Harrington]

Hi Andrew,

Here's an update with mm4 and bk12:

On Mon, 28 Jun 2004, Andrew Morton wrote:
> Bryce Harrington <bryce@osdl.org> wrote:
> >
> >  Here is a listing of LTP results for the linux kernel.  For the 2.6.x
> >  series LTP results have been pretty constant, but they've gotten
> >  interesting lately:
> >
> >  Patch Name           TestReq#     CPU  PASS  FAIL  WARN  BROK  RunTime
> >  ----------------------------------------------------------------------
> >  patch-2.4.27-rc2       294321  2-way  7226     6     3     6    69.0
> >  linux-2.6.7            294027  2-way  7225     6     3     6    46.0
> >  linux-2.6.7            294004  1-way  7225     6     3     6    42.2
> >  patch-2.6.7-bk1        294069  2-way  7224     7     3     6    45.9
> >  patch-2.6.7-bk2        294081  2-way  7224     7     3     6    45.9
> >  patch-2.6.7-bk3        294103  2-way  7224     7     3     6    46.4
> >  patch-2.6.7-bk4        294165  2-way  7187     7     3     6    48.7
> >  patch-2.6.7-bk5        294181  2-way  7181     7     3     6    45.5
> >  patch-2.6.7-bk6        294204  2-way  7224     7     3     6    47.1
> >  patch-2.6.7-bk7        294228  2-way  7224     7     3     6    49.0
> >  patch-2.6.7-bk8        294304  2-way  7223    10     3     7    47.5
> >  patch-2.6.7-bk9        294333  2-way  7224     7     3     6    46.1
> >  patch-2.6.7-bk10       294403  2-way  7223    10     3     7    42.9
> >  patch-2.6.7-bk11       294423  2-way  7178    46     3     6    47.8
     patch-2.6.7-bk12       294442  2-way  7178    46     3     6    47.6

> >  2.6.7-mm1              294146  2-way  7185    46     3     6    59.1
> >  2.6.7-mm1              294126  1-way  7185    46     3     6    52.9
> >  2.6.7-mm2              294271  2-way  7181    47     3     6    44.9
> >  2.6.7-mm3              294363  1-way  7185    46     3     6    41.0
     2.6.7-mm4              294465  1-way  7178    46     3     6    42.1

> >  2.6.7-rc3-mm2          293949  2-way  7223     8     3     6    46.5
> >
> >  I've generated some detailed LTP test result reports on a few of the
> >  above runs, with specifics about the test runs and failures.  These are
> >  available here:
> >
> >      http://developer.osdl.org/bryce/ltp/
>
> Seems that the new failures are all related to failing to return -EFAULT
> when passing a bad filename address into filesystem syscalls.
>
> Perhaps this was fixed recently - they work OK here.

We're seeing the same behavior on the mm4 and bk12 kernels as before.
It looks like you're using a version of LTP from 2003...  If that's
true, could you try running the April 2004 version of LTP, just to rule
out it being a difference in test versions?

    http://prdownloads.sourceforge.net/ltp/ltp-full-20040405.tgz?download

Bryce

> vmm:/usr/src/ltp-full-20031002# ./testcases/kernel/syscalls/access/access03
> access03    1  PASS  :  access((char *)-1,R_OK) failed as expected with errno 14 (EFAULT) : Bad address
> access03    2  PASS  :  access((char *)-1,W_OK) failed as expected with errno 14 (EFAULT) : Bad address
> access03    3  PASS  :  access((char*)-1,X_OK) failed as expected with errno 14 (EFAULT) : Bad address
> access03    4  PASS  :  access((char*)-1,F_OK) failed as expected with errno 14 (EFAULT) : Bad address
> access03    5  PASS  :  access((char*)sbrk(0)+1,R_OK) failed as expected with errno 14 (EFAULT) : Bad address
> access03    6  PASS  :  access((char*)sbrk(0)+1,W_OK) failed as expected with errno 14 (EFAULT) : Bad address
> access03    7  PASS  :  access(high_address,X_OK) failed as expected with errno 14 (EFAULT) : Bad address
> access03    8  PASS  :  access((char*)sbrk(0)+1,F_OK) failed as expected with errno 14 (EFAULT) : Bad address
> vmm:/usr/src/ltp-full-20031002# ./testcases/kernel/syscalls/access/access05
> access05    1  PASS  :  access() fails, Read Access denied on file, errno:13
> access05    2  PASS  :  access() fails, Write Access denied on file, errno:13
> access05    3  PASS  :  access() fails, Execute Access denied on file, errno:13
> access05    4  PASS  :  access() fails, Access mode invalid, errno:22
> access05    5  PASS  :  access() fails, Address beyond address space, errno:14
> access05    6  PASS  :  access() fails, Negative address, errno:14
> access05    7  PASS  :  access() fails, Pathname is empty, errno:2
> access05    8  PASS  :  access() fails, Pathname too long, errno:36
> vmm:/usr/src/ltp-full-20031002# ./testcases/kernel/syscalls/chdir/chdir04
> chdir04     1  PASS  :  expected failure - errno = 36 : File name too long
> chdir04     2  PASS  :  expected failure - errno = 2 : No such file or directory
> chdir04     3  PASS  :  expected failure - errno = 14 : Bad address
>

Re: Recent changes in LTP test results

[William Lee Irwin III]

On Mon, Jun 28, 2004 at 06:46:15PM -0700, Bryce Harrington wrote:
> We usually always see 6-7 fails on the 2.6.x kernels, so the increase is
> unusual.
> I've generated some detailed LTP test result reports on a few of the
> above runs, with specifics about the test runs and failures.  These are
> available here:
>     http://developer.osdl.org/bryce/ltp/

This looks related to some widely-propagated change in errno return
value (probably originating from some centralized source and cascading
up the call chains).


-- wli

Re: [LTP] Re: Recent changes in LTP test results

[Bryce Harrington]

On Wed, 30 Jun 2004, William Lee Irwin III wrote:
> On Mon, Jun 28, 2004 at 06:46:15PM -0700, Bryce Harrington wrote:
> > We usually always see 6-7 fails on the 2.6.x kernels, so the increase is
> > unusual.
> > I've generated some detailed LTP test result reports on a few of the
> > above runs, with specifics about the test runs and failures.  These are
> > available here:
> >     http://developer.osdl.org/bryce/ltp/
>
> This looks related to some widely-propagated change in errno return
> value (probably originating from some centralized source and cascading
> up the call chains).

The results listing has been updated.

    http://developer.osdl.org/bryce/ltp/

Briefly:

Patch Name           TestReq#    CPU  PASS  FAIL  WARN  BROK
patch-2.4.27-rc2       294321  2-way  7226     6     3     6
patch-2.4.27-rc3       294624  2-way  7226     6     3     6
patch-2.6.7-bk8        294304  2-way  7223    10     3     7
patch-2.6.7-bk9        294333  2-way  7224     7     3     6
patch-2.6.7-bk10       294403  2-way  7223    10     3     7
patch-2.6.7-bk11       294423  2-way  7178    46     3     6
patch-2.6.7-bk12       294442  2-way  7178    46     3     6
patch-2.6.7-bk13       294511  2-way  7178    46     3     6
patch-2.6.7-bk14       294573  2-way  7178    46     3     6
patch-2.6.7-bk15       294601  2-way  7178    46     3     6
patch-2.6.7-bk16       294614  2-way  7178    46     3     6
patch-2.6.7-bk17       294636  2-way  7178    46     3     6
patch-2.6.7-bk18       294648  2-way  7178    46     3     6
patch-2.6.7-bk19       294733  2-way  7178    46     3     6
2.6.7-mm2              294271  2-way  7181    47     3     6
2.6.7-mm3              294383  2-way  7185    46     3     6
2.6.7-mm4              294485  2-way  7177    46     3     3
2.6.7-mm5              294554  2-way  7178    46     3     6
2.6.7-mm6              294691  2-way  7178    46     3     6



No significant difference between the results for bk11 and bk19.
Namely:


--- failrpt_294423_2.6.7-bk11.txt       2004-06-28 17:35:18.000000000 -0700
+++ failrpt_294733_2.6.7-bk19.txt       2004-07-06 18:00:23.000000000 -0700
@@ -392,7 +392,7 @@
 Details:

 nanosleep02    1   FAIL : Remaining sleep time 3999392 usec doesn't
-                         match with the expected 3998364 usec time
+                         match with the expected 3997243 usec time
 nanosleep02    1   FAIL : child process exited abnormally

Re: [LTP] Re: Recent changes in LTP test results

[Andrew Morton]

Bryce Harrington <bryce@osdl.org> wrote:
>
> The results listing has been updated.
> 
>      http://developer.osdl.org/bryce/ltp/
> 
>  Briefly:
> 
>  Patch Name           TestReq#    CPU  PASS  FAIL  WARN  BROK
> ...
>  2.6.7-mm6              294691  2-way  7178    46     3     6

Again, these tests do not fail for me, with ltp-full-20040603


vmm:/mnt/hda5/ltp-full-20040603> ./testcases/bin/access03
access03    1  PASS  :  access((char *)-1,R_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    2  PASS  :  access((char *)-1,W_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    3  PASS  :  access((char*)-1,X_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    4  PASS  :  access((char*)-1,F_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    5  PASS  :  access((char*)sbrk(0)+1,R_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    6  PASS  :  access((char*)sbrk(0)+1,W_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    7  PASS  :  access(high_address,X_OK) failed as expected with errno 14 (EFAULT) : Bad address
access03    8  PASS  :  access((char*)sbrk(0)+1,F_OK) failed as expected with errno 14 (EFAULT) : Bad address
vmm:/mnt/hda5/ltp-full-20040603> 

Can you please retest with ltp-full-20040603 and, if it still fails,
send me the .config and a description of the system and the compiler
version used to build the kernel?

Re: [LTP] Re: Recent changes in LTP test results

[Bryce Harrington]

On Tue, 6 Jul 2004, Andrew Morton wrote:
> Bryce Harrington <bryce@osdl.org> wrote:
> >
> > The results listing has been updated.
> >
> >      http://developer.osdl.org/bryce/ltp/
> >
> >  Briefly:
> >
> >  Patch Name           TestReq#    CPU  PASS  FAIL  WARN  BROK
> > ...
> >  2.6.7-mm6              294691  2-way  7178    46     3     6
>
> Again, these tests do not fail for me, with ltp-full-20040603
>
>
> vmm:/mnt/hda5/ltp-full-20040603> ./testcases/bin/access03
> access03    1  PASS  :  access((char *)-1,R_OK) failed as expected with errno 14 (EFAULT) : Bad address
> access03    2  PASS  :  access((char *)-1,W_OK) failed as expected with errno 14 (EFAULT) : Bad address
...
>
> Can you please retest with ltp-full-20040603 and, if it still fails,
> send me the .config and a description of the system and the compiler
> version used to build the kernel?

Hi Andrew,

I have retested with ltp-full-20040603.  This version of LTP hangs on
our system but fortunately completes most of the tests before doing so.
It indicates that it still encounters the same errors, e.g.:

access03       1   FAIL : access((char *)-1,R_OK) failed with errno 2 : No such file or directory but expected 14 (EFAULT)
access03       2   FAIL : access((char *)-1,W_OK) failed with errno 2 : No such file or directory but expected 14 (EFAULT)
...


Here is the .config, system description, compiler version, and other info:

Full results:      http://khack.osdl.org/stp/294760/

Kernel config:     http://khack.osdl.org/stp/294760/environment/kernel-config

System desc:       http://khack.osdl.org/stp/294760/environment/machine_info
                   http://khack.osdl.org/stp/294760/environment/System_Information-after.txt

RH9 Pkg upgrades:  http://khack.osdl.org/stp/294760/environment/package-upgrades

Syslog:            http://khack.osdl.org/stp/294760/environment/syslog-capture

Compiler and other tools:
    Distro                 Red Hat Linux release 9 (Shrike)
    Kernel                 Linux stp1-003 2.6.7-bk19 #1 Wed Jul 7 11:17:10 PDT 2004
    Compiler               gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
    Gnu make               3.79.1
    util-linux             2.11y
    mount                  2.11y
    modutils               2.4.22
    e2fsprogs              1.32
    pcmcia-cs              3.1.31
    PPP                    2.4.1
    isdn4k-utils           3.1pre4
    Linux C Library        2.3.2
    Dynamic linker (ldd)   2.3.2
    Procps                 2.0.11
    Net-tools              1.60
    Kbd                    1.08
    Sh-utils               4.5.3

Thanks,
Bryce

Re: [LTP] Re: Recent changes in LTP test results

[David S. Miller]

On Wed, 7 Jul 2004 13:48:52 -0700 (PDT)
Bryce Harrington <bryce@osdl.org> wrote:

> I have retested with ltp-full-20040603.  This version of LTP hangs on
> our system but fortunately completes most of the tests before doing so.
> It indicates that it still encounters the same errors, e.g.:

It hangs (actually, it OOPS's) on accept01, which is fixed in the current
BK sources via this patch:

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/07/06 22:02:06-07:00 davem@nuts.davemloft.net 
#   [IPV4]: Set UDP accept back to sock_no_accept.
#   
#   Setting it to inet_accept causes UDP accept attempts
#   to OOPS.  In particular, accept01 from LTP tries this.
#   
#   Signed-off-by: David S. Miller <davem@redhat.com>
# 
# net/ipv4/af_inet.c
#   2004/07/06 22:01:31-07:00 davem@nuts.davemloft.net +1 -1
#   [IPV4]: Set UDP accept back to sock_no_accept.
#   
#   Setting it to inet_accept causes UDP accept attempts
#   to OOPS.  In particular, accept01 from LTP tries this.
#   
#   Signed-off-by: David S. Miller <davem@redhat.com>
# 
diff -Nru a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
--- a/net/ipv4/af_inet.c	2004-07-07 14:09:13 -07:00
+++ b/net/ipv4/af_inet.c	2004-07-07 14:09:13 -07:00
@@ -823,7 +823,7 @@
 	.bind =		inet_bind,
 	.connect =	inet_dgram_connect,
 	.socketpair =	sock_no_socketpair,
-	.accept =	inet_accept,
+	.accept =	sock_no_accept,
 	.getname =	inet_getname,
 	.poll =		datagram_poll,
 	.ioctl =	inet_ioctl,

Re: [LTP] Re: Recent changes in LTP test results

[Bryce Harrington]

Hi David,

Thanks, I tried this patch out, and it does fix the accept01 error.  :-)

    http://khack.osdl.org/stp/294783/

Do you have ideas on the other failures encountered?

Bryce

On Wed, 7 Jul 2004, David S. Miller wrote:
> On Wed, 7 Jul 2004 13:48:52 -0700 (PDT)
> Bryce Harrington <bryce@osdl.org> wrote:
>
> > I have retested with ltp-full-20040603.  This version of LTP hangs on
> > our system but fortunately completes most of the tests before doing so.
> > It indicates that it still encounters the same errors, e.g.:
>
> It hangs (actually, it OOPS's) on accept01, which is fixed in the current
> BK sources via this patch:
>
> # This is a BitKeeper generated diff -Nru style patch.
> #
> # ChangeSet
> #   2004/07/06 22:02:06-07:00 davem@nuts.davemloft.net
> #   [IPV4]: Set UDP accept back to sock_no_accept.
> #
> #   Setting it to inet_accept causes UDP accept attempts
> #   to OOPS.  In particular, accept01 from LTP tries this.
> #
> #   Signed-off-by: David S. Miller <davem@redhat.com>
> #
> # net/ipv4/af_inet.c
> #   2004/07/06 22:01:31-07:00 davem@nuts.davemloft.net +1 -1
> #   [IPV4]: Set UDP accept back to sock_no_accept.
> #
> #   Setting it to inet_accept causes UDP accept attempts
> #   to OOPS.  In particular, accept01 from LTP tries this.
> #
> #   Signed-off-by: David S. Miller <davem@redhat.com>
> #
> diff -Nru a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> --- a/net/ipv4/af_inet.c	2004-07-07 14:09:13 -07:00
> +++ b/net/ipv4/af_inet.c	2004-07-07 14:09:13 -07:00
> @@ -823,7 +823,7 @@
>  	.bind =		inet_bind,
>  	.connect =	inet_dgram_connect,
>  	.socketpair =	sock_no_socketpair,
> -	.accept =	inet_accept,
> +	.accept =	sock_no_accept,
>  	.getname =	inet_getname,
>  	.poll =		datagram_poll,
>  	.ioctl =	inet_ioctl,
>

Re: [LTP] Re: Recent changes in LTP test results

[Andrew Morton]

Bryce Harrington <bryce@osdl.org> wrote:
>
> I have retested with ltp-full-20040603.  This version of LTP hangs on
>  our system but fortunately completes most of the tests before doing so.
>  It indicates that it still encounters the same errors, e.g.:
> 
>  access03       1   FAIL : access((char *)-1,R_OK) failed with errno 2 : No such file or directory but expected 14 (EFAULT)
>  access03       2   FAIL : access((char *)-1,W_OK) failed with errno 2 : No such file or directory but expected 14 (EFAULT)

Nope, sorry, still cannot reproduce it - you'll need to debug it at your end.

BTW, how long does a runalltests run take nowadays?  More than 90 minutes,
that's for sure.  That's quite irritating...

Re: [LTP] Re: Recent changes in LTP test results

[Rik van Riel]

On Wed, 7 Jul 2004, Andrew Morton wrote:

> BTW, how long does a runalltests run take nowadays?  More than 90 minutes,
> that's for sure.  That's quite irritating...

Run with '-x 10' to run 10 tests in parallel ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: [LTP] Re: Recent changes in LTP test results

[Daniel McNeil]

On Wed, 2004-07-07 at 23:07, Andrew Morton wrote:
> Bryce Harrington <bryce@osdl.org> wrote:
> >
> > I have retested with ltp-full-20040603.  This version of LTP hangs on
> >  our system but fortunately completes most of the tests before doing so.
> >  It indicates that it still encounters the same errors, e.g.:
> > 
> >  access03       1   FAIL : access((char *)-1,R_OK) failed with errno 2 : No such file or directory but expected 14 (EFAULT)
> >  access03       2   FAIL : access((char *)-1,W_OK) failed with errno 2 : No such file or directory but expected 14 (EFAULT)
> 
> Nope, sorry, still cannot reproduce it - you'll need to debug it at your end.


Andrew,

Mark and I are able to reproduce this with the simple
program below.  The mmap() PROT_NONE is not giving a EFAULT
on read.  The test was mmap a PROT_NONE address and passing
that into the access() syscall and then looking for a
EFAULT.  Instead it was getting ENOENT.  We found that
by backing out the nx-update.patch from -mm1 patches
the problem went away.

The /proc/pid/maps looked like this:

without nx-update patch:
40017000-40018000 ---p 40017000 00:00 0
=====
with -mm1:
40017000-40018000 --xp 40017000 00:00 0

So it looks like the page being executable allows read
access.

Not sure why you do not see this on your machine.  This
fails on my 2-proc xeon box (and all the STP machines).

I can send more info if you need it.

Daniel (and Mark)

#include <unistd.h>
#include <errno.h>
#include <sys/mman.h>


main()
{
	char *p0 = 0;
	char *p1 = (char *)-1;
	char *p2;
	int err;

	p2 = mmap(0, 4096, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);

	errno = 0;
	err = access(p0, R_OK);
	printf("access 0 ptr %p return code %d errno %d\n", p0, err, errno);
	perror("access result:");
	errno = 0;
	err = access(p1, R_OK);
	printf("access 1 ptr %p return code %d errno %d\n", p1, err, errno);
	perror("access result:");
	errno = 0;
	err = access(p2, R_OK);
	printf("access 2 ptr %p return code %d errno %d\n", p2, err, errno);
	perror("access result:");
}

Re: [LTP] Re: Recent changes in LTP test results

[Andrew Morton]

Daniel McNeil <daniel@osdl.org> wrote:
>
> The /proc/pid/maps looked like this:
> 
>  without nx-update patch:
>  40017000-40018000 ---p 40017000 00:00 0
>  =====
>  with -mm1:
>  40017000-40018000 --xp 40017000 00:00 0

Here's mine, with current -linus bk:

40000000-40001000 ---p 40000000 00:00 0 

>  So it looks like the page being executable allows read
>  access.
> 
>  Not sure why you do not see this on your machine.  This
>  fails on my 2-proc xeon box (and all the STP machines).
> 


#include <unistd.h>
#include <errno.h>
#include <sys/mman.h>


main()
{
	char *p0 = 0;
	char *p1 = (char *)-1;
	char *p2;
	int err;

	p2 = mmap(0, 4096, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);

	printf("p2=%p\n", p2);
	printf("pid=%d\n", getpid());

	getchar();

	errno = 0;
	err = access(p0, R_OK);
	printf("access 0 ptr %p return code %d errno %d\n", p0, err, errno);
	perror("access result:");
	errno = 0;
	err = access(p1, R_OK);
	printf("access 1 ptr %p return code %d errno %d\n", p1, err, errno);
	perror("access result:");
	errno = 0;
	err = access(p2, R_OK);
	printf("access 2 ptr %p return code %d errno %d\n", p2, err, errno);
	perror("access result:");
}

vmm:/home/akpm> ./x
p2=0x40000000
pid=2038

access 0 ptr (nil) return code -1 errno 14
access result:: Bad address
access 1 ptr 0xffffffff return code -1 errno 14
access result:: Bad address
access 2 ptr 0x40000000 return code -1 errno 14
access result:: Bad address

I get this result on both p4 xeon and p3 xeon.

Re: [LTP] Re: Recent changes in LTP test results

[Daniel McNeil]

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

On Fri, 2004-07-09 at 23:45, Andrew Morton wrote:

> Here's mine, with current -linus bk:
> 
> 40000000-40001000 ---p 40000000 00:00 0 
> 
> >  So it looks like the page being executable allows read
> >  access.
> > 
> >  Not sure why you do not see this on your machine.  This
> >  fails on my 2-proc xeon box (and all the STP machines).
> > 
> 
> 
> #include <unistd.h>
> #include <errno.h>
> #include <sys/mman.h>
> 
> 
> main()
> {
> 	char *p0 = 0;
> 	char *p1 = (char *)-1;
> 	char *p2;
> 	int err;
> 
> 	p2 = mmap(0, 4096, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
> 
> 	printf("p2=%p\n", p2);
> 	printf("pid=%d\n", getpid());
> 
> 	getchar();
> 
> 	errno = 0;
> 	err = access(p0, R_OK);
> 	printf("access 0 ptr %p return code %d errno %d\n", p0, err, errno);
> 	perror("access result:");
> 	errno = 0;
> 	err = access(p1, R_OK);
> 	printf("access 1 ptr %p return code %d errno %d\n", p1, err, errno);
> 	perror("access result:");
> 	errno = 0;
> 	err = access(p2, R_OK);
> 	printf("access 2 ptr %p return code %d errno %d\n", p2, err, errno);
> 	perror("access result:");
> }
> 
> vmm:/home/akpm> ./x
> p2=0x40000000
> pid=2038
> 
> access 0 ptr (nil) return code -1 errno 14
> access result:: Bad address
> access 1 ptr 0xffffffff return code -1 errno 14
> access result:: Bad address
> access 2 ptr 0x40000000 return code -1 errno 14
> access result:: Bad address
> 
> I get this result on both p4 xeon and p3 xeon.


Andrew,

It is the elf file that makes the difference. I was using
gcc 3.2.2 and ld (GNU ld version 2.13.90.0.18 20030206).
This produces elf binary without the PT_GNU_STACK program
section (from objdump -p x.gcc322)

Program Header:
    PHDR off    0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
         filesz 0x000000c0 memsz 0x000000c0 flags r-x
  INTERP off    0x000000f4 vaddr 0x080480f4 paddr 0x080480f4 align 2**0
         filesz 0x00000013 memsz 0x00000013 flags r--
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00000750 memsz 0x00000750 flags r-x
    LOAD off    0x00000750 vaddr 0x08049750 paddr 0x08049750 align 2**12
         filesz 0x00000118 memsz 0x0000011c flags rw-
 DYNAMIC off    0x0000075c vaddr 0x0804975c paddr 0x0804975c align 2**2
         filesz 0x000000c8 memsz 0x000000c8 flags rw-
    NOTE off    0x00000108 vaddr 0x08048108 paddr 0x08048108 align 2**2
         filesz 0x00000020 memsz 0x00000020 flags r--

With gcc 3.4.1 and GNU ld version 2.14.90.0.6 20030820 and
compile with cc -o x.rw -z noexecstack x.c produces a 
elf binary without execute permission on the stack.
(from objdump -p x.rw)

Program Header:
    PHDR off    0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
         filesz 0x000000e0 memsz 0x000000e0 flags r-x
  INTERP off    0x00000114 vaddr 0x08048114 paddr 0x08048114 align 2**0
         filesz 0x00000013 memsz 0x00000013 flags r--
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00000735 memsz 0x00000735 flags r-x
    LOAD off    0x00000738 vaddr 0x08049738 paddr 0x08049738 align 2**12
         filesz 0x0000011c memsz 0x00000120 flags rw-
 DYNAMIC off    0x00000748 vaddr 0x08049748 paddr 0x08049748 align 2**2
         filesz 0x000000c8 memsz 0x000000c8 flags rw-
    NOTE off    0x00000128 vaddr 0x08048128 paddr 0x08048128 align 2**2
         filesz 0x00000020 memsz 0x00000020 flags r--
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags rw-

With gcc 3.4.1 and GNU ld version 2.14.90.0.6 20030820 and
compiled with cc -o x.rwx -z execstack x.c.  This produces
the same binary as with out the "-z execstack".

Program Header:
    PHDR off    0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
         filesz 0x000000e0 memsz 0x000000e0 flags r-x
  INTERP off    0x00000114 vaddr 0x08048114 paddr 0x08048114 align 2**0
         filesz 0x00000013 memsz 0x00000013 flags r--
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00000735 memsz 0x00000735 flags r-x
    LOAD off    0x00000738 vaddr 0x08049738 paddr 0x08049738 align 2**12
         filesz 0x0000011c memsz 0x00000120 flags rw-
 DYNAMIC off    0x00000748 vaddr 0x08049748 paddr 0x08049748 align 2**2
         filesz 0x000000c8 memsz 0x000000c8 flags rw-
    NOTE off    0x00000128 vaddr 0x08048128 paddr 0x08048128 align 2**2
         filesz 0x00000020 memsz 0x00000020 flags r--
0x6474e551 off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags rwx

Here's the corresponding /proc/pid/maps output from the
3 different binaries:


x.gcc322:	40013000-40014000 --xp 40013000 00:00 0
x.rw:		40013000-40014000 ---p 40013000 00:00 0
x.rwx:		40013000-40014000 ---p 40013000 00:00 0


So binaries compiled with an old compiler are not being
handled correctly with the nx-update.patch changes.

In load_elf_binary()

        for (i = 0; i < elf_ex.e_phnum; i++, elf_ppnt++)
                if (elf_ppnt->p_type == PT_GNU_STACK) {
                        if (elf_ppnt->p_flags & PF_X)
                                executable_stack = EXSTACK_ENABLE_X;
                        else
                                executable_stack = EXSTACK_DISABLE_X;
                        break;
                }
        if (i == elf_ex.e_phnum)
                def_flags |= VM_EXEC | VM_MAYEXEC;

This setting of def_flags if the PT_GNU_STACK is NOT found
is causing the old binaries to get exec on PROT_NONE mmaps.

I've attached the 3 elf binaries.

Daniel

[-- Attachment #2: x.gcc322 --]
[-- Type: application/x-executable-binary, Size: 20435 bytes --]

[-- Attachment #3: x.rw --]
[-- Type: application/x-executable-binary, Size: 12544 bytes --]

[-- Attachment #4: x.rwx --]
[-- Type: application/x-executable-binary, Size: 12544 bytes --]