Hi.

I am resending the patch and am including some justification for the
work.

Peter Staubach wrote:

> Hi.
>
> Attached are some changes to address the problem that modifications to
> the contents of a file, made via an mmap'd region, do not cause the
> modification time on the file to be updated.  This lack can cause 
> corruption
> by allowing backup software to not detect files which should be backed 
> up.
> This also represents a potential security hole because it allows a 
> file to be
> modified with no corresponding change in the file modification or change
> time fields.
>
> The changes add support to detect when the modification time needs to be
> updated by placing a hook in __set_pages_dirty_buffers and
> __set_pages_dirty_nobuffers.  One of these two routines will be invoked
> when the dirty bit is detected in the pte.  The hook sets a new bit in 
> the
> address_space mapping struct indicating that the file which is associated
> with that part of the address space needs to have its modification and
> change time attributes updated.
>
> The new bit described above is used in various system calls to cause the
> modification and change times to be updated.  These are msync, munmap, 
> fsync,
> and exit system calls.  Additionally, these two timestamps will be 
> updated
> if a sync or other inode flushing operation occurs as part of normal 
> system
> operations.
>
> These changes were tested in two ways.  One was to simply create a file,
> write(2) to it, close it, and then test to ensure that the file 
> modification
> time does not change after the file is closed.  Another was a program 
> which
> creates a file, mmap's it, modifies the mapped pages, and then either 
> msync's
> the region, fsync's the file, sync's the system, abruptly exits, or 
> simply
> munmap's the files.  This program shows the file mtime and ctime 
> fields at
> various times and these times were used to ensure that they did change 
> and
> did change in expected ways. 


I embarked on this work due to a bug reported by one of Red Hat's large
customers.  They are finding that files, which should have been backed
up, were not getting backed up.  This is due to the mtime on the files
not changing and their backup software looking for mtime changes.  This
is corruption and I need to get it fixed, sooner as opposed to later.

While I would like to get this fixed on top of Peter Zijlstra's changes,
the process for those is looking long and complicated.  I am wondering
if we could consider these changes and then add the requirement of
maintaining these semantics to those that Peter's work is attempting to
address.

    Thanx...

       ps

Signed-off-by: Peter Staubach <staubach@redhat.com>