linux-ext4 - Re: [4.1-rc] File was modified, but mtime stayed the same (according to unison)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150609221319.GA24666@dastard>
Date:	Wed, 10 Jun 2015 08:13:19 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Theodore Ts'o <tytso@....edu>, Pavel Machek <pavel@....cz>,
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
	kernel list <linux-kernel@...r.kernel.org>, jack@...e.cz
Subject: Re: [4.1-rc] File was modified, but mtime stayed the same (according
 to unison)

On Tue, Jun 09, 2015 at 11:12:09AM -0400, Theodore Ts'o wrote:
> On Tue, Jun 09, 2015 at 12:43:30PM +0200, Pavel Machek wrote:
> > 
> > Hi!
> > 
> > Today, I got strange warning from unison:
> > 
> > pavel/.config/chromium/Default/Extension State/LOG.old — transport
> > failure
> > • The source file /data/pavel/.config/chromium/Default/Extension
> > State/LOG.old
> > has been modified but the fast update detection mechanism
> > failed to detect it.  Try running once with the fastcheck
> > option set to 'no'.
> 
> What does this mean, precisely?  Is Unison checking that files have
> been modified using some kind of a checksum or file comparison
> mechanism?  And I assume that the "fast update detection mechanism"
> using mtime?
> 
> And if it has modified, how was it modified (can you do a diff with
> what the other side of the synchronization setup had for that file),
> and do you know by which process. and what was it trying to do?  And
> how is unison being run?
> 
> One thing that could be going on is that if you have a file which is
> mmap'ed, the mtime field is set the first time the page is modified
> (when the page table entry is set to read/write from read-only).  If
> unison then takes a snapshot of the file, and then file is
> subsequently modified via a write to the mmap'ed page, the mtime field
> will not be updated again.

That's not right: when dirty mmap pages are cleaned by writeback the
PTEs are cleaned, too.  Hence on the next modification of that page
we will get a new write page fault that modifies the mtime. IOWs, if
the "snapshot" involves writing back the file, then it will be
marked clean and the next page fault will cause the mtime to be
updated.

In general, this means that constantly dirtied mmap files will have
the mtime updated at least every 30s and background writeback cleans
dirty pages. Usually, however, it is much more often than that as
each clean page that is dirtied will cause the mtime to be updated
due to traversal through the ->page_mkwrite -> ext4_page_mkwrite()
-> file_update_time() path.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html