linux-kernel - Re: [PATCH 09/12] tools/nolibc: use a custom struct timespec

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: <0b3e7de4-32b8-44ae-b03a-ec176f45a1c5@t-8ch.de>
Date: Sun, 2 Nov 2025 10:41:39 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Willy Tarreau <w@....eu>
Cc: Arnd Bergmann <arnd@...db.de>, shuah <shuah@...nel.org>, 
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 09/12] tools/nolibc: use a custom struct timespec

On 2025-11-02 09:36:22+0100, Willy Tarreau wrote:
> On Thu, Oct 30, 2025 at 03:46:21PM +0100, Arnd Bergmann wrote:
> > On Wed, Oct 29, 2025, at 17:02, Thomas Weißschuh wrote:
> > > 
> > > +struct timespec {
> > > +	time_t	tv_sec;
> > > +	long	tv_nsec;
> > > +};
> > > +#define _STRUCT_TIMESPEC
> > > +
> > > +#include <linux/time.h>
> > 
> > Unfortunately this is not the definition we want on big-endian
> > systems because it puts the tv_nsec field in the wrong place.
> 
> Indeed!
> 
> > You can either uses the simple (non-POSIX) __kernel_timespec
> > definition in nolibc with a 64-bit tv_nsec, or copy the more
> > complicated definition with explicit padding that is used
> > in musl and glibc.
> 
> I think that switching this patch and the next one (10/12) would
> just do the trick since both fields will become __kernel_time64_t.
> Or maybe the two should be squashed into a single one.

Maybe I can make it clearer that this patch does not change anything.
This custom definition of 'struct timespec' is the same as the one we
got from linux/time.h before. This is just a preparation for the next
commit. Merging would also work, but it will be a bit messy to look at.


Thomas