On Wed, 2007-12-12 at 12:50 +0530, Subrata Modak wrote: > Hi, > > Please find a problem reported by Mark Ver for the mincore01 test case > in LTP. He has also provided fix for the same. Kindly review this patch: > > ======================================================================= > Mark Reports: > ======================================================================= > mincore01 testcase fails with: > t75ticltst:~/ltp-full-20071031/testcases/kernel/syscalls/mincore # ./mincore01 > mincore01 1 PASS : expected failure: errno = 22 (Invalid argument) > mincore01 2 FAIL : call succeeded unexpectedly > mincore01 3 PASS : expected failure: errno = 12 (Cannot allocate memory) > t75ticltst:~/ltp-full-20071031/testcases/kernel/syscalls/mincore # > > It only happens on 31bit and seems to work on on SLES-9 SP3. > > > If this is not an installation problem, > Provide output from "uname -a", if possible: > Linux t75ticltst 2.6.5-7.305-s390 #1 SMP Tue Nov 13 23:19:08 UTC 2007 s390 > s390 > s390 GNU/Linux > > > Hardware Environment > Machine type (p650, x235, SF2, etc.): Tested on System z9 EC and z800 > Cpu type (Power4, Power5, IA-64, etc.): > Describe any special hardware you think might be relevant to this problem: > > > Is this reproducible? Yes > If so, how long does it (did it) take to reproduce it? 20sec - 30min > Describe the steps: > - Install SLES-9 SP4 31bit system > - Get, unpack, and compile the ltp test suite > - Run the mincore01 testcase > > =============================================================================== > Investigation from Anoop: > =============================================================================== > This turned out to be a test case problem. The only way how mincore can > generate an -EFAULT on s390 is if the target buffer is an area that is not > contained in a vma. mmap()-ing with a NULL > address gives you a pointer to a piece of memory which will be the highest > address in the anonymous mapping area, if no other mmap() is done. The > testcase > tries to create an invalid pointer by unmap()-ing it. But, if the stack is > unlimited (ulimit -s unlimited) and because stack vma is VM_GROWSDOWN, the > unmap()-ed pointer is part of the stack and is a valid pointer which makes > the syscall succeed. The testcase can be fixed by setting a stack limit by > "ulimit > -s <value>" before its execution. > > Attached is the patch which should fix this.
Thanks Anoop for this Fix. This has been Applied. --Subrata > =============================================================================== > =============================================================================== > > > Regards-- > Subrata, > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ Ltp-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ltp-list ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
