linux-kernel - Re: [GIT PULL v2] timestamp fixes

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: <CAHk-=wjDAqOs5TFuxxEOSST-5-LJJkAS5cEMrDu-pgiYsrjyNw@mail.gmail.com>
Date:   Thu, 21 Sep 2023 12:46:34 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     Christian Brauner <brauner@...nel.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jan Kara <jack@...e.cz>
Subject: Re: [GIT PULL v2] timestamp fixes

On Thu, 21 Sept 2023 at 12:28, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> And that's ok when we're talking about times that are kernel running
> times and we haev a couple of centuries to say "ok, we'll need to make
> it be a bigger type",

Note that the "couple of centuries" here is mostly the machine uptime,
not necessarily "we'll need to change the time in the year 2292".

Although we do also have "ktime_get_real()" which is encoding the
whole "nanoseconds since 1970". That *will* break in 2292.

Anyway, regardless, I am *not* suggesting that ktime_t would be useful
for filesystems, because of this issue.

I *do* suspect that we might consider a "tenth of a microsecond", though.

Resolution-wise, it's pretty much in the "system call time" order of
magnitude, and if we have Linux filesystems around in the year-31k,
I'll happily consider it to be a SEP thing at that point ("somebody
else's problem").

                  Linus