Re: [Y2038] Fifth draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Mon, Feb 27, 2017 at 7:45 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 27 Feb 2017, Arnd Bergmann wrote:
>
>> kernels, so the kernel will either always ignore the padding (which is
>> a bit more work for the kernel) or it will always reject nonzero upper bits
>> of the nanoseconds (as 64-bit kernels do today for native tasks, this
>> means more work in 32-bit glibc, or using 64-bit nanoseconds as
>> Zack suggested).
>
> Note that the rejection for native tasks (ones where the userspace "long"
> type used for tv_nsec is 64-bit) is required.  For example, for utimensat,
> POSIX requires an EINVAL error if "Either of the times argument structures
> specified a tv_nsec value that was neither UTIME_NOW nor UTIME_OMIT, and
> was a value less than zero or greater than or equal to 1000 million.".
> (There are some cases where glibc deals with such rejection itself, if
> e.g. it's converting an absolute timeout to a relative timeout in order to
> pass the latter to the kernel.)

Sure, I was not suggesting that this check would be changed for 64-bit
tasks. Aside from the clear violation of the relevant POSIX definition, that
would also be a subtle ABI change that could lead to breaking existing
application code.

What I meant above is that the kernel would either always treat new
32-bit tasks the same way as 64-bit tasks both under native 32-bit kernels
and emulated on 64-bit kernels and leave the zeroing to user space,
or we do the extra work I described in the kernel, to make it easier for
a libc implementation to use 'long tv_nsec' without having to zero-pad
of copy each timespec, again for both native and compat 32-bit tasks.

       Arnd