Bug 150882 - Kernel doesn't update st_mtime/st_ctime in msync
Summary: Kernel doesn't update st_mtime/st_ctime in msync
Status: CLOSED DUPLICATE of bug 173226
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Peter Staubach
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-11 16:59 UTC by Jakub Jelinek
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2005-11-15 18:11:41 UTC

Attachments (Terms of Use)
Testcase (1.93 KB, text/plain)
2005-03-11 16:59 UTC, Jakub Jelinek
no flags Details

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.
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]

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.

Note You need to log in before you can comment on or make changes to this bug.