All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] kernel/sys.c: Fix UNAME26 for 5.0
@ 2019-01-07 18:03 Jonathan Neuschäfer
  2019-01-07 18:10 ` Linus Torvalds
  0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Neuschäfer @ 2019-01-07 18:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Linus Torvalds, Jonathan Neuschäfer, Andrew Morton,
	Thomas Gleixner, Dominik Brodowski, Cyrill Gorcunov,
	Greg Kroah-Hartman, YueHaibing, Arnd Bergmann,
	Gustavo A. R. Silva, Jann Horn, Kees Cook

UNAME26 is a mechanism to report Linux's version as 2.6.x, for
compatibility with old/broken software. Because of the way it is
implemented, it needs to be adjusted to handle version 5.0.

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
 kernel/sys.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index a48cbf1414b8..479f4ecdb405 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1208,6 +1208,7 @@ DECLARE_RWSEM(uts_sem);
  * Work around broken programs that cannot handle "Linux 3.0".
  * Instead we map 3.x to 2.6.40+x, so e.g. 3.0 would be 2.6.40
  * And we map 4.x to 2.6.60+x, so 4.0 would be 2.6.60.
+ * We map 5.x to 2.6.81+x, so 5.0 would be 2.6.81.
  */
 static int override_release(char __user *release, size_t len)
 {
@@ -1227,7 +1228,7 @@ static int override_release(char __user *release, size_t len)
 				break;
 			rest++;
 		}
-		v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 60;
+		v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 81;
 		copy = clamp_t(size_t, len, 1, sizeof(buf));
 		copy = scnprintf(buf, copy, "2.6.%u%s", v, rest);
 		ret = copy_to_user(release, buf, copy + 1);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] kernel/sys.c: Fix UNAME26 for 5.0
  2019-01-07 18:03 [PATCH] kernel/sys.c: Fix UNAME26 for 5.0 Jonathan Neuschäfer
@ 2019-01-07 18:10 ` Linus Torvalds
  2019-01-08  0:08   ` Jonathan Neuschäfer
  2019-01-12 17:14   ` [PATCH v2] kernel/sys.c: Clarify that UNAME26 does not generate unique versions anymore Jonathan Neuschäfer
  0 siblings, 2 replies; 4+ messages in thread
From: Linus Torvalds @ 2019-01-07 18:10 UTC (permalink / raw)
  To: Jonathan Neuschäfer
  Cc: Linux List Kernel Mailing, Andrew Morton, Thomas Gleixner,
	Dominik Brodowski, Cyrill Gorcunov, Greg Kroah-Hartman,
	YueHaibing, Arnd Bergmann, Gustavo A. R. Silva, Jann Horn,
	Kees Cook

On Mon, Jan 7, 2019 at 10:03 AM Jonathan Neuschäfer
<j.neuschaefer@gmx.net> wrote:
>
> UNAME26 is a mechanism to report Linux's version as 2.6.x, for
> compatibility with old/broken software. Because of the way it is
> implemented, it needs to be adjusted to handle version 5.0.

Do we actually need this?

I'd rather let it bitrot, and just let it return random versions. It
will just start again at 2.4.60, won't it?

Anybody who uses UNAME26 for a 5.x kernel might as well think it's
still 4.x. The user space is so old that it can't possibly care about
differences between 4.x and 5.x, can it?

