On Fri, Jan 18, 2013 at 09:12:36PM +0100, Alexandre SIMON wrote: > Dear Ben and Greg,
[adding [email protected] back, as this shouldn't be a private conversation] > after re-reading myself and some of the rules of how to submit patch to the > -stable tree, I think I'm not totally right on the way to proceed. > In fact, the patch I propose here does not come from upstream tree (I > misunderstood the commit ID upstream, so I put my commit ID !). > The changes in commit 7ff9554bb578ba02166071d2d487b7fc7d860d62 (that solve > the problem) can be back-ported to 3.4 (the patch apply with no problem) but > it does not apply to 3.2 and 3.0. The changes are too deep and important. So > that is why I decided to create a new (simple: only 17 lines of changes) fix > that can be applied to 3.0, 3.2 and 3.4. > I know this process does not follow the rules > (Documentation/stable_kernel_rules.txt) but in another hand back-porting > 7ff9554bb578ba02166071d2d487b7fc7d860d62 (especially in 3.0 and 3.2) is more > complex and intrusive. > > Is there any chance to my patch to be merge into -stable tree ? > Would you like me to proceed in the right way : cherry-pick > 7ff9554bb578ba02166071d2d487b7fc7d860d62 into 3.0, 3.2, 3.4 ? That patch is just too big, as you point out. Your patch is much more "sane", but I'm curious as to why it's needed? Can't we just live with the buffer overflow problem (we just loose data, nothing's corrupted, right?) until people move to 3.7? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
