It is correct to introduce new sys calls to stable versions?

It is correct to introduce new sys calls to stable versions?

[Miao Wang]

Hi, Greg

I saw you have included commit 7697a0fe0154 ("LoongArch: Define
__ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
actually introduced new sys calls newfstatat and fstat to Loongarch.

I wonder if it is correct to add new syscalls, which actually changes
the kernel features, in stable releases, as it might confuse downstream
developers because they may assume the existence of a certain feature
after a certain version.

Cheers,

Miao Wang

Re: It is correct to introduce new sys calls to stable versions?

[Cyril Hrubis]

Hi!
> I wonder if it is correct to add new syscalls, which actually changes
> the kernel features, in stable releases, as it might confuse downstream
> developers because they may assume the existence of a certain feature
> after a certain version.

Just a side note, one thing I've learned by maintaining the Linux Test
Project is that the kernel version is a lie. You should not use the
kernel version for anything, never. All distributions rutinely backport
various new functionalities to older kernels and only reliable way how
to make sure something is implemented is to call the syscall and check
the return value.

That being said I have no idea what rules apply to stable trees.

-- 
Cyril Hrubis
chrubis@suse.cz

Re: It is correct to introduce new sys calls to stable versions?

[Greg Kroah-Hartman]

On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
> Hi, Greg
> 
> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
> actually introduced new sys calls newfstatat and fstat to Loongarch.

See the documentation in that commit for why it was done.

> I wonder if it is correct to add new syscalls, which actually changes
> the kernel features, in stable releases, as it might confuse downstream
> developers because they may assume the existence of a certain feature
> after a certain version.

Version numbers should never be used to be checked for anything as they
are only a "moment in time" stamp.  They do not reflect features or
capabilities or anything else.

Test for functionality if you want to check for something, that's the
only way it will ever work on all of the variants of different
"enterprise" kernels.

thanks,

greg k-h

Re: It is correct to introduce new sys calls to stable versions?

[Miao Wang]

Hi,

> 2024年8月20日 21:36，Greg Kroah-Hartman <gregkh@linuxfoundation.org> 写道：
> 
> On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
>> Hi, Greg
>> 
>> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
>> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
>> actually introduced new sys calls newfstatat and fstat to Loongarch.
> 
> See the documentation in that commit for why it was done.

Thanks for your explanation. I totally understand the necessity of
re-introducing thees two syscalls. I just wonder whether there is any
limitation on what can be included in to the stable trees. If there
was no limitation, theoretically, I could also maintain a so-called
stable tree by applying all the patches from torvalds' tree, except
those that bumps the version number. Apparently such a "stable" tree
is far from stable.

> 
>> I wonder if it is correct to add new syscalls, which actually changes
>> the kernel features, in stable releases, as it might confuse downstream
>> developers because they may assume the existence of a certain feature
>> after a certain version.
> 
> Version numbers should never be used to be checked for anything as they
> are only a "moment in time" stamp.  They do not reflect features or
> capabilities or anything else.

I agree with you and Cyril on the version numbers, recalling that kernels
on RHEL numbered on 3.10 contains various new features.

> Test for functionality if you want to check for something, that's the
> only way it will ever work on all of the variants of different
> "enterprise" kernels.

Thanks again for your quick reply.

> 
> thanks,
> 
> greg k-h

Re: It is correct to introduce new sys calls to stable versions?

[Greg Kroah-Hartman]

On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
> Hi,
> 
> > 2024年8月20日 21:36，Greg Kroah-Hartman <gregkh@linuxfoundation.org> 写道：
> > 
> > On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
> >> Hi, Greg
> >> 
> >> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
> >> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
> >> actually introduced new sys calls newfstatat and fstat to Loongarch.
> > 
> > See the documentation in that commit for why it was done.
> 
> Thanks for your explanation. I totally understand the necessity of
> re-introducing thees two syscalls. I just wonder whether there is any
> limitation on what can be included in to the stable trees. If there
> was no limitation, theoretically, I could also maintain a so-called
> stable tree by applying all the patches from torvalds' tree, except
> those that bumps the version number. Apparently such a "stable" tree
> is far from stable.

Or you could do the opposite, something that I have seen vendors do, and
just bump the kernel version number to try to "claim" they updated their
kernel to a more secure one (i.e. one that fixed loads of known issues),
but they really didn't.

Either way, it's your kernel, you are free to do whatever you want with
it, have fun!  :)

