On Fri 11-03-22 00:23:55, Theodore Ts'o wrote: > On Wed, Mar 09, 2022 at 10:57:24AM -0800, Luis Chamberlain wrote: > > On Tue, Mar 08, 2022 at 02:06:57PM -0500, Sasha Levin wrote: > > > What we can't do is invest significant time into doing the testing work > > > ourselves for each and every subsystem in the kernel. > > > > I think this experience helps though, it gives you I think a better > > appreciation for what concerns we have to merge any fix and the effort > > and dilligence required to ensure we don't regress. I think the > > kernel-ci steady state goal takes this a bit further. > > Different communities seem to have different goals that they believe > the stable kernels should be aiming for. Sure, if you never merge any > fix, you can guarantee that there will be no regressions. However, > the question is whether the result is a better quality kernel. For > example, there is a recent change to XFS which fixes a security bug > which allows an attacker to gain access to deleted data. How do you > balance the tradeoff of "no regressions, ever", versus, "we'll leave a > security bug in XFS which is fixed in mainline linux, but we fear > regressions so much that we won't even backport a single-line fix to > the stable kernel?" > > In my view, the service which Greg, Sasha and the other stable > maintainers provide is super-valuable, and I am happy that ext4 > changes are automatically cherry-picked into the stable kernel. Have > there been times when this has resulted in regressions in ext4 for the > stable kernel? Sure! It's only been a handful of a times, though, > and the number of bug fixes that users using stable kernels have _not_ > seen *far* outweighs the downsides of the occasional regressions > (which gets found and then reverted). Yes, I completely agree it is tradeoff between how many fixes you backport and the risk of regressions. As I wrote distro people (like RHEL or SLES) have infrastructure and do backport sizable chunk of fixes flowing into stable kernels anyway but we leave out some for which we deem the ratio fix value / regression risk is bad for us. Also testing for distro people is somewhat more difficult because we don't have the comfort of testing on the HW & various combinations of setup and workload the customer is going to use. So we do some testing on our HW, default configs, and common workloads and put more effort into patch selection & review to reduce chances of regressions on customers' systems. Overall, the tradeoff simply works out a bit differently for distro people than say for Android and I don't think there's a silver bullet for all... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
