On Wed, Aug 22, 2018 at 10:45 AM gregkh <[email protected]> wrote:
>
> On Wed, Aug 22, 2018 at 10:04:24AM +0200, Arnd Bergmann wrote:
> > On Wed, Aug 22, 2018 at 10:00 AM <[email protected]> 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.
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
_______________________________________________
Y2038 mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/y2038
