Linux 4.4.256

Linux 4.4.256

[Greg Kroah-Hartman]

I'm announcing the release of the 4.4.256 kernel.

This, and the 4.9.256 release are a little bit "different" than normal.

This contains only 1 patch, just the version bump from .255 to .256 which ends
up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
than normal due to the "overflow".

With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0).

Nothing in the kernel build itself breaks with this change, but given that this
is a userspace visible change, and some crazy tools (like glibc and gcc) have
logic that checks the kernel version for different reasons, I wanted to do this
release as an "empty" release to ensure that everything still works properly.

So, this is a YOU MUST UPGRADE requirement of a release.  If you rely on the
4.4.y kernel, please throw this release into your test builds and rebuild the
world and let us know if anything breaks, or if all is well.

Go forth and do full system rebuilds!  Yocto and Gentoo are great for this, as
will systems that use buildroot.

I'll try to hold off on doing a "real" 4.4.y release for a week to give
everyone a chance to test this out and get back to me.  The pending patches in
the 4.4.y queue are pretty serious, so I am loath to wait longer than that,
consider yourself warned...

The updated 4.4.y git tree can be found at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
	https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h

------------

 Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Greg Kroah-Hartman (1):
      Linux 4.4.256

Re: Linux 4.4.256

[Greg Kroah-Hartman]

diff --git a/Makefile b/Makefile
index b18b61e540e9..0057587d2cbe 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 255
+SUBLEVEL = 256
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 

Re: Linux 4.4.256

[Guenter Roeck]

On Fri, Feb 05, 2021 at 03:26:36PM +0100, Greg Kroah-Hartman wrote:
> I'm announcing the release of the 4.4.256 kernel.
> 
> This, and the 4.9.256 release are a little bit "different" than normal.
> 
> This contains only 1 patch, just the version bump from .255 to .256 which ends
> up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
> than normal due to the "overflow".
> 
> With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0).
> 
> Nothing in the kernel build itself breaks with this change, but given that this
> is a userspace visible change, and some crazy tools (like glibc and gcc) have
> logic that checks the kernel version for different reasons, I wanted to do this
> release as an "empty" release to ensure that everything still works properly.
> 
> So, this is a YOU MUST UPGRADE requirement of a release.  If you rely on the
> 4.4.y kernel, please throw this release into your test builds and rebuild the
> world and let us know if anything breaks, or if all is well.
> 
> Go forth and do full system rebuilds!  Yocto and Gentoo are great for this, as
> will systems that use buildroot.
> 
> I'll try to hold off on doing a "real" 4.4.y release for a week to give
> everyone a chance to test this out and get back to me.  The pending patches in
> the 4.4.y queue are pretty serious, so I am loath to wait longer than that,
> consider yourself warned...
> 
Thanks a lot for the heads-up. For chromeos-4.4, the version number wrap
is indeed fatal: Unfortunately we have lots of vendor code in the tree
which uses KERNEL_VERSION(), and all the version comparisons against
KERNEL_VERSION(4,5,0) do result in compile errors.

The best workaround/hack/kludge to address the problem seems to be the idea
to use 4.4.255 as version number for LINUX_VERSION_CODE and KERNEL_VERSION()
if SUBLEVEL is larger than 255. Did anyone find a better solution for the
problem ?

Thanks,
Guenter

Re: Linux 4.4.256

[Greg Kroah-Hartman]

On Fri, Feb 05, 2021 at 12:56:58PM -0800, Guenter Roeck wrote:
> On Fri, Feb 05, 2021 at 03:26:36PM +0100, Greg Kroah-Hartman wrote:
> > I'm announcing the release of the 4.4.256 kernel.
> > 
> > This, and the 4.9.256 release are a little bit "different" than normal.
> > 
> > This contains only 1 patch, just the version bump from .255 to .256 which ends
> > up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
> > than normal due to the "overflow".
> > 
> > With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0).
> > 
> > Nothing in the kernel build itself breaks with this change, but given that this
> > is a userspace visible change, and some crazy tools (like glibc and gcc) have
> > logic that checks the kernel version for different reasons, I wanted to do this
> > release as an "empty" release to ensure that everything still works properly.
> > 
> > So, this is a YOU MUST UPGRADE requirement of a release.  If you rely on the
> > 4.4.y kernel, please throw this release into your test builds and rebuild the
> > world and let us know if anything breaks, or if all is well.
> > 
> > Go forth and do full system rebuilds!  Yocto and Gentoo are great for this, as
> > will systems that use buildroot.
> > 
> > I'll try to hold off on doing a "real" 4.4.y release for a week to give
> > everyone a chance to test this out and get back to me.  The pending patches in
> > the 4.4.y queue are pretty serious, so I am loath to wait longer than that,
> > consider yourself warned...
> > 
> Thanks a lot for the heads-up. For chromeos-4.4, the version number wrap
> is indeed fatal: Unfortunately we have lots of vendor code in the tree
> which uses KERNEL_VERSION(), and all the version comparisons against
> KERNEL_VERSION(4,5,0) do result in compile errors.
> 
> The best workaround/hack/kludge to address the problem seems to be the idea
> to use 4.4.255 as version number for LINUX_VERSION_CODE and KERNEL_VERSION()
> if SUBLEVEL is larger than 255. Did anyone find a better solution for the
> problem ?

