Re: [PATCH v4 0/3] tools/accounting: refactor delay fields and share format_timespec() 

>Thanks.  Sashiko asks one question:
>    https://sashiko.dev/#/patchset/[email protected]
>
>> +/*
>> + * Copied from include/uapi/linux/time_types.h
>> + *
>> + * Uses the arch-dependent __kernel_long_t rather than a hardcoded
>> + * 'long' so that x32 (ILP32 on x86_64), where the kernel defines
>> + * __kernel_long_t as 'long long', gets the correct struct layout.
>> + *
>> + * __kernel_long_t is provided by <asm/posix_types.h> - included
>> + * below via <linux/types.h> on most systems, or directly here.
>> + */
>[ ... ]
>> +struct __kernel_old_timespec {
>> +	__kernel_long_t		tv_sec;
>> +	long			tv_nsec;
>Does this hardcoded long for tv_nsec cause an ABI layout mismatch on x32?
>The header comment above explicitly mentions avoiding a hardcoded long to
>ensure x32 gets the correct struct layout, but tv_nsec is defined as long
>here instead of __kernel_long_t. 
>If tools compile against this header on x32, it looks like they will get a
>32-bit tv_nsec instead of the 64-bit value expected by the core kernel UAPI,
>which could result in truncated timestamps or out-of-bounds structure access.

We cannot replace long with __kernel_long_t for tv_nsec.

struct __kernel_old_timespec is a frozen UAPI type with a fixed layout.
On x32, the kernel uses long for tv_nsec, producing a 12-byte struct.
Changing the stub to __kernel_long_t would yield a 16-byte struct,
breaking sizeof() and struct embedding for any tool that includes
this header.  tv_nsec only needs 32 bits (range 0..999,999,999), so
the kernel intentionally uses plain long here.

The comment about preferring __kernel_long_t applies to tv_sec, not
tv_nsec — the stub should, and already does, match the kernel UAPI
header byte-for-byte.

Thanks
Yaxin