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: <20100817192937.GD26609@fieldses.org>
Date:	Tue, 17 Aug 2010 15:29:38 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"Patrick J. LoPresti" <lopresti@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	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:39:41PM +0100, Alan Cox wrote:
> > The problem with "increment mtime by a nanosecond when necessary" is
> > that timestamps can wind up out of order.  As in:
> 
> Surely that depends on your implementation ?
> 
> > 1) Do a bunch of operations on file A
> > 2) Do one operation on file B
> > 
> > Imagine each operation on A incrementing its timestamp by a nanosecond
> > "just because".  If all of these operations happen in less than 4 ms,
> > you can wind up with the timestamp on B being EARLIER than the
> > timestamp on A.  That is a big no-no (think "make" or anything else
> > relying on timestamps for relative times).
> 
> 
> [time resolution bits of data][value incremented value for that time]
> 
> 
> 	if (time_now == time_last)
> 		return { time_last , ++ct };
> 	else {
> 		ct = 0;
> 		time_last = time_now
> 		return { time_last , 0 };
> 	}
> 
> providing it is done with the same 'ct' across the fs and you can't do
> enough ops/second to wrap the nanosecs - which should be fine for now,
> your ordering is still safe is it not ?

Right, so if I understand correctly, you're proposing a time source
that's global to the filesystem and that guarantees it will always
return a unique value by incrementing the nanoseconds field if jiffies
haven't changed since the last time it was called.

(Does it really need to be global across all filesystems?  Or is it
unreasonable to expect your unbelievably-fast make's to behave well when
sources and targets live on different filesystems?)

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