linux-kernel - Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.1.00.0801181127000.2957@woody.linux-foundation.org>
Date:	Fri, 18 Jan 2008 11:35:51 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Miklos Szeredi <miklos@...redi.hu>
cc:	peterz@...radead.org, salikhmetov@...il.com, linux-mm@...ck.org,
	jakob@...hought.net, linux-kernel@...r.kernel.org,
	valdis.kletnieks@...edu, riel@...hat.com, ksm@...dk,
	staubach@...hat.com, jesper.juhl@...il.com,
	akpm@...ux-foundation.org, protasnb@...il.com,
	r.e.wolff@...wizard.nl, hidave.darkstar@...il.com,
	hch@...radead.org
Subject: Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped
 files

On Fri, 18 Jan 2008, Miklos Szeredi wrote:
> 
> What I'm saying is that the times could be left un-updated for a long
> time if program doesn't do munmap() or msync(MS_SYNC) for a long time.

Sure.

But in those circumstances, the programmer cannot depend on the mtime 
*anyway* (because there is no synchronization), so what's the downside?

Let's face it, there's exactly three possible solutions:

 - the insane one: trap EVERY SINGLE instruction that does a write to the 
   page, and update mtime each and every time.

   This one is so obviously STUPID that it's not even worth discussing 
   further, except to say that "yes, there is an 'exact' algorithm, but 
   no, we are never EVER going to use it".

 - the non-exact solutions that don't give you mtime updates every time 
   a write to the page happens, but give *some* guarantees for things that 
   will update it.

   This is the one I think we can do, and the only things a programmer can 
   impact using it is "msync()" and "munmap()", since no other operations 
   really have any thing to do with it in a programmer-visible way (ie a 
   normal "sync" operation may happen in the background and has no 
   progam-relevant timing information)

   Other things *may* or may not update mtime (some filesystems - take
   most networked one as an example - will *always* update mtime on the 
   server on writeback, so we cannot ever guarantee that nothing but 
   msync/munmap does so), but at least we'll have a minimum set of things 
   that people can depend on.

 - the "we don't care at all solutions".

   mmap(MAP_WRITE) doesn't really update times reliably after the write 
   has happened (but might do it *before* - maybe the mmap() itself does).

Those are the three choices, I think. We currently approximate #3. We 
*can* do #2 (and there are various flavors of it). And even *aiming* for 
#1 is totally insane and stupid.

			Linus
--
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/