Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 150882

Summary: Kernel doesn't update st_mtime/st_ctime in msync
Product: Red Hat Enterprise Linux 4 Reporter: Jakub Jelinek <jakub>
Component: kernelAssignee: Peter Staubach <staubach>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: davej, ezannoni, riel, roland, sct
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-15 18:11:41 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
Testcase none

Description Jakub Jelinek 2005-03-11 16:59:38 UTC
It seems that our kernels (and likely stock ones as well), both 2.4.x and
2.6.x based, violate POSIX for msync.
http://www.opengroup.org/onlinepubs/009695399/functions/msync.html
If msync() causes any write to a file, the file's st_ctime and st_mtime
fields shall be marked for update.

See the attached testcase.  If test_msync is changed to false,
the tests passes, so certainly write marks the st_mtime for update.

This is distilled from a LSB 1.3 testcase, but that test is flawed
and thus usually succeeds although msync really doesn't update
st_mtime.  The flaw is that the test doesn't sleep between writing
the file and calling time (or it could wait longer and increase start by 2
seconds), so usually st_mtime will be equal to start time.
With the added sleep in between writing/mmaping the file and time (&start)
it fails reliably on all arches.

I think msync.c needs to propagate up from filemap_sync_pte whether there were
any dirty pages and call inode_update_time before exiting if there were some.

Comment 1 Jakub Jelinek 2005-03-11 16:59:38 UTC
Created attachment 111896 [details]
Testcase

Comment 2 Peter Staubach 2005-11-15 18:11:41 UTC

*** This bug has been marked as a duplicate of 173226 ***

Comment 3 Linda Wang 2006-01-09 02:51:01 UTC
bookkeeping: remove from U3 canfix list.