On Wed, Aug 22, 2018 at 11:48:12AM +0200, Arnd Bergmann wrote:
> On Wed, Aug 22, 2018 at 10:45 AM gregkh <gre...@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 <gre...@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_TIME
> > > >
> > > > Fixes: 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.
Oops, no, I was wrong, that wasn't in the queue, so I've dropped this
now.
> 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.
4.19 is going to be the next LTS kernel. Odds are if you want a
2038-proof kernel, you can just wait for the LTS I pick next year.
Although running a 18-year-old kernel isn't probably a wise idea anyway :)
thanks,
greg k-h
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
