On Mon, May 13, 2024 at 8:07 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, May 07, 2024 at 11:39:58PM +0900, Mark Brown wrote: > > On Tue, May 07, 2024 at 09:22:48AM -0500, David Lechner wrote: > > > > > It's just fixing a theoretical problem, not one that has actually > > > caused problems for people. The stable guidelines I read [1] said we > > > shouldn't include fixes like that. > > > > > [1]: https://docs.kernel.org/process/stable-kernel-rules.html > > > > > So, sure it would probably be harmless to include it without the > > > other dependencies. But not sure it is worth the effort for only > > > a theoretical problem. > > > > The written stable guidelines don't really reflect what's going on with > > stable these days at all, these days it's very aggressive with what it > > backports. > > It's "aggressive" in that many dependent patches are finally being > properly found and backported as needed to be able to get the "real" fix > applied properly. That's all, nothing odd here, and all of these > commits have been through proper review and development and acceptance > already, so it's not like they are brand new things, they are required > for real fixes. > > > Personally I tend to be a lot more conservative than this > > and would tend to agree that this isn't a great candidate for > > backporting but people seem OK with this sort of stuff. > > Again, we want to keep as close as possible with Linus's tree because > ALMOST EVERY time we try to do our own thing, we get something wrong. > Keeping in sync is essencial to rely on our overall testing and future > fix ability to keep in sync properly. > > To attempt to do "one off" backports all over the place just does not > work, we have tried it and failed. To not accept the fix at all leaves > us vulnerable to a known bug, why would that be ok? > > Change is good, and these changes are extra-good as they fix things. > I see there are differences in opinion of what a "real" problem is. And it sounds like the opinions have been shifting while I was away from kernel development for a few years. If you prefer to take this patch and all of it's dependencies to keep things as close to mainline as possible, I guess that is fine.
