lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 28 Apr 2008 22:21:57 +0300 (EEST) From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> To: Andy Furniss <lists@...yfurniss.entadsl.com> cc: Netdev <netdev@...r.kernel.org> Subject: Re: WARNING: at net/ipv4/tcp_input.c On Mon, 28 Apr 2008, Andy Furniss wrote: > Ilpo Järvinen wrote: > > On Mon, 28 Apr 2008, Andy Furniss wrote: > > > > > Since upgrading to 2.6.25 from 2.6.21.1 I've noticed a few of these. > > > > ...Thanks for the report, you could actually reproduce it in non-infinite > > time?? ...Finally somebody who might actually have a change to catch this > > shows up... :-) > > Hopefully - grepping shows I've had a few, More than one is a good start already. Most people who have reported had just one or have a loaded server which isn't that suitable for expensive tracking that is necessary. > I was running -rc7 for a while and > see a different message from that. I changed to .25 on the 21st. Anything pre -rc9 is not worth to mention. There have been other issues that were fixed in it. > > I've tried to catch these with torrent but never got anything, it seems to > > be quite sensitive to "network weather", which varies too much for me to > > catch it. Maybe I'll try w/o timestamps if that helps me to reproduce it > > (more likely). > > Could be my qos shaking things up. bt uses piggy backed acks and I must drop a > fair few. I probably reorder a bit as well by treating small tcp as higher > prio than large. Egress tcp is also mss clamped to 1150. Thanks for the info, though I've tried to use netem to generate some reordering & drops in my setup but just couldn't make it to happen with them either. > > The debug patch below will add considerable amount of processing per ACK to > > verify where this invariant gets broken for the first time, in case that's > > fine with your server, please consider adding that and waiting until it > > spits something out... :-) > > No problem it's 90% idle most of the time and my wan isn't that fast. > > I'll rebuild tonight. Thanks. -- i.
Powered by blists - more mailing lists