From owner-freebsd-net@FreeBSD.ORG Tue Dec 22 14:05:31 2009 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 2E604106568D for ; Tue, 22 Dec 2009 14:05:31 +0000 (UTC) (envelope-from fengdreamer@126.com) Received: from m50-110.126.com (m50-110.126.com [123.125.50.110]) by mx1.freebsd.org (Postfix) with ESMTP id 23CF78FC1F for ; Tue, 22 Dec 2009 14:05:29 +0000 (UTC) Received: from hao251 (unknown [219.237.184.171]) by smtp4 (Coremail) with SMTP id jdKowLCbSzgq0jBLAESVCA--.52197S2; Tue, 22 Dec 2009 22:05:31 +0800 (CST) Date: Tue, 22 Dec 2009 22:05:21 +0800 From: "fengdreamer" To: "freebsd-net" References: <31264189.456321261063444556.JavaMail.coremail@bj126app49.126.com>, <200912192345192969851@126.com> Message-ID: <200912222205205465309@126.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 X-CM-TRANSID: jdKowLCbSzgq0jBLAESVCA--.52197S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ZrW7Kw13Zw15Cw4rWw45ZFb_yoW8Zw17pa yYq39xGrn2qrZ5Ars7Cr40gr1093yFyFy5J3yUWryYvw1Yg392gF12yrWa9wnruFs2vw1Y 9FWUXF15Ga1kC37anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUy0b7IF0VCYb41lb7IF0VCF04k20xv_Gry3M7k042IE42xK82IY 64kIx2x0424lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI4VWUJwAYFVCjjxCrM7Avxs IEb2xv6ckvw2Wl14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq 3wAFIxvE14AKwVWUJVWUGwA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjx v20xvEc7CjxVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2 jsIEc7CjxVAFwI0_GcCE3s1l57IF6xkI12xvs2x26I8E6xACxx1l57IF6s8CjcxG0xyl5I 8CrVCF0I0E4I0vr24lYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IE b7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwAC62BYpTIE1TZKA3svLVAKvSnIqf ZI6r4l7I0Y64k_MxkFs20EY4vE8sxKj4xv1wCY02Avz4vE14v_Xrylc2IjII80xcxEwVAK I48JMxAIw28IcxkI7VAKI48JMxCjnVAqn7xvrwC2zVAF1VAY17CE14v26r1j6r15MIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMs8CjcxG0xvEn4CqF7xvrwCE64xvF2IEb7IF0Fy7 YxBIdaVFxhVjvjDU0xZFpf9x07UY9aPUUUUU= X-CM-SenderInfo: pihqwv5uhdzvbu6rjloofrz/1tbiHRlBs0ihO5Q-9wAAs4 X-Mailman-Approved-At: Tue, 22 Dec 2009 14:11:55 +0000 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: KASSERT when connect to the peer(system is running out of memory) . 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: Tue, 22 Dec 2009 14:05:31 -0000 Hello ALL: I am using the FreeBSD 7.1. My system is running out of memory, in this sidution when i create the socket and connect, the the KASSERT come out. Here is my description, please read the brief first and get the problem and then contnue with the detail description. How is this problem happen: Brief description: 1. First, Connect side send SYN to the listerner 2. Second, Connect side will retransmit the SYN packet, but when it alloc mbuf fail in the tcp_output. the tcp_sndnxt will not increase. 3. SYN ACK arrives, tcp_snduna increase, and will lager then tcp_sndnxt by 1. sender side will response the ACK, invoke tcp_output: len is 1, but cc is zero. KASSERT happen. Detail description: 1.First, Connect side send SYN to the listerner, tcp->snd_nxt will just larger than the tcp->snd_una by 1. 2. Second, Connect side will retransmit the SYN packet. The retransmit is triger by the retransmit timer, it will then roll back the tcp->snd_nxt equal to tcp->snd_una. and begin to call the tcp_output. If the tcp_output working fun, the tcp->snd_nxt will then advanced by 1 before it calls the ip_output. But if the mbuf alloc fail, the tcp->snd_nxt will stay equal to tcp->snd_una. (on my system, memery is running out, so mbuf alloc may fail. ) please refer the below code in the tcp_output: MGETHDR(m, M_DONTWAIT, MT_DATA); if (m == NULL) { error = ENOBUFS; goto out; // goto out, so the tcp->snd_nxt will not increased. } 3. as above describtion, the tcp->snd_nxt is equal to tcp->snd_una. then the SYN ACK packet arrives, and the connection is established, and the tcp->snd_una will increase by 1. Also the connect side will then send the last ACK, it invode the tcp_output, tcp output len is compute by the below expression: off = tp->snd_nxt - tp->snd_una; len = ((long)ulmin(so->so_snd.sb_cc, sendwin) - off); ofcourse you have seen. the off is -1, the so_snd.sb_cc is 0, so the len is 1. so below KASSERT will came: KASSERT(sb->sb_mb != NULL, ("%s: sb_mb is NULL", __func__)); /* (sbsndptr ) */ Thanks Regard