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]
Date:   Thu, 16 Sep 2021 16:49:21 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Paul Eggert <eggert@...ucla.edu>,
        Peter Zijlstra <peterz@...radead.org>,
        andrealmeid@...labora.com, mingo@...hat.com, dvhart@...radead.org,
        rostedt@...dmis.org, bigeasy@...utronix.de
Cc:     dave@...olabs.net, libc-alpha@...rceware.org,
        linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
        mtk.manpages@...il.com, kernel@...labora.com, krisman@...labora.com
Subject: Re: [PATCH 16/20] futex: Implement sys_futex_waitv()

On Wed, Sep 15 2021 at 10:34, Paul Eggert wrote:

> On 9/15/21 8:37 AM, Peter Zijlstra wrote:
>> I utterly detest timespec.. it makes no sense what so ever.
>> 
>> Can't we just, for new syscalls, simply use a s64 nsec argument and call
>> it a day?
>
> This would stop working in the year 2262. Not a good idea.

Make it u64 and it stops in 2552, i.e. 584 years from now which is
plenty. Lot's of the kernel internal timekeeping will stop working at
that point, so that interface is the least of my worries. And TBH, my
worries about the Y2552 problem are extremly close to zero.

> Any improvements on struct timespec should be a strict superset, not a 
> subset. For example, you could advocate a signed 128-bit argument 
> counting in units of attoseconds (10⁻¹⁸ s), the highest power-of-1000 
> resolution that does not lose info when converting from struct
> timespec.

Which requires a 128bit division on every syscall for no value at all.

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