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] [day] [month] [year] [list]

Date:   Wed, 23 Nov 2016 07:58:16 +1100
From:   Dave Chinner <david@...morbit.com>
To:     David Howells <dhowells@...hat.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, Nov 22, 2016 at 10:39:29AM +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.

Yes, of course it would - this would enable userspace to move from
struct timespec to something with higher resolution without having
to use different structures or guess what the resolution being
returned by the kernel is for different filesystems,

We had a major mess with the time_t -> struct timespec upgrade of
the stat() kernel interface to support nanosecond timestamps in the
syscall because when stat() was first designed  all those years ago
single second resolution was all anyone needed. The original
designers of the stat API didn't have 30+ years of history telling
them that machines will get faster than anyone could imagine and
that timestamps will always get more accurate and increase in
resolution.

Perhaps people are fine with repeating past mistakes - all I can do
is point them out and suggest alternative approaches that will avoid
a repeat...

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com