linux-kernel - Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available

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: <11317.1479509642@warthog.procyon.org.uk>
Date:   Fri, 18 Nov 2016 22:54:02 +0000
From:   David Howells <dhowells@...hat.com>
To:     Dave Chinner <david@...morbit.com>
Cc:     dhowells@...hat.com, Andreas Dilger <adilger@...ger.ca>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available

Dave Chinner <david@...morbit.com> wrote:

> And when we start thinking in those timeframes, an
> increase in timestamp resoultion of at least another 10e-3 is
> likely....

Is it, though?  To be useful, surely you have to be able to jam quite a few
instructions into a 1ns block, including memory accesses.

Rather than providing:

	struct timestamp {
		__s64 seconds;
		__s64 femtoseconds;
	};

which would require 64-bit divisions to get nanosecond timestamps that we do
actually use, I would lean towards:

	struct timestamp {
		__s64 seconds;
		__s32 nanoseconds;
		__s32 femtoseconds;
	};

where the fields are, in effect, additive.  Which means I could represent this
as:

	__s64	stx_atime_s;	/* Last access time */
	__s64	stx_btime_s;	/* File creation time */
	__s64	stx_ctime_s;	/* Last attribute change time */
	__s64	stx_mtime_s;	/* Last data modification time */
	__s32	stx_atime_ns;	/* Last access time (ns part) */
	__s32	stx_btime_ns;	/* File creation time (ns part) */
	__s32	stx_ctime_ns;	/* Last attribute change time (ns part) */
	__s32	stx_mtime_ns;	/* Last data modification time (ns part) */

and then add:

	__s32	stx_atime_fs;	/* Last access time (fs part) */
	__s32	stx_btime_fs;	/* File creation time (fs part) */
	__s32	stx_ctime_fs;	/* Last attribute change time (fs part) */
	__s32	stx_mtime_fs;	/* Last data modification time (fs part) */

later.

If we *really* do want to allow for atto- or femto- second resolution
timestamps (and you've still not entirely convinced me that it's going to be
necessary - the speed of signal propagation still has an ungetroundable
limit), then we could stick the space in now - but I think it's likely to
remain dead space.

Maybe we should switch to Windows-style timestamp resolution:

	struct timestamp {
		__s64 hundred_ns;	/* Time in 100ns increments */
		__s32 femtoseconds;	/* Additional fs component */
	};

> > Using the existing FS_*_FL flags as initial values is not worse than
> > starting with any other arbitrary values for the flags.
>
> Except it starts with a sparse set of flags for no good reason.

Actually, a very good reason.  You can map those flags, on ext4 at least, with
a load, an AND and an OR.  Three instructions[*].  If the bits don't
correspond, it gets more expensive (4-5 instructions per bit + 1).

[*] Leastways, it *should* be three instructions, but gcc fails to optimise it
    correctly.  I have a bz logged for this.

David