linux-kernel - Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps in msync()

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Jan 2008 18:41:41 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Jakob Oestergaard <jakob@...hought.net>
Cc:	Valdis.Kletnieks@...edu, Anton Salikhmetov <salikhmetov@...il.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps in
 msync()

On Wed, 9 Jan 2008 23:33:40 +0100
Jakob Oestergaard <jakob@...hought.net> wrote:
> On Wed, Jan 09, 2008 at 05:06:33PM -0500, Rik van Riel wrote:

> > Can we get by with simply updating the ctime and mtime every time msync()
> > is called, regardless of whether or not the mmaped pages were still dirty
> > by the time we called msync() ?
> 
> The update must still happen, eventually, after a write to the mapped region
> followed by an unmap/close even if no msync is ever called.
> 
> The msync only serves as a "no later than" deadline. The write to the region
> triggers the need for the update.
> 
> At least this is how I read the standard - please feel free to correct me if I
> am mistaken.
 
You are absolutely right.  If we wrote dirty pages to disk, the ctime
and mtime updates must happen no later than msync or close time.

I guess a third possible time (if we want to minimize the number of
updates) would be when natural syncing of the file data to disk, by
other things in the VM, would be about to clear the I_DIRTY_PAGES
flag on the inode.  That way we do not need to remember any special
"we already flushed all dirty data, but we have not updated the mtime
and ctime yet" state.

Does this sound reasonable?

-- 
All rights reversed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/