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: <20100818181240.GA13050@fieldses.org>
Date:	Wed, 18 Aug 2010 14:12:40 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	"Patrick J. LoPresti" <lopresti@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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 12:34:58PM -0700, Patrick J. LoPresti wrote:
> On Tue, Aug 17, 2010 at 12:39 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> 
> >        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 ?
> 
> Yes, that would work.   Assuming you use atomic counters, else there
> is a risk of the visible time ticking backwards.  It seems like a lot
> of effort just to avoid having accurate timestamps on your files,
> though.
> 
> I am having trouble seeing why this is a better idea than a simple
> mount option to obtain decent resolution timestamps.  (Not that we
> can't have both...)  Is there any objection to the mount option I am
> proposing?

I'm completely ignorant about higher-resolution time sources.  Any
recommended reading?  What resolution do they actually provide, what's
the expense of reading them, how reliable are they, and how do the
answers to those questions vary across different hardware and kernel
versions?  A quick look at drivers/clocksource/ doesn't suggest
simple answers.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