I think Sasha's patch here:
	https://lore.kernel.org/r/20210205174702.1904681-1-sashal@kernel.org
is looking like the solution.

thanks,

greg k-h

Re: Linux 4.4.256

[Willy Tarreau]

On Sat, Feb 06, 2021 at 02:00:27PM +0100, Greg Kroah-Hartman wrote:
> I think Sasha's patch here:
> 	https://lore.kernel.org/r/20210205174702.1904681-1-sashal@kernel.org
> is looking like the solution.

It might cause trouble to those forcing SUBLEVEL to a given version such
as .0 to avoid exposing the exact stable version. I guess we should
instead try to integrate a test on the value itself and cap it at 255.

Something like this looks more robust to me, it will use SUBLEVEL for
values 0 to 255 and 255 for any larger value:

-	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
+	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL \<= 255)); \

Willy

Re: Linux 4.4.256

[Greg Kroah-Hartman]

On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> On Sat, Feb 06, 2021 at 02:00:27PM +0100, Greg Kroah-Hartman wrote:
> > I think Sasha's patch here:
> > 	https://lore.kernel.org/r/20210205174702.1904681-1-sashal@kernel.org
> > is looking like the solution.
> 
> It might cause trouble to those forcing SUBLEVEL to a given version such
> as .0 to avoid exposing the exact stable version. I guess we should
> instead try to integrate a test on the value itself and cap it at 255.

That's the main goal of the upstream submission that checks the value
before capping it:
	https://lore.kernel.org/r/20210206035033.2036180-2-sashal@kernel.org

> Something like this looks more robust to me, it will use SUBLEVEL for
> values 0 to 255 and 255 for any larger value:
> 
> -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL \<= 255)); \

I think you just rewrote the above linked patch :)

thanks,

greg k-h

Re: Linux 4.4.256

[Willy Tarreau]

On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> Something like this looks more robust to me, it will use SUBLEVEL for
> values 0 to 255 and 255 for any larger value:
> 
> -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL \<= 255)); \

Bah, I obviously missed a backslash above and forgot spaces around parens.
Here's a tested version:

diff --git a/Makefile b/Makefile
index 7d86ad6ad36c..9b91b8815b40 100644
--- a/Makefile
+++ b/Makefile
@@ -1252,7 +1252,7 @@ endef
 
 define filechk_version.h
 	echo \#define LINUX_VERSION_CODE $(shell                         \
-	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
+	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* \( 0$(SUBLEVEL) \> 255 \) + 0$(SUBLEVEL) \* \( 0$(SUBLEVEL) \<= 255 \) ); \
 	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
 endef
 
Willy

Re: Linux 4.4.256

[Willy Tarreau]

On Sat, Feb 06, 2021 at 02:19:57PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> > On Sat, Feb 06, 2021 at 02:00:27PM +0100, Greg Kroah-Hartman wrote:
> > > I think Sasha's patch here:
> > > 	https://lore.kernel.org/r/20210205174702.1904681-1-sashal@kernel.org
> > > is looking like the solution.
> > 
> > It might cause trouble to those forcing SUBLEVEL to a given version such
> > as .0 to avoid exposing the exact stable version. I guess we should
> > instead try to integrate a test on the value itself and cap it at 255.
> 
> That's the main goal of the upstream submission that checks the value
> before capping it:
> 	https://lore.kernel.org/r/20210206035033.2036180-2-sashal@kernel.org
>
> > Something like this looks more robust to me, it will use SUBLEVEL for
> > values 0 to 255 and 255 for any larger value:
> > 
> > -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL \<= 255)); \
> 
> I think you just rewrote the above linked patch :)

