On Mon, 16 Apr 2018 17:42:38 +0000 Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx> wrote: > >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=a918d2bcea6aab6e671bfb0901cbecc3cf68fca1 > > > >Sure. Even if it has a subtle regression, that's a critical bug being > >fixed. > > This was later reverted, in -stable: > > """ > Commit d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite") removed > the end of line handling when storing the update_fw sysfs attribute. > This changed the userpace API because it started refusing writes > terminated by a line feed, which broke the update tools we already have. > """ I hope it wasn't reverted. It did fix a critical bug. The problem is that it only fixed a critical bug, but didn't go far enough to keep the bug fix from breaking API. I see this as two bugs being fixed. Even though the second bug was "caused" by the first fix. the first fix was still necessary. The second bug was relying on broken code. This hasn't changed my position on that patch from being backported. I would not even mark this as a regression. I would say the original code was broken too much, and fixing part of it just showed revealed another broken part. > > >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=b1999fa6e8145305a6c8bda30ea20783717708e6 > > > >I would consider unlocking a mutex that one didn't lock a critical bug, > >so yes. > > > >Again, things that deal with locking or buffer overflows, I would take > >the fix, as those are critical. But other behavior issues where it's > >not critical, I would leave be unless told further by someone else. > > This too, was reverted: > > """ > It causes run-time breakage in the 4.4-stable tree and more patches are > needed to be applied first before this one in order to resolve the > issue. > """ It wasn't reverted in mainline. Looks like there was some subtle issues with the different stable versions. Perhaps the "fixes" was wrong. > > This is how fun it is reviewing AUTOSEL commits :) > > Even the small "trivial", "obviously correct" patches have room for > errors for various reasons. And that's fine. Any code written can have bugs in it. That's just a given. Which pushes for why we should be extremely picky about what we backport. > > Also note that all of these patches were tagged for stable and actually > ended up in at least one tree. > > This is why I'm basing a lot of my decision making on the rejection rate. > If the AUTOSEL process does the job well enough as the "regular" > process did before, why push it back? Because I think we are adding too many patches to stable. And automating it may just make things worse. Your examples above back my argument more than they refute it. If people can't determine what is "obviously correct" how is automation going to do any better? -- Steve