linux-kernel - Re: [PATCH v2 09/13] tools/nolibc: always use 64-bit time types

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]

Message-Id: <75e632e3-3353-414d-9b8a-8bf9ca46b5a4@app.fastmail.com>
Date: Mon, 01 Dec 2025 08:45:00 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Willy Tarreau" <w@....eu>,
 Thomas Weißschuh <linux@...ssschuh.net>
Cc: shuah <shuah@...nel.org>, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 09/13] tools/nolibc: always use 64-bit time types

On Sun, Nov 30, 2025, at 11:58, Willy Tarreau wrote:
> On Sat, Nov 22, 2025 at 05:59:15PM +0100, Thomas Weißschuh wrote:

>>  struct timespec {
>> -	__kernel_old_time_t	tv_sec;
>> -	long			tv_nsec;
>> +	time_t	tv_sec;
>> +	int64_t	tv_nsec;
>>  };
>>  #define _STRUCT_TIMESPEC
>>  
>> +/* Never use with system calls */
>>  struct timeval {
>> -	__kernel_old_time_t	tv_sec;
>> -	__kernel_suseconds_t	tv_usec;
>> +	time_t	tv_sec;
>> +	int64_t	tv_usec;
>>  };
>
> It seems to me that glibc continues to make the effort of using a long
> for tv_usec and tv_nsec. At least I'm seeing how that can make a
> difference for application code given that these fields are constantly
> multiplied or divided, forcing them to 64-bit when we know they'll never
> be larger than 1 billion is extra burden for the application. Another
> reason might be that the definition really changed from long to suseconds_t
> in timeval a while ago, it's possible that it's used as a long in various
> APIs (or even just printf formats).
>
> IMHO it would be cleaner to keep it as a long here, or do you have a
> particular reason for wanting int64_t (which BTW already forced a cast
> in sys_gettimeofday()) ?

As far as I can tell, it's the other way round for suseconds_t,
which in glibc is defined as

#if __TIMESIZE == 64 && __WORDSIZE == 32
# define __TIME_T_TYPE          __SQUAD_TYPE
# define __SUSECONDS_T_TYPE     __SQUAD_TYPE
#else
# define __TIME_T_TYPE          __SLONGWORD_TYPE
# define __SUSECONDS_T_TYPE     __SLONGWORD_TYPE
#endif

so this one is explicitly the same width as tv_sec, which has all
the issues you listed, but avoids the need for padding.

As far as I remember, the one reason for having a 'long tv_nsec'
with complex padding in glibc and musl is that this is actually
required by both Unix[1] and C11/C11 [2] standards.

C23 has updated the definition and does allow int64_t tv_nsec.
I think it makes sense for nolibc to just follow the kernel's
definition here.

       Arnd

[1] https://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html
[2] https://en.cppreference.com/w/c/chrono/timespec.html