From owner-freebsd-net@FreeBSD.ORG Mon Apr 4 13:17:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD06D106564A for ; Mon, 4 Apr 2011 13:17:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B1D578FC19 for ; Mon, 4 Apr 2011 13:17:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 60E6046B03; Mon, 4 Apr 2011 09:17:22 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F3DE68A01B; Mon, 4 Apr 2011 09:17:21 -0400 (EDT) From: John Baldwin To: "Stefan `Sec` Zehl" Date: Mon, 4 Apr 2011 09:10:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4D8B99B4.4070404@FreeBSD.org> <20110331234017.GC3308@ice.42.org> <20110402115823.GE37730@ice.42.org> In-Reply-To: <20110402115823.GE37730@ice.42.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104040910.58284.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 04 Apr 2011 09:17:22 -0400 (EDT) Cc: freebsd-net@freebsd.org Subject: Re: The tale of a TCP bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 13:17:22 -0000 On Saturday, April 02, 2011 7:58:23 am Stefan `Sec` Zehl wrote: > Hi I'm back :) > > On Fri, Apr 01, 2011 at 01:40 +0200, Stefan `Sec` Zehl wrote: > > I'll of course monitor this value and report back if I ever see it > > increase :-) > > It did: > > | ice:~>uptime > | 1:45PM up 2 days, 17:01, 0 users, load averages: 1.29, 0.98, 0.60 > | ice:~>sysctl net.inet.tcp.adv_neg > | net.inet.tcp.adv_neg: 120 > | ice:~> > > I currently have no idea why. But I think it would be a good idea to fix > that adv calculation on 64bit for the negative case anyway. > > As my original attempt with a (long) cast was frowned upon, maybe > something like what OpenBSD did in r1.15 / 1998? > > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/tcp_output.c.diff?r1=1.14;r2=1.15 > > --- tcp_output.c.pre 2011-04-02 13:50:32.000000000 +0200 > +++ tcp_output.c 2011-04-02 13:50:35.000000000 +0200 > @@ -575,7 +575,7 @@ > * taking into account that we are limited by > * TCP_MAXWIN << tp->rcv_scale. > */ > - long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - > + long adv = lmin(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - > (tp->rcv_adv - tp->rcv_nxt); > > if(min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) < > > > If anyone has an idea what could trigger these cases, I'd be happy to > help debug. But without a clear testcase, it's a bit difficult. Honestly, it you can stomach it it might be better to add a KASSERT() and go ahead and panic and get a coredump. I think if adv is negative, it's a consequence of some other bug that we'd rather fix instead. Having a core dump where one can examine all the TCP pcb state when rcv_adv is too big is probably the best way to track that down. -- John Baldwin