[Greg Kroah-Hartman] wrote the following on [18/01/2013 22:34]: > 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]
Ok, this was just for an advice ;-) I'll now always keep [email protected] in recipients ! >> 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? This is not just data loosing. I can always reproduce a server freeze (no kernel panic, no oops) with all the kernel versions I specify above. In the patch's changelog I write an example to help reproduce the server freezing (echo ... > /dev/kmsg), of course nobody plays with such command in production environment. But in our (production) case, which is not a textbook case, the server produces a lot of printk messages (because we configure "iptables ... -j LOG" and the server reject a lot of traffic), that makes the log_prefix() function access to memory that it must not. Then, I don't know exactly why, the server freezes. I'm not sure we can live with this buffer overflow problem because one day these printk/memory access conditions can occur, and may freeze the server. Linux distributions based on long-term stable kernels 3.[0,2,4] can be affected if they do not back-port the 3.6 commit (7ff9554bb578ba02166071d2d487b7fc7d860d62) or if the do not change something else in printk.c that makes the problem disappears. Alex. > > thanks, > > greg k-h > -- Alexandre SIMON - Réseau Lothaire Université de Lorraine / Direction du Numérique / Infrastructures Château du Montet | [email protected] Rue du Doyen Roubault | +33 (0)3.83.68.24.32 54500 Vandoeuvre-lès-Nancy | Contacts réseau Lothaire : [email protected] / +33 (0)3.83.68.24.24 / http://reseau.ciril.fr -- 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
