> 2024年8月20日 23:05，Willy Tarreau <w@xxxxxx> 写道：
>
> 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@xxxxxxxxxxxxxxxxxxx> ??:
>>>>
>>>> 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
