From: Sasha Levin <sashal@kernel.org>
To: Avi Kivity <avi@scylladb.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
torvalds@linux-foundation.org, stable@vger.kernel.org,
lwn@lwn.net, jslaby@suse.cz
Subject: Re: Linux 4.9.256
Date: Mon, 8 Feb 2021 13:57:07 -0500 [thread overview]
Message-ID: <20210208185707.GC4035784@sasha-vm> (raw)
In-Reply-To: <23a28990-c465-f813-52a4-f7f3db007f9d@scylladb.com>
On Mon, Feb 08, 2021 at 05:50:21PM +0200, Avi Kivity wrote:
>On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
>>I'm announcing the release of the 4.9.256 kernel.
>>
>>This, and the 4.4.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, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
>
>
>I think this is a bad idea. Many kernel features can only be
>discovered by checking the kernel version. If a feature was introduced
>in 4.10, then an application can be tricked into thinking a 4.9 kernel
>has it.
>
>
>IMO, better to stop LINUX_VERSION_CODE at 255 and introduce a
In the upstream (and new -stable fix) we did this part.
>LINUX_VERSION_CODE_IMPROVED that has more bits for patchlevel.
Do you have a usecase where it's actually needed? i.e. userspace that
checks for -stable patchlevels?
--
Thanks,
Sasha
next prev parent reply other threads:[~2021-02-08 20:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-05 14:26 Linux 4.9.256 Greg Kroah-Hartman
2021-02-05 14:26 ` Greg Kroah-Hartman
2021-02-08 12:57 ` Florian Weimer
2021-02-08 13:03 ` Greg Kroah-Hartman
2021-02-08 15:50 ` Avi Kivity
2021-02-08 16:31 ` Greg Kroah-Hartman
2021-02-08 18:57 ` Sasha Levin [this message]
2021-02-09 8:53 ` Avi Kivity
2021-02-11 10:48 ` LINUX_VERSION_CODE overflow (was: Re: Linux 4.9.256) Florian Weimer
2021-02-11 12:58 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210208185707.GC4035784@sasha-vm \
--to=sashal@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=avi@scylladb.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=lwn@lwn.net \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.