Ah I missed it, indeed! Sorry for the noise :-)

Willy

Re: Linux 4.4.256

[Guenter Roeck]

On 2/6/21 5:22 AM, Willy Tarreau wrote:
> On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
>> Something like this looks more robust to me, it will use SUBLEVEL for
>> values 0 to 255 and 255 for any larger value:
>>
>> -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
>> +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL \<= 255)); \
> 
> Bah, I obviously missed a backslash above and forgot spaces around parens.
> Here's a tested version:
> 
> diff --git a/Makefile b/Makefile
> index 7d86ad6ad36c..9b91b8815b40 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1252,7 +1252,7 @@ endef
>  
>  define filechk_version.h
>  	echo \#define LINUX_VERSION_CODE $(shell                         \
> -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* \( 0$(SUBLEVEL) \> 255 \) + 0$(SUBLEVEL) \* \( 0$(SUBLEVEL) \<= 255 \) ); \
>  	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
>  endef
>  

I like that version.

Two questions: Are there any concerns that KERNEL_VERSION(4, 4, 256)
matches KERNEL_VERSION(4, 5. 0), and do you plan to send this patch
upstream ?

Thanks,
Guenter

Re: Linux 4.4.256

[Greg Kroah-Hartman]

On Sat, Feb 06, 2021 at 08:59:42AM -0800, Guenter Roeck wrote:
> On 2/6/21 5:22 AM, Willy Tarreau wrote:
> > On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> >> Something like this looks more robust to me, it will use SUBLEVEL for
> >> values 0 to 255 and 255 for any larger value:
> >>
> >> -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> >> +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL \<= 255)); \
> > 
> > Bah, I obviously missed a backslash above and forgot spaces around parens.
> > Here's a tested version:
> > 
> > diff --git a/Makefile b/Makefile
> > index 7d86ad6ad36c..9b91b8815b40 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1252,7 +1252,7 @@ endef
> >  
> >  define filechk_version.h
> >  	echo \#define LINUX_VERSION_CODE $(shell                         \
> > -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* \( 0$(SUBLEVEL) \> 255 \) + 0$(SUBLEVEL) \* \( 0$(SUBLEVEL) \<= 255 \) ); \
> >  	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
> >  endef
> >  
> 
> I like that version.

See the patch that Sasha queued up already, it just fixes it at 255 for
now, and we will update with what is in Linus's tree like the above when
that gets merged in 5.12-rc1.

> Two questions: Are there any concerns that KERNEL_VERSION(4, 4, 256)
> matches KERNEL_VERSION(4, 5. 0),

As that "release" did nothing, no, I'm not too worried about it, are
you?

> and do you plan to send this patch upstream ?

See the series sent upstream here: https://lore.kernel.org/r/20210206035033.2036180-1-sashal@kernel.org

thanks,

greg k-h

Re: Linux 4.4.256

[Guenter Roeck]

On Sat, Feb 06, 2021 at 07:13:39PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Feb 06, 2021 at 08:59:42AM -0800, Guenter Roeck wrote:
> > On 2/6/21 5:22 AM, Willy Tarreau wrote:
> > > On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> > >> Something like this looks more robust to me, it will use SUBLEVEL for
> > >> values 0 to 255 and 255 for any larger value:
> > >>
> > >> -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > >> +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL \<= 255)); \
> > > 
> > > Bah, I obviously missed a backslash above and forgot spaces around parens.
> > > Here's a tested version:
> > > 
> > > diff --git a/Makefile b/Makefile
> > > index 7d86ad6ad36c..9b91b8815b40 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1252,7 +1252,7 @@ endef
> > >  
> > >  define filechk_version.h
> > >  	echo \#define LINUX_VERSION_CODE $(shell                         \
> > > -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > > +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* \( 0$(SUBLEVEL) \> 255 \) + 0$(SUBLEVEL) \* \( 0$(SUBLEVEL) \<= 255 \) ); \
> > >  	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
> > >  endef
> > >  
> > 
> > I like that version.
> 
> See the patch that Sasha queued up already, it just fixes it at 255 for
> now, and we will update with what is in Linus's tree like the above when
> that gets merged in 5.12-rc1.
> 
> > Two questions: Are there any concerns that KERNEL_VERSION(4, 4, 256)
> > matches KERNEL_VERSION(4, 5. 0),
> 
> As that "release" did nothing, no, I'm not too worried about it, are
> you?
> 
There are lots (35) of "KERNEL_VERSION(4, 5, 0)" in chromeos-4.4.
That should not matter with the clamped LINUX_VERSION_CODE, but
I'd prefer to clamp KERNEL_VERSION as well just to be sure. On
top of that, some of the vendor code we carry along does check
SUBVERSION, but that is probably more of an academic concern.

