Re: [LTP] LTP - fcntl23,mincore01,madvise02 - fixes

[Robert W. <ro...@us...>]

FYI - I applied the change made to madvise02 to our CVS tree.

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


                                                                           
             Gernot Payer                                                  
             <gp...@su...>                                              
             Sent by:                                                   To 
             ltp-list-admin@li         ltp...@li...      
             sts.sourceforge.n                                          cc 
             et                                                            
                                                                   Subject 
                                       Re: [LTP] LTP -                     
             05/19/2005 05:56          fcntl23,mincore01,madvise02 - fixes 
             AM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




On Thursday 19 May 2005 08:35, pra...@wi... wrote:
> Hello,
> Under most test conditions fcntl23,mincore01,madvise02 were failing on
> ENOMEM test scenarios.

Interesting. I did not experience such problems in recent months.

> madvise02 :
> /*
>  *          TEST(madvise(file,stat.st_size + stat.st_size
> ,MADV_NORMAL));
>  *  prashant yendigeri added the below line because with above line
> ENOMEM was not generated
>  *    under most test conditions.
> */
>           TEST(madvise(file,stat.st_size * pagesize,MADV_NORMAL));

Oh, I already fixed that myself and forgot to send in the patch. ;-)

For ia64 I even use

TEST(madvise(file,stat.st_size + 5 * pagesize,MADV_NORMAL));

> mincore01 :
> /*
> * TC[2].len = global_len*5;
> * prashant yendigeri added the below line because under most test
> scenario,
> * ENOMEM was not generated
> */
>   TC[2].len = global_len*getpagesize();

This won't fix the general problem. You can't be 100% sure that you have
any
unmapped virtual memory following address global_pointer, no matter what
value is assigned to TC[2].len.
In order to increase the probability you would have to copy the mmap/munmap

stuff from setup2().

> /*
> * TC[3].addr = global_pointer+2*global_len;
> * prashant yendigeri added the below line because under most TEST
> scenario,
> * ENOMEM was not generated
> */
>   TC[3].addr = global_pointer+global_len * getpagesize();

Here the same applies.

What kernel version and architecture do you use?

> Regards,
> Prashant P Yendigeri

mfg
Gernot


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Ltp-list mailing list
Ltp...@li...
https://lists.sourceforge.net/lists/listinfo/ltp-list