Bug 404201

Summary: remap_file_pages02 system call fails on FC8GA
Product: [Fedora] Fedora Reporter: IBM Bug Proxy <bugproxy>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8   
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: All   
URL: ARRAY(0x8bcb30)
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 05:22:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch for invalid pgoff none

Description IBM Bug Proxy 2007-11-29 10:50:32 UTC
=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

Comment 1 IBM Bug Proxy 2007-11-29 10:50:34 UTC
Created attachment 272781 [details]
Patch for invalid pgoff

Comment 2 IBM Bug Proxy 2007-11-30 08:30:42 UTC
------- Comment From skannery.com 2007-11-30 03:27 EDT-------
LKML discussion: http://lkml.org/lkml/2007/11/29/325

Comment 3 IBM Bug Proxy 2008-02-07 06:32:32 UTC
------- 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 4 IBM Bug Proxy 2008-02-08 12:16:32 UTC
------- 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 5 IBM Bug Proxy 2008-02-11 10:10:06 UTC
------- Comment From skannery.com 2008-02-11 05:00 EDT-------
Closing this issue as WILL_NOT_FIX

Comment 6 IBM Bug Proxy 2008-02-14 09:24:36 UTC
------- Comment From subrata.modak.com 2008-02-14 04:16 EDT-------
Thanks Ricardo. This has been applied to LTP.

--Subrata

Comment 7 Bug Zapper 2008-11-26 08:44:57 UTC
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

Comment 8 Bug Zapper 2009-01-09 05:22:29 UTC
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.