> > and do you plan to send this patch upstream ?
> 
> See the series sent upstream here: https://lore.kernel.org/r/20210206035033.2036180-1-sashal@kernel.org
> 
I backported the relevant patch into chromeos-4.4, so we should
be fine.

Thanks!
Guenter

Re: Linux 4.4.256

[Greg Kroah-Hartman]

On Sat, Feb 06, 2021 at 10:49:26AM -0800, Guenter Roeck wrote:
> On Sat, Feb 06, 2021 at 07:13:39PM +0100, Greg Kroah-Hartman wrote:
> > On Sat, Feb 06, 2021 at 08:59:42AM -0800, Guenter Roeck wrote:
> > > On 2/6/21 5:22 AM, Willy Tarreau wrote:
> > > > On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> > > >> Something like this looks more robust to me, it will use SUBLEVEL for
> > > >> values 0 to 255 and 255 for any larger value:
> > > >>
> > > >> -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > > >> +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL \<= 255)); \
> > > > 
> > > > Bah, I obviously missed a backslash above and forgot spaces around parens.
> > > > Here's a tested version:
> > > > 
> > > > diff --git a/Makefile b/Makefile
> > > > index 7d86ad6ad36c..9b91b8815b40 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -1252,7 +1252,7 @@ endef
> > > >  
> > > >  define filechk_version.h
> > > >  	echo \#define LINUX_VERSION_CODE $(shell                         \
> > > > -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > > > +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* \( 0$(SUBLEVEL) \> 255 \) + 0$(SUBLEVEL) \* \( 0$(SUBLEVEL) \<= 255 \) ); \
> > > >  	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
> > > >  endef
> > > >  
> > > 
> > > I like that version.
> > 
> > See the patch that Sasha queued up already, it just fixes it at 255 for
> > now, and we will update with what is in Linus's tree like the above when
> > that gets merged in 5.12-rc1.
> > 
> > > Two questions: Are there any concerns that KERNEL_VERSION(4, 4, 256)
> > > matches KERNEL_VERSION(4, 5. 0),
> > 
> > As that "release" did nothing, no, I'm not too worried about it, are
> > you?
> > 
> There are lots (35) of "KERNEL_VERSION(4, 5, 0)" in chromeos-4.4.
> That should not matter with the clamped LINUX_VERSION_CODE, but
> I'd prefer to clamp KERNEL_VERSION as well just to be sure. On
> top of that, some of the vendor code we carry along does check
> SUBVERSION, but that is probably more of an academic concern.

Ah, the internal checks, I think the other patch by Sasha will let that
get bigger and should work for you as well.  Can you try it out?

thanks,

greg k-h

RE: Linux 4.4.256

[David Laight]

From: Willy Tarreau
> Sent: 06 February 2021 13:23
> 
> On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> > Something like this looks more robust to me, it will use SUBLEVEL for
> > values 0 to 255 and 255 for any larger value:
> 
> diff --git a/Makefile b/Makefile
> index 7d86ad6ad36c..9b91b8815b40 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1252,7 +1252,7 @@ endef
> 
>  define filechk_version.h
>  	echo \#define LINUX_VERSION_CODE $(shell                         \
> -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* \( 0$(SUBLEVEL) \> 255 \) +
> 0$(SUBLEVEL) \* \( 0$(SUBLEVEL) \<= 255 \) ); \
>  	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
>  endef

Why not:
	$(shell echo $$(($(VERSION)<<16 + $(PATCHLEVEL)<<8 + ($(SUBVERSION) < 255 ? $(SUBVERSION) : 255))))
