On Wed, Aug 22, 2018 at 10:45 AM gregkh gregkh@linuxfoundation.org wrote:
On Wed, Aug 22, 2018 at 10:04:24AM +0200, Arnd Bergmann wrote:
On Wed, Aug 22, 2018 at 10:00 AM gregkh@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIMEFixes: Commit b5793b0d92c9 ("posix-timers: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME")
I don't think we want this: b5793b0d92c9 isn't in linux-4.17.y and probably won't ever be, so the fix doesn't apply but instead causes compat mode to break.
That patch is also part of this series, so yes, we do need this one as well.
Ah, sorry I missed that. I still don't think the y2038 syscall changes are useful in 4.17.y, but taking both of these makes it consistent and should have no downsides.
Some more background:
Changing the system calls for y2038 requires many patches to common code, and about half of them are merged today, the rest will hopefully make it into 4.20 (4.19 had very few changes unfortunately, the timing of my vacation didn't help). After those are in, we have to change each 32-bit architecture to use them, probably 4.21 or 4.22 timeframe), and only after all of those are done will we be able to use the new syscall ABIs from a libc.
Both glibc and and musl are likely to provide backwards compatibility for running applications with 64-bit time_t on older kernels that don't have the new syscalls. For this reason, I don't expect the need for backporting the syscalls to any stable kernels, other than the next CIP SLTS kernel if they pick a version that doesn't have all changes (the only SLTS today is 4.4, which I don't see as a realistic target for y2038).
It's different for patches that do impact the ioctl ABI: for instance audio timestamps don't go through glibc, so running a binary with 64-bit time_t is incompatible with older kernels that don't have the respective interfaces, and we probably do want to backport such driver changes to stable kernels within reason, to allow y2038-proof user space to run on non-y2038-proof kernels I do expect to go through all drivers once we have a complete y2038 safe kernel, and come up with a list of patches we want backported, but anything you pick up now is definitely appreciated.
When you pick the next LTS kernel, that version may also be a target for backporting all the syscall patches, but it's likely still a lot of work that we should discuss once we get there, and backporting just a subset of the syscall patches is rather pointless as the resulting kernel will still break in 2038.
Arnd