Amos Waterland | 1 Oct 07:25 2005
Picon

[PATCH] invalid assumption in setitimer01.c

The K42 open source research operating system recently stumbled upon a
problem in testcases/kernel/syscalls/setitimer/setitimer01.c.

The logic therein assumes that two successive calls to 
setitimer(which, value, ovalue) will result in the tv_sec field of the
`ovalue' returned by the second being equal to the tv_sec field of the
'value' passed to the first.  In other words, that no time measurable in
seconds will transpire between the two calls.  This is an invalid
assumption, as demonstrated by the following:

 $ stress -m 16 -d 2 -i 4 --timeout 10m &
 $ for ((i=0; ; i++)); do setitimer01 || { echo FAIL: $i runs; break; }; done
 setitimer01    1  PASS  :  functionality is correct
 setitimer01    1  PASS  :  functionality is correct
 ...
 setitimer01    1  FAIL  :  old timer value is not equal to expected value
 FAIL: 15078 runs

The fix that seems most in keeping with the intent of the original
author (who is CC'ed) is to just assert that the seconds remaining is less
than or equal to the starting value, rather than exactly equal to the
starting value.

Signed-off-by: Amos Waterland <apw@...>

--- testcases/kernel/syscalls/setitimer/setitimer01.c.orig
+++ testcases/kernel/syscalls/setitimer/setitimer01.c
 <at>  <at>  -130,7 +130,7  <at>  <at> 
 					 "call failed");
 			}
(Continue reading)

John Clemens | 3 Oct 20:26 2005

mmapstress07/08 segv


While tracking down random SEGV's in the mmapstress test suite, I think 
there's an typo in mmapstress07.c:

lines 199-200:
         if ((mapaddr = mmap((caddr_t)0, pagesize*2 + holesize, PROT_READ,
                 MAP_SHARED|MAP_FILE, rofd, sparseoff)) == (caddr_t)-1) {

we mmap holesize plus 2 pages (in our test case, 4096, or one page.. for a 
total of 3 pages).  we then do some stuff, none of which involves mmap, or 
mremap, and then we unmap the above space thus:

line 244:
         if (munmap(mapaddr, holesize + 3*pagesize) == -1) {

Errr... 3*pagesize? that means we'd unmap 4 pages, not 3 like we mmaped in 
the above example..  typo? bug? or am I missing a nuance?  Seems to me 
this should be 2*pagesize.

This was causing segfaults for us because when compiled dynamicaly, it 
just so happens that the application itself (or one of the shared libs) 
was mapped directly after this mmap'd area, so we blew away its first 
mapped page.

In mmapstress08, the program maps small 4k chunks spaced out over the 
entire lower 1GB of the virtual address space, and then unmaps everything 
from then end of the binary (sbrk(0) space) to 1GB.  This causes a problem 
when dynamically linking on some of our systems because sometimes the 
loader maps glibc below 1GB, but not in any of the 4k spaces we happen to 
use.  So, when the program blindly munmaps everything from sbrk(0) - 1GB, 
(Continue reading)

Robert Williamson | 3 Oct 20:45 2005
Picon

Re: [PATCH] nanosleep02


Applied the patch to our CVS tree.

-Robbie
(Embedded image moved to file: pic31327.jpg)

                                                                           
             Sripathi Kodi                                                 
             <sripathik@...                                             
             .com>                                                      To 
             Sent by:                  ltp-list@...      
             ltp-list-admin <at> li                                          cc 
             sts.sourceforge.n                                             
             et                                                    Subject 
                                       [LTP] [PATCH] nanosleep02           

             08/23/2005 03:00                                              
             PM                                                            

Hi,

Please copy me on replies as I have not subscribed to this list.

I am seeing nanosleep02 testcase failure on RHEL3 machines (kernel
2.4.21-32.11.EL and other RHEL3 kernels). I believe the accuracy
expected out of 'nanosleep' call in this testcase is too high and that
is the cause of the problem. I have explained the reasons and provided a
patch for the testcase below. Failure looks like this:

nanosleep02    1  FAIL  :  Remaining sleep time 4010000 usec doesn't
(Continue reading)

Robert Williamson | 3 Oct 20:32 2005
Picon

Re: cleanup compiler warnings


Thanks for all the patches...applied them to the CVS tree for the upcoming
October release.

-Robbie
(Embedded image moved to file: pic07174.jpg)

ltp-list-admin@... wrote on 09/02/2005 01:58:37 PM:

>
> While building LTP I've noticed a number of compiler warnings.  Most of
> these seem to be due to one or more of the following:
>
>    missing include files
>    missing function prototypes
>    missing or mismatched function return types
>    missing return statements
>    missing type casts
>    unused or uninitialized variables
>
> Although these are not usually critical, I have been trying to clean up
> the build as time permitted.  I am submitting a few patches (to follow)
> that eliminate some of these warnings.  If acceptable, please apply
> these to the CVS archive.
>
>
> Thank you,
>
> d.marlin
>
(Continue reading)

Robert Williamson | 3 Oct 23:49 2005
Picon

Re: [patch] dont require perl for simple tasks


Applied all submitted patches, except this one.
> a followup to the previous 'cross-compiling perl sucks' topic ...
>
> a bunch of the generate scripts use perl to do a bunch of simple
> tasks ... ive
> rewritten the scripts in sh and unified the common functionality andit
seems
> to work OK in my quick tests
The perl was added in decrease build time.  Originally, the generate.sh
scripts
were simple shell scripts, but we found that converting them to perl reduce
the
creation time of the datafiles greatly.

>
> so, to review:
>
> - create tools/make-file.sh which attempts to generate a file with
> nothing but
> 'A's in it first with perl, then falling back to awk, and then using pure
sh
> code to get the job done
some of the generate.sh scripts create binary files, and I didn't see that
type
of code in the make-file.sh tool...though I could have just missed it.

>
> - remove testcases/kernel/sched/sched_stress/generate.sh and just
> have it call
(Continue reading)

Rishabh | 4 Oct 12:35 2005

How to compile digsig: Security related tet cases


hi,

I am trying to compile digsig testcase in testcases/kernel/security
directory. I installed bsign on my system also.
When I do "make all" I get the following output:
------------------------------------------------------------------------
--
root@...:/usb/ltp-full-20050707/testcases/kernel/security/digs
ig# make all
make[1]: Entering directory
`/usb/ltp-full-20050707/testcases/kernel/security/digsig/writeexec'
running bsign

