linux-kernel - Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YAVT0XV7uX2NpIRe@kroah.com>
Date:   Mon, 18 Jan 2021 10:24:33 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     masahiroy@...nel.org, michal.lkml@...kovi.net,
        torvalds@...ux-foundation.org, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

On Mon, Jan 18, 2021 at 10:21:16AM +0100, Greg KH wrote:
> On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote:
> > SUBLEVEL only has 8 bits of space, which means that we'll overflow it
> > once it reaches 256.
> > 
> > Few of the stable branches will imminently overflow SUBLEVEL while
> > there's no risk of overflowing VERSION.
> > 
> > Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
> > should create a better balance between the different version numbers we
> > use.
> > 
> > The downside here is that Linus will have 8 bits less to play with, but
> > given our current release cadence (~10 weeks), the number of Linus's
> > fingers & toes (20), and the current VERSION (5) we can calculate that
> > VERSION will overflow in just over 1,000 years, so I'm kicking this can
> > down the road.
> > 
> > Cc: stable@...nel.org
> > Signed-off-by: Sasha Levin <sashal@...nel.org>
> > ---
> >  Makefile | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Makefile b/Makefile
> > index 9e73f82e0d863..dc2bad7a440d8 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1252,8 +1252,8 @@ endef
> >  
> >  define filechk_version.h
> >  	echo \#define LINUX_VERSION_CODE $(shell                         \
> > -	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> > -	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
> > +	expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
> > +	echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
> 
> As much as I agree, this will break in-tree users of LINUX_VERSION_CODE
> that try to suck out the version/patchlevel number of the kernel release
> into their own fields.  Things like USB host controller strings, v4l
> ioctl reports, scsi driver ioctls, and other places do fun bit-movements
> to try to unreverse this bit packing.
> 
> So how about we just provide a "real" version/subversion/revision
> #define as well, and clean up all in-kernel users, so we can get this to
> work, and we can change it in the future more easily.

Or, I can just stop doing stable releases at .255 and then abuse the
EXTRAVERSION field to put in sub-revision values.

Or, we can just not worry about it as anyone using these really old
kernels, userspace will work just fine (the number going backwards for
these fields isn't going to break anything), it's only any crazy
out-of-tree code that will get confused if they are trying to do
different build options based on SUBLEVEL :)

thanks,

greg k-h