Kernel version numbers after 4.9.255 and 4.4.255

Kernel version numbers after 4.9.255 and 4.4.255

[Jari Ruusu]

Greg,
I hope that your linux kernel release scripts are
implemented in a way that understands that PATCHLEVEL= and
SUBLEVEL= numbers in top-level linux Makefile are encoded
as 8-bit numbers for LINUX_VERSION_CODE and
KERNEL_VERSION() macros, and must stay in range 0...255.
These 8-bit limits are hardcoded in both kernel source and
userspace ABI.

After 4.9.255 and 4.4.255, your scripts should be
incrementing a number in EXTRAVERSION= in top-level
linux Makefile.

--
Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 F189

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Greg Kroah-Hartman]

On Thu, Feb 04, 2021 at 05:59:42AM +0000, Jari Ruusu wrote:
> Greg,
> I hope that your linux kernel release scripts are
> implemented in a way that understands that PATCHLEVEL= and
> SUBLEVEL= numbers in top-level linux Makefile are encoded
> as 8-bit numbers for LINUX_VERSION_CODE and
> KERNEL_VERSION() macros, and must stay in range 0...255.
> These 8-bit limits are hardcoded in both kernel source and
> userspace ABI.
> 
> After 4.9.255 and 4.4.255, your scripts should be
> incrementing a number in EXTRAVERSION= in top-level
> linux Makefile.

Should already be fixed in linux-next, right?

thanks,

greg k-h

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Jiri Slaby]

On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 05:59:42AM +0000, Jari Ruusu wrote:
>> Greg,
>> I hope that your linux kernel release scripts are
>> implemented in a way that understands that PATCHLEVEL= and
>> SUBLEVEL= numbers in top-level linux Makefile are encoded
>> as 8-bit numbers for LINUX_VERSION_CODE and
>> KERNEL_VERSION() macros, and must stay in range 0...255.
>> These 8-bit limits are hardcoded in both kernel source and
>> userspace ABI.
>>
>> After 4.9.255 and 4.4.255, your scripts should be
>> incrementing a number in EXTRAVERSION= in top-level
>> linux Makefile.
> 
> Should already be fixed in linux-next, right?

I assume you mean:
commit 537896fabed11f8d9788886d1aacdb977213c7b3
Author: Sasha Levin <sashal@kernel.org>
Date:   Mon Jan 18 14:54:53 2021 -0500

     kbuild: give the SUBLEVEL more room in KERNEL_VERSION

That would IMO break userspace as definition of kernel version has 
changed. And that one is UAPI/ABI (see 
include/generated/uapi/linux/version.h) as Jari writes. For example will 
glibc still work:
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/configure.ac;h=13abda0a51484c5951ffc6d718aa36b72f3a9429;hb=HEAD#l14

? Or gcc 10 (11 will have this differently):
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf.c;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l165

and

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf-helpers.h;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l53

It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + 
Z) assumptions all around the world. So this doesn't look like a good idea.

thanks,
-- 
js
suse labs

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Greg Kroah-Hartman]

On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 05:59:42AM +0000, Jari Ruusu wrote:
> > > Greg,
> > > I hope that your linux kernel release scripts are
> > > implemented in a way that understands that PATCHLEVEL= and
> > > SUBLEVEL= numbers in top-level linux Makefile are encoded
> > > as 8-bit numbers for LINUX_VERSION_CODE and
> > > KERNEL_VERSION() macros, and must stay in range 0...255.
> > > These 8-bit limits are hardcoded in both kernel source and
> > > userspace ABI.
> > > 
> > > After 4.9.255 and 4.4.255, your scripts should be
> > > incrementing a number in EXTRAVERSION= in top-level
> > > linux Makefile.
> > 
> > Should already be fixed in linux-next, right?
> 
> I assume you mean:
> commit 537896fabed11f8d9788886d1aacdb977213c7b3
> Author: Sasha Levin <sashal@kernel.org>
> Date:   Mon Jan 18 14:54:53 2021 -0500
> 
>     kbuild: give the SUBLEVEL more room in KERNEL_VERSION
> 
> That would IMO break userspace as definition of kernel version has changed.
> And that one is UAPI/ABI (see include/generated/uapi/linux/version.h) as
> Jari writes. For example will glibc still work:
> http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/configure.ac;h=13abda0a51484c5951ffc6d718aa36b72f3a9429;hb=HEAD#l14
> 
> ? Or gcc 10 (11 will have this differently):
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf.c;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l165
> 
> and
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf-helpers.h;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l53

