linux-kernel - Re: [PATCH 16/20] futex: Implement sys_futex

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: <bdeb5453-e019-7c5b-1bf0-7a225401d358@cs.ucla.edu>
Date:   Wed, 15 Sep 2021 10:34:17 -0700
From:   Paul Eggert <eggert@...ucla.edu>
To:     Peter Zijlstra <peterz@...radead.org>, andrealmeid@...labora.com,
        tglx@...utronix.de, 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 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.

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. 
This could use __int128 on platforms that have it, a two-integer struct 
otherwise.

I'm not sure this is a hill I'd want to die on. That being said, it 
would be cool to keep up with the people in the building near mine who 
are researching attosecond imaging (tricky because the uncertainty 
principle means attosecond laser pulses must have very broad spectra). 
And extending struct timespec on the low end is clearly the way to go, 
since its high end already goes back well before the Big Bang.

I hope you don't mind my going off the deep end a bit here. Still, the 
point is that if we're going to improve on struct timespec then it 
really should be an improvement.