Hi Stephen, On Thu, Jul 19, 2012 at 11:16:18AM -0700, Stephen Balukoff wrote: > Hello y'all! > > So, I'm attempting to use haproxy to load balance an IPv6 listener > with an IPv6 backend. The interesting problem I'm running into is that > I'm able to reliably crash the linux kernel I'm using. Has anyone > else run into a similar issue? (Obviously, this feels like a kernel > bug to me-- a user space program ought not to be able to crash the > kernel. But still, I do wonder if there's something I'm doing which > is particularly wrong in this case.) > > The kernel is the Scientific Linux port of the latest RHEL 6.2 kernel: > 2.6.32-279.1.1.el6.x86_64 > haproxy version I'm experimenting with is 1.5-dev11, built as an rpm > using the haproxy.spec file included with the source. > > I've tried this on other 2.6.32 kernels with similar results.
Just a followup on this bug so that people who face it know the fix. We finally managed to reproduce it at Exceliance, one year later ! This issue is caused by an integer overflow bug in the IPv6 part of the kernel in any 2.6.32.x up to and including 2.6.32.61 and 3.0.x up to and including 3.0.100. It happens when any somaxconn value and listen queue is 32768 or above. The bug was fixed in kernel 3.2-rc2 with the following commit which is easy to backport : c16a98e ipv6: tcp: fix panic in SYN processing Fortunately we found a simpler workaround which consists in limiting somaxconn to 32767 or less, or to force your "backlog" parameter in haproxy to such a value. This value will not trigger the integer overflow. Best regards, Willy
