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
