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