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. thanks, greg k-h
