[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers
mgorman at suse.de
Thu Jun 21 10:36:50 UTC 2012
On Wed, Jun 20, 2012 at 11:14:33AM -0400, Dave Jones wrote:
> On Wed, Jun 20, 2012 at 09:37:01AM +0100, Mel Gorman wrote:
> > Many of the patches I backport are performance related. Some are throughput
> > or latency style fixes and others are interactivity related particularly
> > when IO is involved. These are not "critical". In some cases there are
> > multiple patches required and that falls foul of the "It must fix only
> > one thing." rule.
> > Hence, if I discover something really bad and fix it in mainline then I tag
> > it for -stable. However, I was not reposting patches for -stable that fixed
> > more subtle issues because they were not critical, just desirable.
> As you mention these are not critical, and mm/vfs/block seem to be historically
> fragile areas that are easy to introduce regressions into.
True. Keeping the backport in the distribution kernel tree is not
necessarily better but I see your point because the distribution kernel
at least has been tested. There is no guarantee that it has been tested
with the -stable combination.
> We never get Fedora bugs like "mmap got 5% slower". We get "I get this weird oops sometimes".
openSUSE got at least one bug that bitched about interactivity problems when
writing to USB that was partially[*] handled by a backported series. I say
"partially" because there were follow-on patches that should also have
been backported but that has not happened yet.
> Fedora users are a different breed to say RHEL/SLES/LTS users, but that's a separate
> problem that needs solving not through stable.
> The only exception I'd give is if the performance difference was huge, and
> impacted a lot of users.
> Also, given the number of patches that goes into the first few stable releases
> once Linus opens up for merges, I suspect changing this rule would make the
> patch-bombs even more unreviewable.
That would be very unfortunate. The last thing we want is a flood of
patches into -stable that are very subtle. As a compromise, how about
allowing these "serious but not critical" issues only to be submitted by
distribution kernel maintainers managing backports?
The intent would be that these patches would not flow from Linux's tree
via a "cc: stable at kernel.org" and instead be submitted by distribution
kernel maintainers who have additional information on what is being fixed.
Would that be better or just higher risk for no major gain?
stable: Allow merging of backports for serious user-visible performance issues
Distribution kernel maintainers routinely backport fixes for users that
were deemed important but not "something critical" as defined by the
rules. To users of these kernels they are very serious and failing to fix
them reduces the value of -stable.
The problem is that the patches fixing these issues are often subtle and
prone to regressions in other ways and need greater care and attention.
To combat this, these "serious" backports should have a higher barrier
This patch relaxes the rules to allow a distribution maintainer to merge
to -stable a backported patch or small series that fixes a "serious"
user-visible performance issue. They should include additional information on
the user-visible bug affected and a link to the bugzilla entry if available.
The same rules about the patch being already in mainline still apply.
Signed-off-by: Mel Gorman <mgorman at suse.de>
Documentation/stable_kernel_rules.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index f0ab5cf..4a7b54b 100644
@@ -12,6 +12,12 @@ Rules on what kind of patches are accepted, and which ones are not, into the
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
+ - Serious issues as reported by a user of a distribution kernel may also
+ be considered if they fix a notable performance or interactivity issue.
+ As these fixes are not as obvious and have a higher risk of a subtle
+ regression they should only be submitted by a distribution kernel
+ maintainer and include an addendum linking to a bugzilla entry if it
+ exists and additional information on the user-visible impact.
- New device IDs and quirks are also accepted.
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.
More information about the Ksummit-2012-discuss