From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1078C433DB for ; Thu, 4 Feb 2021 16:50:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6A93464F60 for ; Thu, 4 Feb 2021 16:50:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238135AbhBDQuT (ORCPT ); Thu, 4 Feb 2021 11:50:19 -0500 Received: from mail.kernel.org ([198.145.29.99]:51248 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238118AbhBDQsy (ORCPT ); Thu, 4 Feb 2021 11:48:54 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id CFECC64DA3; Thu, 4 Feb 2021 16:48:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612457293; bh=XFs0VAuDxw0PgpvNH4+/XNKhcukc6dJkT0donvjsDTU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dvEQU7mD+yC4zlV1QyQpO5Xfg/BZT8mIXuk35br3aM/07obutBF6xlhhreIOcOsbg DxooHzE7Wl3KjQNCA6/bUMUfwJ9JTP/bHOkOc28izycBGDNVto+Qdbl9qzVyblD4bZ wuq+av0rOpALgXYkrhGZTETw/EJXSVplEYLyFuXE= Date: Thu, 4 Feb 2021 17:48:10 +0100 From: Greg Kroah-Hartman To: David Laight Cc: 'Jiri Slaby' , Jari Ruusu , Sasha Levin , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , "torvalds@linux-foundation.org" , "masahiroy@kernel.org" Subject: Re: Kernel version numbers after 4.9.255 and 4.4.255 Message-ID: References: <7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com> <78ada91b-21ee-563f-9f75-3cbaeffafad4@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org 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