On Mon, Apr 16, 2018 at 01:33:21PM -0400, Steven Rostedt wrote: >On Mon, 16 Apr 2018 17:09:38 +0000 >Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx> wrote: > >> Let's play a "be the -stable maintainer" game. Would you take any >> of the following commits? >> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=fc90441e728aa461a8ed1cfede08b0b9efef43fb > >No, not automatically, or without someone from KVM letting me know what >side-effects that may have. Not stopping on a breakpoint is not that >critical, it may be a bit annoying. I would ask the KVM maintainers if >they feel it's critical enough for backporting, but without hearing >from them, I would leave it be. Fair enough. >> 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. """ >> 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. """ This is how fun it is reviewing AUTOSEL commits :) Even the small "trivial", "obviously correct" patches have room for errors for various reasons. 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?