linux-kernel - Re: Proposal: Use hi-res clock for file timestamps

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]

Message-ID: <20100817190447.GA28049@fieldses.org>
Date:	Tue, 17 Aug 2010 15:04:47 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"Patrick J. LoPresti" <lopresti@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Proposal: Use hi-res clock for file timestamps

On Tue, Aug 17, 2010 at 08:29:20PM +0200, Andi Kleen wrote:
> > OK, so that leaves us with the race, even on newer filesystems:
> > 
> > 	1. File is modified, mtime updated
> > 	2. Client fetches mtime to revalidate cache
> > 	3. File is modified again, mtime updated
> > 	4. Client fetches new mtime to revalidate cache
> 
> You'll always have a race window with time, the only way around
> that would be a version number.

Agreed, but as a practical matter, nanosecond resolution would extend
the useful lifetime of NFSv3 by quite a bit.

> > 	- Tell everyone to use NFSv4 (and make sure we have
> > 	  changeattr/i_version working correctly).
> > 	- Use a finer-grained time source.  (I believe you when you say
> > 	  the TSC is too slow, but maybe we should run some tests to
> > 	  make sure.)
> 
> It depends on the CPU too.

If we wanted to look into this, what would you suggest (hardware,
workload) to demonstrate the worst case?  (Or are the results from the
TSC or any other higher-precision time source likely to be useless for
other reasons?)

> > 	- Increment mtime by a nanosecond when necessary.  
> 
> You cannot be more precise than the backing file system: this causes
> non monotonity when the inodes are flushed (has happened in the past)

Right, I think that we probably have to give up ext3 as a lost cause.
But perhaps we could get away with a hack like this on filesystems that
can store nanoseconds.

--b.
--
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/