Untested, but I think only the one $ needs any kind of escape.
The extra leading zeros do have to go - $((...)) does octal :-(

	David

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

RE: Linux 4.4.256

[David Laight]

From: David Laight
> Sent: 08 February 2021 09:10
> 
> From: Willy Tarreau
> > Sent: 06 February 2021 13:23
> >
> > On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> > > Something like this looks more robust to me, it will use SUBLEVEL for
> > > values 0 to 255 and 255 for any larger value:
> >
> > diff --git a/Makefile b/Makefile
> > index 7d86ad6ad36c..9b91b8815b40 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1252,7 +1252,7 @@ endef
> >
> >  define filechk_version.h
> >  	echo \#define LINUX_VERSION_CODE $(shell                         \
> > -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* \( 0$(SUBLEVEL) \> 255 \) +
> > 0$(SUBLEVEL) \* \( 0$(SUBLEVEL) \<= 255 \) ); \
> >  	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
> >  endef
> 
> Why not:
> 	$(shell echo $$(($(VERSION)<<16 + $(PATCHLEVEL)<<8 + ($(SUBVERSION) < 255 ? $(SUBVERSION) :
> 255))))
> Untested, but I think only the one $ needs any kind of escape.
> The extra leading zeros do have to go - $((...)) does octal :-(

Or probably even better:

echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 : (c)))'
echo '#define LINUX_VERSION_CODE KERNEL_VERSION($(VERSION), $(PATCHLEVEL)+0, $(SUBLEVEL)+0)'

Which gets rid of the $(shell) as well.

	David

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

Re: Linux 4.4.256

[Greg Kroah-Hartman]

On Mon, Feb 08, 2021 at 09:38:05AM +0000, David Laight wrote:
> From: David Laight
> > Sent: 08 February 2021 09:10
> > 
> > From: Willy Tarreau
> > > Sent: 06 February 2021 13:23
> > >
> > > On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> > > > Something like this looks more robust to me, it will use SUBLEVEL for
> > > > values 0 to 255 and 255 for any larger value:
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 7d86ad6ad36c..9b91b8815b40 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1252,7 +1252,7 @@ endef
> > >
> > >  define filechk_version.h
> > >  	echo \#define LINUX_VERSION_CODE $(shell                         \
> > > -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > > +	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255 \* \( 0$(SUBLEVEL) \> 255 \) +
> > > 0$(SUBLEVEL) \* \( 0$(SUBLEVEL) \<= 255 \) ); \
> > >  	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
> > >  endef
> > 
> > Why not:
> > 	$(shell echo $$(($(VERSION)<<16 + $(PATCHLEVEL)<<8 + ($(SUBVERSION) < 255 ? $(SUBVERSION) :
> > 255))))
> > Untested, but I think only the one $ needs any kind of escape.
> > The extra leading zeros do have to go - $((...)) does octal :-(
> 
> Or probably even better:
> 
> echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 : (c)))'
> echo '#define LINUX_VERSION_CODE KERNEL_VERSION($(VERSION), $(PATCHLEVEL)+0, $(SUBLEVEL)+0)'
> 
> Which gets rid of the $(shell) as well.

Please comment on the real patch already submitted by Sasha for this.

thanks,

greg k-h

Re: Linux 4.4.256

[Guenter Roeck]

On Sun, Feb 07, 2021 at 09:22:44AM +0100, Greg Kroah-Hartman wrote:
[ ... ]
> > There are lots (35) of "KERNEL_VERSION(4, 5, 0)" in chromeos-4.4.
> > That should not matter with the clamped LINUX_VERSION_CODE, but
> > I'd prefer to clamp KERNEL_VERSION as well just to be sure. On
> > top of that, some of the vendor code we carry along does check
> > SUBVERSION, but that is probably more of an academic concern.
> 
> Ah, the internal checks, I think the other patch by Sasha will let that
> get bigger and should work for you as well.  Can you try it out?
> 
Quite frankly I like the "complete" fix much better, but then I dislike
deviating from stable releases even more. I'll use Sasha's version.

Thanks,
Guenter

Re: Linux 4.4.256

[Greg Kroah-Hartman]

On Mon, Feb 08, 2021 at 09:14:53AM -0800, Guenter Roeck wrote:
> On Sun, Feb 07, 2021 at 09:22:44AM +0100, Greg Kroah-Hartman wrote:
> [ ... ]
> > > There are lots (35) of "KERNEL_VERSION(4, 5, 0)" in chromeos-4.4.
> > > That should not matter with the clamped LINUX_VERSION_CODE, but
> > > I'd prefer to clamp KERNEL_VERSION as well just to be sure. On
> > > top of that, some of the vendor code we carry along does check
> > > SUBVERSION, but that is probably more of an academic concern.
> > 
> > Ah, the internal checks, I think the other patch by Sasha will let that
> > get bigger and should work for you as well.  Can you try it out?
> > 
> Quite frankly I like the "complete" fix much better, but then I dislike
> deviating from stable releases even more. I'll use Sasha's version.

We will backport the "complete" fix soon when it hits Linus's tree.

thanks,

greg k-h