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

[Zack Weinberg <zackw at panix dot com>]

On Mon, Feb 27, 2017 at 2:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> 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.

I don't think user-space zeroing is practical, especially if we don't
want to deviate from POSIX (which I still think is the best solution
overall).

Since the kernel has to have the code to check for out-of-range values
anyway, though, it could postpone looking at the task type until it
notices that the value is out of range.  That is, instead of doing

    if (32-bit task) {
       if (low 32 bits out of range) {
           error;
       }
   } else {
       if (64-bit quantity out of range) {
           error;
       }
   }

it should do

    if (64-bit quantity out of range) {
        if (64-bit task)
            error;
        else if (low 32 bits out of range)
            error;
    }

That way only code that doesn't zero the entire structure is penalized.

zw