netdev - Re: WARNING: at net/ipv4/tcp

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.