The only thing that matters is that it shows "2.4.<largeenough>",
which it will do regardless.

                Linus

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] kernel/sys.c: Fix UNAME26 for 5.0
  2019-01-07 18:10 ` Linus Torvalds
@ 2019-01-08  0:08   ` Jonathan Neuschäfer
  2019-01-12 17:14   ` [PATCH v2] kernel/sys.c: Clarify that UNAME26 does not generate unique versions anymore Jonathan Neuschäfer
  1 sibling, 0 replies; 4+ messages in thread
From: Jonathan Neuschäfer @ 2019-01-08  0:08 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Jonathan Neuschäfer, Linux List Kernel Mailing,
	Andrew Morton, Thomas Gleixner, Dominik Brodowski,
	Cyrill Gorcunov, Greg Kroah-Hartman, YueHaibing, Arnd Bergmann,
	Gustavo A. R. Silva, Jann Horn, Kees Cook

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

On Mon, Jan 07, 2019 at 10:10:31AM -0800, Linus Torvalds wrote:
> On Mon, Jan 7, 2019 at 10:03 AM Jonathan Neuschäfer
> <j.neuschaefer@gmx.net> wrote:
> >
> > UNAME26 is a mechanism to report Linux's version as 2.6.x, for
> > compatibility with old/broken software. Because of the way it is
> > implemented, it needs to be adjusted to handle version 5.0.
> 
> Do we actually need this?

I don't run any such old software, so I don't have a strong opinion
here; I just sent this patch because I knew UNAME26 version strings
would jump back without it.

> I'd rather let it bitrot, and just let it return random versions. It
> will just start again at 2.4.60, won't it?

Correct.
(Well, it's 2.6, not 2.4, but yes)

> Anybody who uses UNAME26 for a 5.x kernel might as well think it's
> still 4.x. The user space is so old that it can't possibly care about
> differences between 4.x and 5.x, can it?
> 
> The only thing that matters is that it shows "2.4.<largeenough>",
> which it will do regardless.

Good point, I guess that's a valid appraoch.



Jonathan Neuschäfer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH v2] kernel/sys.c: Clarify that UNAME26 does not generate unique versions anymore
  2019-01-07 18:10 ` Linus Torvalds
  2019-01-08  0:08   ` Jonathan Neuschäfer
@ 2019-01-12 17:14   ` Jonathan Neuschäfer
  1 sibling, 0 replies; 4+ messages in thread
From: Jonathan Neuschäfer @ 2019-01-12 17:14 UTC (permalink / raw)
  To: linux-kernel
  Cc: Jonathan Neuschäfer, Linus Torvalds, Andrew Morton,
	Dominik Brodowski, Thomas Gleixner, Cyrill Gorcunov,
	Gustavo A. R. Silva, Yang Shi, Kristina Martsenko, Jann Horn,
	Kees Cook

UNAME26 is a mechanism to report Linux's version as 2.6.x, for
compatibility with old/broken software. Due to the way it is
implemented, it would have to be updated after 5.0, to keep the
resulting versions unique. Linus Torvalds argued:

> Do we actually need this?
>
> I'd rather let it bitrot, and just let it return random versions. It
> will just start again at 2.4.60, won't it?
>
> Anybody who uses UNAME26 for a 5.x kernel might as well think it's
> still 4.x. The user space is so old that it can't possibly care about
> differences between 4.x and 5.x, can it?
>
> The only thing that matters is that it shows "2.4.<largeenough>",
> which it will do regardless.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---

v2:
- Switched to documenting why UNAME26 is not updated

v1:
- https://lore.kernel.org/patchwork/patch/1029578/
---
 kernel/sys.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index a48cbf1414b8..f7eb62eceb24 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1207,7 +1207,8 @@ DECLARE_RWSEM(uts_sem);
 /*
  * Work around broken programs that cannot handle "Linux 3.0".
  * Instead we map 3.x to 2.6.40+x, so e.g. 3.0 would be 2.6.40
- * And we map 4.x to 2.6.60+x, so 4.0 would be 2.6.60.
+ * And we map 4.x and later versions to 2.6.60+x, so 4.0/5.0/6.0/... would be
+ * 2.6.60.
  */
 static int override_release(char __user *release, size_t len)
 {
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-01-12 17:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-07 18:03 [PATCH] kernel/sys.c: Fix UNAME26 for 5.0 Jonathan Neuschäfer
2019-01-07 18:10 ` Linus Torvalds
2019-01-08  0:08   ` Jonathan Neuschäfer
2019-01-12 17:14   ` [PATCH v2] kernel/sys.c: Clarify that UNAME26 does not generate unique versions anymore Jonathan Neuschäfer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.