Ugh, I thought this was an internal representation, not an external one
:(

> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> assumptions all around the world. So this doesn't look like a good idea.

Ok, so what happens if we "wrap"?  What will break with that?  At first
glance, I can't see anything as we keep the padding the same, and our
build scripts seem to pick the number up from the Makefile and treat it
like a string.

It's only the crazy out-of-tree kernel stuff that wants to do minor
version checks that might go boom.  And frankly, I'm not all that
concerned if they have problems :)

So, let's leave it alone and just see what happens!

greg k-h

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Jiri Slaby]

On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
>> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
>> assumptions all around the world. So this doesn't look like a good idea.
> 
> Ok, so what happens if we "wrap"?  What will break with that?  At first
> glance, I can't see anything as we keep the padding the same, and our
> build scripts seem to pick the number up from the Makefile and treat it
> like a string.
> 
> It's only the crazy out-of-tree kernel stuff that wants to do minor
> version checks that might go boom.  And frankly, I'm not all that
> concerned if they have problems :)

Agreed. But currently, sublevel won't "wrap", it will "overflow" to 
patchlevel. And that might be a problem. So we might need to update the 
header generation using e.g. "sublevel & 0xff" (wrap around) or 
"sublevel > 255 : 255 : sublevel" (be monotonic and get stuck at 255).

In both LINUX_VERSION_CODE generation and KERNEL_VERSION proper.

thanks,
-- 
js

RE: Kernel version numbers after 4.9.255 and 4.4.255

[David Laight]

From: Jiri Slaby
> Sent: 04 February 2021 11:01
> 
> On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
> >> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> >> assumptions all around the world. So this doesn't look like a good idea.
> >
> > Ok, so what happens if we "wrap"?  What will break with that?  At first
> > glance, I can't see anything as we keep the padding the same, and our
> > build scripts seem to pick the number up from the Makefile and treat it
> > like a string.
> >
> > It's only the crazy out-of-tree kernel stuff that wants to do minor
> > version checks that might go boom.  And frankly, I'm not all that
> > concerned if they have problems :)
> 
> Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> patchlevel. And that might be a problem. So we might need to update the
> header generation using e.g. "sublevel & 0xff" (wrap around) or
> "sublevel > 255 : 255 : sublevel" (be monotonic and get stuck at 255).
> 
> In both LINUX_VERSION_CODE generation and KERNEL_VERSION proper.

A full wrap might catch checks for less than (say) 4.4.2 which
might be present to avoid very early versions.
So sticking at 255 or wrapping onto (say) 128 to 255 might be better.

I'm actually intrigued about how often you expect people to update
systems running these LTS kernels.
At a release every week it takes 5 years to run out of sublevels.
No one is going to reboot a server anywhere near that often.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Greg Kroah-Hartman]

On Thu, Feb 04, 2021 at 04:28:19PM +0000, David Laight wrote:
> From: Jiri Slaby
> > Sent: 04 February 2021 11:01
> > 
> > On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
> > >> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> > >> assumptions all around the world. So this doesn't look like a good idea.
> > >
> > > Ok, so what happens if we "wrap"?  What will break with that?  At first
> > > glance, I can't see anything as we keep the padding the same, and our
> > > build scripts seem to pick the number up from the Makefile and treat it
> > > like a string.
> > >
> > > It's only the crazy out-of-tree kernel stuff that wants to do minor
> > > version checks that might go boom.  And frankly, I'm not all that
> > > concerned if they have problems :)
> > 
> > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > patchlevel. And that might be a problem. So we might need to update the
> > header generation using e.g. "sublevel & 0xff" (wrap around) or
> > "sublevel > 255 : 255 : sublevel" (be monotonic and get stuck at 255).
> > 
> > In both LINUX_VERSION_CODE generation and KERNEL_VERSION proper.
> 
> A full wrap might catch checks for less than (say) 4.4.2 which
> might be present to avoid very early versions.

Who does that?

> So sticking at 255 or wrapping onto (say) 128 to 255 might be better.

Better how?

> I'm actually intrigued about how often you expect people to update
> systems running these LTS kernels.

Whenever they can, and should.

> At a release every week it takes 5 years to run out of sublevels.
> No one is going to reboot a server anywhere near that often.

Why not?

Usually kernels this old are stuck in legacy embedded systems, like last
year's new phone models :)

thanks,

greg k-h

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Christoph Biedl]

David Laight wrote...

> A full wrap might catch checks for less than (say) 4.4.2 which
> might be present to avoid very early versions.
> So sticking at 255 or wrapping onto (say) 128 to 255 might be better.

Hitting such version checks still might happen, though.

