On Fri, Jul 26, 2013 at 06:33:03AM +1000, NeilBrown wrote: > On Thu, 25 Jul 2013 16:18:05 -0400 "J.Bruce Fields" <bfields@xxxxxxxxxxxxxx> > wrote: > > > On Thu, Jul 25, 2013 at 11:30:23AM +1000, NeilBrown wrote: > > > > > > Since we enabled auto-tuning for sunrpc TCP connections we do not > > > guarantee that there is enough write-space on each connection to > > > queue a reply. ... > > This is great, thanks! > > > > Inclined to queue it up for 3.11 and stable.... > > I'd agree for 3.11. > It feels a bit border-line for stable. "dead-lock" and "has been seen in the > wild" are technically enough justification... > I'd probably mark it as "pleas don't apply to -stable until 3.11 is released" > or something like that, just for a bit of breathing space. > Your call though. So my takeaway from http://lwn.net/Articles/559113/ was that Linus and Greg were requesting that: - criteria for -stable and late -rc's should really be about the same, and - people should follow Documentation/stable-kernel-rules.txt. So as an exercise to remind me what those rules are: Easy questions: - "no bigger than 100 lines, with context." Check. - "It must fix only one thing." Check. - "real bug that bothers people". Check. - "tested": yep. It doesn't actually say "tested on stable trees", and I recall this did land you with a tricky bug one time when a prerequisite was omitted from the backport. Judgement calls: - "obviously correct": it's short, but admittedly subtle, and performance regressions can take a while to get sorted out. - "It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical." We could argue that "server stops responding" is critical, though not to the same degree as a panic. - OR: alternatively: "Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue." The only bz I've personally seen was the result of artificial testing of some kind, and it sounds like your case involved a disk failure? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
