Patch "posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIME" has been added to the 4.17-stable tree
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
to the 4.17-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: posix-timers-fix-nanosleep_copyout-for-config_compat_32bit_time.patch and it can be found in the queue-4.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
From foo@baz Wed Aug 22 09:16:55 CEST 2018
From: Arnd Bergmann arnd@arndb.de Date: Mon, 18 Jun 2018 16:07:59 +0200 Subject: posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIME
From: Arnd Bergmann arnd@arndb.de
[ Upstream commit 0fe2795516b9e1c59b58b02bdf8658698117ec4e ]
Commit b5793b0d92c9 added support for building the nanosleep compat system call on 32-bit architectures, but missed one change in nanosleep_copyout(), which would trigger a BUG() as soon as any architecture is switched over to use it.
Use the proper config symbol to enable the code path.
Fixes: Commit b5793b0d92c9 ("posix-timers: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME") Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Thomas Gleixner tglx@linutronix.de Cc: y2038@lists.linaro.org Cc: Anna-Maria Gleixner anna-maria@linutronix.de Cc: Deepa Dinamani deepa.kernel@gmail.com Cc: "Rafael J. Wysocki" rafael.j.wysocki@intel.com Link: https://lkml.kernel.org/r/20180618140811.2998503-1-arnd@arndb.de Signed-off-by: Sasha Levin alexander.levin@microsoft.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- kernel/time/hrtimer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -1659,7 +1659,7 @@ EXPORT_SYMBOL_GPL(hrtimer_init_sleeper); int nanosleep_copyout(struct restart_block *restart, struct timespec64 *ts) { switch(restart->nanosleep.type) { -#ifdef CONFIG_COMPAT +#ifdef CONFIG_COMPAT_32BIT_TIME case TT_COMPAT: if (compat_put_timespec64(ts, restart->nanosleep.compat_rmtp)) return -EFAULT;
Patches currently in stable-queue which might be from arnd@arndb.de are
queue-4.17/posix-timers-fix-nanosleep_copyout-for-config_compat_32bit_time.patch queue-4.17/ieee802154-mcr20a-add-missing-includes.patch queue-4.17/drm-sun4i-link-in-front-end-code-if-needed.patch
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.
Arnd
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.
thanks,
greg k-h
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
On Wed, Aug 22, 2018 at 11:48:12AM +0200, Arnd Bergmann wrote:
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.
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
On Wed, Aug 22, 2018 at 12:19 PM gregkh gregkh@linuxfoundation.org wrote:
On Wed, Aug 22, 2018 at 11:48:12AM +0200, Arnd Bergmann wrote:
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:
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 :)
Wise or not, it's going to be done: WRT54g was a popular wireless router back in 2003, running linux-2.4.1, and I'm sure some of them are still around having never been upgraded. Their owners would be slightly annoyed if it happened to stop working next year when that kernel has reached its drinking age. If you buy an Amazon Kindle today, it probably still runs a 3.0.17 kernel from 2011 (source: wikipedia; my older model is still on 2.6.31). Nobody is ever worried about root exploits on those devices, but it would be a shame if one stops working and takes a collection of downloaded books with it that might not be downloadable any more after 10 years of use.
As an estimate, we may have a thousand times more products that get designed with a years-old kernel now than in 2003. When they get sold for 2 to 10 years each before taken off the market, you end up with a lot of new things in stores running 4.19 years from now, and many of those TV sets, power sockets, airliners, solar panels, traffic lights, bulldozers, and elevator doors will seem absolutely fine on January 18, 2038 running 32-bit user space, but then "suddenly all cry out in terror before being suddenly silenced" the next day.
That still doesn't mean we can do much about it though: even if we backport all the kernel changes to 4.19, most of the crap embedded stuff using it will also have broken user space. For the moment, we're still busy fixing mainline, we'll see how hard the backport is when that is done.
Arnd
-
Arnd Bergmann -
gregkh -
gregkh＠linuxfoundation.org