greg k-h

Re: It is correct to introduce new sys calls to stable versions?

[Willy Tarreau]

On Tue, Aug 20, 2024 at 10:00:35PM +0800, Greg Kroah-Hartman wrote:
> On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
> > Hi,
> > 
> > > 2024?8?20? 21:36,Greg Kroah-Hartman <gregkh@linuxfoundation.org> ??:
> > > 
> > > On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
> > >> Hi, Greg
> > >> 
> > >> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
> > >> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
> > >> actually introduced new sys calls newfstatat and fstat to Loongarch.
> > > 
> > > See the documentation in that commit for why it was done.
> > 
> > Thanks for your explanation. I totally understand the necessity of
> > re-introducing thees two syscalls. I just wonder whether there is any
> > limitation on what can be included in to the stable trees. If there
> > was no limitation, theoretically, I could also maintain a so-called
> > stable tree by applying all the patches from torvalds' tree, except
> > those that bumps the version number. Apparently such a "stable" tree
> > is far from stable.
> 
> Or you could do the opposite, something that I have seen vendors do, and
> just bump the kernel version number to try to "claim" they updated their
> kernel to a more secure one (i.e. one that fixed loads of known issues),
> but they really didn't.

Some of those who do that don't even notice what they're missing. I've
seen some BSP kernels "forward-ported" by merging the next bunch of
stable versions, trying to fix rejects by hand with the usual ratio of
failures, but after that since that version is part of the history, it's
impossible to figure what's really missing or not. Some people don't seem
to realize that *merging* code can actually result in *removing* fixes.
So they don't even need cheat on their versions, they're genuinely
believing they're OK... which is worse!

Willy

Re: It is correct to introduce new sys calls to stable versions?

[Miao Wang]

