From owner-freebsd-net@FreeBSD.ORG Sat Mar 20 11:14:12 2010 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 D0F74106564A for ; Sat, 20 Mar 2010 11:14:12 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 59E158FC0A for ; Sat, 20 Mar 2010 11:14:12 +0000 (UTC) Received: by bwz8 with SMTP id 8so3692982bwz.3 for ; Sat, 20 Mar 2010 04:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Blrya+7gBVBlTjsR9+vJkwOSUSNYJS5D94SCjNrSe4Q=; b=tER1/xxquHeeRxptLme/QAzG5i4TRP0DGjDtrXs7/lL3B+f5lNUvR+FvKj+4Dta/7o ZkzuNen5pIPaPZe7J1JImsUiltFp6eMf19xO0ABZd17uxP3JhdwCWSXTiix2RhEBLKTq EzZ9NrIvloHEy4RBZwAMTABiV3rGnY439rZMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=eJVhx1/+4t9B+iO8zE+g5/D/iaGn+jUZdVGo87geo6rihkdzW/SU3iQKkIyNVzRlrP 2sT8/RGeV83HvkGDnN/Mqg8zvkdfX8qggKUTHcHKV9vLkN5RYi8lOLLVevhqZzSzT1CM jqxi68wKU6yInD9xySz7r+LgWL7H779zlSFGY= Received: by 10.204.24.134 with SMTP id v6mr4606138bkb.204.1269083651076; Sat, 20 Mar 2010 04:14:11 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id g18sm8974956bkw.13.2010.03.20.04.14.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Mar 2010 04:14:10 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Rui Paulo In-Reply-To: <006f01cac6d8$5fc03cb0$1f40b610$@net> Date: Sat, 20 Mar 2010 11:14:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2FEF7D36-31B7-4FD7-9350-EECA7B38D519@freebsd.org> References: <006f01cac6d8$5fc03cb0$1f40b610$@net> To: Chris Harrer X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org Subject: Re: Bug in tcp_output? 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: Sat, 20 Mar 2010 11:14:12 -0000 On 18 Mar 2010, at 20:19, Chris Harrer wrote: > Hi All, >=20 >=20 >=20 > In the following block of code, running on a x86_64 platform, I = believe that > cwin should be declared as an int: >=20 > /* >=20 > * If snd_nxt =3D=3D snd_max and we have transmitted a FIN, the >=20 > * offset will be > 0 even if so_snd.sb_cc is 0, resulting in >=20 > * a negative length. This can also occur when TCP opens up >=20 > * its congestion window while receiving additional duplicate >=20 > * acks after fast-retransmit because TCP will reset snd_nxt >=20 > * to snd_max after the fast-retransmit. >=20 > * >=20 > * In the normal retransmit-FIN-only case, however, snd_nxt = will >=20 > * be set to snd_una, the offset will be 0, and the length may >=20 > * wind up 0. >=20 > * >=20 > * If sack_rxmit is true we are retransmitting from the = scoreboard >=20 > * in which case len is already set. >=20 > */ >=20 > if (sack_rxmit =3D=3D 0) { >=20 > if (sack_bytes_rxmt =3D=3D 0) >=20 > len =3D ((long)ulmin(so->so_snd.sb_cc, sendwin) = - off); >=20 > else { >=20 > long cwin; =DF-- Should be an int >=20 >=20 >=20 > /* >=20 > * We are inside of a SACK recovery episode and = are >=20 > * sending new data, having retransmitted all = the >=20 > * data possible in the scoreboard. >=20 > */ >=20 > len =3D ((long)ulmin(so->so_snd.sb_cc, = tp->snd_wnd)=20 >=20 > - off); >=20 > /* >=20 > * Don't remove this (len > 0) check ! >=20 > * We explicitly check for len > 0 here = (although it=20 >=20 > * isn't really necessary), to work around a gcc=20= >=20 > * optimization issue - to force gcc to compute >=20 > * len above. Without this check, the = computation >=20 > * of len is bungled by the optimizer. >=20 > */ >=20 > if (len > 0) { >=20 > cwin =3D tp->snd_cwnd -=20 >=20 > (tp->snd_nxt - tp->sack_newdata) = - >=20 > sack_bytes_rxmt; >=20 > if (cwin < 0) >=20 > cwin =3D 0; >=20 > len =3D lmin(len, cwin); >=20 > } >=20 > } >=20 > } >=20 >=20 >=20 > Consider the case where: >=20 > sack_rxmit =3D 0 >=20 > sack_bytes_rxmt =3D 0x2238 >=20 > off =3D 0 >=20 > len =3D0xa19c >=20 > tp->snd_cwnd =3D 0x2238 >=20 > tp->snd_nxt =3D 0xdd6d7974 >=20 > tp->sack_newdata =3D 0xdd6d6858 >=20 > In this case cwin evaluates to 0x00000000ffffe37c, which is not <0, = but > instead huge. This causes the remaining data on the socket=92s = so->so_snd > buffer to be sent to the network causing more problems at the receiver = which > is already dropping frames. I see. This is most likely a bug. Can you send-pr so this doesn't get = lost? Regards, -- Rui Paulo