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: <1479822911.2492.4.camel@redhat.com>
Date:   Tue, 22 Nov 2016 08:55:11 -0500
From:   Jeff Layton <jlayton@...hat.com>
To:     David Howells <dhowells@...hat.com>,
        Dave Chinner <david@...morbit.com>
Cc:     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

On Tue, 2016-11-22 at 10:39 +0000, David Howells wrote:
> Dave Chinner <david@...morbit.com> wrote:
> 
> > 
> > No. Just provide a 64 bit high resoultion field, and define it to
> > contain nanoseconds. When we need higher resolution to be exported
> > to userspace, we use a /feature flag/ to indicate that is contains
> > something like attoseconds or the like.
> 
> That sounds suspiciously like a bad idea - if you're talking about a flag with
> a currently undefined meaning that the kernel can inflict on userspace without
> warning to change the meaning of the nanoseconds field to something we haven't
> defined yet.
> 
> Userspace would have to ask for it.
> 

Agreed.

I think the best thing would be to simply plan to add new femtoseconds
fields in the struct if/when it becomes needed. We can easily hide the
ugliness of the fields not being adjacent to the rest of the timestamp
behind the femtosecond resolution glibc API that will also be needed.

If we're worried about space utilization, then let's pad the struct out
by 4 extra 32-bit fields in advance of that.

Again, a major design point of statx is that it is to be extendable. I
don't see any reason that we need to do this now.

-- 
Jeff Layton <jlayton@...hat.com>