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