Re: [Y2038] [PATCH v2 07/10] include: Add new y2038 safe __kernel_timespec

[Ben Hutchings <ben.hutchings@codethink.co.uk>]

On Mon, 2017-11-27 at 11:30 -0800, Deepa Dinamani wrote:
> The new struct __kernel_timespec is similar to current
> internal kernel struct timespec64 on 64 bit architecture.
> The compat structure however is similar to below on little
> endian systems (padding and tv_nsec are switched for big
> endian systems):
> 
> typedef s32            compat_long_t;
> typedef s64            compat_kernel_time64_t;
> 
> struct compat_kernel_timespec {
>        compat_kernel_time64_t  tv_sec;
>        compat_long_t           tv_nsec;
>        compat_long_t           padding;
> };
> 
> This allows for both the native and compat representations to
> be the same and syscalls using this type as part of their ABI
> can have a single entry point to both.
> 
> Note that the compat define is not included anywhere in the
> kernel explicitly to avoid confusion.

If I understand correctly, the intent here is that C libraries will be
allowed to define struct timespec like that when appropriate feature
macros are enabled.  Could you spell that out in the commit message,
and also the need to clear padding on the kernel side?

[...]
> --- a/include/uapi/linux/time.h
> +++ b/include/uapi/linux/time.h
> @@ -42,6 +42,13 @@ struct itimerval {
> > >  	struct timeval it_value;	/* current value */
>  };
>  
> +#ifndef __kernel_timespec
> +struct __kernel_timespec {
> +	__kernel_time64_t       tv_sec;                 /* seconds */
> +	long long               tv_nsec;                /* nanoseconds */
> +};
> +#endif

I wonder if it makes sense to override the alignment of this structure?
 (64-bit types are aligned differently on 32-bit vs 64-bit x86, but not
other compat cases.)  It might reduce the need for conversions in
compat code elsewhere later.

Ben.

>  /*
>   * The IDs of the various system clocks (for POSIX.1b interval timers):
>   */
-- 
Ben Hutchings
Software Developer, Codethink Ltd.