Enter pass phrase:
bsign: incorrect passphrase or gpg not installed
bsign: incorrect passphrase or gpg not installed
bsign: incorrect passphrase or gpg not installed
make[1]: *** [all] Error 69
make[1]: Leaving directory
`/usb/ltp-full-20050707/testcases/kernel/security/digsig/writeexec'
make: *** [all] Error 2
root@...:/usb/ltp-full-20050707/testcases/kernel/security/digs
ig#
------------------------------------------------------------------------
---
What is this passphrase? Coz when I press enter the output shown above
comes up? what can be the probable coz of this problem. Any idea
guys......

(Continue reading)

Rishabh | 4 Oct 13:49 2005

Anybody used SE-Linux Test Suite


Hi all,

I am trying SE-Linux on my MIPS Machine with 2.6 kernel. I am faced with
the problem of where to get chcon. I just simply could not find it
anywhere. Any Idea where ii can download it?

Also, what all security tools required for executing SE-Linux Test
Suite?

Regards,
Rishabh Kumar Goel

The information contained in this e-mail message and in any annexure is
confidential to the  recipient and may contain privileged information. If you are not
the intended recipient, please notify the sender and delete the message along with
any annexure. You should not disclose, copy or otherwise use the information contained
in the message or any annexure. Any views expressed in this e-mail are those of the
individual sender except where the sender specifically states them to be the views of
SoCrates Software India Pvt Ltd., Bangalore.

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Robert Williamson | 4 Oct 17:23 2005
Picon

Re: Unnecessary inclusion of <linux/socket.h>


Applied to the CVS tree for this month's release (should be this
week)..thanks!

-Robbie

(Embedded image moved to file: pic30729.jpg)

                                                                           
             Jeff Bailey                                                   
             <jbailey <at> ubuntu.c                                             
             om>                                                        To 
             Sent by:                  ltp-list@...      
             ltp-list-admin <at> li                                          cc 
             sts.sourceforge.n                                             
             et                                                    Subject 
                                       [LTP] Unnecessary inclusion of      
                                       <linux/socket.h>                    
             09/10/2005 11:08                                              
             AM                                                            

The networking tests unnecessarily include linux/socket.h after
including <sys/socket.h>.

Tks,
Jeff Bailey

(See attached file: testcases-network.diff)
Attachment (testcases-network.diff): application/octet-stream, 4341 bytes
(Continue reading)

Robert Williamson | 4 Oct 18:33 2005
Picon

Re: tbio compile error on linux-2.6.11(x86-64)





Gary,

  I believe these tests only work with 2.4 kernels.  However, I'm not
familiar with them that well, so I would suggest directly contacting the
author (should be listed in the header of each file).

-Robbie
(Embedded image moved to file: pic16542.jpg)

ltp-list-admin <at> lists.sourceforge.net wrote on 09/29/2005 06:15:56 PM:

> Hi all,
>
> I get errors when I try to compile tbio.o in
> /root/gary/works/ltp-08042005/ltp-
> full-20050804/testcases/kernel/device-drivers/tbio/kernel_space.
> BTW, gcc version is 4.0.1.
>
> I found two functions in tbio.c  don't match the bio.h parameter list.
> Do we have a patch to fix it? Or may I have a help to make tbio kernel
> module compiled.
> Attached please find the compile errors between two lines of #########.
> Thanks.
>
> ~*~*~*~*~*~*~*~*
> /usr/src/kernels/2.6.11-1.1369_FC4-x86_64/include/linux/bio.h.
(Continue reading)

Robert Williamson | 4 Oct 18:36 2005
Picon

Re: [PATCH] invalid assumption in setitimer01.c


Thanks for the patch Amos...applied it to our CVS tree for the October
release.

-Robbie
(Embedded image moved to file: pic32049.jpg)

                                                                           
             apw@...                                             
             ux.ibm.com                                                    
             Sent by:                                                   To 
             ltp-list-admin <at> li         ltp-list@...      
             sts.sourceforge.n                                          cc 
             et                        Wayne Boyer/Beaverton/IBM <at> IBMUS     
                                                                   Subject 
                                       [LTP] [PATCH] invalid assumption in 
             10/01/2005 12:25          setitimer01.c                       
             AM                                                            

The K42 open source research operating system recently stumbled upon a
problem in testcases/kernel/syscalls/setitimer/setitimer01.c.

The logic therein assumes that two successive calls to
setitimer(which, value, ovalue) will result in the tv_sec field of the
`ovalue' returned by the second being equal to the tv_sec field of the
'value' passed to the first.  In other words, that no time measurable in
seconds will transpire between the two calls.  This is an invalid
assumption, as demonstrated by the following:

 $ stress -m 16 -d 2 -i 4 --timeout 10m &
(Continue reading)


Gmane