=Comment: #0================================================= Mohammed Omar <mohd.omar.com> - 2007-11-14 04:04 EDT ---Problem description:--- remap_file_pages02 sys call fails when runltp(ltp-full-20071031.tgz) executed for 24 hours on FC8 GA on Power box. Command used nohup ./runltp -c -p -l /root/ltprunall.log -o /root/ltprunall.out -t 24h & ----ltprunall.out ----- <<<test_start>>> tag=remap_file_pages02 stime=1194940973 cmdline="remap_file_pages02" contacts="" analysis=exit initiation_status="ok" <<<test_output>>> remap_file_pages02 1 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : start does not refer to a valid mapping created with the MAP_SHARED flag remap_file_pages02 2 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : start is invalid remap_file_pages02 3 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : size is invalid remap_file_pages02 4 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : prot is invalid remap_file_pages02 5 FAIL : remap_file_pages(2) failed to produce expected error: 22, errno: EINVAL. because got error 0 <<<execution_status>>> duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> ------- uname -a ------- Linux p520b.in.ibm.com 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:05:49 EDT 2007 ppc64 ppc64 ppc64 GNU/Linux ----Hardware Environment---- Machine type : p520 Cpu type : Power5 ---Steps to Reproduce----- 1. Download latest ltp test suite ( i use ltp-full-20071031 ) 2. tar -zxvf ltp-full-20071031.tgz 3. cd ltp-full-20071031 , then run make & make install 4. cd /ltp-full-20071031/testcases/kernel/syscalls/remap_file_pages 5. ./remap_file_pages02 remap_file_pages02 1 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : start does not refer to a valid mapping created with the MAP_SHARED flag remap_file_pages02 2 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : start is invalid remap_file_pages02 3 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : size is invalid remap_file_pages02 4 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : prot is invalid remap_file_pages02 5 FAIL : remap_file_pages(2) failed to produce expected error: 22, errno: EINVAL. because got error 0 ---Is the system sitting in a debugger right now?--- No ----Additional information:------- 1. INFO: pan reported some tests FAIL in nohup.out 2. runltp is not finishing its all tests within 24 hours,when I executed It has been killed before it's normal completion of test. I found the following in nohup.out ./runltp: line 154: 12428 Killed $LTPROOT/testcases/bin/genload --cpu $NUM_PROCS > /dev/null 2>&1 (wd: ~/ltp-full-20071031) --thanks omar =Comment: #1================================================= Supriya Kannery <skannery.com> - 2007-11-15 06:10 EDT pgoff is the fifth parameter of remap_files_pages() syscall. Issue here is, test 5 of remap_file_pages02 sets up invalid 'pgoff' while calling remap_file_pages() and expects an error as return code, but gets 0 (successful). I tried giving various values for pgoff to make it go beyond the number of pages set for 'cache' (file) in the testcase, but everytime remap_file_pages is returning successfully. There is no straight validation done for pgoff value in remap_file_pages system call code. Will be looking in detail at the kernel code on why it is becoming successful with an invalid value of pgoff. =Comment: #2================================================= Supriya Kannery <skannery.com> - 2007-11-22 05:41 EDT There are some changes introduced in remap_file_pages syscall while fixing race conditions related to nonlinear mappings. Discussion at LKML: http://lkml.org/lkml/2007/1/12/252 Previous to this patch, remap_file_pages was calling "populate()" inside which pgoff was getting validated. But with the new patchset, new function populate_range() got introduced and remap_file_pages uses populate_range() instead of populate(). This new function populate_range() doesn't validate pgoff and hence this issue. Working on further to get a patch. =Comment: #3================================================= Supriya Kannery <skannery.com> - 2007-11-23 01:55 EDT Test patch for Invalid pgoff =Comment: #4================================================= Supriya Kannery <skannery.com> - 2007-11-23 01:56 EDT Mohammed, Attached is a draft patch prepared over 2.6.23 vanilla kernel. Please check whether this addresses the issue. Thanks, Supriya =Comment: #8================================================= Subrata Modak1 <subrata.modak.com> - 2007-11-26 01:39 EDT Sorry, My earlier comments got inadvertently embedded. Good to see that our LTP remap_file_pages test case was able to find out some bug in the Kernel source code. We recently added this test case with help from Ricardo. Infact we ported these testcases (earlier written by Ingo Molnar and Nick Piggin) to LTP format and included the same into LTP (as requested by Andrew). Although remap_file_pages01.c were ported to LTP by me and Ricardo, but remap_file_pages02.c was entirely written by Ricardo. So, kudos to him for this. Supriya, please keep us informed whether the Kernel Patch solves your issue and whether/when this patch is making itΕ entry into Mainline Kernel. --Subrata-- =Comment: #11================================================= Supriya Kannery <skannery.com> - 2007-11-26 04:22 EDT Test patch for invalid pgoff =Comment: #14================================================= Mohammed Omar <mohd.omar.com> - 2007-11-27 02:53 EDT hi supriya, subrata : I compiled the kernel with above patch and executed remap_file_pages02 test case Here the results.... ------------------- $./remap_file_pages02 remap_file_pages02 1 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : start does not refer to a valid mapping created with the MAP_SHARED flag remap_file_pages02 2 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : start is invalid remap_file_pages02 3 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : size is invalid remap_file_pages02 4 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : prot is invalid pgoff = 66 remap_file_pages02 5 PASS : remap_file_pages(2) expected failure; Got errno - EINVAL : pgoff is invalid --thanks omar
Created attachment 272781 [details] Patch for invalid pgoff
------- Comment From skannery.com 2007-11-30 03:27 EDT------- LKML discussion: http://lkml.org/lkml/2007/11/29/325
------- Comment From mohd.omar.com 2008-02-07 01:27 EDT------- I cud see the following failures in F9Alpha kernel(2.6.24-2.fc9). ------------------------ remap_file_pages02 5 FAIL : remap_file_pages(2) failed to produce expected error: 22, errno: EINVAL. because got error 0 -------------------------- I think Redhat has not yet picked up the patch. --Regards Omar
------- Comment From skannery.com 2008-02-08 07:13 EDT------- Omar, As per Nick Piggin's inputs in LKML dicussion (URL in comment #21), this issue need not be fixed due two reasons: 1. mmap implementation in Linux won't fail if it maps past i_size. So restricting pgoff value or validating it using file size in remap_file_page won't be a good idea. 2. Locking mechanism through i_size_read() won't be fool-proof. Hence I am rejecting this bug as WILL_NOT_FIX. ------- Comment From skannery.com 2008-02-08 07:14 EDT------- Omar and Redhat Team, Pls let me know if you have any comments/suggestions to make. Thanks & Rgds, Supriya
------- Comment From skannery.com 2008-02-11 05:00 EDT------- Closing this issue as WILL_NOT_FIX
------- Comment From subrata.modak.com 2008-02-14 04:16 EDT------- Thanks Ricardo. This has been applied to LTP. --Subrata
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.