> 2024年8月20日 23:05，Willy Tarreau <w@1wt.eu> 写道：
> 
> On Tue, Aug 20, 2024 at 10:00:35PM +0800, Greg Kroah-Hartman wrote:
>> On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
>>> Hi,
>>> 
>>>> 2024?8?20? 21:36,Greg Kroah-Hartman <gregkh@linuxfoundation.org> ??:
>>>> 
>>>> On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
>>>>> Hi, Greg
>>>>> 
>>>>> I saw you have included commit 7697a0fe0154 ("LoongArch: Define
>>>>> __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which
>>>>> actually introduced new sys calls newfstatat and fstat to Loongarch.
>>>> 
>>>> See the documentation in that commit for why it was done.
>>> 
>>> Thanks for your explanation. I totally understand the necessity of
>>> re-introducing thees two syscalls. I just wonder whether there is any
>>> limitation on what can be included in to the stable trees. If there
>>> was no limitation, theoretically, I could also maintain a so-called
>>> stable tree by applying all the patches from torvalds' tree, except
>>> those that bumps the version number. Apparently such a "stable" tree
>>> is far from stable.
>> 
>> Or you could do the opposite, something that I have seen vendors do, and
>> just bump the kernel version number to try to "claim" they updated their
>> kernel to a more secure one (i.e. one that fixed loads of known issues),
>> but they really didn't.
> 
> Some of those who do that don't even notice what they're missing. I've
> seen some BSP kernels "forward-ported" by merging the next bunch of
> stable versions, trying to fix rejects by hand with the usual ratio of
> failures, but after that since that version is part of the history, it's
> impossible to figure what's really missing or not. Some people don't seem
> to realize that *merging* code can actually result in *removing* fixes.
> So they don't even need cheat on their versions, they're genuinely
> believing they're OK... which is worse!
> 
> Willy

Thank you all for sharing experiences with vendors messing up kernel
version numbers.

However, my original question is whether it is expected to include new
syscalls in kernel stable tree. According to the document "stable-kernel-
rules", if I'm interpreting it correctly, I expect only bug fixes and small
driver enhancements from stable releases. I understand the patch in question
is actually introducing new syscalls, which is beyond my expectation. So I
wonder the consideration of including this patch in stable releases.

Cheers,

Miao Wang

Re: It is correct to introduce new sys calls to stable versions?

[Willy Tarreau]

On Wed, Aug 21, 2024 at 12:09:41AM +0800, Miao Wang wrote:
> However, my original question is whether it is expected to include new
> syscalls in kernel stable tree. According to the document "stable-kernel-
> rules", if I'm interpreting it correctly, I expect only bug fixes and small
> driver enhancements from stable releases. I understand the patch in question
> is actually introducing new syscalls, which is beyond my expectation. So I
> wonder the consideration of including this patch in stable releases.

When you maintain stable software you quickly realize that everything
is not just pure white or black but a shade of gray and that if it can
be considered as a bug to miss a syscall in certain environments for
example, then it can become a valid fix to add it. I don't have any
opinion on this particular one, but since your question is broader I'm
trying to explain.

Different people have different expectations about what needs to be
fixed, that's even why some people will choose a distro over another
one (prefer to fix only critical bugs over fixing all bugs for example),
but there's no point restarting a philosophical on this topic which has
already been rehashed too many times in the past.

As a rule of thumb, just keep in mind that anything that needs to get
fix will eventually be fixed.

Thanks,
Willy

Re: It is correct to introduce new sys calls to stable versions?

[Miao Wang]

> 2024年8月21日 02:30，Willy Tarreau <w@1wt.eu> 写道：
> 
> On Wed, Aug 21, 2024 at 12:09:41AM +0800, Miao Wang wrote:
>> However, my original question is whether it is expected to include new
>> syscalls in kernel stable tree. According to the document "stable-kernel-
>> rules", if I'm interpreting it correctly, I expect only bug fixes and small
>> driver enhancements from stable releases. I understand the patch in question
>> is actually introducing new syscalls, which is beyond my expectation. So I
>> wonder the consideration of including this patch in stable releases.
> 
> When you maintain stable software you quickly realize that everything
> is not just pure white or black but a shade of gray and that if it can
> be considered as a bug to miss a syscall in certain environments for
> example, then it can become a valid fix to add it. I don't have any
> opinion on this particular one, but since your question is broader I'm
> trying to explain.
> 
> Different people have different expectations about what needs to be
> fixed, that's even why some people will choose a distro over another
> one (prefer to fix only critical bugs over fixing all bugs for example),
> but there's no point restarting a philosophical on this topic which has
> already been rehashed too many times in the past.
> 
> As a rule of thumb, just keep in mind that anything that needs to get
> fix will eventually be fixed.

Many thanks for your explanation!

Cheers,

Miao Wang

> 
> Thanks,
> Willy

Re: It is correct to introduce new sys calls to stable versions?

[Theodore Ts'o]

On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
> 
> I agree with you and Cyril on the version numbers, recalling that kernels
> on RHEL numbered on 3.10 contains various new features.

Some enterprise kernel versions have also been known to completely
take code whole from some subsystem (like, for example, a file system
like ext4 or xfs) from much newer upstream kernel version and backport
it into a very old "enterprise" kernel, with massive work to deal with
the dependencies that might be needed by the newer code, and
additional massive work so that structures and function signatures
stay the same so that binary out-of-tree kernel modules can continue
to load on that "stable" enterprise kernel.

That might take huge amounts of effort from a quality assurance
perspective, but that's might some enterprise customers are willing to
pay $$$$ for that frankenkernel and support for that frankenkernel....

This is also why when I get a bug report relating a distro kernel, I
tell bug reporters to go back to the distro for support.  Basically,
you can't really take anything for granted when you're dealing with a
non-upstream kernel, and that includes the version number.
Personally, I think this is a really bad idea, but distros and their
customers have the freedom to do what they want.  And this is why
those customers pay the distro the big bucks.  :-)

    	      	    	    	- Ted