[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YB+jVD6r4vlzuZO0@kroah.com>
Date: Sun, 7 Feb 2021 09:22:44 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
stable@...r.kernel.org, lwn@....net, jslaby@...e.cz,
shuah@...nel.org, patches@...nelci.org,
lkft-triage@...ts.linaro.org, pavel@...x.de, jonathanh@...dia.com
Subject: Re: Linux 4.4.256
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
Powered by blists - more mailing lists