Also, any wrapping introduces a real risk package managers will see
version numbers running backwards and therefore will refrain from
installing an actually newer version.

For scripts/package/builddeb (I don't use that, though), you could work
around by setting an epoch, i.e. (untested)

-$sourcename ($packageversion) $distribution; urgency=low
+$sourcename (1:$packageversion) $distribution; urgency=low

but every packaging mechanism in-tree and outside should adopt such a
change, if even possible. Which is why this feels bad.

Possibly I am missing something: What's the reason to not use
EXTRAVERSION as back in the old 2.6.x.y days, so change to 4.4.255.1 and
so on? Well, unless there are still installations who treat 4.4.255 as
2.6.64.255.

    Christoph

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Greg KH]

On Thu, Feb 04, 2021 at 09:19:33PM +0100, Christoph Biedl wrote:
> David Laight wrote...
> 
> > A full wrap might catch checks for less than (say) 4.4.2 which
> > might be present to avoid very early versions.
> > So sticking at 255 or wrapping onto (say) 128 to 255 might be better.
> 
> Hitting such version checks still might happen, though.

By who?  For what?

> Also, any wrapping introduces a real risk package managers will see
> version numbers running backwards and therefore will refrain from
> installing an actually newer version.

package managers do not take the version from this macro, do they?  If
they do, please show me which ones.

thanks,

greg k-h

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Pavel Machek]

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

On Thu 2021-02-04 09:51:03, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> > On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > > On Thu, Feb 04, 2021 at 05:59:42AM +0000, Jari Ruusu wrote:
> > > > Greg,
> > > > I hope that your linux kernel release scripts are
> > > > implemented in a way that understands that PATCHLEVEL= and
> > > > SUBLEVEL= numbers in top-level linux Makefile are encoded
> > > > as 8-bit numbers for LINUX_VERSION_CODE and
> > > > KERNEL_VERSION() macros, and must stay in range 0...255.
> > > > These 8-bit limits are hardcoded in both kernel source and
> > > > userspace ABI.
> > > > 
> > > > After 4.9.255 and 4.4.255, your scripts should be
> > > > incrementing a number in EXTRAVERSION= in top-level
> > > > linux Makefile.
> > > 
> > > Should already be fixed in linux-next, right?
> > 
> > I assume you mean:
> > commit 537896fabed11f8d9788886d1aacdb977213c7b3
> > Author: Sasha Levin <sashal@kernel.org>
> > Date:   Mon Jan 18 14:54:53 2021 -0500
> > 
> >     kbuild: give the SUBLEVEL more room in KERNEL_VERSION
> > 
> > That would IMO break userspace as definition of kernel version has changed.
> > And that one is UAPI/ABI (see include/generated/uapi/linux/version.h) as
> > Jari writes. For example will glibc still work:
> > http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/configure.ac;h=13abda0a51484c5951ffc6d718aa36b72f3a9429;hb=HEAD#l14
> > 
> > ? Or gcc 10 (11 will have this differently):
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf.c;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l165
> > 
> > and
> > 
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf-helpers.h;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l53
> 
> Ugh, I thought this was an internal representation, not an external one
> :(
> 
> > It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> > assumptions all around the world. So this doesn't look like a good idea.
> 
> Ok, so what happens if we "wrap"?  What will break with that?  At first
> glance, I can't see anything as we keep the padding the same, and our
> build scripts seem to pick the number up from the Makefile and treat it
> like a string.
> 
> It's only the crazy out-of-tree kernel stuff that wants to do minor
> version checks that might go boom.  And frankly, I'm not all that
> concerned if they have problems :)
> 
> So, let's leave it alone and just see what happens!

Yeah, stable is a great place to do the experiments. Not that this is
the first time :-(.
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Greg Kroah-Hartman]

