On Mon, Feb 27, 2017 at 9:59 PM, Zack Weinberg <[email protected]> wrote:
> On Mon, Feb 27, 2017 at 2:46 PM, Arnd Bergmann <[email protected]> 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.
Good idea, thanks! We currently do the checking separately from
the copying, but doing the two together is a good cleanup and also
helps the places that currently lack a range check (typically in
drivers). We have three different checks on a timespec at the moment
(no check on tv_sec range, tv_sec must be positive, or tv_sec must
be within the 400 year range of 64-bit nanoseconds), but the
check for the nanoseconds is always the same.
Arnd
_______________________________________________
Y2038 mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/y2038
