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

Message-ID: <20251130105842.GD31522@1wt.eu>
Date: Sun, 30 Nov 2025 11:58:42 +0100
From: Willy Tarreau <w@....eu>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: Shuah Khan <shuah@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 09/13] tools/nolibc: always use 64-bit time types

Hi Thomas,

On Sat, Nov 22, 2025 at 05:59:15PM +0100, Thomas Weißschuh wrote:
> 32-bit time types will stop working in 2038.
> 
> Switch to 64-bit time types everywhere.
> 
> Suggested-by: Arnd Bergmann <arnd@...db.de>
> Link: https://lore.kernel.org/lkml/cec27d94-c99d-4c57-9a12-275ea663dda8@app.fastmail.com/
> Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> ---
>  tools/include/nolibc/std.h   | 2 +-
>  tools/include/nolibc/types.h | 9 +++++----
>  2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/include/nolibc/std.h b/tools/include/nolibc/std.h
> index 392f4dd94158..b9a116123902 100644
> --- a/tools/include/nolibc/std.h
> +++ b/tools/include/nolibc/std.h
> @@ -29,6 +29,6 @@ typedef unsigned long       nlink_t;
>  typedef  int64_t              off_t;
>  typedef   signed long     blksize_t;
>  typedef   signed long      blkcnt_t;
> -typedef __kernel_time_t      time_t;
> +typedef __kernel_time64_t    time_t;
>  
>  #endif /* _NOLIBC_STD_H */
> diff --git a/tools/include/nolibc/types.h b/tools/include/nolibc/types.h
> index 5d180ffabcb6..8f3cb18df7f1 100644
> --- a/tools/include/nolibc/types.h
> +++ b/tools/include/nolibc/types.h
> @@ -17,14 +17,15 @@
>  #include <linux/wait.h>
>  
>  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()) ?

Thanks,
Willy