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: <AANLkTim9qTjB15Hr+Te8UzgUpZWj41JMXLWf_gJrthc3@mail.gmail.com>
Date:	Wed, 18 Aug 2010 07:46:57 -0700
From:	"Patrick J. LoPresti" <lopresti@...il.com>
To:	Neil Brown <neilb@...e.de>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	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 10:53 PM, Neil Brown <neilb@...e.de> wrote:
>
> I imagine something like this:
>  - Create a global struct timespec which is protected by a seqlock
>   Call it current_nfsd_time or similar.
>  - file_update_time reads this and uses it if it is newer than
>   current_fs_time.
>  - nfsd updates it whenever it reads an mtime out of an inode that matches
>   current_fs_time to the granularity of 1/HZ.

I think nfsd can simply update current_nfsd_time whenever the mtime it
reads from an inode is >= current_nfsd_time.  (The invariant you need
to maintain is that whenever nfsd reads an mtime, any timestamps
produced after that have a later time.  So just code it that way
directly.)

>   If the current value is before current_kernel_time, it
>   is set to current_kernel_time, otherwise tv_nsec is incremented -
>   unless that increases
>   beyond jiffies_to_usec(1)*1000 beyond current_kernel_time.
>  - the global 'struct timespec' is zeroed whenever system time is set
>   backwards.

I believe this works.

> [[You could probably make ext3 work reasonably well by adding a mount option
>  which:
>    - advertises s_time_gran as 1
>    - when storing: rounds timestamps up to the next second if tv_nsec != 0
>    - when loading, setting the timestamp to the current time if the stored
>      number matches current_kernel_time().tv_sec+1
>  You would get occasional forward jumps in mtime, but usually when you
>  aren't looking, and at least you would not get real changes that are not
>  reflected in mtime
> ]]

But I do not believe this works.

1) Modify file A
2) Modify file B
3) File A experiences one of those "occasional forward jumps in mtime"
(inode evicted + read back within 1 second)
4) mtimes on A and B are now out of order -- very bad

As Bruce mentioned, ext3 is a lost cause.

Regardless of any of this, however, the first step is to provide a
mount option to select the timestamp algorithm...  Because it is still
absurd that I cannot have accurate timestamps on my files here in the
21st century.

Once that is done, the rest is just providing the alternative
implementations and choosing defaults.

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