On Fri, Feb 05, 2021 at 10:06:59AM +0100, Pavel Machek wrote:
> On Thu 2021-02-04 09:51:03, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> > > On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > > > On Thu, Feb 04, 2021 at 05:59:42AM +0000, Jari Ruusu wrote:
> > > > > Greg,
> > > > > I hope that your linux kernel release scripts are
> > > > > implemented in a way that understands that PATCHLEVEL= and
> > > > > SUBLEVEL= numbers in top-level linux Makefile are encoded
> > > > > as 8-bit numbers for LINUX_VERSION_CODE and
> > > > > KERNEL_VERSION() macros, and must stay in range 0...255.
> > > > > These 8-bit limits are hardcoded in both kernel source and
> > > > > userspace ABI.
> > > > > 
> > > > > After 4.9.255 and 4.4.255, your scripts should be
> > > > > incrementing a number in EXTRAVERSION= in top-level
> > > > > linux Makefile.
> > > > 
> > > > Should already be fixed in linux-next, right?
> > > 
> > > I assume you mean:
> > > commit 537896fabed11f8d9788886d1aacdb977213c7b3
> > > Author: Sasha Levin <sashal@kernel.org>
> > > Date:   Mon Jan 18 14:54:53 2021 -0500
> > > 
> > >     kbuild: give the SUBLEVEL more room in KERNEL_VERSION
> > > 
> > > That would IMO break userspace as definition of kernel version has changed.
> > > And that one is UAPI/ABI (see include/generated/uapi/linux/version.h) as
> > > Jari writes. For example will glibc still work:
> > > http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/configure.ac;h=13abda0a51484c5951ffc6d718aa36b72f3a9429;hb=HEAD#l14
> > > 
> > > ? Or gcc 10 (11 will have this differently):
> > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf.c;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l165
> > > 
> > > and
> > > 
> > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf-helpers.h;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l53
> > 
> > Ugh, I thought this was an internal representation, not an external one
> > :(
> > 
> > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> > > assumptions all around the world. So this doesn't look like a good idea.
> > 
> > Ok, so what happens if we "wrap"?  What will break with that?  At first
> > glance, I can't see anything as we keep the padding the same, and our
> > build scripts seem to pick the number up from the Makefile and treat it
> > like a string.
> > 
> > It's only the crazy out-of-tree kernel stuff that wants to do minor
> > version checks that might go boom.  And frankly, I'm not all that
> > concerned if they have problems :)
> > 
> > So, let's leave it alone and just see what happens!
> 
> Yeah, stable is a great place to do the experiments. Not that this is
> the first time :-(.

How else can we "test this out"?

Should I do an "empty" release of 4.4.256 and see if anyone complains?

Any other ideas are gladly welcome...

thanks,

greg k-h

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Pavel Machek]

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

Hi!

> > > Ugh, I thought this was an internal representation, not an external one
> > > :(
> > > 
> > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> > > > assumptions all around the world. So this doesn't look like a good idea.
> > > 
> > > Ok, so what happens if we "wrap"?  What will break with that?  At first
> > > glance, I can't see anything as we keep the padding the same, and our
> > > build scripts seem to pick the number up from the Makefile and treat it
> > > like a string.
> > > 
> > > It's only the crazy out-of-tree kernel stuff that wants to do minor
> > > version checks that might go boom.  And frankly, I'm not all that
> > > concerned if they have problems :)
> > > 
> > > So, let's leave it alone and just see what happens!
> > 
> > Yeah, stable is a great place to do the experiments. Not that this is
> > the first time :-(.
> 
> How else can we "test this out"?
> 
> Should I do an "empty" release of 4.4.256 and see if anyone complains?

It seems that would be bad idea, as it would cause problems when stuff
is compiled on 4.4.256, not simply by running it.

Sasha's patch seems like one option that could work.

Even safer option is to switch to 4.4.255-st1, 4.4.255-st2 ... scheme.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

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

Re: Kernel version numbers after 4.9.255 and 4.4.255

[Greg Kroah-Hartman]

On Fri, Feb 05, 2021 at 07:44:12PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > Ugh, I thought this was an internal representation, not an external one
> > > > :(
> > > > 
> > > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> > > > > assumptions all around the world. So this doesn't look like a good idea.
> > > > 
> > > > Ok, so what happens if we "wrap"?  What will break with that?  At first
> > > > glance, I can't see anything as we keep the padding the same, and our
> > > > build scripts seem to pick the number up from the Makefile and treat it
> > > > like a string.
> > > > 
> > > > It's only the crazy out-of-tree kernel stuff that wants to do minor
> > > > version checks that might go boom.  And frankly, I'm not all that
> > > > concerned if they have problems :)
> > > > 
> > > > So, let's leave it alone and just see what happens!
> > > 
> > > Yeah, stable is a great place to do the experiments. Not that this is
> > > the first time :-(.
> > 
> > How else can we "test this out"?
> > 
> > Should I do an "empty" release of 4.4.256 and see if anyone complains?
> 
> It seems that would be bad idea, as it would cause problems when stuff
> is compiled on 4.4.256, not simply by running it.
> 
> Sasha's patch seems like one option that could work.
> 
> Even safer option is to switch to 4.4.255-st1, 4.4.255-st2 ... scheme.

Using EXTRAVERSION would work, but it is effectivly the same thing as
nothing exports that to userspace through the LINUX_VERSION macro.

So clamping the version like Sasha's patches seems to be the best
solution.

thanks,

greg k-h