From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 00:18:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64F1ED41 for ; Sun, 1 Feb 2015 00:18:59 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F9E0D62 for ; Sun, 1 Feb 2015 00:18:59 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id rd3so67005904pab.3 for ; Sat, 31 Jan 2015 16:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KZNN63lYRHfLCpR8hiPtkg4jGecC7BN9UdJQksodfbk=; b=ZPXuiTi2aPyhivbe6zgoNCTxk00D/6cGXNtU3AYnk4VDuGUjAkp6d+LeVE5jCFM7dr +aTUWY8qOIekamI0xGAmfKyTkb5e5i2JWMFmv5pTlONVzpxzZrPwcPfyVx+YlK8Ewj58 BZ2ZzILU3AXPvrxeTiDSasCxFdqp3zAgnRnrrl2UyFctl8CAuFBMjrEwkjIn+0BzTjUC BazaO9Ry7R6tI13A7tTbcU6vGP2M+lsKrcU1Q2INwTf212C1qIdwTulmlAI2FZOCaUq2 eU0JqTJDYZQLiZ+1enu7Z/yOvWkyAUM6PXEzkiwQtsi9bIN8izhhxDoTTEHe23jutxxH ZsvQ== MIME-Version: 1.0 X-Received: by 10.68.242.163 with SMTP id wr3mr19036882pbc.159.1422749938615; Sat, 31 Jan 2015 16:18:58 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.22.231 with HTTP; Sat, 31 Jan 2015 16:18:58 -0800 (PST) In-Reply-To: References: <54C918D2.7090805@FreeBSD.org> Date: Sat, 31 Jan 2015 16:18:58 -0800 X-Google-Sender-Auth: hhZOz-6SAg8SO5NB8dukbbrQydo Message-ID: Subject: Re: Problems with DNSSEC -- answer in fragmented UDP doesn't work From: Kevin Oberman To: David DeSimone Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 00:18:59 -0000 On Fri, Jan 30, 2015 at 10:11 PM, David DeSimone wrote: > Kevin Oberman wrote: > > > > For ipfw you need something like "allow ip from any to me frag". If you > > want to restrict this to DNS, restrict it to dst-port 53. > > Unfortunately, UDP fragments only contain the port number in the very > first fragment. So you will not be able to forward the later fragments > based on port number. You can only see the Src/Dest IP and Protocol number > in the fragment. > > -- > David DeSimone == fox@verio.net == Network Admin > You are, of course, correct. Specifying a destination port is meaningless. If you accept any fragments, you accept all of them. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 09:55:10 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2E15989 for ; Sun, 1 Feb 2015 09:55:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA259EBE for ; Sun, 1 Feb 2015 09:55:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t119tA5Q070332 for ; Sun, 1 Feb 2015 09:55:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197059] network locks up with IPv6 udp traffic Date: Sun, 01 Feb 2015 09:55:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rwatson@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 09:55:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197059 Robert Watson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rwatson@FreeBSD.org --- Comment #2 from Robert Watson --- Some notes form an e-mail from myself to Andrey about this problem: Basically, the general rule, with respect to lock order, is that the network-stack input path can call the output path (e.g., inbound TCP segment triggers an immediate send of a TCP ACK), but you can't directly call in the other direction or you would violate the lock order. In this sort of situation, the output path needs to reinject packets via the netisr, rather than directly invoking the input path. This is how we handle, for example, routing-socket packets triggered by send events -- they are enqueued to the netisr for processing asynchronously, providing a context where transmit-pathj locks can be safely acquired. (Basically, pfctlinput() is never safe to call from the transmit path.) -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 09:56:45 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37F8CB0A for ; Sun, 1 Feb 2015 09:56:45 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD70EDE for ; Sun, 1 Feb 2015 09:56:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t119ujEI070739 for ; Sun, 1 Feb 2015 09:56:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197059] network locks up with IPv6 udp traffic Date: Sun, 01 Feb 2015 09:56:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rwatson@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 09:56:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197059 --- Comment #3 from Robert Watson --- A further note on the problem: A good question is whether the current behaviour actually makes sense: do we really need to notify all sockets of a change in MTU discovered by one socket on transmit? Or can we just let the others sockets discover the change on demand as they next try to transmit? (I don't take a strong view on the answer, except to point out that it would be simpler if, as in IPv4, we didn't try to notify all sockets of the event.) -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 12:06:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 536FFCE for ; Sun, 1 Feb 2015 12:06:27 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D9E9CCD for ; Sun, 1 Feb 2015 12:06:27 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t11C6Q0A033496 for ; Sun, 1 Feb 2015 12:06:26 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t11C6Q7P033495; Sun, 1 Feb 2015 12:06:26 GMT (envelope-from mat) Date: Sun, 1 Feb 2015 12:06:26 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Changed Subscribers] D1438: FreeBSD callout rewrite and cleanup Message-ID: X-Priority: 3 Thread-Topic: D1438: FreeBSD callout rewrite / cleanup X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: YzU3ODk0MGM0Y2E4NmE3NjY4YjJlZmFkM2UyIFTOFsI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 12:06:27 -0000 hselasky added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1438 To: hselasky, jhb, adrian, markj, emaste, sbruno, imp, lstewart, rwatson, gnn, rrs, kostikbel, delphij, neel, erj Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 14:30:13 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6364257B for ; Sun, 1 Feb 2015 14:30:13 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DE9CC01 for ; Sun, 1 Feb 2015 14:30:13 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t11EUC22036810 for ; Sun, 1 Feb 2015 14:30:12 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t11EUCeT036809; Sun, 1 Feb 2015 14:30:12 GMT (envelope-from mat) Date: Sun, 1 Feb 2015 14:30:12 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1438: FreeBSD callout rewrite and cleanup Message-ID: <23ff6bf3c52a6ab754a0d1e8a6a3b075@localhost.localdomain> X-Priority: 3 Thread-Topic: D1438: FreeBSD callout rewrite / cleanup X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: YzU3ODk0MGM0Y2E4NmE3NjY4YjJlZmFkM2UyIFTOOHQ= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 14:30:13 -0000 hselasky added a comment. The last patch also corrects the first argument for the "cpu_new_callout()" function. REVISION DETAIL https://reviews.freebsd.org/D1438 To: hselasky, jhb, adrian, markj, emaste, sbruno, imp, lstewart, rwatson, gnn, rrs, kostikbel, delphij, neel, erj Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 19:28:13 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 456E9A77 for ; Sun, 1 Feb 2015 19:28:13 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2466F9F1 for ; Sun, 1 Feb 2015 19:28:13 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t11JSDsh023014 for ; Sun, 1 Feb 2015 19:28:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 184149] [vimage] IPv6 link-local collisions on epair[n]b devices Date: Sun, 01 Feb 2015 19:28:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hrs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: hrs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 19:28:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184149 Hiroki Sato changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hrs@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |hrs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 22:23:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FC7D526 for ; Sun, 1 Feb 2015 22:23:51 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 03680D38 for ; Sun, 1 Feb 2015 22:23:51 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 016B35C002 for ; Mon, 2 Feb 2015 01:23:27 +0300 (MSK) Message-ID: <54CEA776.1040505@FreeBSD.org> Date: Mon, 02 Feb 2015 01:23:50 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Does "setfib" in ipfw forces to re-route packet? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 22:23:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "man 8 ipfw" doesn't state, that setting new fib on "out" packet (whrn routing decision is done and output interface is known) change routing decision: ""The packet is tagged so as to use the FIB (routing table) fibnum in any subsequent forwarding decisions."" But according to ip_output.c (around line 527) "setfib" FORCES to make NEW decision! Do I read sources right? Maybe, wording in ipfw(8) should be changed? - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUzqd0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePNOAQALejRnxFP9P/PO8hitto6vfj hFFQho21+gNcs67xfkX1kNmG0qmHhjV7OGcWjW6+Dm7ZBRRU2CHcWPIKPVHDBZ/t /aZNg1B4res23Q8Q2dSlAxGGeumkWESwZtfN1L8nR2TGt/ZWrBLNpc3ORgVC2hXv 6pA9cIsK4lzYFbanDgKqlbOWYubWv6gdtsfz/eOO1huX4z5b94XU3tc6a9c9WnFv E7EzxdNyPN4s9+Wcp/IABYa6VzhPIYV9BzYvJ/Tvx31CK6VPC8kxu9JFXsGaC5f4 hPiOdBqTuj78UcE1IxjDgca3G6QkmthNqQwt0B9JtlRJBT+ZhguK+RgbJAdmtPGA vmbwQJM0mCVh5Y9CSjlbV5SJRbYAKJ6SWF06C9vIDDVRWgpqO991DDRAkQgYzT2g rzps0/FT4h42FDsfvZmfMO8INqdSrosrRW69BkoXgMriWTd41Tm8n1Yhcc8Q8Fei Dy5HGlv2K25iwolnICFGEPgxARFS9HU4xsJ41Ca7GB+icgJGd2EwYYTBBDFMHCSs J3hqrDesDz+oTyFdcZZUPbktpNuVyXG1INA5AZBVR7vKuzXKRHxC/Yo/scgMeyXF iERcfnU2F7eUdO6WnWJwGzVUigXoYNrI5j1HBngBZ3gRMl3XlIIZE7jnVC50awrK HPvYMPd+LJoF4SYQcTaC =Poez -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 22:25:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A08F6A8 for ; Sun, 1 Feb 2015 22:25:59 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5D78BD51 for ; Sun, 1 Feb 2015 22:25:59 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 7D8FA5C002 for ; Mon, 2 Feb 2015 01:25:58 +0300 (MSK) Message-ID: <54CEA80D.1020701@FreeBSD.org> Date: Mon, 02 Feb 2015 01:26:21 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: dhclient + dhclient-script + "routers" DHCP option+ FIB? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 22:25:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Is it possible to add routes, passed from DHCP server, not to default FIB but to FIB specified in /etc/dhclient.conf? - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUzqgNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePi7wP/2JfQJbl0zU150B0e6WcUXuU tAtHYgeGrh7oyXWhjq5EcdR7kqVC6JOTpK9dN7zy7PxTDt1fAFEn89XUElveRFrP hvhsFn8rh9Bj/3PBrki8ICbjuT0qZ1JRIy9vwMffMTAIb+fa+0MAGWVZkZ1rO1wB 6RIQHqBx0NLhxtvEKiHQLD1gRXrIKvwlT02Z4HBPNaQzNl7tkzeZ46KI6hJPYaNt lQelwSBvI/zdaaBMftFSQvfP2EOsB3U6MV3zo9lDgBbMtkP7Cb1R411Nz0/DX67G CluoPZKnOrMMjMWLtYdzRCSvIM+W3qDtBFN0b20h7VJPMYoCAthJkp3kpdbhvS8v rT1gzm4XtuFm5hfdkIxhg8MANfxI79tPOoqgKmefELaNmJqJvMEg6gfmeblEePv9 CIIWHjCb1MiYdsDbnrdznnBSM7zSoQurs6r03dwu00HYQBeuOY2MV8Pwkfo/UFDT gbhMbzStkyJktBdl93hXdNh7Hpsg9iqihNS+P8vDlSjZF93j3kCmxmtMpuqEDGpT TPezutCjX+o7PaFXLlv1bW91bdMkNQfa7qs2kRd/1C3iqt6gaY3Cky+sBrq+EIHJ 7tPKgYTlTn1tvxcVHxfRLuSfoY+B1N+HeAGNlFVOv1GanoF9tApApVTBTJ4AOina v7uS/FXIihWqNMPIqaT4 =xJ+5 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 11:09:16 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69A266D7; Mon, 2 Feb 2015 11:09:16 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 235BD20A; Mon, 2 Feb 2015 11:09:15 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t12B9BuN032786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Feb 2015 03:09:14 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54CF5AD2.4000004@freebsd.org> Date: Mon, 02 Feb 2015 19:09:06 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: dhclient + dhclient-script + "routers" DHCP option+ FIB? References: <54CEA80D.1020701@FreeBSD.org> In-Reply-To: <54CEA80D.1020701@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 11:09:16 -0000 On 2/2/15 6:26 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > Is it possible to add routes, passed from DHCP server, not to default > FIB but to FIB specified in /etc/dhclient.conf? I don't believe so directly. There is no place to specify that information.. HOWEVER once you have done a DCHP server discovery, you could possibly make multiple requests with different identification information. It would probably mean that you should have a different alias for each FIB to request from. It might be best to make the packets appear as if they have come through a dhcp relay in some way. I think it depends on what information the dhcpd is keying on, Usually its the MAC address which is a problem. > > - -- > // Lev Serebryakov AKA Black Lion > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJUzqgNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePi7wP/2JfQJbl0zU150B0e6WcUXuU > tAtHYgeGrh7oyXWhjq5EcdR7kqVC6JOTpK9dN7zy7PxTDt1fAFEn89XUElveRFrP > hvhsFn8rh9Bj/3PBrki8ICbjuT0qZ1JRIy9vwMffMTAIb+fa+0MAGWVZkZ1rO1wB > 6RIQHqBx0NLhxtvEKiHQLD1gRXrIKvwlT02Z4HBPNaQzNl7tkzeZ46KI6hJPYaNt > lQelwSBvI/zdaaBMftFSQvfP2EOsB3U6MV3zo9lDgBbMtkP7Cb1R411Nz0/DX67G > CluoPZKnOrMMjMWLtYdzRCSvIM+W3qDtBFN0b20h7VJPMYoCAthJkp3kpdbhvS8v > rT1gzm4XtuFm5hfdkIxhg8MANfxI79tPOoqgKmefELaNmJqJvMEg6gfmeblEePv9 > CIIWHjCb1MiYdsDbnrdznnBSM7zSoQurs6r03dwu00HYQBeuOY2MV8Pwkfo/UFDT > gbhMbzStkyJktBdl93hXdNh7Hpsg9iqihNS+P8vDlSjZF93j3kCmxmtMpuqEDGpT > TPezutCjX+o7PaFXLlv1bW91bdMkNQfa7qs2kRd/1C3iqt6gaY3Cky+sBrq+EIHJ > 7tPKgYTlTn1tvxcVHxfRLuSfoY+B1N+HeAGNlFVOv1GanoF9tApApVTBTJ4AOina > v7uS/FXIihWqNMPIqaT4 > =xJ+5 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 11:42:41 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E18886FC for ; Mon, 2 Feb 2015 11:42:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8B8E8B4 for ; Mon, 2 Feb 2015 11:42:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t12Bgfax026529 for ; Mon, 2 Feb 2015 11:42:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194672] [carp] Changing advskew to 0 from another value doesn't work Date: Mon, 02 Feb 2015 11:42:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 11:42:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194672 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: loos Date: Mon Feb 2 11:42:36 UTC 2015 New revision: 278075 URL: https://svnweb.freebsd.org/changeset/base/278075 Log: MFC r276751: Remove the check that prevent carp(4) advskew to be set to '0'. CARP devices are created with advskew set to '0' and once you set it to any other value in the valid range (0..254) you can't set it back to zero. The code in question is also used to prevent that zeroed values overwrite the CARP defaults when a new CARP device is created. Since advskew already defaults to '0' for newly created devices and the new value is guaranteed to be within the valid range, it is safe to overwrite it here. PR: 194672 Reported by: cmb@pfsense.org Changes: _U stable/10/ stable/10/sys/netinet/ip_carp.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 13:23:24 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92B7BDAE; Mon, 2 Feb 2015 13:23:24 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 53BD5344; Mon, 2 Feb 2015 13:23:24 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 606C45C002; Mon, 2 Feb 2015 16:23:12 +0300 (MSK) Message-ID: <54CF7A3E.1050603@FreeBSD.org> Date: Mon, 02 Feb 2015 16:23:10 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-net@freebsd.org Subject: Re: dhclient + dhclient-script + "routers" DHCP option+ FIB? References: <54CEA80D.1020701@FreeBSD.org> <54CF5AD2.4000004@freebsd.org> In-Reply-To: <54CF5AD2.4000004@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 13:23:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02.02.2015 14:09, Julian Elischer wrote: > Is it possible to add routes, passed from DHCP server, not to > default FIB but to FIB specified in /etc/dhclient.conf? >> I don't believe so directly. There is no place to specify that >> information.. HOWEVER once you have done a DCHP server >> discovery, you could possibly make multiple requests with >> different identification information. It would probably mean >> that you should have a different alias for each FIB to request >> from. It might be best to make the packets appear as if they have >> come through a dhcp relay in some way. I think it depends on what >> information the dhcpd is keying on, Usually its the MAC address >> which is a problem. I'm asking as CLIENT administrator, not SERVER one. I need to acquire configuration information from my ISP, but apply "default route" not to default FIB. It is why I mention "/etc/dhclient.conf" :) - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz3o+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP+G8P/iSRdSxi6plLVtavDNxlz0Ay 7TAsUrzgeYON/nP7FPrvn0UgvoHq1dGvr73EWSlKXt0qQrT0zfi4z1nhPDsRMaDe oqepghoJPYzkN7z0PRmFV1UNUS/nwp8M+juAIIokAu6n9Xjib/BpMIznTai4NxWj vGr6+qS/MpjbOJaepGqu9RU+DIUBAqj+aMgs71lraUA8/2gd9+pG+GTYzOR04HN+ Vxy7Suo6mrCSRLMCxuZ6hiyTkCxRqdD1z5rF2OKLXoLUwrloTvwZxcdXRfaieNPn N/TwIWRsEMUkb805oQWRmC8F/Q6gevh5t7E14ZOUhl14IM0ffEeAh6U1vqvxzaJQ 5I1qcI1jVB+19kyfnHQ2WNZHaHdPi/sAOTO0/+VXaaJs/LMNiefRTIBHydHwkrnz SAMa30kbeUocoRXC6I5EZv5xofZsLOOCqayL5REJY/0fE4K3M8HAhOlIWV2f0N5g SYwy2o0LH3uRvaQy3sWm9QD5awWRetJIqslqId+SaCUKcjBEjHTtk7TByge8cYgA Uum52yz+1sUN+NpGLh/zjkDr8v3YJiHIimElY4wWKhD0PiuhLMxDc/bBci7VLPHj 24zc+I8u9eMlsaFo/6kGIgAKfFEYMHrPFNGHdNHe0/MlOZXE8id2ffXX+bR7IB9o t5YDiQU3vKD/huC8z7uv =SP0G -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 15:21:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C35E4661; Mon, 2 Feb 2015 15:21:45 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D58926A; Mon, 2 Feb 2015 15:21:45 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id r20so15842322wiv.4; Mon, 02 Feb 2015 07:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CMofHEkS0Ufuwyo55mClY+bw3dhtWno5E2D/FWOl8rg=; b=KfNiddP5hsAI1ja27jDko38DhCX7iw5FgZAyorRVYeXAl6UNyhx6pdoltVCo4kiUtA bAEQczEO+inI86HPsVa9jgRU9Dliw7kGwn4/37IkdGoZDClksjAJfo5uNyKU2u3Gjpu5 orJw1o+NBEQ64cyUfJZWZh5L8cQRKDFvAAMmQnMgTwmogVcFaJTMjWDah8i4dxhQrFIm DvqjZnr31v5g3T3ADvcr3sYmZazN385sUazd6JfJLiLdCwjWfFRcQinK4E763gylx7uP eZyCPr2fz8FYICLWLNVk73GkWXZoa7Nid5WwuhfmMglg8VFremBdF46RJHgToWu7wNok 7roA== MIME-Version: 1.0 X-Received: by 10.180.20.226 with SMTP id q2mr26078064wie.28.1422890503602; Mon, 02 Feb 2015 07:21:43 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.27.32.77 with HTTP; Mon, 2 Feb 2015 07:21:43 -0800 (PST) In-Reply-To: <54CF7A3E.1050603@FreeBSD.org> References: <54CEA80D.1020701@FreeBSD.org> <54CF5AD2.4000004@freebsd.org> <54CF7A3E.1050603@FreeBSD.org> Date: Mon, 2 Feb 2015 16:21:43 +0100 X-Google-Sender-Auth: pA8OtItEUgtiO0Exj-rRlKrzOXQ Message-ID: Subject: Re: dhclient + dhclient-script + "routers" DHCP option+ FIB? From: Nikolay Denev To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 15:21:45 -0000 On Mon, Feb 2, 2015 at 2:23 PM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02.02.2015 14:09, Julian Elischer wrote: > > > Is it possible to add routes, passed from DHCP server, not to > > default FIB but to FIB specified in /etc/dhclient.conf? > >> I don't believe so directly. There is no place to specify that > >> information.. HOWEVER once you have done a DCHP server > >> discovery, you could possibly make multiple requests with > >> different identification information. It would probably mean > >> that you should have a different alias for each FIB to request > >> from. It might be best to make the packets appear as if they have > >> come through a dhcp relay in some way. I think it depends on what > >> information the dhcpd is keying on, Usually its the MAC address > >> which is a problem. > I'm asking as CLIENT administrator, not SERVER one. I need to acquire > configuration information from my ISP, but apply "default route" not > to default FIB. It is why I mention "/etc/dhclient.conf" :) > > - -- > // Lev Serebryakov > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJUz3o+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP+G8P/iSRdSxi6plLVtavDNxlz0Ay > 7TAsUrzgeYON/nP7FPrvn0UgvoHq1dGvr73EWSlKXt0qQrT0zfi4z1nhPDsRMaDe > oqepghoJPYzkN7z0PRmFV1UNUS/nwp8M+juAIIokAu6n9Xjib/BpMIznTai4NxWj > vGr6+qS/MpjbOJaepGqu9RU+DIUBAqj+aMgs71lraUA8/2gd9+pG+GTYzOR04HN+ > Vxy7Suo6mrCSRLMCxuZ6hiyTkCxRqdD1z5rF2OKLXoLUwrloTvwZxcdXRfaieNPn > N/TwIWRsEMUkb805oQWRmC8F/Q6gevh5t7E14ZOUhl14IM0ffEeAh6U1vqvxzaJQ > 5I1qcI1jVB+19kyfnHQ2WNZHaHdPi/sAOTO0/+VXaaJs/LMNiefRTIBHydHwkrnz > SAMa30kbeUocoRXC6I5EZv5xofZsLOOCqayL5REJY/0fE4K3M8HAhOlIWV2f0N5g > SYwy2o0LH3uRvaQy3sWm9QD5awWRetJIqslqId+SaCUKcjBEjHTtk7TByge8cYgA > Uum52yz+1sUN+NpGLh/zjkDr8v3YJiHIimElY4wWKhD0PiuhLMxDc/bBci7VLPHj > 24zc+I8u9eMlsaFo/6kGIgAKfFEYMHrPFNGHdNHe0/MlOZXE8id2ffXX+bR7IB9o > t5YDiQU3vKD/huC8z7uv > =SP0G > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Would starting dhclient in non default FIB work? e.g. setfib 1 dhclient $EXT_IF --Nikolay From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 15:45:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17284C6A; Mon, 2 Feb 2015 15:45:06 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C4FF374A; Mon, 2 Feb 2015 15:45:05 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t12Fj0Np033912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Feb 2015 07:45:02 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54CF9B76.80508@freebsd.org> Date: Mon, 02 Feb 2015 23:44:54 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: dhclient + dhclient-script + "routers" DHCP option+ FIB? References: <54CEA80D.1020701@FreeBSD.org> <54CF5AD2.4000004@freebsd.org> <54CF7A3E.1050603@FreeBSD.org> In-Reply-To: <54CF7A3E.1050603@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 15:45:06 -0000 On 2/2/15 9:23 PM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02.02.2015 14:09, Julian Elischer wrote: > >> Is it possible to add routes, passed from DHCP server, not to >> default FIB but to FIB specified in /etc/dhclient.conf? >>> I don't believe so directly. There is no place to specify that >>> information.. HOWEVER once you have done a DCHP server >>> discovery, you could possibly make multiple requests with >>> different identification information. It would probably mean >>> that you should have a different alias for each FIB to request >>> from. It might be best to make the packets appear as if they have >>> come through a dhcp relay in some way. I think it depends on what >>> information the dhcpd is keying on, Usually its the MAC address >>> which is a problem. > I'm asking as CLIENT administrator, not SERVER one. I need to acquire > configuration information from my ISP, but apply "default route" not > to default FIB. It is why I mention "/etc/dhclient.conf" :) the client runs a script after getting the lease you can put whatever you want in there. /sbin/dhclient-script it also looks for and runs /etc/dhclient-enter-hooks and /etc/dhclient-exit-hooks and you can put whatever you want in there as well. check the man pages for some details julian@vps1:man -k dhclient dhclient(8) - Dynamic Host Configuration Protocol (DHCP) client dhclient-script(8) - DHCP client network configuration script dhclient.conf(5) - DHCP client configuration file dhclient.leases(5) - DHCP client lease database > > - -- > // Lev Serebryakov > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJUz3o+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP+G8P/iSRdSxi6plLVtavDNxlz0Ay > 7TAsUrzgeYON/nP7FPrvn0UgvoHq1dGvr73EWSlKXt0qQrT0zfi4z1nhPDsRMaDe > oqepghoJPYzkN7z0PRmFV1UNUS/nwp8M+juAIIokAu6n9Xjib/BpMIznTai4NxWj > vGr6+qS/MpjbOJaepGqu9RU+DIUBAqj+aMgs71lraUA8/2gd9+pG+GTYzOR04HN+ > Vxy7Suo6mrCSRLMCxuZ6hiyTkCxRqdD1z5rF2OKLXoLUwrloTvwZxcdXRfaieNPn > N/TwIWRsEMUkb805oQWRmC8F/Q6gevh5t7E14ZOUhl14IM0ffEeAh6U1vqvxzaJQ > 5I1qcI1jVB+19kyfnHQ2WNZHaHdPi/sAOTO0/+VXaaJs/LMNiefRTIBHydHwkrnz > SAMa30kbeUocoRXC6I5EZv5xofZsLOOCqayL5REJY/0fE4K3M8HAhOlIWV2f0N5g > SYwy2o0LH3uRvaQy3sWm9QD5awWRetJIqslqId+SaCUKcjBEjHTtk7TByge8cYgA > Uum52yz+1sUN+NpGLh/zjkDr8v3YJiHIimElY4wWKhD0PiuhLMxDc/bBci7VLPHj > 24zc+I8u9eMlsaFo/6kGIgAKfFEYMHrPFNGHdNHe0/MlOZXE8id2ffXX+bR7IB9o > t5YDiQU3vKD/huC8z7uv > =SP0G > -----END PGP SIGNATURE----- > > From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 16:42:49 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDF31386 for ; Mon, 2 Feb 2015 16:42:49 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 9532BE73 for ; Mon, 2 Feb 2015 16:42:49 +0000 (UTC) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 02 Feb 2015 08:38:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="448763102" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by FMSMGA003.fm.intel.com with ESMTP; 02 Feb 2015 08:28:03 -0800 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 2 Feb 2015 08:42:07 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.11.110]) by ORSMSX158.amr.corp.intel.com ([169.254.10.150]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 08:42:07 -0800 From: "Pieper, Jeffrey E" To: Jack Vogel , hiren panchasara Subject: RE: Intel 82574L (em) Thread-Topic: Intel 82574L (em) Thread-Index: AQHQPNFkP3MptScjxEq0dTQWShT445zZ7wMAgAA6nwCAA2nSEA== Date: Mon, 2 Feb 2015 16:42:06 +0000 Message-ID: <2A35EA60C3C77D438915767F458D6568806C25DE@ORSMSX111.amr.corp.intel.com> References: <54CBF396.3090903@ignoranthack.me> <20150131010014.GB19333@strugglingcoder.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 16:42:49 -0000 Iirc, we experienced issues with 82574L, where the interface will hang/die.= This is resolved in both FreeBSD and Linux by forcing ASPM off and disabli= ng MSIX. Jeff ----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Jack Vogel Sent: Friday, January 30, 2015 8:30 PM To: hiren panchasara Cc: FreeBSD Net Subject: Re: Intel 82574L (em) Yup, I wrote that :) Sean, I will check around to see if anything may have changed in that regard. Jack On Fri, Jan 30, 2015 at 5:00 PM, hiren panchasara < hiren@strugglingcoder.info> wrote: > On Fri, Jan 30, 2015 at 01:11:50PM -0800, Sean Bruno wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > > http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-data= sheet.pdf > > > > According to 7.1.11, this device does indeed have 2 queues for stuff an= d > > or things. So, basic RSS would be possible in something like an Atom > box. > > > > I note that the em(4) driver intentionally disables this on > > initialization. I'm up for some science on my new shiny, soon to be > > router box. Any reason not to default to 1 queue and allow loader.conf > > to raise it to 2? > > Intel folks know better but it seems this is hartwell. > > em_setup_msix() in very start says: > > /* > ** Setup MSI/X for Hartwell: tests have shown > ** use of two queues to be unstable, and to > ** provide no great gain anyway, so we simply > ** seperate the interrupts and use a single queue. > */ > > Things may have changed now. I guess you can try enabling it and find out > :-) > > cheers, > Hiren > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 17:23:15 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10684F05 for ; Mon, 2 Feb 2015 17:23:15 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C36573FA for ; Mon, 2 Feb 2015 17:23:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t12HNESk038421 for ; Mon, 2 Feb 2015 17:23:14 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t12HNEXp038420; Mon, 2 Feb 2015 17:23:14 GMT (envelope-from mat) Date: Mon, 2 Feb 2015 17:23:14 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Updated, 239 lines] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTPsoI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 17:23:15 -0000 rrs updated this revision to Diff 3591. rrs added a comment. This revision now requires review to proceed. Ok I have stripped out the kernel test framework and moved this to D1755.. jhb, you are a reviewer there as well ;-) This boils things down to *just* the fixes to the callout. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1711?vs=3503&id=3591 REVISION DETAIL https://reviews.freebsd.org/D1711 AFFECTED FILES sys/kern/kern_timeout.c sys/sys/callout.h To: rrs, gnn, rwatson, adrian, sbruno, lstewart, hselasky, imp Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 17:25:50 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37939FDB for ; Mon, 2 Feb 2015 17:25:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA479604 for ; Mon, 2 Feb 2015 17:25:49 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t12HPnED040854 for ; Mon, 2 Feb 2015 17:25:49 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t12HPnP4040853; Mon, 2 Feb 2015 17:25:49 GMT (envelope-from mat) Date: Mon, 2 Feb 2015 17:25:49 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTPsx0= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 17:25:50 -0000 adrian accepted this revision. adrian added a comment. This revision is now accepted and ready to land. My only request here is that you commit the mechanical changes separate to the migration fixes. That way it's very clear what's supposed to be fixing the bug and what's improving the readability/consistency of the code. Other than that, great work on nailing this down. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, hselasky, imp, adrian Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 17:27:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70FD41A0 for ; Mon, 2 Feb 2015 17:27:44 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C269635 for ; Mon, 2 Feb 2015 17:27:43 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 22D911941DD; Mon, 2 Feb 2015 17:27:43 +0000 (UTC) Message-ID: <54CFB38E.1040408@ignoranthack.me> Date: Mon, 02 Feb 2015 09:27:42 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Pieper, Jeffrey E" , Jack Vogel , hiren panchasara Subject: Re: Intel 82574L (em) References: <54CBF396.3090903@ignoranthack.me> <20150131010014.GB19333@strugglingcoder.info> <2A35EA60C3C77D438915767F458D6568806C25DE@ORSMSX111.amr.corp.intel.com> In-Reply-To: <2A35EA60C3C77D438915767F458D6568806C25DE@ORSMSX111.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 17:27:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/02/15 08:42, Pieper, Jeffrey E wrote: > Iirc, we experienced issues with 82574L, where the interface will > hang/die. This is resolved in both FreeBSD and Linux by forcing > ASPM off and disabling MSIX. > > Jeff > > Are you running tests with the multi-queue implementation in the h/w and driver turned on? sean > ----Original Message----- From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jack Vogel > Sent: Friday, January 30, 2015 8:30 PM To: hiren panchasara Cc: > FreeBSD Net Subject: Re: Intel 82574L (em) > > Yup, I wrote that :) > > Sean, I will check around to see if anything may have changed in > that regard. > > Jack > > > On Fri, Jan 30, 2015 at 5:00 PM, hiren panchasara < > hiren@strugglingcoder.info> wrote: > >> On Fri, Jan 30, 2015 at 01:11:50PM -0800, Sean Bruno wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >>> >>> >> http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf >>> >>> >> According to 7.1.11, this device does indeed have 2 queues for stuff and >>> or things. So, basic RSS would be possible in something like >>> an Atom >> box. >>> >>> I note that the em(4) driver intentionally disables this on >>> initialization. I'm up for some science on my new shiny, soon >>> to be router box. Any reason not to default to 1 queue and >>> allow loader.conf to raise it to 2? >> >> Intel folks know better but it seems this is hartwell. >> >> em_setup_msix() in very start says: >> >> /* ** Setup MSI/X for Hartwell: tests have shown ** use of two >> queues to be unstable, and to ** provide no great gain anyway, so >> we simply ** seperate the interrupts and use a single queue. */ >> >> Things may have changed now. I guess you can try enabling it and >> find out :-) >> >> cheers, Hiren >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net To > unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net To > unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUz7OLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kYn0IALVCtNNmWMWIRLlbcVGDg9wo KUbKpvN4UBxOuAvsav8Hussxvy+gh4UXZvgqZ2opTElRrPiUb/iGXa967LWsRaTB TrbvnFE7rJp2xGVlG+rsID+wSdsEAX/isTJWOvpWIqPEULaFvtFh/LUPUrux51Ca SPNzJ+LAh/vWk4sOXN+4PxICiaprlRDs0HF/Mqh5mh8W5TwE3OZy74js7izhNqZS NgowzDyYOq6uhxHZRAC5/GUdpX+ybyCRFZgqKBrNy8BYZV9f+wts2vh7IzwDBSE+ 0ikcM2QGunsr9HH2mnermE2lYF4QKL1Zm8m0mh+TNNIA1O/8Qi4mbE1uMdrzJv4= =9wHn -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 17:36:02 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8ADE771E; Mon, 2 Feb 2015 17:36:02 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 5A7D17B9; Mon, 2 Feb 2015 17:36:02 +0000 (UTC) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 02 Feb 2015 09:32:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,507,1418112000"; d="scan'208";a="521423158" Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by orsmga003.jf.intel.com with ESMTP; 02 Feb 2015 09:28:29 -0800 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 2 Feb 2015 09:35:59 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.11.110]) by ORSMSX157.amr.corp.intel.com ([169.254.9.139]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 09:35:59 -0800 From: "Pieper, Jeffrey E" To: "sbruno@freebsd.org" , Jack Vogel , hiren panchasara Subject: RE: Intel 82574L (em) Thread-Topic: Intel 82574L (em) Thread-Index: AQHQPNFkP3MptScjxEq0dTQWShT445zZ7wMAgAA6nwCAA2nSEIAAlB4A//96LpA= Date: Mon, 2 Feb 2015 17:35:58 +0000 Message-ID: <2A35EA60C3C77D438915767F458D6568806C268D@ORSMSX111.amr.corp.intel.com> References: <54CBF396.3090903@ignoranthack.me> <20150131010014.GB19333@strugglingcoder.info> <2A35EA60C3C77D438915767F458D6568806C25DE@ORSMSX111.amr.corp.intel.com> <54CFB38E.1040408@ignoranthack.me> In-Reply-To: <54CFB38E.1040408@ignoranthack.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 17:36:02 -0000 In the past we have, yes. This was a few years ago, but iirc the current im= plementation is supposed to be the official solution. Jeff -----Original Message----- From: Sean Bruno [mailto:sbruno@ignoranthack.me]=20 Sent: Monday, February 02, 2015 9:28 AM To: Pieper, Jeffrey E; Jack Vogel; hiren panchasara Cc: FreeBSD Net Subject: Re: Intel 82574L (em) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/02/15 08:42, Pieper, Jeffrey E wrote: > Iirc, we experienced issues with 82574L, where the interface will > hang/die. This is resolved in both FreeBSD and Linux by forcing > ASPM off and disabling MSIX. >=20 > Jeff >=20 >=20 Are you running tests with the multi-queue implementation in the h/w and driver turned on? sean > ----Original Message----- From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jack Vogel=20 > Sent: Friday, January 30, 2015 8:30 PM To: hiren panchasara Cc: > FreeBSD Net Subject: Re: Intel 82574L (em) >=20 > Yup, I wrote that :) >=20 > Sean, I will check around to see if anything may have changed in > that regard. >=20 > Jack >=20 >=20 > On Fri, Jan 30, 2015 at 5:00 PM, hiren panchasara <=20 > hiren@strugglingcoder.info> wrote: >=20 >> On Fri, Jan 30, 2015 at 01:11:50PM -0800, Sean Bruno wrote: >>>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >>>=20 >>>=20 >> http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-dat= asheet.pdf >>> >>> >>=20 According to 7.1.11, this device does indeed have 2 queues for stuff and >>> or things. So, basic RSS would be possible in something like >>> an Atom >> box. >>>=20 >>> I note that the em(4) driver intentionally disables this on=20 >>> initialization. I'm up for some science on my new shiny, soon >>> to be router box. Any reason not to default to 1 queue and >>> allow loader.conf to raise it to 2? >>=20 >> Intel folks know better but it seems this is hartwell. >>=20 >> em_setup_msix() in very start says: >>=20 >> /* ** Setup MSI/X for Hartwell: tests have shown ** use of two >> queues to be unstable, and to ** provide no great gain anyway, so >> we simply ** seperate the interrupts and use a single queue. */ >>=20 >> Things may have changed now. I guess you can try enabling it and >> find out :-) >>=20 >> cheers, Hiren >>=20 > _______________________________________________=20 > freebsd-net@freebsd.org mailing list=20 > http://lists.freebsd.org/mailman/listinfo/freebsd-net To > unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org"=20 > _______________________________________________=20 > freebsd-net@freebsd.org mailing list=20 > http://lists.freebsd.org/mailman/listinfo/freebsd-net To > unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" >=20 >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUz7OLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kYn0IALVCtNNmWMWIRLlbcVGDg9wo KUbKpvN4UBxOuAvsav8Hussxvy+gh4UXZvgqZ2opTElRrPiUb/iGXa967LWsRaTB TrbvnFE7rJp2xGVlG+rsID+wSdsEAX/isTJWOvpWIqPEULaFvtFh/LUPUrux51Ca SPNzJ+LAh/vWk4sOXN+4PxICiaprlRDs0HF/Mqh5mh8W5TwE3OZy74js7izhNqZS NgowzDyYOq6uhxHZRAC5/GUdpX+ybyCRFZgqKBrNy8BYZV9f+wts2vh7IzwDBSE+ 0ikcM2QGunsr9HH2mnermE2lYF4QKL1Zm8m0mh+TNNIA1O/8Qi4mbE1uMdrzJv4=3D =3D9wHn -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 17:37:09 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13818823 for ; Mon, 2 Feb 2015 17:37:09 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD2277DE for ; Mon, 2 Feb 2015 17:37:08 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t12Hb80J053069 for ; Mon, 2 Feb 2015 17:37:08 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t12Hb8G5053068; Mon, 2 Feb 2015 17:37:08 GMT (envelope-from mat) Date: Mon, 2 Feb 2015 17:37:08 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTPtcQ= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 17:37:09 -0000 hselasky accepted this revision. hselasky added a comment. Looks good. There are some non-related changes still, like the definition of access macros to improve readability. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, imp, adrian, hselasky Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 18:32:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F16F6CCA for ; Mon, 2 Feb 2015 18:32:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8822EDD for ; Mon, 2 Feb 2015 18:32:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t12IWxdo013996 for ; Mon, 2 Feb 2015 18:32:59 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t12IWxdt013995; Mon, 2 Feb 2015 18:32:59 GMT (envelope-from mat) Date: Mon, 2 Feb 2015 18:32:59 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Updated] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTPwts= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 18:33:00 -0000 rrs added reviewers: jhb, kostikbel. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, imp, hselasky, adrian, jhb, kostikbel Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 18:35:31 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B0B9E75 for ; Mon, 2 Feb 2015 18:35:31 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5F57F0A for ; Mon, 2 Feb 2015 18:35:30 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t12IZURN016162 for ; Mon, 2 Feb 2015 18:35:30 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t12IZUXk016161; Mon, 2 Feb 2015 18:35:30 GMT (envelope-from mat) Date: Mon, 2 Feb 2015 18:35:30 +0000 To: freebsd-net@freebsd.org From: "kostikbel (Konstantin Belousov)" Subject: [Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <0a5fb8d8e545c5947117de2d5f72961e@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTPw3I= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 18:35:31 -0000 kostikbel accepted this revision. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, imp, hselasky, adrian, jhb, kostikbel Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 18:58:20 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CD2C93B for ; Mon, 2 Feb 2015 18:58:20 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A97C207 for ; Mon, 2 Feb 2015 18:58:20 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t12IwJPH042011 for ; Mon, 2 Feb 2015 18:58:19 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t12IwJgm042004; Mon, 2 Feb 2015 18:58:19 GMT (envelope-from mat) Date: Mon, 2 Feb 2015 18:58:19 +0000 To: freebsd-net@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <74aef0753edc0732cefae0f14cd8fd28@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTPyMs= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 18:58:20 -0000 emaste added a comment. For future diffs, please generate with full context, e.g. -U999999 INLINE COMMENTS sys/kern/kern_timeout.c:789 added EOL whitespace? sys/kern/kern_timeout.c:1067-1069 I'm a bit confused by this sentence. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, imp, hselasky, adrian, jhb, kostikbel Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 19:17:38 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47C7724F; Mon, 2 Feb 2015 19:17:38 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id DA68665B; Mon, 2 Feb 2015 19:17:37 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EDCAE5C002; Mon, 2 Feb 2015 22:17:26 +0300 (MSK) Message-ID: <54CFCD45.9070304@FreeBSD.org> Date: Mon, 02 Feb 2015 22:17:25 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw , freebsd-net Subject: [RFC][patch] Two new actions: state-allow and state-deny Content-Type: multipart/mixed; boundary="------------040906070105090005040205" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 19:17:38 -0000 This is a multi-part message in MIME format. --------------040906070105090005040205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Now to make stateful firewall with NAT you need to make some not very "readable" tricks to record state ("allow") of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs add 1000 skipto 2000 all from any to any out xmit outIface add 1010 skipto 3000 all from any to any in recv outIface add 2000 skipto 2010 from any to any keep-state add 2010 nat NR from any to any out // Note this "out" in out section! add 2020 allow all from any to any add 3000 nat NR from any to any add 3010 check-state // Use dynamic rule based on 2000 (b) Adding "allow keep-state" to _IN_ rules on _internal_ interfaces to check this states AFTER _IN_ nat on _external_ interfaces. I don't like both of them. First one is not very clear and needs additional "out" option on outbound NAT rule. Second one requires to have "allow keep-state" and "check-state" rules in different parts of firewall, on different interfaces, which is not very clear too and needs additional conditions for "allow keep-state" if you don't want stateful firewall for internal networks and only want states for external traffic. I propose two new actions: state-allow and state-deny. They imply "keep-state" and create new dynamic rules, when called directly, but pass packet to NEXT rule after that (don't stop search). When they are called as dynamic rule, they acts as "allow" and "deny". So, stateful firewall with NAT could be rewritten like this: add 1000 skipto 2000 all from any to any out xmit outIface add 1010 skipto 3000 all from any to any in recv outIface add 2000 state-allow from any to any // keep-state is implied add 2010 nat NR from any to any // No "out" here! add 2020 allow all from any to any add 3000 nat NR from any to any add 3010 check-state // Use dynamic rule based on 2000 as "allow" here What do you think? - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz81EXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePkhwQAJg4s1Ipomi0lZTqa8pklExD GHvkeuVdm1RSakolwHf8M26a+Xg1zlIm0tD2PQ18FkaA1QTjwai7kyKu2SwhsvkF P7B3GE33Pj4dhMzhpnmSnxcjLZEAENENzAOnGBN47NM617KOkJmyRmH54RO8xFI8 UbctlfiWC0ECujlWC4HcLthlrI3ZemqeFK1llzQ+k0LgUDQ8eegFmrLCbMVbVKxJ 4HACPQzzPwzabZE+kifE1KDnOEthEuTXuMpL6pS98s8w+b92TFJsS40DqngWNuqv M2QCCJbLZRwoDRTkf3H8AlbdIk94CPFjJkmZd86ZUpKF3rVJ7VICH7SkV90P1hlm yRc/26jX2LvqyyKgxMDQ4UpJuSikxASHx/3mDOV83snxlXtwW0or6f+XSW1QVFFt 2OCo6DmwclQ2HzBaomy0QKqlKq09VzHJdEBtfsyBqKyQP2UG3/CDj6rwqc564rOb MDJFDtsMsquOgJTBSYLcAQhc8v9I3HUuELT/eyo3YCCrPKAAPtV89jWZ2dI+np3h utaVJxJ4qSyVp5R3H2MTvWdk1PPptygxx0UHMVyNTgSnsbczNsywWzELoOzTzEZn XS352D2dWXsvFV07cwtHovnY+vCKOXVI2ljJ6uHwZZlisJg4M+o80LChHT5jQ6nw 9DVWmu2YK6nC7aJI6Fy7 =TMJo -----END PGP SIGNATURE----- --------------040906070105090005040205 Content-Type: text/plain; charset=windows-1251; name="ipfw-state-actions.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-actions.diff" SW5kZXg6IHNiaW4vaXBmdy9pcGZ3LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncuOAkocmV2aXNpb24gMjc4MDIxKQorKysgc2Jpbi9pcGZ3L2lwZncuOAkod29ya2luZyBj b3B5KQpAQCAtOTMyLDYgKzkzMiwyNiBAQAogLkVkCiAuUHAKIFRoaXMgY29zbWV0aWMgYW5u b3lhbmNlIG1heSBiZSBmaXhlZCBpbiBmdXR1cmUgcmVsZWFzZXMuCisuSXQgQ20gc3RhdGUt YWxsb3cKK0NyZWF0ZSBkeW5hbWljIHJ1bGUgd2hpY2ggYWN0cyBhcworLkNtIGFsbG93City dWxlIHdoZW4gY2hlY2tlZCB3aXRoCisuQ20gY2hlY2stc3RhdGUKK2FjdGlvbi4KK1doZW4g dGhpcyBhY3Rpb24gaXMgdGFrZW4gZGlyZWN0bHksIHNlYXJjaCBjb250aW51ZXMgd2l0aCB0 aGUgbmV4dCBydWxlLgorVGhpcyBhY3Rpb24gaW1wbGllcworLkNtIGtlZXAtc3RhdGUKK2lu c3RydWN0aW9uLgorLkl0IENtIHN0YXRlLWRlbnkKK0NyZWF0ZSBkeW5hbWljIHJ1bGUgd2hp Y2ggYWN0cyBhcworLkNtIGRlbnkKK3J1bGUgd2hlbiBjaGVja2VkIHdpdGgKKy5DbSBjaGVj ay1zdGF0ZQorYWN0aW9uLgorV2hlbiB0aGlzIGFjdGlvbiBpcyB0YWtlbiBkaXJlY3RseSwg c2VhcmNoIGNvbnRpbnVlcyB3aXRoIHRoZSBuZXh0IHJ1bGUuCitUaGlzIGFjdGlvbiBpbXBs aWVzCisuQ20ga2VlcC1zdGF0ZQoraW5zdHJ1Y3Rpb24uCiAuSXQgQ20gdGVlIEFyIHBvcnQK IFNlbmQgYSBjb3B5IG9mIHBhY2tldHMgbWF0Y2hpbmcgdGhpcyBydWxlIHRvIHRoZQogLlhy IGRpdmVydCA0CkluZGV4OiBzYmluL2lwZncvaXBmdzIuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz YmluL2lwZncvaXBmdzIuYwkocmV2aXNpb24gMjc4MDIxKQorKysgc2Jpbi9pcGZ3L2lwZncy LmMJKHdvcmtpbmcgY29weSkKQEAgLTI2NCw2ICsyNjQsMTIgQEAKIAl7ICJzZXRkc2NwIiwJ CVRPS19TRVREU0NQIH0sCiAJeyAiY2FsbCIsCQlUT0tfQ0FMTCB9LAogCXsgInJldHVybiIs CQlUT0tfUkVUVVJOIH0sCisJeyAic3RhdGUtYWNjZXB0IiwJVE9LX1NUQVRFX0FDQ0VQVCB9 LAorCXsgInN0YXRlLXBhc3MiLAkJVE9LX1NUQVRFX0FDQ0VQVCB9LAorCXsgInN0YXRlLWFs bG93IiwJVE9LX1NUQVRFX0FDQ0VQVCB9LAorCXsgInN0YXRlLXBlcm1pdCIsCVRPS19TVEFU RV9BQ0NFUFQgfSwKKwl7ICJzdGF0ZS1kZW55IiwJCVRPS19TVEFURV9ERU5ZIH0sCisJeyAi c3RhdGUtZHJvcCIsCQlUT0tfU1RBVEVfREVOWSB9LAogCXsgTlVMTCwgMCB9CS8qIHRlcm1p bmF0b3IgKi8KIH07CiAKQEAgLTE1ODQsNiArMTU5MCwxNCBAQAogCQkJCWJwcmludF91aW50 X2FyZyhicCwgImNhbGwgIiwgY21kLT5hcmcxKTsKIAkJCWJyZWFrOwogCisJCWNhc2UgT19T VEFURV9BQ0NFUFQ6CisJCQlicHJpbnRmKGJwLCAic3RhdGUtYWxsb3ciKTsKKwkJCWJyZWFr OworCisJCWNhc2UgT19TVEFURV9ERU5ZOgorCQkJYnByaW50ZihicCwgInN0YXRlLWRlbnki KTsKKwkJCWJyZWFrOworCiAJCWRlZmF1bHQ6CiAJCQlicHJpbnRmKGJwLCAiKiogdW5yZWNv Z25pemVkIGFjdGlvbiAlZCBsZW4gJWQgIiwKIAkJCQljbWQtPm9wY29kZSwgY21kLT5sZW4p OwpAQCAtMzgwNyw2ICszODIxLDE2IEBACiAJCWZpbGxfY21kKGFjdGlvbiwgT19DQUxMUkVU VVJOLCBGX05PVCwgMCk7CiAJCWJyZWFrOwogCisJY2FzZSBUT0tfU1RBVEVfQUNDRVBUOgor CQloYXZlX3N0YXRlID0gYWN0aW9uOworCQlhY3Rpb24tPm9wY29kZSA9IE9fU1RBVEVfQUND RVBUOworCQlicmVhazsKKworCWNhc2UgVE9LX1NUQVRFX0RFTlk6CisJCWhhdmVfc3RhdGUg PSBhY3Rpb247CisJCWFjdGlvbi0+b3Bjb2RlID0gT19TVEFURV9ERU5ZOworCQlicmVhazsK KwogCWRlZmF1bHQ6CiAJCWVycngoRVhfREFUQUVSUiwgImludmFsaWQgYWN0aW9uICVzXG4i LCBhdlstMV0pOwogCX0KQEAgLTM4OTgsNyArMzkyMiw3IEBACiAJCWNtZCA9IG5leHRfY21k KGNtZCwgJmNibGVuKTsKIAl9CiAKLQlpZiAoaGF2ZV9zdGF0ZSkJLyogbXVzdCBiZSBhIGNo ZWNrLXN0YXRlLCB3ZSBhcmUgZG9uZSAqLworCWlmIChoYXZlX3N0YXRlICYmIGhhdmVfc3Rh dGUtPm9wY29kZSA9PSBUT0tfQ0hFQ0tTVEFURSkJLyogY2hlY2stc3RhdGUsIHdlIGFyZSBk b25lICovCiAJCWdvdG8gZG9uZTsKIAogI2RlZmluZSBPUl9TVEFSVCh0YXJnZXQpCQkJCQlc CkBAIC00NTgwLDcgKzQ2MDQsOSBAQAogCS8qCiAJICogZ2VuZXJhdGUgT19QUk9CRV9TVEFU RSBpZiBuZWNlc3NhcnkKIAkgKi8KLQlpZiAoaGF2ZV9zdGF0ZSAmJiBoYXZlX3N0YXRlLT5v cGNvZGUgIT0gT19DSEVDS19TVEFURSkgeworCWlmIChoYXZlX3N0YXRlICYmIGhhdmVfc3Rh dGUtPm9wY29kZSAhPSBPX0NIRUNLX1NUQVRFICYmCisJICAgIGhhdmVfc3RhdGUtPm9wY29k ZSAhPSBPX1NUQVRFX0FDQ0VQVCAmJgorCSAgICBoYXZlX3N0YXRlLT5vcGNvZGUgIT0gT19T VEFURV9ERU5ZKSB7CiAJCWZpbGxfY21kKGRzdCwgT19QUk9CRV9TVEFURSwgMCwgMCk7CiAJ CWRzdCA9IG5leHRfY21kKGRzdCwgJnJibGVuKTsKIAl9CkBAIC00NjA2LDcgKzQ2MzIsOSBA QAogCS8qCiAJICogcHV0IGJhY2sgdGhlIGhhdmVfc3RhdGUgY29tbWFuZCBhcyBsYXN0IG9w Y29kZQogCSAqLwotCWlmIChoYXZlX3N0YXRlICYmIGhhdmVfc3RhdGUtPm9wY29kZSAhPSBP X0NIRUNLX1NUQVRFKSB7CisJaWYgKGhhdmVfc3RhdGUgJiYgaGF2ZV9zdGF0ZS0+b3Bjb2Rl ICE9IE9fQ0hFQ0tfU1RBVEUgJiYKKwkgICAgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fU1RB VEVfQUNDRVBUICYmCisJICAgIGhhdmVfc3RhdGUtPm9wY29kZSAhPSBPX1NUQVRFX0RFTlkp IHsKIAkJaSA9IEZfTEVOKGhhdmVfc3RhdGUpOwogCQlDSEVDS19SQlVGTEVOKGkpOwogCQli Y29weShoYXZlX3N0YXRlLCBkc3QsIGkgKiBzaXplb2YodWludDMyX3QpKTsKSW5kZXg6IHNi aW4vaXBmdy9pcGZ3Mi5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vaXBmdy9pcGZ3Mi5oCShy ZXZpc2lvbiAyNzgwMjEpCisrKyBzYmluL2lwZncvaXBmdzIuaAkod29ya2luZyBjb3B5KQpA QCAtMTAzLDYgKzEwMyw4IEBACiAJVE9LX1JFQVNTLAogCVRPS19DQUxMLAogCVRPS19SRVRV Uk4sCisJVE9LX1NUQVRFX0FDQ0VQVCwKKwlUT0tfU1RBVEVfREVOWSwKIAogCVRPS19BTFRR LAogCVRPS19MT0csCkluZGV4OiBzeXMvbmV0aW5ldC9pcF9mdy5oCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHN5cy9uZXRpbmV0L2lwX2Z3LmgJKHJldmlzaW9uIDI3ODAyMSkKKysrIHN5cy9uZXRp bmV0L2lwX2Z3LmgJKHdvcmtpbmcgY29weSkKQEAgLTI1Myw2ICsyNTMsOSBAQAogCU9fU0VU RFNDUCwJCS8qIGFyZzE9RFNDUCB2YWx1ZSAqLwogCU9fSVBfRkxPV19MT09LVVAsCS8qIGFy ZzE9dGFibGUgbnVtYmVyLCB1MzI9dmFsdWUJKi8KIAorCU9fU1RBVEVfQUNDRVBULAkJLyog bm9uZQkJCQkqLworCU9fU1RBVEVfREVOWSwJCS8qIG5vbmUgCQkJKi8KKwogCU9fTEFTVF9P UENPREUJCS8qIG5vdCBhbiBvcGNvZGUhCQkqLwogfTsKIApJbmRleDogc3lzL25ldHBmaWwv aXBmdy9pcF9mdzIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3 Mi5jCShyZXZpc2lvbiAyNzgwMjEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3Mi5jCSh3 b3JraW5nIGNvcHkpCkBAIC0xODU2LDcgKzE4NTYsNyBAQAogCiAJCQljYXNlIE9fTE9HOgog CQkJCWlwZndfbG9nKGNoYWluLCBmLCBobGVuLCBhcmdzLCBtLAotCQkJCSAgICBvaWYsIG9m ZnNldCB8IGlwNmZfbWYsIHRhYmxlYXJnLCBpcCk7CisJCQkJICAgIG9pZiwgb2Zmc2V0IHwg aXA2Zl9tZiwgdGFibGVhcmcsIGlwLCBxKTsKIAkJCQltYXRjaCA9IDE7CiAJCQkJYnJlYWs7 CiAKQEAgLTIxODgsNyArMjE4OCw3IEBACiAJCQkJYnJlYWs7CiAKIAkJCWNhc2UgT19BQ0NF UFQ6Ci0JCQkJcmV0dmFsID0gMDsJLyogYWNjZXB0ICovCisJCQkJcmV0dmFsID0gSVBfRldf UEFTUzsJLyogYWNjZXB0ICovCiAJCQkJbCA9IDA7CQkvKiBleGl0IGlubmVyIGxvb3AgKi8K IAkJCQlkb25lID0gMTsJLyogZXhpdCBvdXRlciBsb29wICovCiAJCQkJYnJlYWs7CkBAIC0y NTM4LDYgKzI1MzgsMjQgQEAKIAkJCQlicmVhazsKIAkJCX0KIAorCQkJY2FzZSBPX1NUQVRF X0FDQ0VQVDoKKwkJCWNhc2UgT19TVEFURV9ERU5ZOiB7CisJCQkJbCA9IDA7CS8qIGluIGFu eSBjYXNlIGV4aXQgaW5uZXIgbG9vcCAqLworCQkJCWlmIChxID09IE5VTEwgfHwgcS0+cnVs ZSAhPSBmKSB7CisJCQkJCWlmIChpcGZ3X2luc3RhbGxfc3RhdGUoY2hhaW4sIGYsCisJCQkJ CSAgICAoaXBmd19pbnNuX2xpbWl0ICopY21kLCBhcmdzLCB0YWJsZWFyZykpIHsKKwkJCQkJ CS8qIGVycm9yIG9yIGxpbWl0IHZpb2xhdGlvbiAqLworCQkJCQkJcmV0dmFsID0gSVBfRldf REVOWTsKKwkJCQkJCWRvbmUgPSAxOyAvKiBleGl0IG91dGVyIGxvb3AgKi8KKwkJCQkJfQor CQkJCX0gZWxzZSB7CisJCQkJCXJldHZhbCA9IGNtZC0+b3Bjb2RlID09IE9fU1RBVEVfQUND RVBUID8KKwkJCQkJICAgIElQX0ZXX1BBU1MgOiBJUF9GV19ERU5ZOworCQkJCQlkb25lID0g MTsJLyogZXhpdCBvdXRlciBsb29wICovCisJCQkJfQorCQkJCWJyZWFrOworCQkJfQorCiAJ CQlkZWZhdWx0OgogCQkJCXBhbmljKCItLSB1bmtub3duIG9wY29kZSAlZFxuIiwgY21kLT5v cGNvZGUpOwogCQkJfSAvKiBlbmQgb2Ygc3dpdGNoKCkgb24gb3Bjb2RlcyAqLwpJbmRleDog c3lzL25ldHBmaWwvaXBmdy9pcF9md19keW5hbWljLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lz L25ldHBmaWwvaXBmdy9pcF9md19keW5hbWljLmMJKHJldmlzaW9uIDI3ODAyMSkKKysrIHN5 cy9uZXRwZmlsL2lwZncvaXBfZndfZHluYW1pYy5jCSh3b3JraW5nIGNvcHkpCkBAIC03MDgs NiArNzA4LDggQEAKIAogCXN3aXRjaCAoY21kLT5vLm9wY29kZSkgewogCWNhc2UgT19LRUVQ X1NUQVRFOgkvKiBiaWRpciBydWxlICovCisJY2FzZSBPX1NUQVRFX0FMTE9XOgorCWNhc2Ug T19TVEFURV9ERU5ZOgogCQlxID0gYWRkX2R5bl9ydWxlKCZhcmdzLT5mX2lkLCBpLCBPX0tF RVBfU1RBVEUsIHJ1bGUpOwogCQlicmVhazsKIApJbmRleDogc3lzL25ldHBmaWwvaXBmdy9p cF9md19sb2cuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X2xv Zy5jCShyZXZpc2lvbiAyNzgwMjEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X2xvZy5j CSh3b3JraW5nIGNvcHkpCkBAIC0yNDgsNyArMjQ4LDcgQEAKIHZvaWQKIGlwZndfbG9nKHN0 cnVjdCBpcF9md19jaGFpbiAqY2hhaW4sIHN0cnVjdCBpcF9mdyAqZiwgdV9pbnQgaGxlbiwK ICAgICBzdHJ1Y3QgaXBfZndfYXJncyAqYXJncywgc3RydWN0IG1idWYgKm0sIHN0cnVjdCBp Zm5ldCAqb2lmLAotICAgIHVfc2hvcnQgb2Zmc2V0LCB1aW50MzJfdCB0YWJsZWFyZywgc3Ry dWN0IGlwICppcCkKKyAgICB1X3Nob3J0IG9mZnNldCwgdWludDMyX3QgdGFibGVhcmcsIHN0 cnVjdCBpcCAqaXAsIGlwZndfZHluX3J1bGUgKnEpCiB7CiAJY2hhciAqYWN0aW9uOwogCWlu dCBsaW1pdF9yZWFjaGVkID0gMDsKQEAgLTQxOSw2ICs0MTksMTggQEAKIAkJCQlzbnByaW50 ZihTTlBBUkdTKGFjdGlvbjIsIDApLCAiQ2FsbCAlZCIsCiAJCQkJICAgIGNtZC0+YXJnMSk7 CiAJCQlicmVhazsKKwkJY2FzZSBPX1NUQVRFX0FDQ0VQVDoKKwkJCWlmIChxICE9IE5VTEwg JiYgcS0+cnVsZSA9PSBmKQorCQkJCWFjdGlvbiA9ICJBY2NlcHQiOworCQkJZWxzZQorCQkJ CWFjdGlvbiA9ICJDcmVhdGUgYWNjZXB0IHN0YXRlIjsKKwkJCWJyZWFrOworCQljYXNlIE9f U1RBVEVfREVOWToKKwkJCWlmIChxICE9IE5VTEwgJiYgcS0+cnVsZSA9PSBmKQorCQkJCWFj dGlvbiA9ICJEZW55IjsKKwkJCWVsc2UKKwkJCQlhY3Rpb24gPSAiQ3JlYXRlIGRlbnkgc3Rh dGUiOworCQkJYnJlYWs7CiAJCWRlZmF1bHQ6CiAJCQlhY3Rpb24gPSAiVU5LTk9XTiI7CiAJ CQlicmVhazsKSW5kZXg6IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfcHJpdmF0ZS5oCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZndfcHJpdmF0ZS5oCShyZXZpc2lv biAyNzgwMjEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3ByaXZhdGUuaAkod29ya2lu ZyBjb3B5KQpAQCAtMTU0LDcgKzE1NCw3IEBACiB2b2lkIGlwZndfbG9nX2JwZihpbnQpOwog dm9pZCBpcGZ3X2xvZyhzdHJ1Y3QgaXBfZndfY2hhaW4gKmNoYWluLCBzdHJ1Y3QgaXBfZncg KmYsIHVfaW50IGhsZW4sCiAgICAgc3RydWN0IGlwX2Z3X2FyZ3MgKmFyZ3MsIHN0cnVjdCBt YnVmICptLCBzdHJ1Y3QgaWZuZXQgKm9pZiwKLSAgICB1X3Nob3J0IG9mZnNldCwgdWludDMy X3QgdGFibGVhcmcsIHN0cnVjdCBpcCAqaXApOworICAgIHVfc2hvcnQgb2Zmc2V0LCB1aW50 MzJfdCB0YWJsZWFyZywgc3RydWN0IGlwICppcCwgaXBmd19keW5fcnVsZSAqcSk7CiBWTkVU X0RFQ0xBUkUodV9pbnQ2NF90LCBub3J1bGVfY291bnRlcik7CiAjZGVmaW5lCVZfbm9ydWxl X2NvdW50ZXIJVk5FVChub3J1bGVfY291bnRlcikKIFZORVRfREVDTEFSRShpbnQsIHZlcmJv c2VfbGltaXQpOwpJbmRleDogc3lzL25ldHBmaWwvaXBmdy9pcF9md19zb2Nrb3B0LmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gc3lzL25ldHBmaWwvaXBmdy9pcF9md19zb2Nrb3B0LmMJKHJldmlz aW9uIDI3ODAyMSkKKysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZndfc29ja29wdC5jCSh3b3Jr aW5nIGNvcHkpCkBAIC0xNjQ1LDYgKzE2NDUsOCBAQAogCQljYXNlIE9fU0tJUFRPOgogCQlj YXNlIE9fUkVBU1M6CiAJCWNhc2UgT19DQUxMUkVUVVJOOgorCQljYXNlIE9fU1RBVEVfQUND RVBUOgorCQljYXNlIE9fU1RBVEVfREVOWToKIGNoZWNrX3NpemU6CiAJCQlpZiAoY21kbGVu ICE9IEZfSU5TTl9TSVpFKGlwZndfaW5zbikpCiAJCQkJZ290byBiYWRfc2l6ZTsK --------------040906070105090005040205 Content-Type: application/octet-stream; name="ipfw-state-actions.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-actions.diff.sig" iQJ8BAABCgBmBQJUz81FXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFFQUIwM0M1OEJGREM0 NzhGAAoJEOqwPFi/3EePADAP/3EHzxUT1adKBR/DeDZ4gx5laQcFfc22KbN5v/b4ccHyrc+X /25W6ejKGSPU92wTyUX2QX3Y2u80SmkSYEd9gOV8JWgepwhK3aObuIKbr7tG0TOmRlXO533+ pUkgV0VAGPyXrsUtd3fPORYOGqc4AMCGP357efFIZdD3DPLnUgFaSN+StLH/zXC+eEOSTc9Q YauXwK0mpt9C7DCNq4oKQ+t9z7QeVFnTIzZzhGhgA4ZMsOD19mPDDOBRPIAncZkc7CvpLxQp Br6clTHOyzu4I1wLo8QDE5TAPpfMRTvbseQXbnVVPuFpZI5O6gVqqr8ldhJUdx95rnBjMees TvuR4VGDcfgRHTZU7+fVupxCQHuPnswisS4mpzRvQJUGoRobDkGFf6EWzVgT4HkLukq47EPJ Oqi+IyUjFtFn14NXoAuzJpyMMbGfoURGNXgosInYwWRFJH0Jd8LxZQM3hPMvpa77LhebPdi1 rZQsOA75Bk9I4K1VKJ/D3nPz2CduUyalVnwNAPhU1754UxB0BvJcFwAgqlyEJ3NPYCa7oCZJ IX6jWMorJ8Exfe8lPc6ZKWEWYE0MkEezCqb79+uxls8cB9Iz6Uq4Jg7H88NKGEgw5OHb8Ifo q0b6/kxu9fePqpqyWM3dLaCtyN4t4iWduAlpojyoXoMtpSKbAC4FfeIOnYpl --------------040906070105090005040205-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 19:44:07 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82637B28 for ; Mon, 2 Feb 2015 19:44:07 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 696A3995 for ; Mon, 2 Feb 2015 19:44:07 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t12Ji7aT034980 for ; Mon, 2 Feb 2015 19:44:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" under heavy load Date: Mon, 02 Feb 2015 19:44:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 19:44:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|andre@freebsd.org |freebsd-net@FreeBSD.org --- Comment #13 from Andrey V. Elsukov --- Reassign to freebsd-net. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 19:57:43 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDF01B0 for ; Mon, 2 Feb 2015 19:57:43 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3F04AE1 for ; Mon, 2 Feb 2015 19:57:43 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t12JvhVm076105 for ; Mon, 2 Feb 2015 19:57:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" under heavy load Date: Mon, 02 Feb 2015 19:57:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 19:57:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D148807 --- Comment #14 from Andrey V. Elsukov --- Second panic: panic: sbsndptr: sockbuf 0xfffffe03e62b5c20 and mbuf 0xfffffe01d8fd3900 clashing cpuid =3D 31 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff90d4fca= 430 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff90d4fca4f0 panic() at panic+0x1ce/frame 0xffffff90d4fca5f0 sbsndptr() at sbsndptr+0xe4/frame 0xffffff90d4fca610 tcp_output() at tcp_output+0x16cd/frame 0xffffff90d4fca7c0 tcp_usr_send() at tcp_usr_send+0x325/frame 0xffffff90d4fca820 sosend_generic() at sosend_generic+0x3f6/frame 0xffffff90d4fca8c0 soo_write() at soo_write+0x5e/frame 0xffffff90d4fca8f0 dofilewrite() at dofilewrite+0x85/frame 0xffffff90d4fca940 kern_writev() at kern_writev+0x6c/frame 0xffffff90d4fca980 sys_write() at sys_write+0x64/frame 0xffffff90d4fca9d0 amd64_syscall() at amd64_syscall+0x5ea/frame 0xffffff90d4fcaaf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff90d4fcaaf0 --- syscall (4, FreeBSD ELF64, sys_write), rip =3D 0x802da3bec, rsp =3D 0x7fffffffdae8, rbp =3D 0x7fffffffdbf0 --- Uptime: 1m48s Dumping 3468 out of 65475 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..= 91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/if_igb.ko...Reading symbols from /boot/kernel/if_igb.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_igb.ko Reading symbols from /boot/kernel/aac.ko...Reading symbols from /boot/kernel/aac.ko.symbols...done. done. Loaded symbols for /boot/kernel/aac.ko Reading symbols from /boot/kernel/ipdivert.ko...Reading symbols from /boot/kernel/ipdivert.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipdivert.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/t5fw_cfg.ko...Reading symbols from /boot/kernel/t5fw_cfg.ko.symbols...done. done. Loaded symbols for /boot/kernel/t5fw_cfg.ko Reading symbols from /boot/kernel/if_cxgbe.ko...Reading symbols from /boot/kernel/if_cxgbe.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_cxgbe.ko Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /boot/kernel/ipmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipmi.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko #0 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:271 271 if (textdump && textdump_pending) { (kgdb) bt #0 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:271 #1 0xffffffff80907eb4 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:454 #2 0xffffffff809083a7 in panic (fmt=3D0x1
) at /usr/src/sys/kern/kern_shutdown.c:642 #3 0xffffffff809766e4 in sbsndptr (sb=3D, off=3D, len=3D, moff=3D) at /usr/src/sys/kern/uipc_sockbuf.c:985 #4 0xffffffff80aaedbd in tcp_output (tp=3D0xfffffe03e675a3d0) at /usr/src/sys/netinet/tcp_output.c:954 #5 0xffffffff80abc555 in tcp_usr_send (so=3D0xfffffe03e62b5aa0, flags=3D0, m=3D0xfffffe01d8fd2200, nam=3D0x0, control=3D, td=3D0xfffffe0021e90000) at /usr/src/sys/netinet/tcp_usrreq.c:874 #6 0xffffffff8097c1f6 in sosend_generic (so=3D0xfffffe03e62b5aa0, addr=3D0= x0, uio=3D0xffffff90d4fca990, top=3D0xfffffe01d8fd2200, control=3D0x0, flags=3D= ,=20 td=3D0xfffffe0021e90000) at /usr/src/sys/kern/uipc_socket.c:1376 #7 0xffffffff8095ea6e in soo_write (fp=3D, uio=3D0xffffff90d4fca990, active_cred=3D, flags=3D,=20 td=3D) at /usr/src/sys/kern/sys_socket.c:102 #8 0xffffffff80957195 in dofilewrite (td=3D0xfffffe0021e90000, fd=3D3, fp=3D0xfffffe0021cf3820, auio=3D0xffffff90d4fca990, offset=3D, flags=3D0) at file.h:295 #9 0xffffffff809574cc in kern_writev (td=3D0xfffffe0021e90000, fd=3D3, auio=3D0xffffff90d4fca990) at /usr/src/sys/kern/sys_generic.c:477 #10 0xffffffff80957554 in sys_write (td=3D, uap=3D) at /usr/src/sys/kern/sys_generic.c:393 #11 0xffffffff80cfea4a in amd64_syscall (td=3D0xfffffe0021e90000, traced=3D= 0) at subr_syscall.c:135 #12 0xffffffff80ce8ac7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #13 0x0000000802da3bec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) p *(struct sockbuf *)0xfffffe03e62b5c20 $1 =3D {sb_sel =3D {si_tdlist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, si= _note =3D {kl_list =3D {slh_first =3D 0x0}, kl_lock =3D 0xffffffff808cd0c0 ,=20 kl_unlock =3D 0xffffffff808cd090 , kl_assert_locke= d =3D 0xffffffff808c9a10 ,=20 kl_assert_unlocked =3D 0xffffffff808c9a20 , kl_lockarg =3D 0xfffffe03e62b5c68}, si_mtx =3D 0x0}, sb_mtx =3D {lock_objec= t =3D { lo_name =3D 0xffffffff80f3e7fd "so_snd", lo_flags =3D 16973824, lo_da= ta =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 18446741875255214080}, sb_sx =3D {lock_ob= ject =3D { lo_name =3D 0xffffffff80f3ed6b "so_snd_sx", lo_flags =3D 36896768, lo= _data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 18446741875255214080}, sb_state =3D 0,= =20 sb_mb =3D 0xfffffe01f4069900, sb_mbtail =3D 0xfffffe01d8fd3900, sb_lastre= cord =3D 0xfffffe01f4069900, sb_sndptr =3D 0xfffffe01d8fd3900, sb_sndptroff =3D 1632= , sb_cc =3D 1716,=20 sb_hiwat =3D 131376, sb_mbcnt =3D 4864, sb_mcnt =3D 11, sb_ccnt =3D 1, sb= _mbmax =3D 1051008, sb_ctl =3D 0, sb_lowat =3D 2048, sb_timeo =3D 0, sb_flags =3D 2048= , sb_upcall =3D 0,=20 sb_upcallarg =3D 0x0} (kgdb) p *(struct mbuf *)0xfffffe01d8fd3900 $2 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0xfffff= e01d8fd3928 "", mh_len =3D 68, mh_flags =3D 0, mh_type =3D 1, pad =3D "\000\000\000\000= \000"}, M_dat =3D {MH =3D { MH_pkthdr =3D {rcvif =3D 0xb1dee9e530000000, header =3D 0xf10fc01307a= ab916, len =3D -337628730, flowid =3D 2682375970, csum_flags =3D -966380398, csum_data= =3D -1624117065,=20 tso_segsz =3D 11596, PH_vt =3D {vt_vtag =3D 31606, vt_nrecs =3D 316= 06}, tags =3D {slh_first =3D 0xa2b0a659a4311f25}}, MH_dat =3D {MH_ext =3D { ext_buf =3D 0x43772562c99aa431
, ext_free =3D 0x7e1cffd9b6b13fc6, ext_arg1 =3D 0x731c9ab425536605,= =20 ext_arg2 =3D 0xebc6cac44b21a941, ext_size =3D 520953289, ref_cnt = =3D 0x5165381046dcad94, ext_type =3D 1308134978},=20 MH_databuf =3D "1=EF=BF=BD\232=EF=BF=BDb%wC=EF=BF=BD?=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD\= 034~\005fS%=EF=BF=BD\232\034sA=EF=BF=BD!K=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD\035\r\037I=DC=A1q\224=EF=BF=BD=EF=BF=BDF\0208eQB\216=EF=BF=BDM= =EF=BF=BDP=EF=BF=BD/\000\026OS^Lq%=EF=BF=BDMY\212\200\030\b\004\021\000\000= \000\001\001\b\n2=EF=BF=BD=EF=BF=BD \v=EF=BF=BD=EF=BF=BDO\000\000\000 =EF=BF=BD=EF=BF=BDn=EF=BF=BD=D9=BB=EF=BF=BDEr\032S\201\220\220=EF=BF=BD=EF= =BF=BDI=EF=BF=BD\"\210\233\v\0223?=3D=EF=BF=BD*a|\231\001\022=EF=BF=BD6}=EF= =BF=BDG=EF=BF=BD\026=EF=BF=BD\036z\n\023=EF=BF=BD<=EF=BF=BD=EF=BF=BD=EF=BF= =BDB8=EF=BF=BD\200\000\000\000\000\000\000\002%\220=EF=BF=BD=EF=BF=BD=EF=BF= =BDB8\001\003Ip\000\000\000"}},=20 M_databuf =3D "\000\000\0000=EF=BF=BD=EF=BF=BD=DE=B1\026=EF=BF=BD=EF=BF=BD\a\023=EF=BF=BD= \017=EF=BF=BD=EF=BF=BD1=EF=BF=BD=EF=BF=BD\"=EF=BF=BD=EF=BF=BD\237\2224f=C6= =B7=EF=BF=BD1\237L-v{X=EF=BF=BD\235\214%\0371=EF=BF=BDY=EF=BF=BD=EF=BF=BD= =EF=BF=BD1=EF=BF=BD\232=EF=BF=BDb%wC=EF=BF=BD?=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD\034~\005fS%=EF=BF=BD\232\034sA=EF=BF=BD!K=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD\035\r\037I=DC=A1q\224=EF=BF=BD=EF=BF=BDF\0208eQB\216= =EF=BF=BDM=EF=BF=BDP=EF=BF=BD/\000\026OS^Lq%=EF=BF=BDMY\212\200\030\b\004\0= 21\000\000\000\001\001\b\n2=EF=BF=BD=EF=BF=BD \v=EF=BF=BD=EF=BF=BDO\000\000\000 =EF=BF=BD=EF=BF=BDn=EF=BF=BD=D9=BB=EF=BF=BDEr\032S\201\220\220=EF=BF=BD=EF= =BF=BDI=EF=BF=BD\"\210\233\v\0223?=3D=EF=BF=BD*a|\231\001\022=EF=BF=BD6}=EF= =BF=BDG=EF=BF=BD\026=EF=BF=BD\036z\n\023=EF=BF=BD<=EF=BF=BD=EF=BF=BD=EF=BF= =BDB8=EF=BF=BD\200\000\000\000\000\000\000"...}} (kgdb) f 6 #6 0xffffffff8097c1f6 in sosend_generic (so=3D0xfffffe03e62b5aa0, addr=3D0= x0, uio=3D0xffffff90d4fca990, top=3D0xfffffe01d8fd2200, control=3D0x0, flags=3D= ,=20 td=3D0xfffffe0021e90000) at /usr/src/sys/kern/uipc_socket.c:1376 1376 error =3D (*so->so_proto->pr_usrreqs->pru_send)(so, (kgdb) p *so $3 =3D {so_count =3D 1, so_type =3D 1, so_options =3D 12, so_linger =3D 0, = so_state =3D 258, so_qstate =3D 0, so_pcb =3D 0xfffffe03e678a640, so_vnet =3D 0x0,=20 so_proto =3D 0xffffffff8143c3f0, so_head =3D 0x0, so_incomp =3D {tqh_firs= t =3D 0x0, tqh_last =3D 0x0}, so_comp =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, so_li= st =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0xfffffe01d8f96040}, so_qlen =3D 0, so_incqlen =3D 0, so_q= limit =3D 0, so_timeo =3D 0, so_error =3D 0, so_sigio =3D 0x0, so_oobmark =3D 0, so_aioj= obq =3D { tqh_first =3D 0x0, tqh_last =3D 0xfffffe03e62b5b20}, so_rcv =3D {sb_sel= =3D {si_tdlist =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffffe03e62b5b30}, si_not= e =3D {kl_list =3D { slh_first =3D 0x0}, kl_lock =3D 0xffffffff808cd0c0 , kl_unlock =3D 0xffffffff808cd090 ,=20 kl_assert_locked =3D 0xffffffff808c9a10 , kl_assert_unlocked =3D 0xffffffff808c9a20 ,=20 kl_lockarg =3D 0xfffffe03e62b5b78}, si_mtx =3D 0xffffff800e02f670},= sb_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff80f3e7f6 "so_rcv", lo_flags =3D= 16973824,=20 lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4}, sb_sx =3D {loc= k_object =3D {lo_name =3D 0xffffffff80f3ed75 "so_rcv_sx", lo_flags =3D 36896768, lo_data= =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, sb_state =3D 0, sb_mb =3D 0x0,= sb_mbtail =3D 0x0, sb_lastrecord =3D 0x0, sb_sndptr =3D 0x0, sb_sndptroff =3D 0, sb_cc = =3D 0,=20 sb_hiwat =3D 131376, sb_mbcnt =3D 0, sb_mcnt =3D 0, sb_ccnt =3D 0, sb_m= bmax =3D 1051008, sb_ctl =3D 0, sb_lowat =3D 1, sb_timeo =3D 0, sb_flags =3D 2056, s= b_upcall =3D 0,=20 sb_upcallarg =3D 0x0}, so_snd =3D {sb_sel =3D {si_tdlist =3D {tqh_first= =3D 0x0, tqh_last =3D 0x0}, si_note =3D {kl_list =3D {slh_first =3D 0x0},=20 kl_lock =3D 0xffffffff808cd0c0 , kl_unlock =3D 0xffffffff808cd090 ,=20 kl_assert_locked =3D 0xffffffff808c9a10 , kl_assert_unlocked =3D 0xffffffff808c9a20 ,=20 kl_lockarg =3D 0xfffffe03e62b5c68}, si_mtx =3D 0x0}, sb_mtx =3D {lo= ck_object =3D {lo_name =3D 0xffffffff80f3e7fd "so_snd", lo_flags =3D 16973824, lo_dat= a =3D 0,=20 lo_witness =3D 0x0}, mtx_lock =3D 18446741875255214080}, sb_sx =3D {lock_object =3D {lo_name =3D 0xffffffff80f3ed6b "so_snd_sx", lo_flags =3D = 36896768, lo_data =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 18446741875255214080}, sb_state = =3D 0, sb_mb =3D 0xfffffe01f4069900, sb_mbtail =3D 0xfffffe01d8fd3900,=20 sb_lastrecord =3D 0xfffffe01f4069900, sb_sndptr =3D 0xfffffe01d8fd3900, sb_sndptroff =3D 1632, sb_cc =3D 1716, sb_hiwat =3D 131376, sb_mbcnt =3D 48= 64, sb_mcnt =3D 11,=20 sb_ccnt =3D 1, sb_mbmax =3D 1051008, sb_ctl =3D 0, sb_lowat =3D 2048, s= b_timeo =3D 0, sb_flags =3D 2048, sb_upcall =3D 0, sb_upcallarg =3D 0x0}, so_cred =3D 0xfffffe01f48ce900,=20 so_label =3D 0x0, so_peerlabel =3D 0x0, so_gencnt =3D 13244, so_emuldata = =3D 0x0, so_accf =3D 0x0, so_fibnum =3D 0, so_user_cookie =3D 0} (kgdb) set $inp=3D(struct inpcb *)so->so_pcb (kgdb) p *$inp $4 =3D {inp_hash =3D {le_next =3D 0x0, le_prev =3D 0xfffffe0012f573b0}, inp_pcbgrouphash =3D {le_next =3D 0x0, le_prev =3D 0x0}, inp_list =3D {le_n= ext =3D 0xfffffe03e679bc80,=20 le_prev =3D 0xfffffe03e6743020}, inp_ppcb =3D 0xfffffe03e675a3d0, inp_p= cbinfo =3D 0xffffffff81531060, inp_pcbgroup =3D 0x0, inp_pcbgroup_wild =3D {le_next = =3D 0x0,=20 le_prev =3D 0x0}, inp_socket =3D 0xfffffe03e62b5aa0, inp_cred =3D 0xfffffe01f48ce900, inp_flow =3D 3457486592, inp_flags =3D 545300480, inp_f= lags2 =3D 0, inp_vflag =3D 6 '\006',=20 inp_ip_ttl =3D 64 '@', inp_ip_p =3D 0 '\0', inp_ip_minttl =3D 0 '\0', inp= _flowid =3D 1779132015, inp_refcount =3D 1, inp_pspare =3D {0x0, 0x0, 0x0, 0x0, 0x0}, inp_ispare =3D {0, 0,=20 0, 0, 0, 0}, inp_inc =3D {inc_flags =3D 1 '\001', inc_len =3D 0 '\0', i= nc_fibnum =3D 0, inc_ie =3D {ie_fport =3D 21327, ie_lport =3D 5632, ie_dependfaddr =3D {ie46_foreign =3D { ia46_pad32 =3D {3087401514, 17039360, 4283245058}, ia46_addr4 =3D= {s_addr =3D 801984766}}, ie6_foreign =3D {__u6_addr =3D { __u6_addr8 =3D "*\002\006=EF=BF=BD\000\000\004\001\002\"M=EF=BF= =BD=EF=BF=BDP=EF=BF=BD/", __u6_addr16 =3D {554, 47110, 0, 260, 8706, 65357, 20734, 12237}, __u6_addr32 =3D {30874= 01514, 17039360,=20 4283245058, 801984766}}}}, ie_dependladdr =3D {ie46_local =3D {ia46_pad32 =3D {3087401514, 917504, 0}, ia46_addr4 =3D {s_addr =3D 1375797= 248}}, ie6_local =3D { __u6_addr =3D {__u6_addr8 =3D "*\002\006=EF=BF=BD\000\000\016\000\000\000\000\000\000\000\001R", __u6_add= r16 =3D {554, 47110, 0, 14, 0, 0, 0, 20993}, __u6_addr32 =3D { 3087401514, 917504, 0, 1375797248}}}}, ie6_zoneid =3D 0}}, inp_label =3D 0x0, inp_sp =3D 0x0, inp_depend4 =3D {inp4_ip_tos =3D 0 '\0', inp4_options =3D 0x0,=20 inp4_moptions =3D 0x0}, inp_depend6 =3D {inp6_options =3D 0x0, inp6_out= putopts =3D 0xfffffe0013424500, inp6_moptions =3D 0x0, inp6_icmp6filt =3D 0x0, inp6_cks= um =3D 0,=20 inp6_hops =3D -1}, inp_portlist =3D {le_next =3D 0xfffffe03e6d8f640, le= _prev =3D 0xfffffe03e6743140}, inp_phd =3D 0xfffffe03e6dfa540, inp_gencnt =3D 1509, i= np_lle =3D 0x0,=20 inp_rt =3D 0x0, inp_lock =3D {lock_object =3D {lo_name =3D 0xffffffff80f5= 9235 "tcpinp", lo_flags =3D 90898432, lo_data =3D 0, lo_witness =3D 0x0}, rw_loc= k =3D 18446741875255214080}} --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 22:55:16 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68FCFBD6; Mon, 2 Feb 2015 22:55:16 +0000 (UTC) Received: from webmail2.jnielsen.net (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47C40C2; Mon, 2 Feb 2015 22:55:15 +0000 (UTC) Received: from [10.10.1.196] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by webmail2.jnielsen.net (8.15.1/8.14.9) with ESMTPSA id t12MsrBC014646 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 15:54:56 -0700 (MST) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host office.betterlinux.com [199.58.199.60] claimed to be [10.10.1.196] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Does "setfib" in ipfw forces to re-route packet? From: John Nielsen In-Reply-To: <54CEA776.1040505@FreeBSD.org> Date: Mon, 2 Feb 2015 15:54:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65FDDA6C-5910-4FBC-B43B-73BB72526AA5@jnielsen.net> References: <54CEA776.1040505@FreeBSD.org> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 22:55:16 -0000 On Feb 1, 2015, at 3:23 PM, Lev Serebryakov wrote: > "man 8 ipfw" doesn't state, that setting new fib on "out" packet > (whrn routing decision is done and output interface is known) change > routing decision: >=20 > ""The packet is tagged so as to use the FIB (routing table) fibnum in > any subsequent forwarding decisions."" >=20 > But according to ip_output.c (around line 527) "setfib" FORCES to > make NEW decision! >=20 > Do I read sources right? Maybe, wording in ipfw(8) should be changed? AFAIK, ipfw's setfib can only be usefully applied to incoming packets = (before a routing decision is made) that are passing through (and not = destined for) the FreeBSD machine as a router. For locally-originated traffic you need to either start your = application(s) using setfib(1) to begin with or use ipfw fwd rules to = redirect the traffic (which essentially ignores the original routing = decision). Be warned that FreeBSD 10.0 had a bug which broke ipfw fwd = (see the errata). I use the latter on a multi-homed non-router machine. $IP1/$CIDR1 is assigned to $IF1, and $GW1 is the default route for the = system (just one FIB). $IP2/$CIDR2 is assigned to $IF2, and I'd like = traffic originating from $IP2 to use $GW2 instead of $GW1. $LOCALTABLE = is an ipfw table containing directly-connected subnets (traffic for = which does not need to be routed). ipfw table $LOCALTABLE add $IP1/$CIDR1 ipfw table $LOCALTABLE add $IP2/$CIDR2 ipfw table $LOCALTABLE add 127.0.0.0/8 ... ipfw fwd $GW2 ip from $IP2 to not "table($LOCALTABLE)" out via $IF1 JN From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 23:14:01 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 011A322D for ; Mon, 2 Feb 2015 23:14:00 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id B4E2334C for ; Mon, 2 Feb 2015 23:14:00 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id D0EE55C002; Tue, 3 Feb 2015 02:13:12 +0300 (MSK) Message-ID: <54D004A2.4010203@FreeBSD.org> Date: Tue, 03 Feb 2015 02:13:38 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Nielsen Subject: Re: Does "setfib" in ipfw forces to re-route packet? References: <54CEA776.1040505@FreeBSD.org> <65FDDA6C-5910-4FBC-B43B-73BB72526AA5@jnielsen.net> In-Reply-To: <65FDDA6C-5910-4FBC-B43B-73BB72526AA5@jnielsen.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 23:14:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 01:54, John Nielsen wrote: > AFAIK, ipfw's setfib can only be usefully applied to incoming > packets (before a routing decision is made) that are passing > through (and not destined for) the FreeBSD machine as a router. Nope! > For locally-originated traffic you need to either start your > application(s) using setfib(1) to begin with or use ipfw fwd rules > to redirect the traffic (which essentially ignores the original > routing decision). Be warned that FreeBSD 10.0 had a bug which > broke ipfw fwd (see the errata). Problem is, sometimes you want to change routing decision in out way even on router machine. For example, after "nat global", it you don't want to use "fwd" actions (because it has static IP to use encoded to rule, which doesn't look good!). And looks like, it is possible. Please, look at sys/netinet/ip_output.c, lines 493-535. It checks, did packet filter change (a) destination address or (b) FIB, and if it does, it re-run routing decision. So, it will work "as expected" and only documentation need fix :) - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0ASiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTH8QAN2I1IynNr/yx2WzLXmIcr3Z 5dNVHqZ3kv6Bavh4hYtodyka03I7W6Cjt5SYQIapLxVeJJUK7bgHcxLzCO4Oq5zM zoZ5NAKH618B43UiVTf2o8MjiPDkUnDwRThDBw9ZkRADrw/8w3y1BgRXV1n47F/n IthJbRnHSMhAVQQQwGggcb+8BLUJacFzkmLvvzRJfSP4P2sHlOC45yYJWBuE784/ EovXt70tqVE0z1u06EU9n+JRjVNDTnrjzZeh1wMvcoQGjGS3iD0oSsn6y+wNPSrC 6MPTpVzWtTAzaC/Rh7l2XHJYPIdm5vmsiYzBtPR+jp1mYOWRcpA/HuVNazN1+oWI 6RWrjkcg+Ep53lUGuh91UqbbN677WkjxFcK/ru70jBQuoLT9fV2HMSiOnUZ8bDsx SQsqH+DNNHSbjp/YTwvR21/Q31MUURpG172GKWsu0OYf9vnOhTSnzAqI066R2BGa PCn5vsBcJYjPnTNxQeLZxMmBGQ8p6fwyjtJW05Dlgv5uYuoNct9BFAJzj5D1FFzg sT544DQWlrVceK+5E9z9INP5WMNdsZ+bn09uXDugxWNzqUW656G+0Pz2xUnHZF9M uoQCpF+UQIPdFXddSH/mxr/KK4M7E3RRKoCcd70Vahc4mD9gOvv/KN9oXmJiFWnn 8mCyp+bwjlf22b+6noVc =1Ynq -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 23:43:45 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7561AAEF for ; Mon, 2 Feb 2015 23:43:45 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4167386F for ; Mon, 2 Feb 2015 23:43:45 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id ey11so88510952pad.7 for ; Mon, 02 Feb 2015 15:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=X3GMIAU5ls5U75qbMTK3Ip8PKvNwVhrDKFNOS6nuu0s=; b=lUGw/V3XbXrxKpxN1TUXlpBstr40BHlyQ/fq+hjzMtCK/naRY6awjf0QKSaMj4NSqG tcDegoXjgjStjqe+o7+C24zn5vBg17jQyHsb8h0dk3vRNUxQ3nAubAoNDK2SuegRY4zK VmQKpb3GtJt5aNrp5RQJSBTvYhk1QgqtGSkbKVdLMN4+IFU7SFenx432Oa8HcpEE/Wc5 ZdmTLPOTvb/DJ3PseSLdeNxz4iQy7hQ83z0Ydvjcz3p1NB7vI/mgJpcUx93ZAqF1gYJY ENUI04k+gCTh05GXabSxi14A6GMAW0dhKTXEYAWKiLDTYWp/evicle+9RqJ99T8D7iOB 8dIg== MIME-Version: 1.0 X-Received: by 10.66.101.66 with SMTP id fe2mr33305751pab.118.1422920624794; Mon, 02 Feb 2015 15:43:44 -0800 (PST) Received: by 10.70.12.67 with HTTP; Mon, 2 Feb 2015 15:43:44 -0800 (PST) Date: Mon, 2 Feb 2015 17:43:44 -0600 Message-ID: Subject: netmap nic to host stack forwarding From: Xiaoye Sun To: net@freebsd.org, Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "yx15@rice.edu" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Feb 2015 23:43:45 -0000 Hi, I am new to netmap. What I want to do with netmap is to implement file transfer protocol so that netmap can help achieve fast network IO. In the netmap client program, I want that the unrelated packets are forwarded to the linux host stack and all the packets from the host stack are forwarded to the NIC also. That is, besides the netmap client achieving our file transfer protocol, all the other netowrk applications running on top of the host stack are not affected. Our machine configuration is as follows: Linux 3.11 + Myricom 10G nic + original Myricom driver coming in the linux kernel, not the modified one. We start to play with the bridge.c example in the netmap google code repository. We want to use it in a way so that the netmap client forwards packets from nic to the host stack and vice versa. So we use the command as follows sudo ./bridge -i netmap:eth3 to run the bridge netmap client. We did not change anything in the bridge.c code and the netmap source code. We test the functionality with the ping command line in linux. In our setting, another machine (not running netmap) sends ping request message to the netmap client machine and waits for the reply message. By looking at the tcpdump, we found that all the packets got a copy. That is, in the tcpdump results, there is a duplicate for each packet. Here is the output of tcpdump -i eth3: 17:40:32.708585 IP 10.10.10.74 > 10.10.10.52: ICMP echo request, id 19910, seq 1, length 64 17:40:32.708647 IP 10.10.10.74 > 10.10.10.52: ICMP echo request, id 19910, seq 1, length 64 17:40:32.708721 IP 10.10.10.52 > 10.10.10.74: ICMP echo reply, id 19910, seq 1, length 64 17:40:32.708760 IP 10.10.10.52 > 10.10.10.74: ICMP echo reply, id 19910, seq 1, length 64 17:40:33.708410 IP 10.10.10.74 > 10.10.10.52: ICMP echo request, id 19910, seq 2, length 64 17:40:33.708454 IP 10.10.10.74 > 10.10.10.52: ICMP echo request, id 19910, seq 2, length 64 17:40:33.708507 IP 10.10.10.52 > 10.10.10.74: ICMP echo reply, id 19910, seq 2, length 64 17:40:33.708540 IP 10.10.10.52 > 10.10.10.74: ICMP echo reply, id 19910, seq 2, length 64 17:40:34.708400 IP 10.10.10.74 > 10.10.10.52: ICMP echo request, id 19910, seq 3, length 64 17:40:34.708441 IP 10.10.10.74 > 10.10.10.52: ICMP echo request, id 19910, seq 3, length 64 17:40:34.708488 IP 10.10.10.52 > 10.10.10.74: ICMP echo reply, id 19910, seq 3, length 64 17:40:34.708516 IP 10.10.10.52 > 10.10.10.74: ICMP echo reply, id 19910, seq 3, length 64 Here is the output of the bridge.c in verbose mode 420.122815 main [749] poll timeout [0] ev 1 0 rx 0@0 tx 1023, [1] ev 1 0 rx 0@0 tx 1023 422.625336 main [749] poll timeout [0] ev 1 0 rx 0@0 tx 1023, [1] ev 1 0 rx 0@0 tx 1023 425.127857 main [749] poll timeout [0] ev 1 0 rx 0@0 tx 1023, [1] ev 1 0 rx 0@0 tx 1023 427.630354 main [749] poll timeout [0] ev 1 0 rx 0@0 tx 1023, [1] ev 1 0 rx 0@0 tx 1023 430.132872 main [749] poll timeout [0] ev 1 0 rx 0@0 tx 1023, [1] ev 1 0 rx 0@0 tx 1023 432.635393 main [749] poll timeout [0] ev 1 0 rx 0@0 tx 1023, [1] ev 1 0 rx 0@0 tx 1023 432.708611 main [749] poll ok [0] ev 1 0 rx 0@0 tx 1023, [1] ev 1 1 rx 1@0 tx 1023 432.708635 main [749] poll ok [0] ev 5 4 rx 0@0 tx 1023, [1] ev 0 0 rx 1@0 tx 1023 432.708641 process_rings [562] net->host sent 1 packets to 0x7fef1aeaa000 432.708743 main [749] poll ok [0] ev 1 1 rx 1@0 tx 1023, [1] ev 1 0 rx 0@1 tx 1023 432.708751 main [749] poll ok [0] ev 0 0 rx 1@0 tx 1023, [1] ev 5 4 rx 0@1 tx 1023 432.708755 process_rings [562] net->host sent 1 packets to 0x7fef1aea1000 433.708430 main [749] poll ok [0] ev 1 0 rx 0@1 tx 1023, [1] ev 1 1 rx 1@1 tx 1022 433.708445 main [749] poll ok [0] ev 5 4 rx 0@1 tx 1023, [1] ev 0 0 rx 1@1 tx 1022 433.708449 process_rings [562] net->host sent 1 packets to 0x7fef1aeaa000 433.708525 main [749] poll ok [0] ev 1 1 rx 1@1 tx 1023, [1] ev 1 0 rx 0@2 tx 1022 433.708532 main [749] poll ok [0] ev 0 0 rx 1@1 tx 1023, [1] ev 5 4 rx 0@2 tx 1022 433.708536 process_rings [562] net->host sent 1 packets to 0x7fef1aea1000 434.708416 main [749] poll ok [0] ev 1 0 rx 0@2 tx 1023, [1] ev 1 1 rx 1@2 tx 1022 434.708432 main [749] poll ok [0] ev 5 4 rx 0@2 tx 1023, [1] ev 0 0 rx 1@2 tx 1022 434.708437 process_rings [562] net->host sent 1 packets to 0x7fef1aeaa000 434.708497 main [749] poll ok [0] ev 1 1 rx 1@2 tx 1023, [1] ev 1 0 rx 0@3 tx 1022 434.708505 main [749] poll ok [0] ev 0 0 rx 1@2 tx 1023, [1] ev 5 4 rx 0@3 tx 1022 434.708511 process_rings [562] net->host sent 1 packets to 0x7fef1aea1000 437.211025 main [749] poll timeout [0] ev 1 0 rx 0@3 tx 1023, [1] ev 1 0 rx 0@3 tx 1022 437.709106 main [749] poll ok [0] ev 1 1 rx 1@3 tx 1023, [1] ev 1 0 rx 0@3 tx 1022 437.709116 main [749] poll ok [0] ev 0 0 rx 1@3 tx 1023, [1] ev 5 4 rx 0@3 tx 1022 437.709121 process_rings [562] net->host sent 1 packets to 0x7fef1aea1000 437.709226 main [749] poll ok [0] ev 1 0 rx 0@4 tx 1023, [1] ev 1 1 rx 1@3 tx 1022 437.709235 main [749] poll ok [0] ev 5 4 rx 0@4 tx 1023, [1] ev 0 0 rx 1@3 tx 1022 437.709240 process_rings [562] net->host sent 1 packets to 0x7fef1aeaa000 440.211745 main [749] poll timeout [0] ev 1 0 rx 0@4 tx 1023, [1] ev 1 0 rx 0@4 tx 1022 442.714271 main [749] poll timeout [0] ev 1 0 rx 0@4 tx 1023, [1] ev 1 0 rx 0@4 tx 1022 444.026300 main [749] poll timeout [0] ev 1 0 rx 0@4 tx 1023, [1] ev 1 0 rx 0@4 tx 1022 I am wondering if the output looks normal. In particular, is this the expected behavior of the bridge.c example? In addition, how to make the netmap client only send one copy of the packets to the network host stack and how to drop the packets in the netmap client? Do you think the problem is due to the unmodified Myricom driver? Thanks! Best, Xiaoye -- Xiaoye Steven Sun, Ph.D. Student 6100 Main St. MS-366 Department of Electrical and Computer Engineering (ECE) & Department of Computer Science (CS) George R. Brown School of Engineering Rice University, Houston, Texas, USA From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 05:00:12 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A294D26E; Tue, 3 Feb 2015 05:00:12 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 73010DAA; Tue, 3 Feb 2015 05:00:12 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t13508Ix036775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Feb 2015 21:00:10 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D055D2.9010503@freebsd.org> Date: Tue, 03 Feb 2015 13:00:02 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, Hiroki Sato Subject: Re: Does "setfib" in ipfw forces to re-route packet? References: <54CEA776.1040505@FreeBSD.org> <65FDDA6C-5910-4FBC-B43B-73BB72526AA5@jnielsen.net> <54D004A2.4010203@FreeBSD.org> In-Reply-To: <54D004A2.4010203@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 05:00:12 -0000 On 2/3/15 7:13 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > And looks like, it is possible. > > Please, look at sys/netinet/ip_output.c, lines 493-535. > > It checks, did packet filter change (a) destination address or (b) > FIB, and if it does, it re-run routing decision. > > So, it will work "as expected" and only documentation need fix :) yes I see the change.. commit 272391 by hrs (CC'd) Hrs, can you fix the documentation? (man pages) ipfw(8) It is important that we always keep the documentation up to date with out source commits. this change of behaviour shoudlhave been accomanied byt a change to the documentation in the actual commit. It should note in hte man page that this is a sub-optimal path because each packet looks up a route twice, and much of ip_output( is run a second time which may be quite expensive if it redoes firewall work etc. (one reason I didn't do this in the first place). I would even consider the following around line 542 (head): if (inp != NULL) { /* switch the socket over so this is it's default FIB now */ np->inp_inc.inc_fibnum = M_GETFIB(m); } also now that we have a fibnum local variable, it should be used instead of all the later M_GETFIB() later in the function. eventually struct route should have a fibnum entry in it. (though some people have suggested it go right away.) From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 06:44:56 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A21B227B; Tue, 3 Feb 2015 06:44:56 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 771BDA33; Tue, 3 Feb 2015 06:44:56 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t136ioF6037065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Feb 2015 22:44:52 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D06E5C.3090701@freebsd.org> Date: Tue, 03 Feb 2015 14:44:44 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> In-Reply-To: <54CFCD45.9070304@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 06:44:56 -0000 On 2/3/15 3:17 AM, Lev Serebryakov wrote: > > I propose two new actions: state-allow and state-deny. > > They imply "keep-state" and create new dynamic rules, when called > directly, but pass packet to NEXT rule after that (don't stop search). > > When they are called as dynamic rule, they acts as "allow" and "deny". > > So, stateful firewall with NAT could be rewritten like this: > > add 1000 skipto 2000 all from any to any out xmit outIface > add 1010 skipto 3000 all from any to any in recv outIface > > add 2000 state-allow from any to any // keep-state is implied > add 2010 nat NR from any to any // No "out" here! > add 2020 allow all from any to any > > add 3000 nat NR from any to any > add 3010 check-state // Use dynamic rule based on 2000 as "allow" here > > What do you think? I understand what you are trying to do.. but part of the usefulness of the state runes is that they can be any action, not just allow and deny. I might try the following action: record: (or record-only) it allows the rule to be stored, but the action is not performed. on check-state, the rule is performed.. so skipto 2000 ip from me to fred 80 record-only out xmit bge0 would do nothing but record the session and on input the session packet would skipto 2000 you could do deny or accept as well so it's a superset of what you suggest. I'm not sure where in the rule record-only shoudl be put.. maybe ipfw add 1000 log record-only skipto 2000 tcp from me to fred 80,443 out xmit bge0 might be more syntactically correct? What I would find more useful, is separate state rules for each interface. so you could not have the danger of a packet on interface A adding a rule that eventually does something unexpected on a packet on interface B. looking at my own rules I don't seem to have a problem.. -------- Just for kicks, here is the base ipfw script.. just sets up the framework --- #!/bin/sh fwcmd="/sbin/ipfw" # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi # set these to your outside interface network and netmask and ip oif="tun0" onet="192.168.36.0" omask="24" oip="x.x.x.x" # set these to your inside interface network and netmask and ip iif="vr0" inet="192.168.2.0" imask="255.255.255.0" iip="192.168.2.21" # for not the natd target is us but change this if you # change that in natd.conf natd_target=${oip} work_vpnserver=y.y.y.y INCOMING=4000 OUTGOING=8000 LOCAL=1000 SET=1 sysctl net.inet.ip.fw.enable=0 ${fwcmd} -q flush ${fwcmd} -q table 1 flush ${fwcmd} -q table 2 flush ${fwcmd} -q table 3 flush ${fwcmd} -q table 4 flush ${fwcmd} table 1 add 10.0.0.0/8 ${fwcmd} table 1 add 172.16.0.0/12 #${fwcmd} table 1 add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes # RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class D), # and class E) on the outside interface ${fwcmd} table 1 add 0.0.0.0/8 ${fwcmd} table 1 add 169.254.0.0/16 ${fwcmd} table 1 add 192.0.2.0/24 ${fwcmd} table 1 add 224.0.0.0/4 ${fwcmd} table 1 add 240.0.0.0/4 # add legit sources of ssh.. DNS is not up yet so use IPs # could add to /etc/hosts I guess. # myotherhouse.org ${fwcmd} table 2 add a.b.c.d # work ${fwcmd} table 2 add c.d.e.f/24 # my vps ${fwcmd} table 2 add f.g.h.i/24 # add legit DNS tcp (zone) sources # my.dns.friends ${fwcmd} table 3 add m.n.o.p # my.dns.friend ${fwcmd} table 3 add q.r.s.t # my.vps ${fwcmd} table 3 add f.g.h.i # Add our local networks here ${fwcmd} table 4 add 192.168.2.0/24 ${fwcmd} table 4 add 172.16.15.0/24 # common spoofing code # --------------- ALL PACKETS START HERE. ------------ ${fwcmd} set disable ${SET} # Stop localhost spoofing ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny log all from any to 127.0.0.0/8 ${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any # If we've already decided on it. keep our word. ${fwcmd} add check-state #-------- Interception rules for external interfaces go here ------- #-------- Internal traffic. generally don't care # except to stop spoofing. # make extra sure we don't block DHCP to our server (me) # as initial request will be from 0.0.0.0/0 ${fwcmd} add ${LOCAL} set ${SET} allow udp from any to any 67 in recv ${iif} ${fwcmd} add allow udp from any 67 to any out xmit ${iif} # other wise it has to be to and from a net we actually have. ${fwcmd} add deny log all from not "table(4)" to any in recv ${iif} ${fwcmd} add deny log all from any to not "table(4)" out xmit ${iif} ${fwcmd} add reject log tcp from "table(5)" to any 80,443 in recv vr0 ${fwcmd} add allow ip from any to any sysctl net.inet.ip.fw.enable=1 -------- and now the rules for my external interface.. you run this after the other file. note that the rules go into a separate set and can be disabled at once. #!/bin/sh set -x fwcmd="/sbin/ipfw" # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi # set these to your outside interface network and netmask and ip oif="vr2" oip="$1" onet="$2" omask="$3" # set these to your inside interface network and netmask and ip iif="vr0" inet="192.168.2.0" imask="255.255.255.0" iip="192.168.2.21" # for not the natd target is us but change this if you # change that in natd.conf natd_target=${oip} work_vpnserver=64.244.102.15 INTERCEPT=610 INCOMING=14000 OUTGOING=18000 NATD2=8669 SET=2 sysctl net.inet.ip.fw.enable=0 ${fwcmd} -q delete ${INTERCEPT} ${fwcmd} set disable ${SET} # effectively clear it ${fwcmd} set move 30 to ${SET} # common spoofing code # --------------- ALL PACKETS START HERE. ------------ ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${INCOMING} ip from any to any in recv ${oif} ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${OUTGOING} ip from any to any out xmit ${oif} #-------- Internal traffic. generally don't care Add in a new incoming and outgoing section for the new interface #------- INCOMING # don't allow packets from the wrong net! ${fwcmd} add ${INCOMING} set ${SET} deny log all from "table(4)" to any # in fact don't accept packets that are not for this interface exactly ${fwcmd} add set ${SET} deny log ip from any to not ${oip} # Allow access to our ssh from trusted places (work, freebsd (sometimes)) ${fwcmd} add set ${SET} pass tcp from "table(2)" to ${oip} 22 setup keep-state # allow our DNS secondaries to get zone transfers ${fwcmd} add set ${SET} pass tcp from "table(3)" to ${oip} 53 setup keep-state # allow DNS requests, since we are authoratitive ${fwcmd} add set ${SET} pass udp from any to ${oip} 53 # Allow setup of incoming email # not on this interface # me, DNS and root can start outgoing sessions and have # them come in if there is a waiting socket # !!@# Don't do this it breaks ntp from inside # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 0 # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 53 # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 1000 # ignore any mention of RFC1918 nets on the outside interface ${fwcmd} add set ${SET} deny log all from any to "table(1)" # except the ${fwcmd} add set ${SET} deny log not icmp from "table(1)" to any #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v INCOMING NAT POINT ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v # NAT anything that is left and trust NATD ${fwcmd} add set ${SET} divert ${NATD2} all from any to any #After translation.. trust Nat to filter non matches # explicitly allow NAT-T from the vpn server to inside nets ${fwcmd} add set ${SET} allow udp from ${work_vpnserver} to "table(4)" # Allow TCP through if setup succeeded . # bypass the logging step. too much data ${fwcmd} add set ${SET} allow tcp from any to any established # take note of unexpected stuff. then drop it. # hmm, NAtd must have let this through why? ${fwcmd} add set ${SET} drop log ip from any to ${natd_target} # Allow IP fragments to pass through (NOPE) # ${fwcmd} add set ${SET} pass all from any to any frag # XXX remove this if you turn on the target option on # natd to allow a server # Reject & Log all setup of incoming connections from the outside # that have not been explicitly allowed above. ${fwcmd} add set ${SET} deny log tcp from any to ${natd_target} setup # anything here should be logged. it's intersting. ${fwcmd} add set ${SET} count log ip from any to any # after that gauntlet, allow it to proceed. ${fwcmd} add set ${SET} allow ip from any to any #----- OUTGOING # Stop RFC1918 nets getting out to the outside interface # except for the wierdness of our next hop being such an address. ${fwcmd} add ${OUTGOING} set ${SET} allow icmp from ${oip} to ${onet}:${omask} keep-state ${fwcmd} add set ${SET} deny log all from any to "table(1)" # The firewall and inside can talk out if it wants to. # these are local sessions by definition. ${fwcmd} add set ${SET} pass all from ${oip} to any keep-state #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v OUTGOING NAT POINT ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v ${fwcmd} add set ${SET} divert ${NATD2} all from any to any out recv ${iif} # just in case natd goes wierd. ${fwcmd} add set ${SET} deny log all from "table(1)" to any # in fact don't allow packets out that are not from this interface exactly ${fwcmd} add set ${SET} deny log ip from not ${oip} to any ${fwcmd} add set ${SET} allow all from any to any ${fwcmd} set enable ${SET} sysctl net.inet.ip.fw.enable=1 and here's rules for un untrusted tunnel this file can also be run after the main one when hte tunnel is in use. I'm not using this one at the moment, so I'm not sure it works but you can get the idea.. I add a separate script file for each interface.. and they slot in separate rules as needed. #!/bin/sh fwcmd="/sbin/ipfw" # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi # set these to your inside interface network and netmask and ip iif="vr0" inet="192.168.2.0" imask="255.255.255.0" iip="192.168.2.21" # set these to your outside interface network and netmask and ip oif="tun0" onet="192.168.36.0" omask="24" oip="l.m.n.o" INTERCEPT=500 INCOMING=4000 OUTGOING=8000 SET=1 # for now the natd target is us but change this if you # change that in natd.conf natd_target=${oip} work_vpnserver=t.u.v.w sysctl net.inet.ip.fw.enable=0 #-------- Select direction and interface class ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${INCOMING} ip from any to any in recv ${oif} ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${OUTGOING} ip from any to any out xmit ${oif} #------- INCOMING # don't allow packets from the wrong net! ${fwcmd} add ${INCOMING} set ${SET} deny log all from "table(4)" to any # in fact don't accept packets that are not for this interface exactly ${fwcmd} add set ${SET} deny log ip from any to not ${oip} # Allow access to our ssh from trusted places (work, freebsd, (sometimes)) ${fwcmd} add set ${SET} pass tcp from "table(2)" to ${oip} 22 setup keep-state # allow our DNS secondaries to get zone transfers ${fwcmd} add set ${SET} pass tcp from "table(3)" to ${oip} 53 setup keep-state # allow DNS requests, since we are authoratitive ${fwcmd} add set ${SET} pass udp from any to ${oip} 53 # Allow setup of incoming email # julian and root can start outgoing sessions and have them come in if there is a waiting socket :-) ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 0 ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 53 ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 1000 # ignore any mention of RFC1918 nets on the outside interface ${fwcmd} add set ${SET} deny log all from any to "table(1)" ${fwcmd} add set ${SET} deny log not icmp from "table(1)" to any #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v INCOMING NAT POINT ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v # NAT anything that is left and trust NATD ${fwcmd} add set ${SET} divert natd all from any to any #After translation # explicitly allow NAT-T from the vpn server to inside nets ${fwcmd} add set ${SET} allow udp from ${work_vpnserver} to "table(4)" # Allow TCP through if setup succeeded . # bypass the logging step. too much data ${fwcmd} add set ${SET} allow tcp from any to any established # take note of unexpected stuff. then drop it. ${fwcmd} add set ${SET} drop log ip from any to ${natd_target} # Allow IP fragments to pass through (NOPE) # ${fwcmd} add set ${SET} pass all from any to any frag # XXX remove this if you turn on the target option on # natd to allow a server # Reject & Log all setup of incoming connections from the outside # that have not been explicitly allowed above. ${fwcmd} add set ${SET} deny log tcp from any to ${natd_target} setup # anything here should be logged. it's interesting. ${fwcmd} add set ${SET} count log ip from any to any #currently slam that door .. this rule comes and goes depending on if I need it. ${fwcmd} add set ${SET} deny log ip from any to any # after that gauntlet, allow it to proceed. ${fwcmd} add set ${SET} allow ip from any to any #----- OUTGOING # Stop RFC1918 nets getting out to the outside interface # except for the wierdness of our next hop being such an address. ${fwcmd} add ${OUTGOING} set ${SET} allow icmp from ${oip} to ${onet}/${omask} keep-state ${fwcmd} add set ${SET} deny log all from any to "table(1)" # The firewall (and my laptop) can talk out if it wants to. # these are local sessions by definition. ${fwcmd} add set ${SET} pass all from ${oip} to any keep-state # ${fwcmd} add set ${SET} pass udp from ${oip} to any keep-state # ${fwcmd} add set ${SET} pass icmp from ${oip} to any keep-state # Allow NTP queries out in the world from the firewall. # ${fwcmd} add set ${SET} pass udp from ${oip} to any 123 keep-state # Allow DNS queries out in the world from the firewall. # ${fwcmd} add set ${SET} pass udp from ${oip} to any 53 keep-state #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v OUTGOING NAT POINT ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v ${fwcmd} add set ${SET} divert natd all from any to any out recv ${iif} # just in case natd goes wierd. ${fwcmd} add set ${SET} deny log all from "table(1)" to any # in fact don't allow packets out that are not from this interface exactly ${fwcmd} add set ${SET} deny log ip from not ${oip} to any ${fwcmd} add set ${SET} allow all from any to any ${fwcmd} set enable ${SET} sysctl net.inet.ip.fw.enable=1 From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 06:45:04 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4F63348 for ; Tue, 3 Feb 2015 06:45:04 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A31EDA3E for ; Tue, 3 Feb 2015 06:45:04 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t136j4Vw094613 for ; Tue, 3 Feb 2015 06:45:04 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t136j4n9094612; Tue, 3 Feb 2015 06:45:04 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 06:45:04 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Request, 68 lines] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJm X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 06:45:04 -0000 hselasky created this revision. hselasky added reviewers: rmacklem, rrs, glebius, gnn, emaste, bz, adrian, rwatson. hselasky added a subscriber: freebsd-net. hselasky set the repository for this revision to rS (FreeBSD src repository). REVISION SUMMARY To be able to handle the transfer rates of tomorrow we need to reduce the number of requests to the TCP stack when receiving packets. Currently there is a limitation of 65535 bytes, which is due to using the 16-bit IP payload field in the IP header when accumulating LRO data. Instead use the 32-bit m_len field of the mbuf when doing data accumulation. TEST PLAN Test IPv4 Test IPv6 Test ip_fragment() REVISION DETAIL https://reviews.freebsd.org/D1761 AFFECTED FILES sys/netinet/ip_input.c sys/netinet/ip_output.c sys/netinet/tcp_input.c sys/netinet/tcp_lro.c sys/sys/mbuf.h To: hselasky, rmacklem, rrs, glebius, gnn, emaste, bz, adrian, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 06:54:19 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADF2F445; Tue, 3 Feb 2015 06:54:19 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82679B11; Tue, 3 Feb 2015 06:54:19 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id et14so92534913pad.4; Mon, 02 Feb 2015 22:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2X6dA5vpZissLKDr2jLs7L6YuT1CFvavMDFPfqnq9/0=; b=OBva4X9y3Nzt08mhdJTYRXqKEo1P2MT7oh+QSkDEwDXTzWlYv3c8gu2pgYSRBFKFZ0 q+sIPnF8vXM8ijPer6YjjetCxGRtsVS8G6xWRQJBJLQpHve2ikFUnwN5Ej8iqg804AAy hZSlGXuxmqdX1rLa75wnYRc9ETBnwZAynrizqpvCEfBK3R1AvLcd9mSLTErP271ETr0Z wz/px/BHyTWVxbL6wMeCcHyGXMqzhgAPt1XmSXuvUjrh8pe5DrptiZtPzkNUV1xoOM4x VQVWXjc3NId5Re8g8a1ofwF3WUCSuLmUi/p3UO1vMI/zi3j6WNaL2Y/317p/YQ0jErK6 xf9w== MIME-Version: 1.0 X-Received: by 10.70.94.129 with SMTP id dc1mr11353357pdb.70.1422946458929; Mon, 02 Feb 2015 22:54:18 -0800 (PST) Received: by 10.70.45.228 with HTTP; Mon, 2 Feb 2015 22:54:18 -0800 (PST) In-Reply-To: <54D06E5C.3090701@freebsd.org> References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org> Date: Tue, 3 Feb 2015 14:54:18 +0800 Message-ID: Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny From: bycn82 To: Julian Elischer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ipfw , lev@freebsd.org, freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 06:54:19 -0000 *cool, I like this, it got some points.* *though the email is too looooong to be read.* On 3 February 2015 at 14:44, Julian Elischer wrote: > On 2/3/15 3:17 AM, Lev Serebryakov wrote: > >> >> I propose two new actions: state-allow and state-deny. >> >> They imply "keep-state" and create new dynamic rules, when called >> directly, but pass packet to NEXT rule after that (don't stop search). >> >> When they are called as dynamic rule, they acts as "allow" and "deny". >> >> So, stateful firewall with NAT could be rewritten like this: >> >> add 1000 skipto 2000 all from any to any out xmit outIface >> add 1010 skipto 3000 all from any to any in recv outIface >> >> add 2000 state-allow from any to any // keep-state is implied >> add 2010 nat NR from any to any // No "out" here! >> add 2020 allow all from any to any >> >> add 3000 nat NR from any to any >> add 3010 check-state // Use dynamic rule based on 2000 as "allow" here >> >> What do you think? >> > > I understand what you are trying to do.. > but part of the usefulness of the state runes is that they > can be any action, not just allow and deny. > I might try the following action: > > record: (or record-only) > it allows the rule to be stored, but the action is not performed. > on check-state, the rule is performed.. > > so skipto 2000 ip from me to fred 80 record-only out xmit bge0 > would do nothing but record the session > and on input the session packet would skipto 2000 > > you could do deny or accept as well so it's a superset of what you > suggest. > I'm not sure where in the rule record-only shoudl be put.. > maybe > > ipfw add 1000 log record-only skipto 2000 tcp from me to fred 80,443 out > xmit bge0 > > might be more syntactically correct? > > What I would find more useful, is separate state rules for each interface. > so you could not have the danger of a packet on interface A adding a rule > that eventually does something unexpected on a packet on interface B. > > > looking at my own rules I don't seem to have a problem.. > -------- > Just for kicks, > here is the base ipfw script.. just sets up the framework > > --- > #!/bin/sh > > fwcmd="/sbin/ipfw" > > # Suck in the configuration variables. > if [ -z "${source_rc_confs_defined}" ]; then > if [ -r /etc/defaults/rc.conf ]; then > . /etc/defaults/rc.conf > source_rc_confs > elif [ -r /etc/rc.conf ]; then > . /etc/rc.conf > fi > fi > > > # set these to your outside interface network and netmask and ip > oif="tun0" > onet="192.168.36.0" > omask="24" > oip="x.x.x.x" > > > # set these to your inside interface network and netmask and ip > iif="vr0" > inet="192.168.2.0" > imask="255.255.255.0" > iip="192.168.2.21" > > # for not the natd target is us but change this if you > # change that in natd.conf > natd_target=${oip} > work_vpnserver=y.y.y.y > > INCOMING=4000 > OUTGOING=8000 > LOCAL=1000 > SET=1 > > sysctl net.inet.ip.fw.enable=0 > ${fwcmd} -q flush > ${fwcmd} -q table 1 flush > ${fwcmd} -q table 2 flush > ${fwcmd} -q table 3 flush > ${fwcmd} -q table 4 flush > > ${fwcmd} table 1 add 10.0.0.0/8 > ${fwcmd} table 1 add 172.16.0.0/12 > #${fwcmd} table 1 add 192.168.0.0/16 > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > # RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class > D), > # and class E) on the outside interface > ${fwcmd} table 1 add 0.0.0.0/8 > ${fwcmd} table 1 add 169.254.0.0/16 > ${fwcmd} table 1 add 192.0.2.0/24 > ${fwcmd} table 1 add 224.0.0.0/4 > ${fwcmd} table 1 add 240.0.0.0/4 > > # add legit sources of ssh.. DNS is not up yet so use IPs > # could add to /etc/hosts I guess. > # myotherhouse.org > ${fwcmd} table 2 add a.b.c.d > # work > ${fwcmd} table 2 add c.d.e.f/24 > # my vps > ${fwcmd} table 2 add f.g.h.i/24 > > # add legit DNS tcp (zone) sources > # my.dns.friends > ${fwcmd} table 3 add m.n.o.p > # my.dns.friend > ${fwcmd} table 3 add q.r.s.t > # my.vps > ${fwcmd} table 3 add f.g.h.i > > # Add our local networks here > ${fwcmd} table 4 add 192.168.2.0/24 > ${fwcmd} table 4 add 172.16.15.0/24 > > # common spoofing code > # --------------- ALL PACKETS START HERE. ------------ > > ${fwcmd} set disable ${SET} > > # Stop localhost spoofing > ${fwcmd} add 100 pass all from any to any via lo0 > ${fwcmd} add 200 deny log all from any to 127.0.0.0/8 > ${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any > > # If we've already decided on it. keep our word. > ${fwcmd} add check-state > > #-------- Interception rules for external interfaces go here ------- > > #-------- Internal traffic. generally don't care > # except to stop spoofing. > # make extra sure we don't block DHCP to our server (me) > # as initial request will be from 0.0.0.0/0 > > ${fwcmd} add ${LOCAL} set ${SET} allow udp from any to any 67 in > recv ${iif} > ${fwcmd} add allow udp from any 67 to any out xmit ${iif} > > # other wise it has to be to and from a net we actually have. > ${fwcmd} add deny log all from not "table(4)" to any in recv ${iif} > ${fwcmd} add deny log all from any to not "table(4)" out xmit > ${iif} > > ${fwcmd} add reject log tcp from "table(5)" to any 80,443 in recv > vr0 > > ${fwcmd} add allow ip from any to any > > > > sysctl net.inet.ip.fw.enable=1 > > -------- > and now the rules for my external interface.. > you run this after the other file. note that the rules go into a separate > set > and can be disabled at once. > > #!/bin/sh > set -x > fwcmd="/sbin/ipfw" > > # Suck in the configuration variables. > if [ -z "${source_rc_confs_defined}" ]; then > if [ -r /etc/defaults/rc.conf ]; then > . /etc/defaults/rc.conf > source_rc_confs > elif [ -r /etc/rc.conf ]; then > . /etc/rc.conf > fi > fi > > # set these to your outside interface network and netmask and ip > oif="vr2" > oip="$1" > onet="$2" > omask="$3" > > > # set these to your inside interface network and netmask and ip > iif="vr0" > inet="192.168.2.0" > imask="255.255.255.0" > iip="192.168.2.21" > > # for not the natd target is us but change this if you > # change that in natd.conf > natd_target=${oip} > work_vpnserver=64.244.102.15 > > INTERCEPT=610 > INCOMING=14000 > OUTGOING=18000 > NATD2=8669 > SET=2 > > sysctl net.inet.ip.fw.enable=0 > ${fwcmd} -q delete ${INTERCEPT} > ${fwcmd} set disable ${SET} > # effectively clear it > ${fwcmd} set move 30 to ${SET} > > > # common spoofing code > # --------------- ALL PACKETS START HERE. ------------ > > > ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${INCOMING} ip from > any to any in recv ${oif} > ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${OUTGOING} ip from > any to any out xmit ${oif} > > #-------- Internal traffic. generally don't care > Add in a new incoming and outgoing section for the new interface > > #------- INCOMING > # don't allow packets from the wrong net! > ${fwcmd} add ${INCOMING} set ${SET} deny log all from "table(4)" > to any > > # in fact don't accept packets that are not for this interface > exactly > ${fwcmd} add set ${SET} deny log ip from any to not ${oip} > > # Allow access to our ssh from trusted places (work, freebsd > (sometimes)) > ${fwcmd} add set ${SET} pass tcp from "table(2)" to ${oip} 22 > setup keep-state > > # allow our DNS secondaries to get zone transfers > ${fwcmd} add set ${SET} pass tcp from "table(3)" to ${oip} 53 > setup keep-state > > # allow DNS requests, since we are authoratitive > ${fwcmd} add set ${SET} pass udp from any to ${oip} 53 > > # Allow setup of incoming email # not on this interface > > # me, DNS and root can start outgoing sessions and have > # them come in if there is a waiting socket > # !!@# Don't do this it breaks ntp from inside > # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 0 > # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 53 > # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 1000 > > # ignore any mention of RFC1918 nets on the outside interface > ${fwcmd} add set ${SET} deny log all from any to "table(1)" > # except the > ${fwcmd} add set ${SET} deny log not icmp from "table(1)" to any > > #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v INCOMING NAT POINT > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > # NAT anything that is left and trust NATD > ${fwcmd} add set ${SET} divert ${NATD2} all from any to any > > #After translation.. trust Nat to filter non matches > > # explicitly allow NAT-T from the vpn server to inside nets > ${fwcmd} add set ${SET} allow udp from ${work_vpnserver} to > "table(4)" > > # Allow TCP through if setup succeeded . > # bypass the logging step. too much data > ${fwcmd} add set ${SET} allow tcp from any to any established > > # take note of unexpected stuff. then drop it. > # hmm, NAtd must have let this through why? > ${fwcmd} add set ${SET} drop log ip from any to ${natd_target} > > # Allow IP fragments to pass through (NOPE) > # ${fwcmd} add set ${SET} pass all from any to any frag > > # XXX remove this if you turn on the target option on > # natd to allow a server > # Reject & Log all setup of incoming connections from the outside > # that have not been explicitly allowed above. > ${fwcmd} add set ${SET} deny log tcp from any to ${natd_target} > setup > > # anything here should be logged. it's intersting. > ${fwcmd} add set ${SET} count log ip from any to any > > # after that gauntlet, allow it to proceed. > ${fwcmd} add set ${SET} allow ip from any to any > > > > #----- OUTGOING > # Stop RFC1918 nets getting out to the outside interface > # except for the wierdness of our next hop being such an address. > ${fwcmd} add ${OUTGOING} set ${SET} allow icmp from ${oip} to > ${onet}:${omask} keep-state > ${fwcmd} add set ${SET} deny log all from any to "table(1)" > > # The firewall and inside can talk out if it wants to. > # these are local sessions by definition. > ${fwcmd} add set ${SET} pass all from ${oip} to any keep-state > > #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v OUTGOING NAT POINT > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > ${fwcmd} add set ${SET} divert ${NATD2} all from any to any out > recv ${iif} > > # just in case natd goes wierd. > ${fwcmd} add set ${SET} deny log all from "table(1)" to any > # in fact don't allow packets out that are not from this > interface exactly > ${fwcmd} add set ${SET} deny log ip from not ${oip} to any > ${fwcmd} add set ${SET} allow all from any to any > > ${fwcmd} set enable ${SET} > sysctl net.inet.ip.fw.enable=1 > > and here's rules for un untrusted tunnel > this file can also be run after the main one when hte tunnel is in use. > I'm not using this one at the moment, so I'm not sure it works but you can > get the idea.. > I add a separate script file for each interface.. and they slot in > separate rules as needed. > > #!/bin/sh > fwcmd="/sbin/ipfw" > > # Suck in the configuration variables. > if [ -z "${source_rc_confs_defined}" ]; then > if [ -r /etc/defaults/rc.conf ]; then > . /etc/defaults/rc.conf > source_rc_confs > elif [ -r /etc/rc.conf ]; then > . /etc/rc.conf > fi > fi > > > > # set these to your inside interface network and netmask and ip > iif="vr0" > inet="192.168.2.0" > imask="255.255.255.0" > iip="192.168.2.21" > > # set these to your outside interface network and netmask and ip > oif="tun0" > onet="192.168.36.0" > omask="24" > oip="l.m.n.o" > INTERCEPT=500 > INCOMING=4000 > OUTGOING=8000 > SET=1 > > # for now the natd target is us but change this if you > # change that in natd.conf > natd_target=${oip} > work_vpnserver=t.u.v.w > > sysctl net.inet.ip.fw.enable=0 > > #-------- Select direction and interface class > ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${INCOMING} ip from > any to any in recv ${oif} > ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${OUTGOING} ip from > any to any out xmit ${oif} > > > #------- INCOMING > # don't allow packets from the wrong net! > ${fwcmd} add ${INCOMING} set ${SET} deny log all from "table(4)" > to any > > # in fact don't accept packets that are not for this interface > exactly > ${fwcmd} add set ${SET} deny log ip from any to not ${oip} > > # Allow access to our ssh from trusted places (work, freebsd, > (sometimes)) > ${fwcmd} add set ${SET} pass tcp from "table(2)" to ${oip} 22 > setup keep-state > > # allow our DNS secondaries to get zone transfers > ${fwcmd} add set ${SET} pass tcp from "table(3)" to ${oip} 53 > setup keep-state > > # allow DNS requests, since we are authoratitive > ${fwcmd} add set ${SET} pass udp from any to ${oip} 53 > > # Allow setup of incoming email > > # julian and root can start outgoing sessions and have them come > in if there is a waiting socket :-) > ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 0 > ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 53 > ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 1000 > > # ignore any mention of RFC1918 nets on the outside interface > ${fwcmd} add set ${SET} deny log all from any to "table(1)" > ${fwcmd} add set ${SET} deny log not icmp from "table(1)" to any > > #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v INCOMING NAT POINT > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > # NAT anything that is left and trust NATD > ${fwcmd} add set ${SET} divert natd all from any to any > > #After translation > > # explicitly allow NAT-T from the vpn server to inside nets > ${fwcmd} add set ${SET} allow udp from ${work_vpnserver} to > "table(4)" > > # Allow TCP through if setup succeeded . > # bypass the logging step. too much data > ${fwcmd} add set ${SET} allow tcp from any to any established > > # take note of unexpected stuff. then drop it. > ${fwcmd} add set ${SET} drop log ip from any to ${natd_target} > > # Allow IP fragments to pass through (NOPE) > # ${fwcmd} add set ${SET} pass all from any to any frag > > # XXX remove this if you turn on the target option on > # natd to allow a server > # Reject & Log all setup of incoming connections from the outside > # that have not been explicitly allowed above. > ${fwcmd} add set ${SET} deny log tcp from any to ${natd_target} > setup > > # anything here should be logged. it's interesting. > ${fwcmd} add set ${SET} count log ip from any to any > > #currently slam that door .. this rule comes and goes depending on > if I need it. > ${fwcmd} add set ${SET} deny log ip from any to any > > # after that gauntlet, allow it to proceed. > ${fwcmd} add set ${SET} allow ip from any to any > > > > #----- OUTGOING > # Stop RFC1918 nets getting out to the outside interface > # except for the wierdness of our next hop being such an address. > ${fwcmd} add ${OUTGOING} set ${SET} allow icmp from ${oip} to > ${onet}/${omask} keep-state > ${fwcmd} add set ${SET} deny log all from any to "table(1)" > > # The firewall (and my laptop) can talk out if it wants to. > # these are local sessions by definition. > ${fwcmd} add set ${SET} pass all from ${oip} to any keep-state > # ${fwcmd} add set ${SET} pass udp from ${oip} to any keep-state > # ${fwcmd} add set ${SET} pass icmp from ${oip} to any keep-state > > # Allow NTP queries out in the world from the firewall. > # ${fwcmd} add set ${SET} pass udp from ${oip} to any 123 keep-state > > # Allow DNS queries out in the world from the firewall. > # ${fwcmd} add set ${SET} pass udp from ${oip} to any 53 keep-state > > #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v OUTGOING NAT POINT > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > ${fwcmd} add set ${SET} divert natd all from any to any out recv > ${iif} > > # just in case natd goes wierd. > ${fwcmd} add set ${SET} deny log all from "table(1)" to any > # in fact don't allow packets out that are not from this > interface exactly > ${fwcmd} add set ${SET} deny log ip from not ${oip} to any > ${fwcmd} add set ${SET} allow all from any to any > > ${fwcmd} set enable ${SET} > > sysctl net.inet.ip.fw.enable=1 > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 06:55:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2EF75D8 for ; Tue, 3 Feb 2015 06:55:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFBBEB56 for ; Tue, 3 Feb 2015 06:55:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t136tpli014368 for ; Tue, 3 Feb 2015 06:55:51 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t136tpAi014367; Tue, 3 Feb 2015 06:55:51 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 06:55:51 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Updated] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <69d3eb995cbe34a0fa0a8a6cd8a7c868@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTQcPc= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 06:55:52 -0000 hselasky added a reviewer: imp. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, bz, adrian, rwatson, imp Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 06:55:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF0B75ED for ; Tue, 3 Feb 2015 06:55:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC33AB61 for ; Tue, 3 Feb 2015 06:55:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t136tqRC014414 for ; Tue, 3 Feb 2015 06:55:52 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t136tqnH014413; Tue, 3 Feb 2015 06:55:52 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 06:55:52 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Updated] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTQcPg= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 06:55:53 -0000 hselasky set the repository for this revision to rS (FreeBSD src repository). REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, bz, adrian, rwatson, imp Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 09:30:20 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 784BF4F8; Tue, 3 Feb 2015 09:30:20 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 014F1CE8; Tue, 3 Feb 2015 09:30:20 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id DB66C5C003; Tue, 3 Feb 2015 12:30:06 +0300 (MSK) Message-ID: <54D0951F.2000304@FreeBSD.org> Date: Tue, 03 Feb 2015 12:30:07 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org> In-Reply-To: <54D06E5C.3090701@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 09:30:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 09:44, Julian Elischer wrote: >> So, stateful firewall with NAT could be rewritten like this: >> >> add 1000 skipto 2000 all from any to any out xmit outIface add >> 1010 skipto 3000 all from any to any in recv outIface >> >> add 2000 state-allow from any to any // keep-state is implied add >> 2010 nat NR from any to any // No "out" here! add 2020 allow all >> from any to any >> >> add 3000 nat NR from any to any add 3010 check-state // Use >> dynamic rule based on 2000 as "allow" here >> >> What do you think? > > I understand what you are trying to do.. but part of the usefulness > of the state runes is that they can be any action, not just allow > and deny. Typically, it is Ok that they are "terminal" actions. And typicaly you don't need anything non-terminal-now but "allow" in NAT case :) > record: (or record-only) it allows the rule to be stored, but the > action is not performed. on check-state, the rule is performed.. I think, it hould be option like "record-only" instead of "keep-state". Problem is, it adds "if" branch for EACH action (in kernel code). IMHO, it is very prohibitive. I've though about that, but decide it is too expensive to have "if (!iHaveRecordOnly || fromDynamic)" for EACH action, always. It could be done easily, of course. > so skipto 2000 ip from me to fred 80 record-only out xmit bge0 > would do nothing but record the session and on input the session > packet would skipto 2000 Nooooo, not "skipto" again :) > What I would find more useful, is separate state rules for each > interface. so you could not have the danger of a packet on > interface A adding a rule that eventually does something unexpected > on a packet on interface B. Still, in case of NAT and, especially, in case of multiple NATs with "nat global" added, it doesn't solve problem of ugliness of hacks we need use to add statefullness. > looking at my own rules I don't seem to have a problem.. You have "check-state" only once, on entrance, before all NATs, so it could work only for packets which don't need NAT. And looks like (correct me if I'm wrong) you don't try to track states of connections passed through NAT. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0JUfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePFCUP/jqRAvX00JUQyEV0hmffmh4w iTHeK8v56k76VTm2s/Gm2Mjt5EjqXdjKal5eZ6KfQrkPUBHSkmaA+Grig7AoSw81 2XUX2vj/ihkB8fpC7U5enG8UDDn/KV6rEq8nkHfZ0wEzIyGPXPCsC/8kGTotBnZo oI0JX9uehDmOgqdOL22jeSX3vgrMZu/V7G9ckrEadmSp7yyiPdwEkTqzZsyt8Df4 n6RT7ox0vezpdZDE0Xsx1zNU9iEd1ViT+gEPgSfHYiEyhml1bnv3qF5pPMZEtYEO /DG6RFfhel6gukrGZ2Yu7tUaGj+QEXXGz5syuxDmIUBzqdHLi9upoX0TbfDH2L3L KkcVyYdrcyEQwkeZO3gvugGLnNTRJMDOvrfPR8sgcfmWj2kaVYZZiA/SPr/76XqX ypCAHnaTbytnkOk0k6afjfofSQ8Gc5mPbll9N+uVkS3Ne11kf1uZKIUgsy/5rtw0 59D3Z5OyFJwYscMMjFkt/rAdLlaD2gd5Et/Jk751UO/x49VXdOz/6ErHZWvtg3io ku1E8W5SRow+EurWVBmIKkbcuCkUW2eaM30o6LYWwkYB8DdG79ihXfYep6Lj3074 1mvuPsWeouBdxbv9ZWu270aD3MmyNE5IL7aaf86XCa2gG4V+dZisw97v4ZRAHenZ YdcZpExF2wAV3VVAgO74 =tnKG -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 10:04:23 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAC4EDC3; Tue, 3 Feb 2015 10:04:23 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07C2DFA; Tue, 3 Feb 2015 10:04:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t13A4Fcb073244; Tue, 3 Feb 2015 21:04:16 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 3 Feb 2015 21:04:15 +1100 (EST) From: Ian Smith To: Lev Serebryakov Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny In-Reply-To: <54CFCD45.9070304@FreeBSD.org> Message-ID: <20150203205715.A38620@sola.nimnet.asn.au> References: <54CFCD45.9070304@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20150203205715.E38620@sola.nimnet.asn.au> Cc: freebsd-ipfw , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 10:04:23 -0000 On Mon, 2 Feb 2015 22:17:25 +0300, Lev Serebryakov wrote: > Now to make stateful firewall with NAT you need to make some not very > "readable" tricks to record state ("allow") of outbound connection > before NAT, but pass packet to NAT after that. I know two: > > (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 10:24:26 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DFF3136; Tue, 3 Feb 2015 10:24:26 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id C29B0357; Tue, 3 Feb 2015 10:24:25 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 1D6ED5C002; Tue, 3 Feb 2015 13:23:37 +0300 (MSK) Message-ID: <54D0A1AA.4080402@FreeBSD.org> Date: Tue, 03 Feb 2015 13:23:38 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> In-Reply-To: <20150203205715.A38620@sola.nimnet.asn.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 10:24:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 13:04, Ian Smith wrote: >> Now to make stateful firewall with NAT you need to make some not >> very "readable" tricks to record state ("allow") of outbound >> connection before NAT, but pass packet to NAT after that. I know >> two: >> >> (a) skipto-nat-allow pattern from many HOWOTOs > > Lev, can you provide references for these HOWTOs you refer to? > > I have a suspicion that some of them should be taken out and shot. google for "FreeBSD ipfw nat stateful" :) There are lot of them. Not real HOWTOs, but blog posts & alike. BTW, without new mechanism it is really hard to do such firewall, as we need action (nat) after "allow keep-state". It could be done with this ugly skip-to or with "allow keep-state" in INCOMING section of firewall, what is not much better, as I prefer to decide let packet out or not in OUTCOMING part of firewall and with "allow keep-state" in incoming path it flood state table with unused states. Another problem, that "keep-state" acts as "check-state" too, so you could not have ANOTHER "keep-state" before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with "keep-state", grrrrr, ugly!). - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KGqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePYvYQALeGCF9EuZKP3jLDaRwad+TO IhYq5I3xPPqU3eNEdQ6OqdFonVQ4mDB+UipZzspC/U5drf1qo2LkOF8oBNDlVDW4 2I+bgYStptIkpSoBOe5AGRYwO3jfec77GvXhR8cMeQZK2Z9NIazn5ZtFkdQyiiDU +b7pxBQ0SbbMUT3hubl4H+v93dMGfjnzrFg1aSY4/uYnmilb8plWN1o4BshZVMSz z1lrFSaorj4RNYxnpM6f6YtDDYx4TahA7+OILl/BvzmNoztWb5hKNX+1TGLZPcch QE19iix+8O75yuVEMim6FxZ7u6sRk+4PpL/WzCLC2PpPxP/AyiFRh4zw7Q34HDNm xPe4Nfzt5vDj0/2HYMY0q0UeSfVY/U0iB3TWmV/3HFObaLeibCgHqOFGmtCpHw5/ EXJX36mpffO1wI6ImPAvQ9C/wE6/JdoL8R3EPrsN3hdNmoVNIrnDuaeAwiQM6Ljm 4CHzsqlYYzyjzgyMmmJahaZ3Lrr0IjnVixC3/z46SfpPipaua8Pr+oZozC4WFmnn 4IhsXH+XK7fTbKQaZML6o9j6Bm0hs9g6mt+VSWCYWGCHh/V3DzTuH2BECUeC8lsD 9pwHv4x4vPbh7d/kBwAl75mOe3etb8nD/+i+x0oqbPn0T73DgdGgYPnIKqElOi4Y Ws6uw/Euno3YnSSds5Eb =FJZe -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 10:26:58 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B8D920F; Tue, 3 Feb 2015 10:26:58 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D021F36F; Tue, 3 Feb 2015 10:26:57 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id E79945C002; Tue, 3 Feb 2015 13:26:26 +0300 (MSK) Message-ID: <54D0A253.1080302@FreeBSD.org> Date: Tue, 03 Feb 2015 13:26:27 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org> <54D0951F.2000304@FreeBSD.org> In-Reply-To: <54D0951F.2000304@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 10:26:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 12:30, Lev Serebryakov wrote: > "keep-state". Problem is, it adds "if" branch for EACH action (in > kernel code). IMHO, it is very prohibitive. I've though about > that, but decide it is too expensive to have "if (!iHaveRecordOnly > || fromDynamic)" for EACH action, always. It could be done easily, > of course. Oh, I'm stupid! I know how to do "keep-state-only" cheap for fast path! I'll prepare new patch today or tomorrow. Also, I BADLY want "keep-state-but-dont-check" one. Sometimes it adds couple of "skipto" rules to avoid "keep-state" because it will trigger check too, even if MATCH will fail. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KJTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTEMP/R3MZ8AmqKA0h7pFPy5SCwjT /zhnjjRvk+sDpc5BJPA/xIXV8IBupCPBCDR8CvCcqbaxFBECTTbW+JHCaHB0idXf F7lI2fTjiXcx5EK3E1RkjJ8dbRuHLAiYttMA4e1YIZBidsflgX/wLIEexseeia1K Vqh0NLofJLgzZET+wDbDBNncgWSaUnyJyW05BtVDUi/kpHekpZg4zm71gfWAoLgl tROv3i0y1YfkulwzZ84BcegsEAPMqD11AhSYZayeF1Ozl5jBGXTpC4rhaOQNYl7n +Hcr828rOZFiP/b4p/QhHx0TAMdYm3oqxSXMtr8GzWK+q5cClk7vdBv2Nj2W5f43 jOaJhDHgy21HxKCmFKKvSg/ZMb43F21ZHh0hU4eVlAK+AH74cli8hISTzZo4KxwC g74vUIPQkKs177UB+Hx1ADxwmur9fzbJpWWcK5zd/bLKQ8klUfiVrXp4awqLHma5 z6mKH89pxG9IC8rHFODetgfyvCJCiI0VY8bYuR8zJ6ciyk4NLGVhLk/VlzPyap8Y IT8O+kYLCaOWPbJvR+Zqti+hnvsk+5JnGxa16tVUkxXiJfh7VfWt9dDQ12Z9At1t srjr79R9yEJ0aPYKZRT4Z3q+CPhJZ+TpZyCxX3QT0vJuzewrj+R0CwSPP2xaWUZ3 x+Z6nsvc0bx37IgR7vsx =DlMK -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 11:46:07 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 224C2759 for ; Tue, 3 Feb 2015 11:46:07 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D550FDE5 for ; Tue, 3 Feb 2015 11:46:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13Bk6Xd023858 for ; Tue, 3 Feb 2015 11:46:06 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13Bk6Z4023857; Tue, 3 Feb 2015 11:46:06 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 11:46:06 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <263427484074104a3f4e7c867fce352f@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTQtP4= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 11:46:07 -0000 rrs added inline comments. INLINE COMMENTS sys/kern/kern_timeout.c:789 Opps I will fix that thanks Ed! sys/kern/kern_timeout.c:1067-1069 Let me see if I can edit this comment a bit and make it more clear. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, imp, hselasky, adrian, jhb, kostikbel Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 11:57:10 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7575A2E for ; Tue, 3 Feb 2015 11:57:10 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 957A5F04 for ; Tue, 3 Feb 2015 11:57:10 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13BvABJ035281 for ; Tue, 3 Feb 2015 11:57:10 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13BvAIp035279; Tue, 3 Feb 2015 11:57:10 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 11:57:10 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Updated, 242 lines] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <883dc0b48a57680a3a8eefa6aa52357c@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTQt5Y= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 11:57:10 -0000 rrs updated this revision to Diff 3602. rrs added a comment. This revision now requires review to proceed. Ed: See if this comment clarification does not help a bit. Hans: I have no intention of *not* leaving the macro changes in here, this was a comment suggested by imp and I think its a good one! R CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1711?vs=3591&id=3602 REVISION DETAIL https://reviews.freebsd.org/D1711 AFFECTED FILES kern/kern_timeout.c sys/callout.h To: rrs, gnn, rwatson, sbruno, lstewart, imp, jhb, kostikbel, adrian, hselasky Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 12:06:25 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4D5FEDF for ; Tue, 3 Feb 2015 12:06:25 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9303BC2 for ; Tue, 3 Feb 2015 12:06:25 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13C6P5r045402 for ; Tue, 3 Feb 2015 12:06:25 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13C6PBN045401; Tue, 3 Feb 2015 12:06:25 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 12:06:25 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Updated, 241 lines] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <6e18d60f54d3173f95afe9e059cd52b8@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTQucE= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 12:06:25 -0000 rrs updated this revision to Diff 3603. rrs added a comment. Lets try this one more time to get line 789 right ;-) CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1711?vs=3602&id=3603 REVISION DETAIL https://reviews.freebsd.org/D1711 AFFECTED FILES kern/kern_timeout.c sys/callout.h To: rrs, gnn, rwatson, sbruno, lstewart, imp, jhb, hselasky, adrian, kostikbel Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 12:07:23 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A79AF94 for ; Tue, 3 Feb 2015 12:07:23 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31278E7 for ; Tue, 3 Feb 2015 12:07:23 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13C7Mmo046093 for ; Tue, 3 Feb 2015 12:07:22 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13C7Muk046092; Tue, 3 Feb 2015 12:07:22 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 12:07:22 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <45e1b90a9bbd08e691586863998870ad@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTQufo= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 12:07:23 -0000 hselasky accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, imp, jhb, adrian, kostikbel, hselasky Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 12:32:06 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BD797F1; Tue, 3 Feb 2015 12:32:06 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F8F3606; Tue, 3 Feb 2015 12:32:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t13CVwed078133; Tue, 3 Feb 2015 23:31:59 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 3 Feb 2015 23:31:58 +1100 (EST) From: Ian Smith To: Lev Serebryakov Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny In-Reply-To: <54D0A1AA.4080402@FreeBSD.org> Message-ID: <20150203231410.Y38620@sola.nimnet.asn.au> References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 12:32:06 -0000 On Tue, 3 Feb 2015 13:23:38 +0300, Lev Serebryakov wrote: > On 03.02.2015 13:04, Ian Smith wrote: > > >> Now to make stateful firewall with NAT you need to make some not > >> very "readable" tricks to record state ("allow") of outbound > >> connection before NAT, but pass packet to NAT after that. I know > >> two: > >> > >> (a) skipto-nat-allow pattern from many HOWOTOs > > > > Lev, can you provide references for these HOWTOs you refer to? > > > > I have a suspicion that some of them should be taken out and shot. > > google for "FreeBSD ipfw nat stateful" :) There are lot of them. Not > real HOWTOs, but blog posts & alike. As I suspected, most of them either are or refer to or are based on the handbook IPFW page, which I believe has caused more damage to the cause of IPFW adoption and usage than anything else. ipfw(8) is your friend, and pretty much your only friend in this regard. Of those, https://nileshgr.com/2014/12/07/freebsd-ipfw-nat-jails isn't bad. Many of the others are up to 10 years old and not much help. http://www.pl.freebsd.org/doc/handbook/firewalls-ipfw.html is an earlier version of https://www.freebsd.org/doc/handbook/firewalls-ipfw.html which has undergone significant improvement lately (compare), but still contains factual errors in the rulesets and very muddle-headed ideas regarding syslog and other things, IMHO. I'd best say no more on this topic; you can't discombobulate confusion. Cheers, Ian out > BTW, without new mechanism it is really hard to do such firewall, as > we need action (nat) after "allow keep-state". It could be done with > this ugly skip-to or with "allow keep-state" in INCOMING section of > firewall, what is not much better, as I prefer to decide let packet > out or not in OUTCOMING part of firewall and with "allow keep-state" > in incoming path it flood state table with unused states. > > Another problem, that "keep-state" acts as "check-state" too, so you > could not have ANOTHER "keep-state" before NAT in outgoing part or you > miss nat completely (sate is created in outgoing path, and then > checked before nat in outgoing path with "keep-state", grrrrr, ugly!). > > > - -- > // Lev Serebryakov AKA Black Lion From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 14:51:15 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16D4D9CA for ; Tue, 3 Feb 2015 14:51:15 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8459958 for ; Tue, 3 Feb 2015 14:51:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13EpEax060206 for ; Tue, 3 Feb 2015 14:51:14 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13EpEH3060205; Tue, 3 Feb 2015 14:51:14 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 14:51:14 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Updated, 68 lines] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTQ4GI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 14:51:15 -0000 hselasky updated this revision to Diff 3606. hselasky added a comment. Add context to patch. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1761?vs=3601&id=3606 REVISION DETAIL https://reviews.freebsd.org/D1761 AFFECTED FILES sys/netinet/ip_input.c sys/netinet/ip_output.c sys/netinet/tcp_input.c sys/netinet/tcp_lro.c sys/sys/mbuf.h To: hselasky, rmacklem, rrs, glebius, gnn, emaste, bz, adrian, rwatson, imp Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 15:10:48 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2B2776 for ; Tue, 3 Feb 2015 15:10:48 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3B35BE3 for ; Tue, 3 Feb 2015 15:10:48 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13FAmbP084391 for ; Tue, 3 Feb 2015 15:10:48 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13FAmJB084378; Tue, 3 Feb 2015 15:10:48 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 15:10:48 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Updated, 2, 384 lines] D1438: FreeBSD callout rewrite and cleanup Message-ID: <1d2ed4530cbea83f65d8cb029e798f3f@localhost.localdomain> X-Priority: 3 Thread-Topic: D1438: FreeBSD callout rewrite / cleanup X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: YzU3ODk0MGM0Y2E4NmE3NjY4YjJlZmFkM2UyIFTQ5Pg= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 15:10:49 -0000 hselasky updated this revision to Diff 3607. hselasky added a comment. Add full context to patch. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1438?vs=3574&id=3607 REVISION DETAIL https://reviews.freebsd.org/D1438 AFFECTED FILES share/man/man9/Makefile share/man/man9/timeout.9 sys/kern/init_main.c sys/kern/kern_condvar.c sys/kern/kern_lock.c sys/kern/kern_switch.c sys/kern/kern_synch.c sys/kern/kern_thread.c sys/kern/kern_timeout.c sys/kern/subr_sleepqueue.c sys/ofed/include/linux/completion.h sys/sys/_callout.h sys/sys/callout.h sys/sys/proc.h To: hselasky, jhb, adrian, markj, emaste, sbruno, imp, lstewart, rwatson, gnn, rrs, kostikbel, delphij, neel, erj Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 16:13:33 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3043A14A; Tue, 3 Feb 2015 16:13:33 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id C4A31608; Tue, 3 Feb 2015 16:13:32 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2CD2C5C002; Tue, 3 Feb 2015 19:13:16 +0300 (MSK) Message-ID: <54D0F39B.4070707@FreeBSD.org> Date: Tue, 03 Feb 2015 19:13:15 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw , freebsd-net Subject: [RFC][patch] New "keep-state-only" option Content-Type: multipart/mixed; boundary="------------050009060301010507000304" Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 16:13:33 -0000 This is a multi-part message in MIME format. --------------050009060301010507000304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ok, "allow-state"/"deny-state" was very limited idea. Here is more universal mechanism: new "keep-state-only" (aliased as "record-only") option, which works exactly as "keep-state" BUT cancel match of rule after state creation. It allows to write stateful + nat firewall as easy as: nat 1 config if outIface 1000 skipto 2000 in skipto 3000 out deny all from any to any // Safeguard 2000 skipto 4000 recv inIface skipto 6000 recv outIface deny all from any to any // Safeguard 3000 skipto 5000 xmit inIface skipto 7000 xmit outIface deny all from any to any // Safeguard 4000 // For sake of simplicity! // Real firewall will have some checks about local network here allow all from any to any deny all from any to any // Safeguard 5000 // For sake of simplicity! // Real firewall will have some checks about local network here allow all from any to any deny all from any to any // Safeguard 6000 deny all not dst-ip $EXT_IP nat 1 all from any to any // All enabled with "keep-state-only" at block 7000 before NAT check-state all from any to any // Here could be accept rules for our servers or servers in DMZ // Disable everything else deny all from any to any 7000 // Here goes rules which could DISABLE outbound external traffic // Create state for "check-state" at block 6000 and fallthrough allow keep-state-only allow src-ip $EXT_IP // Save NAT some work nat 1 all from any to any allow all from any to any deny all from any to any // Safeguard And variants with multiple NATs and "nat global" becomes as easy as this, too! No stupid "skipto", no "keep-state" at "incoming from local network" parts of firewall, nothing! P.S. I HATE this "all any to any" part! - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0POaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePR+gP/1Oxi+h7pi0UlnqfrKyfHJRS FUbrMNeR9NATnTwxIK1UxNT1kF3m7wiwnFlgwW7rwLtTviFB1wK/pfd38l2h4t/w qUbtyK4PFMCq8I6wAJIB0qUl3C/mN1rwc+LSJJyFM07R52snoQs6FvkIYkCz0fOy Cak1f/P+scc21IRhFvYJXMMDO/1Y1nkxZk/HdHbn1GELpTXuHugvL1T9hHl98sqO HKlHnvtqAVlyZn9Sv3uC9nsyjFA2sdOCtb67UGnPDV3CIs4Jwj5CSst5jbz13qFG aXF8ZSm0coPJMUjH1PSogZM9Xiq23yZ47V0mesBxQsHL24548jM/wKcsR3buDjP7 NJ2rqo2OBCzTu6VCK2oIY5j9A6vq1mu8+/eBs5jF4C2k0xHiw53Okou7zOCA0gJ+ z+VGZvD3la/+tFjacty7Ra7LLNA8kNCnRa0QML7LOJ1/99a4l3Z/uGFxy5zYnk7d p27Y85CAhTJQjkYZSGAiFD5SE4XxRqtSJ9OL89w7vLxoHqW0rqwi+DVrr9uvXQZS 8Z5G5iQARG4ygXuKsl6MlwChCXa3ucbOs41lorrug94cuVCwGg859zBZY3dpQsKz XIhtVQS21wPLxXywzIc678ar4uKVWNiaRWg+k57O7375gAszvqujRuTEcfHRf/T+ gHJJZt8Tc+en4bw8XItY =wOAJ -----END PGP SIGNATURE----- --------------050009060301010507000304 Content-Type: text/plain; charset=windows-1251; name="ipfw-state-only.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only.diff" SW5kZXg6IHNiaW4vaXBmdy9pcGZ3LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncuOAkocmV2aXNpb24gMjc4MTUxKQorKysgc2Jpbi9pcGZ3L2lwZncuOAkod29ya2luZyBj b3B5KQpAQCAtMTY2LDcgKzE2Niw4IEBACiBkZXBlbmRpbmcgb24gaG93IHRoZSBrZXJuZWwg aXMgY29uZmlndXJlZC4KIC5QcAogSWYgdGhlIHJ1bGVzZXQgaW5jbHVkZXMgb25lIG9yIG1v cmUgcnVsZXMgd2l0aCB0aGUKLS5DbSBrZWVwLXN0YXRlCisuQ20ga2VlcC1zdGF0ZSAsCisu Q20ga2VlcC1zdGF0ZS1vbmx5CiBvcgogLkNtIGxpbWl0CiBvcHRpb24sCkBAIC0xODAsNyAr MTgxLDggQEAKIER5bmFtaWMgcnVsZXMsIHdoaWNoIGhhdmUgYSBsaW1pdGVkIGxpZmV0aW1l LCBhcmUgY2hlY2tlZAogYXQgdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgYQogLkNtIGNoZWNr LXN0YXRlICwKLS5DbSBrZWVwLXN0YXRlCisuQ20ga2VlcC1zdGF0ZSAsCisuQ20ga2VlcC1z dGF0ZS1vbmx5CiBvcgogLkNtIGxpbWl0CiBydWxlLCBhbmQgYXJlIHR5cGljYWxseSB1c2Vk IHRvIG9wZW4gdGhlIGZpcmV3YWxsIG9uLWRlbWFuZCB0bwpAQCAtNTgyLDcgKzU4NCw4IEBA CiBwYWNrZXQgZGVsaXZlcnkuCiAuUHAKIE5vdGU6IHRoaXMgY29uZGl0aW9uIGlzIGNoZWNr ZWQgYmVmb3JlIGFueSBvdGhlciBjb25kaXRpb24sIGluY2x1ZGluZwotb25lcyBzdWNoIGFz IGtlZXAtc3RhdGUgb3IgY2hlY2stc3RhdGUgd2hpY2ggbWlnaHQgaGF2ZSBzaWRlIGVmZmVj dHMuCitvbmVzIHN1Y2ggYXMga2VlcC1zdGF0ZSwga2VlcC1zdGF0LW9ubHkgb3IgY2hlY2st c3RhdGUgd2hpY2ggbWlnaHQgaGF2ZQorc2lkZSBlZmZlY3RzLgogLkl0IENtIGxvZyBPcCBD bSBsb2dhbW91bnQgQXIgbnVtYmVyCiBQYWNrZXRzIG1hdGNoaW5nIGEgcnVsZSB3aXRoIHRo ZQogLkNtIGxvZwpAQCAtNzQ4LDcgKzc1MSw4IEBACiBJZiBubwogLkNtIGNoZWNrLXN0YXRl CiBydWxlIGlzIGZvdW5kLCB0aGUgZHluYW1pYyBydWxlc2V0IGlzIGNoZWNrZWQgYXQgdGhl IGZpcnN0Ci0uQ20ga2VlcC1zdGF0ZQorLkNtIGtlZXAtc3RhdGUgLAorLkNtIGtlZXAtc3Rh dGUtb25seSAsCiBvcgogLkNtIGxpbWl0CiBydWxlLgpAQCAtMTU4Myw2ICsxNTg3LDE0IEBA CiAuWHIgc3lzY3RsIDgKIHZhcmlhYmxlcyksIGFuZCB0aGUgbGlmZXRpbWUgaXMgcmVmcmVz aGVkIGV2ZXJ5IHRpbWUgYSBtYXRjaGluZwogcGFja2V0IGlzIGZvdW5kLgorLkl0IENtIGtl ZXAtc3RhdGUtb25seSB8IHJlY29yZC1vbmx5CitVcG9uIGEgbWF0Y2gsIHRoZSBmaXJld2Fs bCB3aWxsIGNyZWF0ZSBhIGR5bmFtaWMgcnVsZSBhcyBpZgorLkNtIGtlZXAtc3RhdGUKK3dh cyBzcGVjaWZpZWQsIGJ1dCBhZnRlciB0aGF0IG1hdGNoIGlzIGNhbmNlbGxlZCBhbmQgdGhl IHNlYXJjaAorY29udGludWVzIHdpdGggdGhlIG5leHQgcnVsZS4KK09uIGR5bmFtaWMgcnVs ZSBtYXRjaCBhY3Rpb24sIHNwZWNpZmllZCBpbiB0aGlzIHJ1bGUsCitwZXJmb3JtZWQgYXMg aWYgcnVsZSBjb250YWlucworLkNtIGtlZXAtc3RhdGUgLgogLkl0IENtIGxheWVyMgogTWF0 Y2hlcyBvbmx5IGxheWVyMiBwYWNrZXRzLCBpLmUuLCB0aG9zZSBwYXNzZWQgdG8KIC5ObQpJ bmRleDogc2Jpbi9pcGZ3L2lwZncyLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncyLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5jCSh3b3JraW5n IGNvcHkpCkBAIC0yOTIsNiArMjkyLDggQEAKIAl7ICJpbiIsCQkJVE9LX0lOIH0sCiAJeyAi bGltaXQiLAkJVE9LX0xJTUlUIH0sCiAJeyAia2VlcC1zdGF0ZSIsCQlUT0tfS0VFUFNUQVRF IH0sCisJeyAicmVjb3JkLXN0YXRlIiwJVE9LX1NUQVRFX09OTFkgfSwKKwl7ICJrZWVwLXN0 YXRlLW9ubHkiLAlUT0tfU1RBVEVfT05MWSB9LAogCXsgImJyaWRnZWQiLAkJVE9LX0xBWUVS MiB9LAogCXsgImxheWVyMiIsCQlUT0tfTEFZRVIyIH0sCiAJeyAib3V0IiwJCVRPS19PVVQg fSwKQEAgLTE5OTMsNiArMTk5NSwxMCBAQAogCQkJCWJwcmludGYoYnAsICIga2VlcC1zdGF0 ZSIpOwogCQkJCWJyZWFrOwogCisJCQljYXNlIE9fU1RBVEVfT05MWToKKwkJCQlicHJpbnRm KGJwLCAiIGtlZXAtc3RhdGUtb25seSIpOworCQkJCWJyZWFrOworCiAJCQljYXNlIE9fTElN SVQ6IHsKIAkJCQlzdHJ1Y3QgX3NfeCAqcCA9IGxpbWl0X21hc2tzOwogCQkJCWlwZndfaW5z bl9saW1pdCAqYyA9IChpcGZ3X2luc25fbGltaXQgKiljbWQ7CkBAIC00MzM1LDE0ICs0MzQx LDE2IEBACiAJCQlicmVhazsKIAogCQljYXNlIFRPS19LRUVQU1RBVEU6CisJCWNhc2UgVE9L X1NUQVRFX09OTFk6CiAJCQlpZiAob3Blbl9wYXIpCi0JCQkJZXJyeChFWF9VU0FHRSwgImtl ZXAtc3RhdGUgY2Fubm90IGJlIHBhcnQgIgorCQkJCWVycngoRVhfVVNBR0UsICJrZWVwLXN0 YXRlIG9yIGtlZXAtc3RhdGUtb25seSBjYW5ub3QgYmUgcGFydCAiCiAJCQkJICAgICJvZiBh biBvciBibG9jayIpOwogCQkJaWYgKGhhdmVfc3RhdGUpCiAJCQkJZXJyeChFWF9VU0FHRSwg Im9ubHkgb25lIG9mIGtlZXAtc3RhdGUgIgogCQkJCQkiYW5kIGxpbWl0IGlzIGFsbG93ZWQi KTsKIAkJCWhhdmVfc3RhdGUgPSBjbWQ7Ci0JCQlmaWxsX2NtZChjbWQsIE9fS0VFUF9TVEFU RSwgMCwgMCk7CisJCQlmaWxsX2NtZChjbWQsIGkgPT0gVE9LX0tFRVBTVEFURSA/CisJCQkJ T19LRUVQX1NUQVRFIDogT19TVEFURV9PTkxZLCAwLCAwKTsKIAkJCWJyZWFrOwogCiAJCWNh c2UgVE9LX0xJTUlUOiB7CkBAIC00NTg1LDcgKzQ1OTMsNyBAQAogCQlkc3QgPSBuZXh0X2Nt ZChkc3QsICZyYmxlbik7CiAJfQogCi0JLyogY29weSBhbGwgY29tbWFuZHMgYnV0IE9fTE9H LCBPX0tFRVBfU1RBVEUsIE9fTElNSVQsIE9fQUxUUSwgT19UQUcgKi8KKwkvKiBjb3B5IGFs bCBjb21tYW5kcyBidXQgT19MT0csIE9fS0VFUF9TVEFURSwgT19TVEFURV9PTkxZLCBPX0xJ TUlULCBPX0FMVFEsIE9fVEFHICovCiAJZm9yIChzcmMgPSAoaXBmd19pbnNuICopY21kYnVm OyBzcmMgIT0gY21kOyBzcmMgKz0gaSkgewogCQlpID0gRl9MRU4oc3JjKTsKIAkJQ0hFQ0tf UkJVRkxFTihpKTsKQEAgLTQ1OTMsNiArNDYwMSw3IEBACiAJCXN3aXRjaCAoc3JjLT5vcGNv ZGUpIHsKIAkJY2FzZSBPX0xPRzoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19T VEFURV9PTkxZOgogCQljYXNlIE9fTElNSVQ6CiAJCWNhc2UgT19BTFRROgogCQljYXNlIE9f VEFHOgpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9p cGZ3L2lwZncyLmgJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5oCSh3 b3JraW5nIGNvcHkpCkBAIC0yMjcsNiArMjI3LDcgQEAKIAlUT0tfTE9DSywKIAlUT0tfVU5M T0NLLAogCVRPS19WTElTVCwKKwlUT0tfU1RBVEVfT05MWSwKIH07CiAKIC8qCkluZGV4OiBz eXMvbmV0aW5ldC9pcF9mdy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L2lwX2Z3 LmgJKHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRpbmV0L2lwX2Z3LmgJKHdvcmtpbmcg Y29weSkKQEAgLTI1Miw2ICsyNTIsOCBAQAogCU9fRFNDUCwJCQkvKiAyIHUzMiA9IERTQ1Ag bWFzayAqLwogCU9fU0VURFNDUCwJCS8qIGFyZzE9RFNDUCB2YWx1ZSAqLwogCU9fSVBfRkxP V19MT09LVVAsCS8qIGFyZzE9dGFibGUgbnVtYmVyLCB1MzI9dmFsdWUJKi8KKwkKKwlPX1NU QVRFX09OTFksCQkvKiBub25lCQkJCSovCiAKIAlPX0xBU1RfT1BDT0RFCQkvKiBub3QgYW4g b3Bjb2RlIQkJKi8KIH07CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3Mi5jCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHJldmlzaW9uIDI3ODE1 MSkKKysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHdvcmtpbmcgY29weSkKQEAgLTIx MDcsOSArMjEwNyw5IEBACiAJCQkgKiBPX1RBRywgT19MT0cgYW5kIE9fQUxUUSBhY3Rpb24g cGFyYW1ldGVyczoKIAkJCSAqICAgcGVyZm9ybSBzb21lIGFjdGlvbiBhbmQgc2V0IG1hdGNo ID0gMTsKIAkJCSAqCi0JCQkgKiBPX0xJTUlUIGFuZCBPX0tFRVBfU1RBVEU6IHRoZXNlIG9w Y29kZXMgYXJlCi0JCQkgKiAgIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQg cmlnaHQKLQkJCSAqICAgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgor CQkJICogT19MSU1JVCwgT19LRUVQX1NUQVRFIGFuZCBPX1NUQVRFX09OTFk6IHRoZXNlCisJ CQkgKiAgIG9wY29kZXMgYXJlIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQK KwkJCSAqICAgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgog CQkJICogICBUaGVzZSBvcGNvZGVzIHRyeSB0byBpbnN0YWxsIGFuIGVudHJ5IGluIHRoZQog CQkJICogICBzdGF0ZSB0YWJsZXM7IGlmIHN1Y2Nlc3NmdWwsIHdlIGNvbnRpbnVlIHdpdGgK IAkJCSAqICAgdGhlIG5leHQgb3Bjb2RlIChtYXRjaD0xOyBicmVhazspLCBvdGhlcndpc2UK QEAgLTIxMjYsOSArMjEyNiwyMCBAQAogCQkJICogICBmdXJ0aGVyIGluc3RhbmNlcyBvZiB0 aGVzZSBvcGNvZGVzIGJlY29tZSBOT1BzLgogCQkJICogICBUaGUganVtcCB0byB0aGUgbmV4 dCBydWxlIGlzIGRvbmUgYnkgc2V0dGluZwogCQkJICogICBsPTAsIGNtZGxlbj0wLgorCQkJ ICoKKwkJCSAqIE9fU1RBVEVfT05MWTogdGhpcyBvcGNvZGUgaXMgbm90IHJlYWwgJ2FjdGlv bicKKwkJCSAqICB0b28sIGFuZCBpcyBzdG9yZWQgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9u JworCQkJICogIHBhcnQgb2YgdGhlIHJ1bGUsIHJpZ2h0IGFmdGVyIE9fS0VFUF9TVEFURQor CQkJICogIG9wY29kZS4gSXQgY2F1c2VzIG1hdGNoIGZhaWx1cmUgc28gcmVhbAorCQkJICog ICdhY3Rpb24nIGNvdWxkIGJlIGV4ZWN1dGVkIG9ubHkgaWYgcnVsZQorCQkJICogIGlzIGNo ZWNrZWQgdmlhIGR5bmFtaWMgcnVsZSBmcm9tIHN0YXRlCisJCQkgKiAgdGFibGUsIGFzIGlu IHN1Y2ggY2FzZSBleGVjdXRpb24gc3RhcnRzCisJCQkgKiAgZnJvbSB0cnVlICdhY3Rpb24n IG9wY29kZSBkaXJlY3RseS4KKwkJCSAqICAgCiAJCQkgKi8KIAkJCWNhc2UgT19MSU1JVDoK IAkJCWNhc2UgT19LRUVQX1NUQVRFOgorCQkJY2FzZSBPX1NUQVRFX09OTFk6CiAJCQkJaWYg KGlwZndfaW5zdGFsbF9zdGF0ZShjaGFpbiwgZiwKIAkJCQkgICAgKGlwZndfaW5zbl9saW1p dCAqKWNtZCwgYXJncywgdGFibGVhcmcpKSB7CiAJCQkJCS8qIGVycm9yIG9yIGxpbWl0IHZp b2xhdGlvbiAqLwpAQCAtMjEzNiw3ICsyMTQ3LDExIEBACiAJCQkJCWwgPSAwOwkvKiBleGl0 IGlubmVyIGxvb3AgKi8KIAkJCQkJZG9uZSA9IDE7IC8qIGV4aXQgb3V0ZXIgbG9vcCAqLwog CQkJCX0KLQkJCQltYXRjaCA9IDE7CisJCQkJaWYgKGNtZC0+b3Bjb2RlID09IE9fU1RBVEVf T05MWSkgeworCQkJCQlsID0gMDsJLyogZXhpdCBpbm5lciBsb29wICovCisJCQkJCW1hdGNo ID0gMDsKKwkJCQl9IGVsc2UKKwkJCQkJbWF0Y2ggPSAxOwogCQkJCWJyZWFrOwogCiAJCQlj YXNlIE9fUFJPQkVfU1RBVEU6CkBAIC0yMTg4LDYgKzIyMDMsNyBAQAogCQkJCWJyZWFrOwog CiAJCQljYXNlIE9fQUNDRVBUOgorCiAJCQkJcmV0dmFsID0gMDsJLyogYWNjZXB0ICovCiAJ CQkJbCA9IDA7CQkvKiBleGl0IGlubmVyIGxvb3AgKi8KIAkJCQlkb25lID0gMTsJLyogZXhp dCBvdXRlciBsb29wICovCkBAIC0yNTM3LDcgKzI1NTMsNyBAQAogCQkJCWRvbmUgPSAxOwkv KiBleGl0IG91dGVyIGxvb3AgKi8KIAkJCQlicmVhazsKIAkJCX0KLQorCQkJCiAJCQlkZWZh dWx0OgogCQkJCXBhbmljKCItLSB1bmtub3duIG9wY29kZSAlZFxuIiwgY21kLT5vcGNvZGUp OwogCQkJfSAvKiBlbmQgb2Ygc3dpdGNoKCkgb24gb3Bjb2RlcyAqLwpJbmRleDogc3lzL25l dHBmaWwvaXBmdy9pcF9md19keW5hbWljLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldHBm aWwvaXBmdy9pcF9md19keW5hbWljLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRw ZmlsL2lwZncvaXBfZndfZHluYW1pYy5jCSh3b3JraW5nIGNvcHkpCkBAIC03MDgsNiArNzA4 LDcgQEAKIAogCXN3aXRjaCAoY21kLT5vLm9wY29kZSkgewogCWNhc2UgT19LRUVQX1NUQVRF OgkvKiBiaWRpciBydWxlICovCisJY2FzZSBPX1NUQVRFX09OTFk6CiAJCXEgPSBhZGRfZHlu X3J1bGUoJmFyZ3MtPmZfaWQsIGksIE9fS0VFUF9TVEFURSwgcnVsZSk7CiAJCWJyZWFrOwog CkBAIC0xMzU3LDYgKzEzNTgsNyBAQAogCQlzd2l0Y2ggKGNtZC0+b3Bjb2RlKSB7CiAJCWNh c2UgT19MSU1JVDoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19TVEFURV9PTkxZ OgogCQljYXNlIE9fUFJPQkVfU1RBVEU6CiAJCWNhc2UgT19DSEVDS19TVEFURToKIAkJCXJl dHVybiAoMSk7CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYwkocmV2aXNp b24gMjc4MTUxKQorKysgc3lzL25ldHBmaWwvaXBmdy9pcF9md19zb2Nrb3B0LmMJKHdvcmtp bmcgY29weSkKQEAgLTE0MzMsNiArMTQzMyw3IEBACiAJCXN3aXRjaCAoY21kLT5vcGNvZGUp IHsKIAkJY2FzZSBPX1BST0JFX1NUQVRFOgogCQljYXNlIE9fS0VFUF9TVEFURToKKwkJY2Fz ZSBPX1NUQVRFX09OTFk6CiAJCWNhc2UgT19QUk9UTzoKIAkJY2FzZSBPX0lQX1NSQ19NRToK IAkJY2FzZSBPX0lQX0RTVF9NRToK --------------050009060301010507000304 Content-Type: application/octet-stream; name="ipfw-state-only.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only.diff.sig" iQJ8BAABCgBmBQJU0POaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFFQUIwM0M1OEJGREM0 NzhGAAoJEOqwPFi/3EeP+IYP/34Ksov2rvdf1N29a/AjpP64aqeG78LcIeiSem9Ai4s0P3tB xNQfUSmSUZh6C2wsRCxXP6ee3oMOSc4jbETBaedYHU446I0iX/GvD04SvHyyramYf+nU3gXq SF7GF5DbN3XHfqpihunaijLLZQz6zhwLuwPPSeLFG2xccc4o/8M+P6UHbyLDQNfOHR9YefmK 4bS7llfioqcDwb2bvmcD07wAXCxcKDzkefRcq3qyaPkIwxQ+A1CiTtyySpk6HjvEs1VogKRk 5iZbcAszmLMemIpXTUwNrScGaeCrnyCatAjtKTe9u26VI7X0XRP633a+/E/C7JJ6gHgWrmXF E9XVuaz7lWbjdsIlyGi1AW7fjzUxPCBoLopnwpqL0d3WX43OykR0U/x8euizlseGjnd13sWn Oly5i9SZAPJzvwR4F9wtmBgbHxqZu6fn1uC0xQPcjJsz/lsRno0lVFCUzmGNwPKJS4xvUSaq FfET86rxuzVQUhRHGupzMsqlKtAa7DTD/RSwVh05CMtoiGao7KR46nmly6fccGY4a2Gsvphh vR/xi4AdyqA/0+hPokBr/br1CGUZ72IkFs7h4tbG1u6Y2J1BED+hLb3ccOThTovQW9JCkK6l Osgt9KrWxAWsavIpTWljlWni8fi6cEULZGclx9yKUBizx/ht+8gHE+cj9xdy --------------050009060301010507000304-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 16:46:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC230A2E for ; Tue, 3 Feb 2015 16:46:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A399A905 for ; Tue, 3 Feb 2015 16:46:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13Gkp2d083439 for ; Tue, 3 Feb 2015 16:46:51 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13Gkps5083438; Tue, 3 Feb 2015 16:46:51 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 16:46:51 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <211485a5dc5f1a92b131e69537057582@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTQ+3s= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 16:46:51 -0000 adrian accepted this revision. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, imp, jhb, kostikbel, hselasky, adrian Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 16:56:07 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 147ACCC1; Tue, 3 Feb 2015 16:56:07 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9050499B; Tue, 3 Feb 2015 16:56:06 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 273055C002; Tue, 3 Feb 2015 19:55:57 +0300 (MSK) Message-ID: <54D0FD9B.5000108@FreeBSD.org> Date: Tue, 03 Feb 2015 19:55:55 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option (version 2) References: <54D0F39B.4070707@FreeBSD.org> In-Reply-To: <54D0F39B.4070707@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------050501000709010809070907" Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 16:56:07 -0000 This is a multi-part message in MIME format. --------------050501000709010809070907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 19:13, Lev Serebryakov wrote: > Ok, "allow-state"/"deny-state" was very limited idea. Here is more > universal mechanism: new "keep-state-only" (aliased as > "record-only") option, which works exactly as "keep-state" BUT > cancel match of rule after state creation. It allows to write > stateful + nat firewall as easy as: To work as expected, "keep-state-only" should not imply "check-state" in opposite to "keep-state". - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0P2bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePkkoQAJHlybB+Hmcae64Bu5CyimWy FJsicjr/DkNLhzAVJAglslBqgEkSrN2CiYTaASMMTmg6bj8RL6LLHWm0v/bAYQQR lMGqCCcz+NvKjrB2D4egRYkA4NHGQ60Lj4O4YfsNOc9Jrsyn7RAqVc9vwMXT/GvN GmDgVqsgA+IWSNZ4flE/MbnkZ8tq/jztuxaQneeKq6qmT9HaiNN8QeNrecO0kghz GXZCXTGVgoguv4K/SDTkqcKapL7vP1mzRuR34FQcN/Mmj4lJ9Mdk2JNzIg0YHBZ+ HzvRvoNBHJfgw1G5ydORGOeIBgd5XCzlYTws2dboksLrd3taF4emDGjpvzn+Qwzd X7B2hRnSOByM5j8LfctO2E7Zj7zPDtVtlZ3YsCpKvWzCdtSthzQAlvB/iE9CBOis JAXbINONngevwwrWqCsZCxgXCGSrp9scGHY7Es02M2Pov6GSzXtPq1349SmFrH5I J/ijTfV8e0kNnwBHfy/jf5wpXNQSV93IqRwDNp5jG+0qtDL2ZZNhMamELauWhbhB nTJ+Og2TsPeOSp88/Jb6bW+pIsDQ7XIxdBNFC0j9lU/jFwNIfAK5xkvc239IsqeC ylQGghwiGl9E4P3yIhLa2OAUdCy9J+dw8ZlyBkS3pN27j/RIoyMvkAA5l8i6dVRR AEfyn36tKaR/BEUkGN5g =9avV -----END PGP SIGNATURE----- --------------050501000709010809070907 Content-Type: text/plain; charset=windows-1251; name="ipfw-state-only-v2.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only-v2.diff" SW5kZXg6IHNiaW4vaXBmdy9pcGZ3LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncuOAkocmV2aXNpb24gMjc4MTUxKQorKysgc2Jpbi9pcGZ3L2lwZncuOAkod29ya2luZyBj b3B5KQpAQCAtMTY2LDcgKzE2Niw4IEBACiBkZXBlbmRpbmcgb24gaG93IHRoZSBrZXJuZWwg aXMgY29uZmlndXJlZC4KIC5QcAogSWYgdGhlIHJ1bGVzZXQgaW5jbHVkZXMgb25lIG9yIG1v cmUgcnVsZXMgd2l0aCB0aGUKLS5DbSBrZWVwLXN0YXRlCisuQ20ga2VlcC1zdGF0ZSAsCisu Q20ga2VlcC1zdGF0ZS1vbmx5CiBvcgogLkNtIGxpbWl0CiBvcHRpb24sCkBAIC01ODIsNyAr NTgzLDggQEAKIHBhY2tldCBkZWxpdmVyeS4KIC5QcAogTm90ZTogdGhpcyBjb25kaXRpb24g aXMgY2hlY2tlZCBiZWZvcmUgYW55IG90aGVyIGNvbmRpdGlvbiwgaW5jbHVkaW5nCi1vbmVz IHN1Y2ggYXMga2VlcC1zdGF0ZSBvciBjaGVjay1zdGF0ZSB3aGljaCBtaWdodCBoYXZlIHNp ZGUgZWZmZWN0cy4KK29uZXMgc3VjaCBhcyBrZWVwLXN0YXRlLCBrZWVwLXN0YXQtb25seSBv ciBjaGVjay1zdGF0ZSB3aGljaCBtaWdodCBoYXZlCitzaWRlIGVmZmVjdHMuCiAuSXQgQ20g bG9nIE9wIENtIGxvZ2Ftb3VudCBBciBudW1iZXIKIFBhY2tldHMgbWF0Y2hpbmcgYSBydWxl IHdpdGggdGhlCiAuQ20gbG9nCkBAIC0xNTgzLDYgKzE1ODUsMTggQEAKIC5YciBzeXNjdGwg OAogdmFyaWFibGVzKSwgYW5kIHRoZSBsaWZldGltZSBpcyByZWZyZXNoZWQgZXZlcnkgdGlt ZSBhIG1hdGNoaW5nCiBwYWNrZXQgaXMgZm91bmQuCisuSXQgQ20ga2VlcC1zdGF0ZS1vbmx5 IHwgcmVjb3JkLW9ubHkKK1Vwb24gYSBtYXRjaCwgdGhlIGZpcmV3YWxsIHdpbGwgY3JlYXRl IGEgZHluYW1pYyBydWxlIGFzIGlmCisuQ20ga2VlcC1zdGF0ZQord2FzIHNwZWNpZmllZCwg YnV0IGFmdGVyIHRoYXQgbWF0Y2ggaXMgY2FuY2VsbGVkIGFuZCB0aGUgc2VhcmNoCitjb250 aW51ZXMgd2l0aCB0aGUgbmV4dCBydWxlLgorT24gZHluYW1pYyBydWxlIG1hdGNoIGFjdGlv biwgc3BlY2lmaWVkIGluIHRoaXMgcnVsZSwKK3BlcmZvcm1lZCBhcyBpZiBydWxlIGNvbnRh aW5zCisuQ20ga2VlcC1zdGF0ZSAuCitUaGlzIG9wdGlvbiBkb2Vzbid0IGFjdCBhcworLkNt IGNoZWNrLXN0YXRlCitpbiBjb250cmFzdCB0bworLkNtIGtlZXAtc3RhdGUgLgogLkl0IENt IGxheWVyMgogTWF0Y2hlcyBvbmx5IGxheWVyMiBwYWNrZXRzLCBpLmUuLCB0aG9zZSBwYXNz ZWQgdG8KIC5ObQpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c2Jpbi9pcGZ3L2lwZncyLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3 Mi5jCSh3b3JraW5nIGNvcHkpCkBAIC0yOTIsNiArMjkyLDggQEAKIAl7ICJpbiIsCQkJVE9L X0lOIH0sCiAJeyAibGltaXQiLAkJVE9LX0xJTUlUIH0sCiAJeyAia2VlcC1zdGF0ZSIsCQlU T0tfS0VFUFNUQVRFIH0sCisJeyAicmVjb3JkLXN0YXRlIiwJVE9LX1NUQVRFX09OTFkgfSwK Kwl7ICJrZWVwLXN0YXRlLW9ubHkiLAlUT0tfU1RBVEVfT05MWSB9LAogCXsgImJyaWRnZWQi LAkJVE9LX0xBWUVSMiB9LAogCXsgImxheWVyMiIsCQlUT0tfTEFZRVIyIH0sCiAJeyAib3V0 IiwJCVRPS19PVVQgfSwKQEAgLTE5OTMsNiArMTk5NSwxMCBAQAogCQkJCWJwcmludGYoYnAs ICIga2VlcC1zdGF0ZSIpOwogCQkJCWJyZWFrOwogCisJCQljYXNlIE9fU1RBVEVfT05MWToK KwkJCQlicHJpbnRmKGJwLCAiIGtlZXAtc3RhdGUtb25seSIpOworCQkJCWJyZWFrOworCiAJ CQljYXNlIE9fTElNSVQ6IHsKIAkJCQlzdHJ1Y3QgX3NfeCAqcCA9IGxpbWl0X21hc2tzOwog CQkJCWlwZndfaW5zbl9saW1pdCAqYyA9IChpcGZ3X2luc25fbGltaXQgKiljbWQ7CkBAIC00 MzM1LDE0ICs0MzQxLDE2IEBACiAJCQlicmVhazsKIAogCQljYXNlIFRPS19LRUVQU1RBVEU6 CisJCWNhc2UgVE9LX1NUQVRFX09OTFk6CiAJCQlpZiAob3Blbl9wYXIpCi0JCQkJZXJyeChF WF9VU0FHRSwgImtlZXAtc3RhdGUgY2Fubm90IGJlIHBhcnQgIgorCQkJCWVycngoRVhfVVNB R0UsICJrZWVwLXN0YXRlIG9yIGtlZXAtc3RhdGUtb25seSBjYW5ub3QgYmUgcGFydCAiCiAJ CQkJICAgICJvZiBhbiBvciBibG9jayIpOwogCQkJaWYgKGhhdmVfc3RhdGUpCiAJCQkJZXJy eChFWF9VU0FHRSwgIm9ubHkgb25lIG9mIGtlZXAtc3RhdGUgIgogCQkJCQkiYW5kIGxpbWl0 IGlzIGFsbG93ZWQiKTsKIAkJCWhhdmVfc3RhdGUgPSBjbWQ7Ci0JCQlmaWxsX2NtZChjbWQs IE9fS0VFUF9TVEFURSwgMCwgMCk7CisJCQlmaWxsX2NtZChjbWQsIGkgPT0gVE9LX0tFRVBT VEFURSA/CisJCQkJT19LRUVQX1NUQVRFIDogT19TVEFURV9PTkxZLCAwLCAwKTsKIAkJCWJy ZWFrOwogCiAJCWNhc2UgVE9LX0xJTUlUOiB7CkBAIC00NTgwLDEyICs0NTg4LDEzIEBACiAJ LyoKIAkgKiBnZW5lcmF0ZSBPX1BST0JFX1NUQVRFIGlmIG5lY2Vzc2FyeQogCSAqLwotCWlm IChoYXZlX3N0YXRlICYmIGhhdmVfc3RhdGUtPm9wY29kZSAhPSBPX0NIRUNLX1NUQVRFKSB7 CisJaWYgKGhhdmVfc3RhdGUgJiYgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fQ0hFQ0tfU1RB VEUgJiYKKwkgICAgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fU1RBVEVfT05MWSkgewogCQlm aWxsX2NtZChkc3QsIE9fUFJPQkVfU1RBVEUsIDAsIDApOwogCQlkc3QgPSBuZXh0X2NtZChk c3QsICZyYmxlbik7CiAJfQogCi0JLyogY29weSBhbGwgY29tbWFuZHMgYnV0IE9fTE9HLCBP X0tFRVBfU1RBVEUsIE9fTElNSVQsIE9fQUxUUSwgT19UQUcgKi8KKwkvKiBjb3B5IGFsbCBj b21tYW5kcyBidXQgT19MT0csIE9fS0VFUF9TVEFURSwgT19TVEFURV9PTkxZLCBPX0xJTUlU LCBPX0FMVFEsIE9fVEFHICovCiAJZm9yIChzcmMgPSAoaXBmd19pbnNuICopY21kYnVmOyBz cmMgIT0gY21kOyBzcmMgKz0gaSkgewogCQlpID0gRl9MRU4oc3JjKTsKIAkJQ0hFQ0tfUkJV RkxFTihpKTsKQEAgLTQ1OTMsNiArNDYwMiw3IEBACiAJCXN3aXRjaCAoc3JjLT5vcGNvZGUp IHsKIAkJY2FzZSBPX0xPRzoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19TVEFU RV9PTkxZOgogCQljYXNlIE9fTElNSVQ6CiAJCWNhc2UgT19BTFRROgogCQljYXNlIE9fVEFH OgpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3 L2lwZncyLmgJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5oCSh3b3Jr aW5nIGNvcHkpCkBAIC0yMjcsNiArMjI3LDcgQEAKIAlUT0tfTE9DSywKIAlUT0tfVU5MT0NL LAogCVRPS19WTElTVCwKKwlUT0tfU1RBVEVfT05MWSwKIH07CiAKIC8qCkluZGV4OiBzeXMv bmV0aW5ldC9pcF9mdy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L2lwX2Z3LmgJ KHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRpbmV0L2lwX2Z3LmgJKHdvcmtpbmcgY29w eSkKQEAgLTI1Miw2ICsyNTIsOCBAQAogCU9fRFNDUCwJCQkvKiAyIHUzMiA9IERTQ1AgbWFz ayAqLwogCU9fU0VURFNDUCwJCS8qIGFyZzE9RFNDUCB2YWx1ZSAqLwogCU9fSVBfRkxPV19M T09LVVAsCS8qIGFyZzE9dGFibGUgbnVtYmVyLCB1MzI9dmFsdWUJKi8KKwkKKwlPX1NUQVRF X09OTFksCQkvKiBub25lCQkJCSovCiAKIAlPX0xBU1RfT1BDT0RFCQkvKiBub3QgYW4gb3Bj b2RlIQkJKi8KIH07CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3Mi5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHJldmlzaW9uIDI3ODE1MSkK KysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHdvcmtpbmcgY29weSkKQEAgLTIxMDcs OSArMjEwNyw5IEBACiAJCQkgKiBPX1RBRywgT19MT0cgYW5kIE9fQUxUUSBhY3Rpb24gcGFy YW1ldGVyczoKIAkJCSAqICAgcGVyZm9ybSBzb21lIGFjdGlvbiBhbmQgc2V0IG1hdGNoID0g MTsKIAkJCSAqCi0JCQkgKiBPX0xJTUlUIGFuZCBPX0tFRVBfU1RBVEU6IHRoZXNlIG9wY29k ZXMgYXJlCi0JCQkgKiAgIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQgcmln aHQKLQkJCSAqICAgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgorCQkJ ICogT19MSU1JVCwgT19LRUVQX1NUQVRFIGFuZCBPX1NUQVRFX09OTFk6IHRoZXNlCisJCQkg KiAgIG9wY29kZXMgYXJlIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQKKwkJ CSAqICAgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgogCQkJ ICogICBUaGVzZSBvcGNvZGVzIHRyeSB0byBpbnN0YWxsIGFuIGVudHJ5IGluIHRoZQogCQkJ ICogICBzdGF0ZSB0YWJsZXM7IGlmIHN1Y2Nlc3NmdWwsIHdlIGNvbnRpbnVlIHdpdGgKIAkJ CSAqICAgdGhlIG5leHQgb3Bjb2RlIChtYXRjaD0xOyBicmVhazspLCBvdGhlcndpc2UKQEAg LTIxMjYsOSArMjEyNiwyMCBAQAogCQkJICogICBmdXJ0aGVyIGluc3RhbmNlcyBvZiB0aGVz ZSBvcGNvZGVzIGJlY29tZSBOT1BzLgogCQkJICogICBUaGUganVtcCB0byB0aGUgbmV4dCBy dWxlIGlzIGRvbmUgYnkgc2V0dGluZwogCQkJICogICBsPTAsIGNtZGxlbj0wLgorCQkJICoK KwkJCSAqIE9fU1RBVEVfT05MWTogdGhpcyBvcGNvZGUgaXMgbm90IHJlYWwgJ2FjdGlvbicK KwkJCSAqICB0b28sIGFuZCBpcyBzdG9yZWQgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9uJwor CQkJICogIHBhcnQgb2YgdGhlIHJ1bGUsIHJpZ2h0IGFmdGVyIE9fS0VFUF9TVEFURQorCQkJ ICogIG9wY29kZS4gSXQgY2F1c2VzIG1hdGNoIGZhaWx1cmUgc28gcmVhbAorCQkJICogICdh Y3Rpb24nIGNvdWxkIGJlIGV4ZWN1dGVkIG9ubHkgaWYgcnVsZQorCQkJICogIGlzIGNoZWNr ZWQgdmlhIGR5bmFtaWMgcnVsZSBmcm9tIHN0YXRlCisJCQkgKiAgdGFibGUsIGFzIGluIHN1 Y2ggY2FzZSBleGVjdXRpb24gc3RhcnRzCisJCQkgKiAgZnJvbSB0cnVlICdhY3Rpb24nIG9w Y29kZSBkaXJlY3RseS4KKwkJCSAqICAgCiAJCQkgKi8KIAkJCWNhc2UgT19MSU1JVDoKIAkJ CWNhc2UgT19LRUVQX1NUQVRFOgorCQkJY2FzZSBPX1NUQVRFX09OTFk6CiAJCQkJaWYgKGlw ZndfaW5zdGFsbF9zdGF0ZShjaGFpbiwgZiwKIAkJCQkgICAgKGlwZndfaW5zbl9saW1pdCAq KWNtZCwgYXJncywgdGFibGVhcmcpKSB7CiAJCQkJCS8qIGVycm9yIG9yIGxpbWl0IHZpb2xh dGlvbiAqLwpAQCAtMjEzNiw3ICsyMTQ3LDExIEBACiAJCQkJCWwgPSAwOwkvKiBleGl0IGlu bmVyIGxvb3AgKi8KIAkJCQkJZG9uZSA9IDE7IC8qIGV4aXQgb3V0ZXIgbG9vcCAqLwogCQkJ CX0KLQkJCQltYXRjaCA9IDE7CisJCQkJaWYgKGNtZC0+b3Bjb2RlID09IE9fU1RBVEVfT05M WSkgeworCQkJCQlsID0gMDsJLyogZXhpdCBpbm5lciBsb29wICovCisJCQkJCW1hdGNoID0g MDsKKwkJCQl9IGVsc2UKKwkJCQkJbWF0Y2ggPSAxOwogCQkJCWJyZWFrOwogCiAJCQljYXNl IE9fUFJPQkVfU1RBVEU6CkBAIC0yMTg4LDYgKzIyMDMsNyBAQAogCQkJCWJyZWFrOwogCiAJ CQljYXNlIE9fQUNDRVBUOgorCiAJCQkJcmV0dmFsID0gMDsJLyogYWNjZXB0ICovCiAJCQkJ bCA9IDA7CQkvKiBleGl0IGlubmVyIGxvb3AgKi8KIAkJCQlkb25lID0gMTsJLyogZXhpdCBv dXRlciBsb29wICovCkBAIC0yNTM3LDcgKzI1NTMsNyBAQAogCQkJCWRvbmUgPSAxOwkvKiBl eGl0IG91dGVyIGxvb3AgKi8KIAkJCQlicmVhazsKIAkJCX0KLQorCQkJCiAJCQlkZWZhdWx0 OgogCQkJCXBhbmljKCItLSB1bmtub3duIG9wY29kZSAlZFxuIiwgY21kLT5vcGNvZGUpOwog CQkJfSAvKiBlbmQgb2Ygc3dpdGNoKCkgb24gb3Bjb2RlcyAqLwpJbmRleDogc3lzL25ldHBm aWwvaXBmdy9pcF9md19keW5hbWljLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldHBmaWwv aXBmdy9pcF9md19keW5hbWljLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRwZmls L2lwZncvaXBfZndfZHluYW1pYy5jCSh3b3JraW5nIGNvcHkpCkBAIC03MDgsNiArNzA4LDcg QEAKIAogCXN3aXRjaCAoY21kLT5vLm9wY29kZSkgewogCWNhc2UgT19LRUVQX1NUQVRFOgkv KiBiaWRpciBydWxlICovCisJY2FzZSBPX1NUQVRFX09OTFk6CiAJCXEgPSBhZGRfZHluX3J1 bGUoJmFyZ3MtPmZfaWQsIGksIE9fS0VFUF9TVEFURSwgcnVsZSk7CiAJCWJyZWFrOwogCkBA IC0xMzU3LDYgKzEzNTgsNyBAQAogCQlzd2l0Y2ggKGNtZC0+b3Bjb2RlKSB7CiAJCWNhc2Ug T19MSU1JVDoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19TVEFURV9PTkxZOgog CQljYXNlIE9fUFJPQkVfU1RBVEU6CiAJCWNhc2UgT19DSEVDS19TVEFURToKIAkJCXJldHVy biAoMSk7CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYwkocmV2aXNpb24g Mjc4MTUxKQorKysgc3lzL25ldHBmaWwvaXBmdy9pcF9md19zb2Nrb3B0LmMJKHdvcmtpbmcg Y29weSkKQEAgLTE0MzMsNiArMTQzMyw3IEBACiAJCXN3aXRjaCAoY21kLT5vcGNvZGUpIHsK IAkJY2FzZSBPX1BST0JFX1NUQVRFOgogCQljYXNlIE9fS0VFUF9TVEFURToKKwkJY2FzZSBP X1NUQVRFX09OTFk6CiAJCWNhc2UgT19QUk9UTzoKIAkJY2FzZSBPX0lQX1NSQ19NRToKIAkJ Y2FzZSBPX0lQX0RTVF9NRToK --------------050501000709010809070907 Content-Type: application/octet-stream; name="ipfw-state-only-v2.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only-v2.diff.sig" iQJ8BAABCgBmBQJU0P2bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFFQUIwM0M1OEJGREM0 NzhGAAoJEOqwPFi/3EePIxsQAK5cLdzjilkT9lO7q0JT4KmF+TTnx5uLQVLwppIdt5S/CBte xamb5G96KiGfGw19PDOTOWfe73FzOBVw/8G8ETyIig4TqbxfXDpRgkp38XcRKRsOdNm7C6Pt 99fo6FfaTeulRuYLKcbEqvXYF1JipADGogufPl8HkwImTy1iSG9C5yf22wW4tct3H5nOTcK8 3I1GaVBVwwUVlpIxIua2esQrPGGsyqGlCzkwBOCa/pH6p4INtj6JPAV+LRLbGRrb1tQuduBK pkjxoSSL+es1n8s1q+u7HiqNtDrMyb4YCB/vwAczt9qPT4XnUaPesjSmh9A7gNfAFhmifgb+ 0msVg2XmBwxYNhEppPI5PizDiQ/rQMA2P21zOVyvknhYSt8p9EayuKrFSv1hNW4gfprgmkY4 w/RDX0fG2K9C29BdHLSMCIG7lq+DwTttFhqFY6cSby7zfCgPjd77mJyNaFpoNOnVZEV/KPuO L1i+n+6zjaic7OZ8YXyV4XoQQx9pRe6wRvY2olRTs941QvbBTQAKjzdjq874cEOOXD5dTeOd 7vA55OaxI+y9wn3GNh2aAj3r4LwOy98MlW2q1rPS7PXdT4YACFa8bV6+gWYibqAfZBEDZsdm 521pgS1sRTIGvzENddLM01l9KQlLbSdofXHdy057yuQAgxv4m2fvecjlUsWd --------------050501000709010809070907-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 17:17:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA7E0F5D for ; Tue, 3 Feb 2015 17:17:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98A22AC3 for ; Tue, 3 Feb 2015 17:17:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13HHxCf022191 for ; Tue, 3 Feb 2015 17:17:59 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13HHxLv022165; Tue, 3 Feb 2015 17:17:59 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 17:17:59 +0000 To: freebsd-net@freebsd.org From: "imp (Warner Losh)" Subject: [Differential] [Updated] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <48873a786e27d1420fbb08e54c97a9f0@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRAsc= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 17:17:59 -0000 imp added a comment. Except for the signed / unsigned issue, I like this change. However, please get approval from some of the networking guys before committing. INLINE COMMENTS sys/netinet/ip_input.c:1450 Shouldn't this be unsigned? sys/netinet/ip_output.c:129 shouldn't this be unsigned? sys/netinet/ip_output.c:709 unsigned? sys/netinet/tcp_lro.c:233 This really isn't a compile time constant (though I think FreeBSD has magic to kinda make it such). I don't see what's wrong with uint16_t p_len = htons(65535) honestly. The enum type is also signed, which may cause some grief with subtle assumptions in the code. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, bz, adrian, rwatson, imp Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 17:21:43 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96DCD9E for ; Tue, 3 Feb 2015 17:21:43 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74E06B0D for ; Tue, 3 Feb 2015 17:21:43 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13HLhpU038368 for ; Tue, 3 Feb 2015 17:21:43 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13HLhkR038367; Tue, 3 Feb 2015 17:21:43 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 17:21:43 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Updated] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <64d310e88308f1595c3535292bba0a65@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRA6c= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 17:21:43 -0000 adrian added a comment. Hi, My main concern with this patch is the special casing of what is the "packet length" being sprinkled all throughout the code. It feels like we could be chasing down obscure "is this the right length for this kind of packet" bugs for quite some time. Is there any way we could unify this stuff a bit? I'm open to ideas. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, bz, rwatson, imp, adrian Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 17:23:46 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12043188 for ; Tue, 3 Feb 2015 17:23:46 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E460BB3C for ; Tue, 3 Feb 2015 17:23:45 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13HNjX6040000 for ; Tue, 3 Feb 2015 17:23:45 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13HNjX4039999; Tue, 3 Feb 2015 17:23:45 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 17:23:45 +0000 To: freebsd-net@freebsd.org From: "bz (Bjoern A. Zeeb)" Subject: [Differential] [Updated] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <17e152d700ce46c8e15db5e4c84d5f8a@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRBCE= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 17:23:46 -0000 bz added a comment. I have raised my concerns about the change a few weeks ago elsewhere already but gnn mentioned a possible idea today to keep it clean(er). I'll let him follow-up here. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, rwatson, imp, adrian, bz Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 17:33:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACAF434C for ; Tue, 3 Feb 2015 17:33:55 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6ADF8BEF for ; Tue, 3 Feb 2015 17:33:55 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13HXtN6050288 for ; Tue, 3 Feb 2015 17:33:55 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13HXtKc050287; Tue, 3 Feb 2015 17:33:55 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 17:33:55 +0000 To: freebsd-net@freebsd.org From: "imp (Warner Losh)" Subject: [Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRBoM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 17:33:55 -0000 imp accepted this revision. imp added a comment. I think we're ready to land. It fixes all the issues discussed, and enhanced testing shows no additional errors. INLINE COMMENTS kern/kern_timeout.c:1159 "When the callout wheel runs, it will ignore this callout" maybe is a better phrase to use here rather than have an ambiguous "callout" that refers to two different things in the same sentence. kern/kern_timeout.c:1234 tiny nit: I think this is indented wrong, but Phabric is so lame I can't tell for sure. Please check and fix if it isn't indented 4 spaces. sys/callout.h:67 I'd be tempted to create a callout_processed() macro too and use it in the last chunk of kern_timeout.c, but that can be done as a separate commit. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, jhb, kostikbel, hselasky, adrian, imp Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 17:44:35 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A817C641 for ; Tue, 3 Feb 2015 17:44:35 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80015CA6 for ; Tue, 3 Feb 2015 17:44:35 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13HiZNv060418 for ; Tue, 3 Feb 2015 17:44:35 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13HiZam060417; Tue, 3 Feb 2015 17:44:35 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 17:44:35 +0000 To: freebsd-net@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <56a2f0bf236a6cacb20d07d654e70cba@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRCQM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 17:44:35 -0000 emaste added inline comments. INLINE COMMENTS kern/kern_timeout.c:1159 Yeah, something like @imp's suggestion makes it more clear to me. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, jhb, kostikbel, hselasky, adrian, imp Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 17:47:12 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04E15724 for ; Tue, 3 Feb 2015 17:47:12 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6BB2CDC for ; Tue, 3 Feb 2015 17:47:11 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13HlBp4062478 for ; Tue, 3 Feb 2015 17:47:11 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13HlBGn062476; Tue, 3 Feb 2015 17:47:11 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 17:47:11 +0000 To: freebsd-net@freebsd.org From: "sbruno (Sean Bruno)" Subject: [Differential] [Updated] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRCZ8= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 17:47:12 -0000 sbruno added a comment. We're dubious over here in "actually running this on live systems" land. We're seeing pretty chaotic panics, unsure what we should dig into here. Within minutes of running live on a machine, we see various panics in cam or the network stack running this against stable/10. Let me find a convenient place to drop the panic information. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 17:53:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD496843 for ; Tue, 3 Feb 2015 17:53:44 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9564AD42 for ; Tue, 3 Feb 2015 17:53:44 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13HriD2069376 for ; Tue, 3 Feb 2015 17:53:44 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13HriQM069375; Tue, 3 Feb 2015 17:53:44 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 17:53:44 +0000 To: freebsd-net@freebsd.org From: "sbruno (Sean Bruno)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <1bd4a7c830a5da3a8381155fb545ac1f@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRCyg= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 17:53:44 -0000 sbruno added a comment. Sanitized panic #1 Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 2 Dump Length: 6451576832B (6152 MB) Blocksize: 512 Dumptime: Sat Jan 31 21:30:37 2015 Hostname: xxxxxxxxxxxxxxxxxxxx Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.1-STABLE-llnw10-D1711 #0 r277988M: Sat Jan 31 19:48:14 MST 2015 root@xxxxxxxxxxxxxxxxx:/usr/obj/usr/src/sys/SIXFOUR Panic String: duplicate worklist: 0xfffff80023118b00 Dump Parity: 3331327211 Bounds: 0 Dump Status: good Backtrace: Reading symbols from /boot/kernel/cc_cubic.ko.symbols...done. Loaded symbols for /boot/kernel/cc_cubic.ko.symbols Reading symbols from /boot/kernel/cc_cdg.ko.symbols...done. Loaded symbols for /boot/kernel/cc_cdg.ko.symbols Reading symbols from /boot/kernel/h_ertt.ko.symbols...done. Loaded symbols for /boot/kernel/h_ertt.ko.symbols #0 doadump (textdump=1) at pcpu.h:219 in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff8072d967 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff8072dd44 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80928082 in softdep_disk_write_complete ( bp=) at /usr/src/sys/ufs/ffs/ffs_softdep.c:10944 #4 0xffffffff807bb3c3 in bufdone_finish (bp=0xfffffe1f2b0ade80) at buf.h:420 #5 0xffffffff807bb227 in bufdone (bp=) at /usr/src/sys/kern/vfs_bio.c:3769 #6 0xffffffff806925b0 in g_io_deliver (bp=0xfffff803b80c74d8, error=) at /usr/src/sys/geom/geom_io.c:669 #7 0xffffffff806925b0 in g_io_deliver (bp=0xfffff803b80a1e88, error=) at /usr/src/sys/geom/geom_io.c:669 #8 0xffffffff806925b0 in g_io_deliver (bp=0xfffff803b80a1d90, error=) at /usr/src/sys/geom/geom_io.c:669 #9 0xffffffff806902ab in g_disk_done (bp=0xfffff803b80b41f0) at /usr/src/sys/geom/geom_disk.c:252 #10 0xffffffff802e065c in dadone (periph=, done_ccb=) at /usr/src/sys/cam/scsi/scsi_da.c:3041 #11 0xffffffff802bcefd in xpt_done_process (ccb_h=0xfffff8021e3e1000) at /usr/src/sys/cam/cam_xpt.c:5258 #12 0xffffffff802c02d6 in xpt_done_td (arg=0xffffffff81248e80) at /usr/src/sys/cam/cam_xpt.c:5285 #13 0xffffffff806fc16a in fork_exit ( callout=0xffffffff802c01b0 , arg=0xffffffff81248e80, frame=0xfffffe1f9e79eac0) at /usr/src/sys/kern/kern_fork.c:1017 #14 0xffffffff80acf40e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #15 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 17:56:21 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06971936 for ; Tue, 3 Feb 2015 17:56:21 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3101D70 for ; Tue, 3 Feb 2015 17:56:20 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13HuKLt071613 for ; Tue, 3 Feb 2015 17:56:20 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13HuKHf071612; Tue, 3 Feb 2015 17:56:20 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 17:56:20 +0000 To: freebsd-net@freebsd.org From: "sbruno (Sean Bruno)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <6133cbc4b9de97ce65d8b4d4392d7f8e@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRC8Q= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 17:56:21 -0000 sbruno added a comment. Sanitized panic #2 Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 2 Dump Length: 6752395264B (6439 MB) Blocksize: 512 Dumptime: Mon Feb 2 14:42:05 2015 Hostname: xxxxxxxxxxxxxxxxxxxxxxxx Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.1-STABLE-llnw10-D1711 #0 r277988M: Mon Feb 2 11:45:34 MST 2015 root@xxxxxxxxxxxxxxxxxxxxx:/usr/obj/usr/src/sys/SIXFOUR Panic String: general protection fault Dump Parity: 1989734895 Bounds: 0 Dump Status: good Backtrace: Reading symbols from /boot/kernel/cc_cubic.ko.symbols...done. Loaded symbols for /boot/kernel/cc_cubic.ko.symbols Reading symbols from /boot/kernel/cc_cdg.ko.symbols...done. Loaded symbols for /boot/kernel/cc_cdg.ko.symbols Reading symbols from /boot/kernel/h_ertt.ko.symbols...done. Loaded symbols for /boot/kernel/h_ertt.ko.symbols #0 doadump (textdump=1) at pcpu.h:219 in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff8072d967 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff8072dd44 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80ae944f in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:859 #4 0xffffffff80ae90ac in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:203 #5 0xffffffff80aceed2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #6 0xffffffff808b588c in in6_lltable_lookup (llt=0xfffff8001ffafe00, flags=0, l3addr=0xfffff8026d300e20) at /usr/src/sys/netinet6/in6.c:2613 #7 0xffffffff808ce1f4 in nd6_output_lle (ifp=0xfffff8001682c800, origifp=0xfffff8001682c800, m0=0xfffff8013f631500, dst=0xfffff8026d300e20, rt0=0xfffff8001682c800, lle=0x0, chain=0x1) at if_llatbl.h:199 #8 0xffffffff808ce9b8 in nd6_output (ifp=0xffffffff80cdf7c5, origifp=0xfffff8026d300e30, m0=0x10, dst=0x1, rt0=0xfffff8001682c800) at /usr/src/sys/netinet6/nd6.c:1839 #9 0xffffffff808c51c7 in ip6_output (m0=, opt=, flags=, im6o=, ifpp=, inp=) at /usr/src/sys/netinet6/ip6_output.c:858 #10 0xffffffff808dbe7d in udp6_send (so=, flags=, m=, addr=, control=0x0, td=) at /usr/src/sys/netinet6/udp6_usrreq.c:845 #11 0xffffffff807a63a5 in sosend_dgram (so=0xfffff805f5b592b8, addr=0x0, uio=, top=, control=0xfffff8001682c800, flags=, td=0xfffff80500000000) at /usr/src/sys/kern/uipc_socket.c:1102 #12 0xffffffff807aca65 in kern_sendit (td=0xfffff805f5ba3490, s=980, mp=0xfffffe2021317948, flags=0, control=0x0, segflg=) at /usr/src/sys/kern/uipc_syscalls.c:944 #13 0xffffffff807acd1c in sendit (td=0xffffffff80cdf7c5, s=, mp=0xfffffe2021317948, flags=1) at /usr/src/sys/kern/uipc_syscalls.c:871 #14 0xffffffff807acda1 in sys_sendmsg (td=0xfffff805f5ba3490, uap=0xfffffe2021317a40) at /usr/src/sys/kern/uipc_syscalls.c:1073 #15 0xffffffff80ae9d4a in amd64_syscall (td=0xfffff805f5ba3490, traced=0) at subr_syscall.c:134 #16 0xffffffff80acf1bb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #17 0x0000000801b8802a in ?? () Current language: auto; currently minimal (kgdb) REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 18:08:14 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8CD1E40 for ; Tue, 3 Feb 2015 18:08:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A68F6E6A for ; Tue, 3 Feb 2015 18:08:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13I8Enn082748 for ; Tue, 3 Feb 2015 18:08:14 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13I8Ed1082745; Tue, 3 Feb 2015 18:08:14 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 18:08:14 +0000 To: freebsd-net@freebsd.org From: "rwatson (Robert Watson)" Subject: [Differential] [Updated] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRDo4= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 18:08:14 -0000 rwatson added a comment. Historically, I believe that we've allowed additional trailer content/padding to be included at the end of mbuf chains that isn't in the IP datagram, and is silently ignored, as it isn't included in the IP packet length. I may misunderstand what was going on there, but it gives me serious pause in pondering the proposed change, as those two semantics are not really compatible with one another. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, imp, adrian, bz, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 18:08:30 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3536EEA for ; Tue, 3 Feb 2015 18:08:30 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A123BE7E for ; Tue, 3 Feb 2015 18:08:30 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13I8UNb082973 for ; Tue, 3 Feb 2015 18:08:30 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13I8UCK082972; Tue, 3 Feb 2015 18:08:30 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 18:08:30 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <341d558f123153002e8ab049cf1d308f@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRDp4= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 18:08:30 -0000 hselasky added a comment. See comments added. INLINE COMMENTS sys/netinet/ip_output.c:129 Because the variable is later on compared to the "mtu" which is also an "int". Else you will get a compile warning about signed comparison mismatch. Same goes for other location where "int" is used. sys/netinet/tcp_lro.c:233 This is a dummy value which should not be used in the new LRO implementation. 65535 is chosen to make the packet drop as invalid in case some code that is not updated, if any, decides to check the "p_len" with "m_pkthdr.len". REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, imp, adrian, bz, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 18:10:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2723CFC7 for ; Tue, 3 Feb 2015 18:10:32 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03DB7ECD for ; Tue, 3 Feb 2015 18:10:32 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13IAVXt084723 for ; Tue, 3 Feb 2015 18:10:31 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13IAVQU084721; Tue, 3 Feb 2015 18:10:31 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 18:10:31 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <8a5d19dcbe7b4873bd329386f5668201@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRDxc= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 18:10:32 -0000 hselasky added a comment. rwatson: The LRO code ensures that all trailing and padding is stripped. This happens both before and after my change. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, imp, adrian, bz, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 18:18:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3908528A for ; Tue, 3 Feb 2015 18:18:27 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1741EF50 for ; Tue, 3 Feb 2015 18:18:27 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13IIQen092569 for ; Tue, 3 Feb 2015 18:18:26 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13IIQlB092568; Tue, 3 Feb 2015 18:18:26 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 18:18:26 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <8e537bd1de6e5b5f49406ba240983bad@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTREPI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 18:18:27 -0000 hselasky added a comment. adrian: I'm not in a position to change the IP header structure to support 32-bit payload length. That's why m_pkthdr.len was chosen. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, imp, adrian, bz, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 18:44:33 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF300894 for ; Tue, 3 Feb 2015 18:44:33 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CE37154 for ; Tue, 3 Feb 2015 18:44:33 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13IiX5f019676 for ; Tue, 3 Feb 2015 18:44:33 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13IiXQm019675; Tue, 3 Feb 2015 18:44:33 GMT (envelope-from mat) Date: Tue, 3 Feb 2015 18:44:33 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <121233fc036c2c4edbbe9aad6c8738ea@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRFxE= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 18:44:33 -0000 adrian added a comment. *laugh* I know you're not; I'm just worried that we'll have lots of subtle bugs here and there with the semantics of "sometimes the length is in ip_hdr; sometimes the length is in m_pkthdr; and there's no clear definition of when we should check both." If we had a clearer definition of that and we had accessor macros that abstracted that away, it'll make things clearer and it'll give us a place to put assertions about our assumptions. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, imp, adrian, bz, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 20:43:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DADFDBDB for ; Tue, 3 Feb 2015 20:43:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0E8CBA5 for ; Tue, 3 Feb 2015 20:43:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13Kh66d077987 for ; Tue, 3 Feb 2015 20:43:06 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13Kh6Av077986; Tue, 3 Feb 2015 20:43:06 GMT (envelope-from root) Date: Tue, 3 Feb 2015 20:43:06 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Changed Subscribers] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRMto= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 20:43:06 -0000 hiren added a subscriber: hiren. hiren added a comment. Sanitized panic #3 Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 2 Dump Length: 5393809408B (5143 MB) Blocksize: 512 Dumptime: Tue Feb 3 13:21:19 2015 Hostname: xxxxxxxxxxxxxxxxxxxxxxxx Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.1-STABLE-D1711 #0: Tue Feb 3 12:19:58 MST 2015 root@xxxxxxxxxxxxxxxxxxxxxxxx:/usr/obj/usr/src/sys/SIXFOUR Panic String: page fault Dump Parity: 4197108606 Bounds: 0 Dump Status: good Backtrace: Reading symbols from /boot/kernel/cc_cubic.ko.symbols...done. Loaded symbols for /boot/kernel/cc_cubic.ko.symbols Reading symbols from /boot/kernel/cc_cdg.ko.symbols...done. Loaded symbols for /boot/kernel/cc_cdg.ko.symbols Reading symbols from /boot/kernel/h_ertt.ko.symbols...done. Loaded symbols for /boot/kernel/h_ertt.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols #0 doadump (textdump=1) at pcpu.h:219 in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff8072d0b7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff8072d494 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80ae703f in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:865 #4 0xffffffff80ae7358 in trap_pfault (frame=0xfffffe1f9e73f7b0, usermode=) at /usr/src/sys/amd64/amd64/trap.c:676 #5 0xffffffff80ae69ba in trap (frame=0xfffffe1f9e73f7b0) at /usr/src/sys/amd64/amd64/trap.c:440 #6 0xffffffff80acca22 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #7 0xffffffff8072b400 in __rw_wlock_hard (c=0xfffff8030a59aa28, tid=18446735277970927616, file=0x0, line=173648384) at /usr/src/sys/kern/kern_rwlock.c:757 #8 0xffffffff80742915 in softclock_call_cc (c=0xfffff8030a59aa98, cc=0xffffffff81342180, direct=0) at /usr/src/sys/kern/kern_timeout.c:637 #9 0xffffffff80742db4 in softclock (arg=0xffffffff81342180) at /usr/src/sys/kern/kern_timeout.c:801 #10 0xffffffff806fde4b in intr_event_execute_handlers ( p=, ie=0xfffff80015214c00) at /usr/src/sys/kern/kern_intr.c:1264 #11 0xffffffff806fe7e6 in ithread_loop (arg=0xfffff800151f6f00) at /usr/src/sys/kern/kern_intr.c:1277 #12 0xffffffff806fba6a in fork_exit ( callout=0xffffffff806fe750 , arg=0xfffff800151f6f00, frame=0xfffffe1f9e73fac0) at /usr/src/sys/kern/kern_fork.c:1017 #13 0xffffffff80accf5e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #14 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 20:51:26 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11341DDA for ; Tue, 3 Feb 2015 20:51:26 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8CF4C33 for ; Tue, 3 Feb 2015 20:51:25 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13KpP70086542 for ; Tue, 3 Feb 2015 20:51:25 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13KpPrr086541; Tue, 3 Feb 2015 20:51:25 GMT (envelope-from root) Date: Tue, 3 Feb 2015 20:51:25 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Changed Subscribers] D1764: Factor out ip6_deletefraghdr() Message-ID: <174a14f4b8e13044b307808daba2c719@localhost.localdomain> X-Priority: 3 Thread-Topic: D1764: Factor out ip6_deletefraghdr() X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDE3NDlmNTBjMTFkOWUxZjE5ZTU2MDhhM2Q4IFTRNM0= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 20:51:26 -0000 kristof added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1764 To: kristof Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 20:52:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74F2AE74 for ; Tue, 3 Feb 2015 20:52:53 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 588D9CC8 for ; Tue, 3 Feb 2015 20:52:53 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13KqrW9088155 for ; Tue, 3 Feb 2015 20:52:53 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13Kqrxr088154; Tue, 3 Feb 2015 20:52:53 GMT (envelope-from root) Date: Tue, 3 Feb 2015 20:52:53 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Changed Subscribers] D1765: PF: Handle fragmented IPv6 packets Message-ID: <08dd32d7f02c3ea25affe6243ce64a0e@localhost.localdomain> X-Priority: 3 Thread-Topic: D1765: PF: Handle fragmented IPv6 packets X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MzdiMDI4N2YyYWVmNTFkOWE2N2EwODM4MzY0IFTRNSU= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 20:52:53 -0000 kristof added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1765 To: kristof Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 20:53:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18395F0C for ; Tue, 3 Feb 2015 20:53:22 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0567CD5 for ; Tue, 3 Feb 2015 20:53:21 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13KrLbb088523 for ; Tue, 3 Feb 2015 20:53:21 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13KrLaQ088522; Tue, 3 Feb 2015 20:53:21 GMT (envelope-from root) Date: Tue, 3 Feb 2015 20:53:21 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Changed Subscribers] D1766: Factor out ip6_fragment() Message-ID: X-Priority: 3 Thread-Topic: D1766: Factor out ip6_fragment() X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: YzZhYWI5M2ViMzc5NTk2YmY1MjY3NGQ3NjcxIFTRNUE= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 20:53:22 -0000 kristof added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1766 To: kristof Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 20:53:50 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFD86FA0 for ; Tue, 3 Feb 2015 20:53:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92C33CE0 for ; Tue, 3 Feb 2015 20:53:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t13Kro9S088919 for ; Tue, 3 Feb 2015 20:53:50 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t13Krokp088918; Tue, 3 Feb 2015 20:53:50 GMT (envelope-from root) Date: Tue, 3 Feb 2015 20:53:50 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Changed Subscribers] D1767: Refragment packets after defragmenting them in PF Message-ID: <5a2097f8174543503a1dc35d5e6b504c@localhost.localdomain> X-Priority: 3 Thread-Topic: D1767: Refragment packets after defragmenting them in PF X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NWYyMjc0NjgyNTdhMmMwM2FiOGUzN2QzYjU1IFTRNV4= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Feb 2015 20:53:50 -0000 kristof added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1767 To: kristof Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 00:16:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23D972AD; Wed, 4 Feb 2015 00:16:47 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B5F466A7; Wed, 4 Feb 2015 00:16:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DfBADmY9FU/95baINahDWCfcd7gV0BAQEBAX2ENgRSNQINGQJfiEDAJpZSAQEBBwEBAQEBHYEhjgAjNIJvgUEFih2PLIMDhh2Ea4M9IoF/H4FuIIE0QX4BAQE X-IronPort-AV: E=Sophos;i="5.09,516,1418101200"; d="scan'208";a="190537358" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 03 Feb 2015 19:16:44 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D5DD6B3F7F; Tue, 3 Feb 2015 19:16:44 -0500 (EST) Date: Tue, 3 Feb 2015 19:16:44 -0500 (EST) From: Rick Macklem To: freebsd-net Message-ID: <830919216.3191973.1423009004865.JavaMail.root@uoguelph.ca> Subject: net device drivers need to set if_hw_tsomaxsegcount and friends MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Hans Petter Selasky X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 00:16:47 -0000 Hi, If you are an author/maintainer of a network device driver that supports TSO, please add a few lines to your driver to set these TSO related parameters in "struct ifnet", before you call ether_ifattach(). Thanks go to hselasky@ for committing the patch for these. if_hw_tsomax - Maximum size of a TSO segment in bytes, excluding any link level header(s). Many devices expect this value to be in the 16bit length in the IP header part of the TSO segment, but not all. --> If it must fit in the 16bit IP length field, then I think IP_MAXPACKET (65535) would be the correct value. *** See below w.r.t. weird default for this, which is probably incorrect/suboptimal for your hardware. if_hw_tsomaxsegcount - The maximum number of discontiguous transmit buffers that a TSO segment can live in, typically referred to as transmit segments. (This is essentially the upper bound on the number of data mbufs that tcp_output() can use for the TSO segment.) --> If your hardware allows it, please make this at least 35. (35 is sufficient for a 64K data payload + assorted headers for NFS/iSCSI, TCP/IP etc.) if_hw_tsomaxsegsize - The maximum size in bytes of each of these transmit segments. --> If this is less than MCLBYTES, you may need to reduce if_hw_tsomaxsegcount by one, if the link level header needs to be in one of these transmit segments. (Again, see below for this case.) *** The weird default value for if_hw_tsomax is a workaround for a problem where devices with a transmit segment limit of 32 would fail for a TSO segment of just under 64K. - When a TSO segment was less than 64K by less than the size of the link level header, the driver couldn't fit the TSO segment into 32 * MCLBYTES when the size of the link level (MAC) header was included. --> Since the device only supported 32 transmit segments, even m_defrag() couldn't get a > than 64K TSO segment (including link header) to work. Therefore, the default for if_hw_tsomax was set to: 32 * MCLBYTES - (max size of ethernet link level header) as a hack/workaround for the problem. (It is only slightly smaller than IP_MAXPACKET, which was the previous default.) --> If the driver sets if_hw_tsomaxsegcount correctly, this hack should not be needed. For the weird case of if_hw_tsomaxsegsize < MCLBYTES, you might need to set if_hw_tsomaxsegcount to 1 less than the hardware limit so that you have a transmit segment available for the link level (ethernet) header. If you don't set these values in your driver, the default value of if_hw_tsomax will probably make things work, but your driver will end up calling m_defrag() over and over and over again for TSO segments, if your hardware supports less than 35 transmit segments. If your hardware supports >= 35 transmit segments, then you might still be using TSO suboptimally. So, please set these...Thanks, rick ps: Here's the comment from if_var.h, in case it does a better job of describing these. /* 237 * Network adapter TSO limits: 238 * =========================== 239 * 240 * If the "if_hw_tsomax" field is zero the maximum segment 241 * length limit does not apply. If the "if_hw_tsomaxsegcount" 242 * or the "if_hw_tsomaxsegsize" field is zero the TSO segment 243 * count limit does not apply. If all three fields are zero, 244 * there is no TSO limit. 245 * 246 * NOTE: The TSO limits only apply to the data payload part of 247 * a TCP/IP packet. That means there is no need to subtract 248 * space for ethernet-, vlan-, IP- or TCP- headers from the 249 * TSO limits unless the hardware driver in question requires 250 * so. 251 */ From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 00:34:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A027A85C for ; Wed, 4 Feb 2015 00:34:53 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C5558D6 for ; Wed, 4 Feb 2015 00:34:53 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t140Yr6F026964 for ; Wed, 4 Feb 2015 00:34:53 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t140Yrc0026963; Wed, 4 Feb 2015 00:34:53 GMT (envelope-from root) Date: Wed, 4 Feb 2015 00:34:53 +0000 To: freebsd-net@freebsd.org From: "np (Navdeep Parhar)" Subject: [Differential] [Changed Subscribers] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRaS0= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 00:34:53 -0000 np added a subscriber: np. np added a reviewer: lstewart. np added a comment. LRO affects the kernel TCP code in subtle (and almost always undesirable) ways by "compressing" multiple TCP headers into one. Think TCP timestamps, bursty changes in sequence space as seen by the kernel, what happens to pure acks, etc. Our LRO implementation is even willing to combine multiple received TCP PSHes into one. All this is a decent tradeoff when a handful of segments are involved but the proposed LRO_PLEN_MAX (1MB) is 700+ MSS sized segments at 1500 MTU. I wonder how well the kernel TCP will deal with such big bubbles of data. Please do get the big picture reviewed by one of our TCP protocol experts. M_HASHTYPE_LRO_TCP isn't really a hash type and will likely confuse the RSS code. There is some value in providing the hash type to the stack but with your proposed change the hash type will be clobbered by tcp_lro_flush. Data for a single stream will show up in the stack with either the correct hash type or M_HASHTYPE_LRO_TCP. Not pretty. I wonder what one of these gigantic LRO'd packet looks like to bpf consumers? If they go by the ip header then they will likely get confused. A good test would be to see if wireshark is able to follow the TCP stream accurately or does it lose track when it encounters one of these VLRO (Very Large RO) packets? At the very least, allow drivers to opt out of this VLRO by a) making LRO_PLEN_MAX per lro_ctrl, to be set when the LRO structures are initialized by the driver. b) never clobbering the hash type in tcp_lro.c if the total length accumulated is <= 65535. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, imp, adrian, bz, rwatson, lstewart Cc: np, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 00:58:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03AC5276 for ; Wed, 4 Feb 2015 00:58:32 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4266AE7 for ; Wed, 4 Feb 2015 00:58:31 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t140wVD6064172 for ; Wed, 4 Feb 2015 00:58:31 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t140wVbm064171; Wed, 4 Feb 2015 00:58:31 GMT (envelope-from root) Date: Wed, 4 Feb 2015 00:58:31 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <10b1cf0868c1beba7c140cc495e2bcfa@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRbrc= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 00:58:32 -0000 adrian added a comment. .. and yes, I don't think you should be using the hashtype field to flag LRO information. They're totally separate things. (It's totally feasible that a NIC doing > 64KiB LRO will reassemble frames with correct RSS information and feed it to an RSS kernel, which can then ensure it's running on the correct cpuset with the TCP state and locks.) REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, imp, adrian, bz, rwatson, lstewart Cc: np, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 05:06:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A04199CE; Wed, 4 Feb 2015 05:06:59 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 714D98CD; Wed, 4 Feb 2015 05:06:59 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t1456lxp041659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:06:49 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1A8E1.8010100@freebsd.org> Date: Wed, 04 Feb 2015 13:06:41 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org> <54D0951F.2000304@FreeBSD.org> In-Reply-To: <54D0951F.2000304@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:06:59 -0000 On 2/3/15 5:30 PM, Lev Serebryakov wrote: > >> looking at my own rules I don't seem to have a problem.. > You have "check-state" only once, on entrance, before all NATs, so > it could work only for packets which don't need NAT. And looks like > (correct me if I'm wrong) you don't try to track states of connections > passed through NAT. yes, because NAT is a stateful filter so it's a duplication > - -- > // Lev Serebryakov AKA Black Lion > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 05:29:36 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BED7BC3B; Wed, 4 Feb 2015 05:29:36 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E634A97; Wed, 4 Feb 2015 05:29:36 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t145TW3e041754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:29:34 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1AE36.8090504@freebsd.org> Date: Wed, 04 Feb 2015 13:29:26 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option (version 2) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> In-Reply-To: <54D0FD9B.5000108@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:29:36 -0000 On 2/4/15 12:55 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 03.02.2015 19:13, Lev Serebryakov wrote: > >> Ok, "allow-state"/"deny-state" was very limited idea. Here is more >> universal mechanism: new "keep-state-only" (aliased as >> "record-only") option, which works exactly as "keep-state" BUT >> cancel match of rule after state creation. It allows to write >> stateful + nat firewall as easy as: > To work as expected, "keep-state-only" should not imply "check-state" > in opposite to "keep-state". agreed.. I hate the implied check-state.. man page must be very explicit about this.. From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 05:33:02 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEC8ED1A; Wed, 4 Feb 2015 05:33:02 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 88187B43; Wed, 4 Feb 2015 05:33:02 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t145WvOP041772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:33:00 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1AF04.8050106@freebsd.org> Date: Wed, 04 Feb 2015 13:32:52 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option References: <54D0F39B.4070707@FreeBSD.org> In-Reply-To: <54D0F39B.4070707@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:33:03 -0000 On 2/4/15 12:13 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > Ok, "allow-state"/"deny-state" was very limited idea. > Here is more universal mechanism: new "keep-state-only" (aliased as > "record-only") option, which works exactly as "keep-state" BUT cancel > match of rule after state creation. It allows to write stateful + nat > firewall as easy as: > > nat 1 config if outIface > > 1000 skipto 2000 in > skipto 3000 out > deny all from any to any // Safeguard > 2000 skipto 4000 recv inIface > skipto 6000 recv outIface > deny all from any to any // Safeguard > 3000 skipto 5000 xmit inIface > skipto 7000 xmit outIface > deny all from any to any // Safeguard > 4000 // For sake of simplicity! > // Real firewall will have some checks about local network here > allow all from any to any > deny all from any to any // Safeguard > 5000 // For sake of simplicity! > // Real firewall will have some checks about local network here > allow all from any to any > deny all from any to any // Safeguard > 6000 deny all not dst-ip $EXT_IP > nat 1 all from any to any > // All enabled with "keep-state-only" at block 7000 before NAT > check-state all from any to any > // Here could be accept rules for our servers or servers in DMZ > // Disable everything else > deny all from any to any > 7000 // Here goes rules which could DISABLE outbound external traffic > // Create state for "check-state" at block 6000 and fallthrough > allow keep-state-only > allow src-ip $EXT_IP // Save NAT some work > nat 1 all from any to any > allow all from any to any > deny all from any to any // Safeguard > > And variants with multiple NATs and "nat global" becomes as easy as > this, too! No stupid "skipto", no "keep-state" at "incoming from local > network" parts of firewall, nothing! > > P.S. I HATE this "all any to any" part! can we get rid of it? (implied).. or just add "everything" also I am not sure about "keep-state-only".. how about 'set-state'? or record-state as I started with.. > > - -- > // Lev Serebryakov > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJU0POaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePR+gP/1Oxi+h7pi0UlnqfrKyfHJRS > FUbrMNeR9NATnTwxIK1UxNT1kF3m7wiwnFlgwW7rwLtTviFB1wK/pfd38l2h4t/w > qUbtyK4PFMCq8I6wAJIB0qUl3C/mN1rwc+LSJJyFM07R52snoQs6FvkIYkCz0fOy > Cak1f/P+scc21IRhFvYJXMMDO/1Y1nkxZk/HdHbn1GELpTXuHugvL1T9hHl98sqO > HKlHnvtqAVlyZn9Sv3uC9nsyjFA2sdOCtb67UGnPDV3CIs4Jwj5CSst5jbz13qFG > aXF8ZSm0coPJMUjH1PSogZM9Xiq23yZ47V0mesBxQsHL24548jM/wKcsR3buDjP7 > NJ2rqo2OBCzTu6VCK2oIY5j9A6vq1mu8+/eBs5jF4C2k0xHiw53Okou7zOCA0gJ+ > z+VGZvD3la/+tFjacty7Ra7LLNA8kNCnRa0QML7LOJ1/99a4l3Z/uGFxy5zYnk7d > p27Y85CAhTJQjkYZSGAiFD5SE4XxRqtSJ9OL89w7vLxoHqW0rqwi+DVrr9uvXQZS > 8Z5G5iQARG4ygXuKsl6MlwChCXa3ucbOs41lorrug94cuVCwGg859zBZY3dpQsKz > XIhtVQS21wPLxXywzIc678ar4uKVWNiaRWg+k57O7375gAszvqujRuTEcfHRf/T+ > gHJJZt8Tc+en4bw8XItY > =wOAJ > -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 05:38:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ED06DFF; Wed, 4 Feb 2015 05:38:34 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F128B68; Wed, 4 Feb 2015 05:38:34 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t145cT2b041805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:38:32 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1B050.2040706@freebsd.org> Date: Wed, 04 Feb 2015 13:38:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option References: <54D0F39B.4070707@FreeBSD.org> <54D1AF04.8050106@freebsd.org> In-Reply-To: <54D1AF04.8050106@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:38:34 -0000 On 2/4/15 1:32 PM, Julian Elischer wrote: > On 2/4/15 12:13 AM, Lev Serebryakov wrote: >> >> And variants with multiple NATs and "nat global" becomes as easy as >> this, too! No stupid "skipto", no "keep-state" at "incoming from local >> network" parts of firewall, nothing! >> >> P.S. I HATE this "all any to any" part! > can we get rid of it? (implied).. or just add "everything" > also I am not sure about "keep-state-only".. > how about 'set-state'? or record-state as I started with.. or record-session.. (state always annoyed me) > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 06:47:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E0F73E8 for ; Wed, 4 Feb 2015 06:47:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0181E16A for ; Wed, 4 Feb 2015 06:47:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t146lofs017758 for ; Wed, 4 Feb 2015 06:47:50 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t146loD2017757; Wed, 4 Feb 2015 06:47:50 GMT (envelope-from root) Date: Wed, 4 Feb 2015 06:47:50 +0000 To: freebsd-net@freebsd.org From: "rwatson (Robert Watson)" Subject: [Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <1142ded2a7364ec06271ae98365609aa@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTRwJY= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 06:47:51 -0000 rwatson added a comment. np@'s comments are good ones, both with respect to ACK clocking and BPF -- but this will also affect local firewalls that do state tracking and/or transformation, and likewise will run into problems. Given this discussion, I'm increasingly convinced that this is Not A Good Idea In Its Current Form -- far more thought is required about how we might want to handle this. I would recommend we set aside time at a BSDCan devsummit session to talk about the implications of VLRO for the stack as a whole. Given our default direct-dispatch input configuration, presumably much of the benefit from VLRO comes from reducing the number of tcpcb lookups, and a bit more comes from avoiding reassembly costs. I do wonder if we might choose to present VLRO in a different way: rather than as a single, very large datagram, but instead as a series of datagrams that the lower layer promises are for the same TCP connection, and sequential, allowing a single lookup and reassembly avoidance, but avoiding diverging from the current assumption that mbuf chains correspond to a single IP datagram that meets its invariant properties. We could easily assert that the IP addresses match and that the segments are sequential, allowing us to catch bugs while making strong assumptions. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, imp, adrian, bz, rwatson, lstewart Cc: np, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 07:23:41 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ACDA7EB for ; Wed, 4 Feb 2015 07:23:41 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB905755 for ; Wed, 4 Feb 2015 07:23:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t147Netc055842 for ; Wed, 4 Feb 2015 07:23:40 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t147Neqw055841; Wed, 4 Feb 2015 07:23:40 GMT (envelope-from root) Date: Wed, 4 Feb 2015 07:23:40 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <0ef82189a68b631642b45aca29a488fb@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRyPw= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 07:23:41 -0000 rrs added a comment. Sbruno: I have a hard time connecting the dots between the kernel panic's you are seeing and the callout system (especially the changes I made above). You were getting a spin-lock held too long right? hiren: This looks interesting to me, it is definitely something I would like to look at. I assume you are on 10.stable like Sean? Note please email me at rrs@netflix.com .. unfortunately my mail server is down and I am about a 3 hour drive away from it ;-( REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 07:30:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BEEE936 for ; Wed, 4 Feb 2015 07:30:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA9EF7A1 for ; Wed, 4 Feb 2015 07:30:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t147UoIF062708 for ; Wed, 4 Feb 2015 07:30:50 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t147UoQM062706; Wed, 4 Feb 2015 07:30:50 GMT (envelope-from root) Date: Wed, 4 Feb 2015 07:30:50 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <48e7206f1f28e06b09422fab39999099@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRyqo= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 07:30:51 -0000 rrs added a comment. Hiren: Ok looking at kern_timeout.c thats a call to class->lc_lock(c_lock, lock_status); If my 10.x matches yours. And the call inside that kern_rwlock.c:757 is v = rw->rw_lock; owner = (struct thread *)RW_OWNER(v); I would imagine v is probably a freed lock or some such.. not sure. If you have a vmcore sending the registers would be helpful. And for that matter if you have a vmcore if you could get in the frame of kern_timeout and tell me what c_lock c_func are that would be helpful. I have not tested this with my test framework for locks that pass in a lock.. If the c_func is not some private thing but something in BSD I can puzzle out what sub-system is using the callout this way and try to reproduce a test that will blow up this way on me as well. Assuming of course its not the caller that has freed the lock ahead of the callout system running... REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 07:40:00 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E75B6AB0 for ; Wed, 4 Feb 2015 07:40:00 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A31348A1 for ; Wed, 4 Feb 2015 07:40:00 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t147e0mC071563 for ; Wed, 4 Feb 2015 07:40:00 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t147e07u071562; Wed, 4 Feb 2015 07:40:00 GMT (envelope-from root) Date: Wed, 4 Feb 2015 07:40:00 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <50fe9a61a5befbcf85f8899e86856943@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRzNA= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 07:40:01 -0000 hiren added a comment. >>! In D1711#58, @rrs wrote: > hiren: > > This looks interesting to me, it is definitely something I would like to look at. I assume you > are on 10.stable like Sean? Yes, its plain stable10+D1711. Also, all 3 panics are from the same system. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 07:43:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5D9EC86 for ; Wed, 4 Feb 2015 07:43:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7E4297D for ; Wed, 4 Feb 2015 07:43:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t147hqnE077005 for ; Wed, 4 Feb 2015 07:43:52 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t147hqWX077004; Wed, 4 Feb 2015 07:43:52 GMT (envelope-from root) Date: Wed, 4 Feb 2015 07:43:52 +0000 To: freebsd-net@freebsd.org From: "arybchik (Andrew Rybchenko)" Subject: [Differential] [Commented On] D1707: sfxge: access statistics buffers under port lock Message-ID: <11eeba157e1f2596b1439cd8e892d100@localhost.localdomain> X-Priority: 3 Thread-Topic: D1707: sfxge: access statistics buffers under port lock X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MmFkY2EyODhjMzI1YWNkNjhmYWJmNzczN2QyIFTRzbg= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 07:43:53 -0000 arybchik added a comment. I've published review request D1772 to add macros. Please, review. Also I have a patch to make lock names unique - will follow. REVISION DETAIL https://reviews.freebsd.org/D1707 To: arybchik, gnn Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 07:51:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7905D78 for ; Wed, 4 Feb 2015 07:51:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 833479C4 for ; Wed, 4 Feb 2015 07:51:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t147p62s083307 for ; Wed, 4 Feb 2015 07:51:06 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t147p66R083306; Wed, 4 Feb 2015 07:51:06 GMT (envelope-from root) Date: Wed, 4 Feb 2015 07:51:06 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <3f0b29bf7ce72ac8fc468ca9876b011a@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTRz2o= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 07:51:06 -0000 hselasky added a comment. Hi, There is only one or two likely consumers of callout_init_rw() at the present moment, and one of them is: ./netinet6/nd6.c: canceled = callout_stop(&ln->ln_timer_ch); ./netinet6/nd6.c: canceled = callout_reset(&ln->ln_timer_ch, INT_MAX, ./netinet6/nd6.c: canceled = callout_reset(&ln->ln_timer_ch, tick, ./netinet6/in6.c: callout_init_rw(&lle->base.ln_timer_ch, &lle->base.lle_lock, hiren: Is this box configured for IPv6 ? static void in_lltable_free(struct lltable *llt, struct llentry *lle) { LLE_WUNLOCK(lle); LLE_LOCK_DESTROY(lle); free(lle, M_LLTABLE); } ln_lltable_free() does not drain the callout associated with it and I am not sure if we have a sleeping context for that. Even if the refcount is zero, it doesn't mean that the callback is finished using the RW mutex. This is another example where we really need a "callout_drain_async_function()". REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 08:01:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36BD1F26 for ; Wed, 4 Feb 2015 08:01:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E731DAAB for ; Wed, 4 Feb 2015 08:01:39 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t1481d2Z095932 for ; Wed, 4 Feb 2015 08:01:39 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t1481dpJ095931; Wed, 4 Feb 2015 08:01:39 GMT (envelope-from root) Date: Wed, 4 Feb 2015 08:01:39 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <5490ffea094555ee2d3e4766b56a3167@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTR0eM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:01:40 -0000 hiren added a comment. >>! In D1711#59, @rrs wrote: > Hiren: > > Ok looking at kern_timeout.c thats a call to > class->lc_lock(c_lock, lock_status); > > If my 10.x matches yours. It's not :-( Looks like what we have here is not stock stable10 really. I'll check all the details and get back first thing in the morning tomorrow. Thanks for checking and sorry for the trouble. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 08:05:11 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8D82D9 for ; Wed, 4 Feb 2015 08:05:11 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E038B70 for ; Wed, 4 Feb 2015 08:05:11 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t1485B6R098703 for ; Wed, 4 Feb 2015 08:05:11 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t1485BFf098702; Wed, 4 Feb 2015 08:05:11 GMT (envelope-from root) Date: Wed, 4 Feb 2015 08:05:11 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <3b93ab37fc903c2a9a54e1fa31b1cbf6@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTR0rc= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:05:12 -0000 hiren added a comment. >>! In D1711#61, @hselasky wrote: > Hi, > > There is only one or two likely consumers of callout_init_rw() at the present moment, and one of them is: > > ./netinet6/nd6.c: canceled = callout_stop(&ln->ln_timer_ch); > ./netinet6/nd6.c: canceled = callout_reset(&ln->ln_timer_ch, INT_MAX, > ./netinet6/nd6.c: canceled = callout_reset(&ln->ln_timer_ch, tick, > ./netinet6/in6.c: callout_init_rw(&lle->base.ln_timer_ch, &lle->base.lle_lock, > > hiren: Is this box configured for IPv6 ? No, not for panic #3. But as I replied to rrs's comment, I need to first make sure what tree we are running and if we are missing critical fixes from stable-10. > > static void > in_lltable_free(struct lltable *llt, struct llentry *lle) > { > LLE_WUNLOCK(lle); > LLE_LOCK_DESTROY(lle); > free(lle, M_LLTABLE); > } > > ln_lltable_free() does not drain the callout associated with it and I am not sure if we have a sleeping context for that. Even if the refcount is zero, it doesn't mean that the callback is finished using the RW mutex. > > This is another example where we really need a "callout_drain_async_function()". REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 09:24:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08C1C5F9; Wed, 4 Feb 2015 09:24:47 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 56CD73EE; Wed, 4 Feb 2015 09:24:46 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2185A5C002; Wed, 4 Feb 2015 12:24:36 +0300 (MSK) Message-ID: <54D1E558.1010700@FreeBSD.org> Date: Wed, 04 Feb 2015 12:24:40 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw , freebsd-net Subject: [RFC][patch] New "keep-state-only" option (version 3) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> In-Reply-To: <54D0FD9B.5000108@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------020107060303090503050300" Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 09:24:47 -0000 This is a multi-part message in MIME format. --------------020107060303090503050300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 19:55, Lev Serebryakov wrote: >> Ok, "allow-state"/"deny-state" was very limited idea. Here is >> more universal mechanism: new "keep-state-only" (aliased as >> "record-only") option, which works exactly as "keep-state" BUT >> cancel match of rule after state creation. It allows to write >> stateful + nat firewall as easy as: > To work as expected, "keep-state-only" should not imply > "check-state" in opposite to "keep-state". Re-installation of state (with second, third, etc... packet of connection) should update TCP state of state (sorry!), or it will die in 10 seconds. This version seems to be final (apart from name of new option!). It works perfectly on my router with 2 uplink ISPs. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0eVYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePOD0P/RwpwF9yMUjyAj/KZnphr/0Y aXHM040qIocIUqnxH7T/vwdhm2w3Zciry8hwXp9f+r2bTIe8+tTn8OwaJ0M/Wp1j QBPxW+rjw49hy3rf2eIQbgX7nTwdIZo7YDnT82Kqtje1mImTBR4qdFcSStJac4hE dJsbpzC6raHUuE8h5V5pWPV/m/OQebK3P5CZzBKKpVTMCX3nVsTnff9qf9L1A0Jd q4KYfOv+NJBaB8G6vJhDHjcqtzGfEJBmYL8kOAslYhlUuyYe+iAhyGFbcUBsXwk8 /dqBalUL2iewFaZppszYZ0rTpVOfA4fOV0ECbVmpcw36uocrC2iOEpBl0WRIy+TM HYIMkIeubF9IT24CwMwiriONpppl8MGynCmL9hyMgu+HiuvHZ/C/vYcVV9/DHFGB iKkNe9QjX34anP6qVvEvHHmuv26PO7eq7hkdK2PZNlA9dwwNHehN8xG3DxB9N8gG MPRGtM8yH/C/FXpqKmHoqj6shMGQCSfmZKPfJ0D49Rze8tSjo7kZaSmaELJAjmsc xLv5umEAg7gym54bMhv8As2lXHnyeDp3uJz6glM72cmtBM5/n8N7NLk6Xga+8eM3 cZ122dgOqzGpts9TqCGWmTRW+f2Y8hLukzIjOLdzlqLPfQmXVn9pOWmqo9OKHdvD we0uYcnte/iSltopkVuG =muco -----END PGP SIGNATURE----- --------------020107060303090503050300 Content-Type: text/plain; charset=windows-1251; name="ipfw-state-only-v3.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only-v3.diff" SW5kZXg6IHNiaW4vaXBmdy9pcGZ3LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncuOAkocmV2aXNpb24gMjc4MTUxKQorKysgc2Jpbi9pcGZ3L2lwZncuOAkod29ya2luZyBj b3B5KQpAQCAtMTY2LDcgKzE2Niw4IEBACiBkZXBlbmRpbmcgb24gaG93IHRoZSBrZXJuZWwg aXMgY29uZmlndXJlZC4KIC5QcAogSWYgdGhlIHJ1bGVzZXQgaW5jbHVkZXMgb25lIG9yIG1v cmUgcnVsZXMgd2l0aCB0aGUKLS5DbSBrZWVwLXN0YXRlCisuQ20ga2VlcC1zdGF0ZSAsCisu Q20ga2VlcC1zdGF0ZS1vbmx5CiBvcgogLkNtIGxpbWl0CiBvcHRpb24sCkBAIC01ODIsNyAr NTgzLDggQEAKIHBhY2tldCBkZWxpdmVyeS4KIC5QcAogTm90ZTogdGhpcyBjb25kaXRpb24g aXMgY2hlY2tlZCBiZWZvcmUgYW55IG90aGVyIGNvbmRpdGlvbiwgaW5jbHVkaW5nCi1vbmVz IHN1Y2ggYXMga2VlcC1zdGF0ZSBvciBjaGVjay1zdGF0ZSB3aGljaCBtaWdodCBoYXZlIHNp ZGUgZWZmZWN0cy4KK29uZXMgc3VjaCBhcyBrZWVwLXN0YXRlLCBrZWVwLXN0YXQtb25seSBv ciBjaGVjay1zdGF0ZSB3aGljaCBtaWdodCBoYXZlCitzaWRlIGVmZmVjdHMuCiAuSXQgQ20g bG9nIE9wIENtIGxvZ2Ftb3VudCBBciBudW1iZXIKIFBhY2tldHMgbWF0Y2hpbmcgYSBydWxl IHdpdGggdGhlCiAuQ20gbG9nCkBAIC0xNTgzLDYgKzE1ODUsMTggQEAKIC5YciBzeXNjdGwg OAogdmFyaWFibGVzKSwgYW5kIHRoZSBsaWZldGltZSBpcyByZWZyZXNoZWQgZXZlcnkgdGlt ZSBhIG1hdGNoaW5nCiBwYWNrZXQgaXMgZm91bmQuCisuSXQgQ20ga2VlcC1zdGF0ZS1vbmx5 IHwgcmVjb3JkLW9ubHkKK1Vwb24gYSBtYXRjaCwgdGhlIGZpcmV3YWxsIHdpbGwgY3JlYXRl IGEgZHluYW1pYyBydWxlIGFzIGlmCisuQ20ga2VlcC1zdGF0ZQord2FzIHNwZWNpZmllZCwg YnV0IGFmdGVyIHRoYXQgbWF0Y2ggaXMgY2FuY2VsbGVkIGFuZCB0aGUgc2VhcmNoCitjb250 aW51ZXMgd2l0aCB0aGUgbmV4dCBydWxlLgorT24gZHluYW1pYyBydWxlIG1hdGNoIGFjdGlv biwgc3BlY2lmaWVkIGluIHRoaXMgcnVsZSwKK3BlcmZvcm1lZCBhcyBpZiBydWxlIGNvbnRh aW5zCisuQ20ga2VlcC1zdGF0ZSAuCitUaGlzIG9wdGlvbiBkb2Vzbid0IGFjdCBhcworLkNt IGNoZWNrLXN0YXRlCitpbiBjb250cmFzdCB0bworLkNtIGtlZXAtc3RhdGUgLgogLkl0IENt IGxheWVyMgogTWF0Y2hlcyBvbmx5IGxheWVyMiBwYWNrZXRzLCBpLmUuLCB0aG9zZSBwYXNz ZWQgdG8KIC5ObQpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c2Jpbi9pcGZ3L2lwZncyLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3 Mi5jCSh3b3JraW5nIGNvcHkpCkBAIC0yOTIsNiArMjkyLDggQEAKIAl7ICJpbiIsCQkJVE9L X0lOIH0sCiAJeyAibGltaXQiLAkJVE9LX0xJTUlUIH0sCiAJeyAia2VlcC1zdGF0ZSIsCQlU T0tfS0VFUFNUQVRFIH0sCisJeyAicmVjb3JkLXN0YXRlIiwJVE9LX1NUQVRFX09OTFkgfSwK Kwl7ICJrZWVwLXN0YXRlLW9ubHkiLAlUT0tfU1RBVEVfT05MWSB9LAogCXsgImJyaWRnZWQi LAkJVE9LX0xBWUVSMiB9LAogCXsgImxheWVyMiIsCQlUT0tfTEFZRVIyIH0sCiAJeyAib3V0 IiwJCVRPS19PVVQgfSwKQEAgLTE5OTMsNiArMTk5NSwxMCBAQAogCQkJCWJwcmludGYoYnAs ICIga2VlcC1zdGF0ZSIpOwogCQkJCWJyZWFrOwogCisJCQljYXNlIE9fU1RBVEVfT05MWToK KwkJCQlicHJpbnRmKGJwLCAiIGtlZXAtc3RhdGUtb25seSIpOworCQkJCWJyZWFrOworCiAJ CQljYXNlIE9fTElNSVQ6IHsKIAkJCQlzdHJ1Y3QgX3NfeCAqcCA9IGxpbWl0X21hc2tzOwog CQkJCWlwZndfaW5zbl9saW1pdCAqYyA9IChpcGZ3X2luc25fbGltaXQgKiljbWQ7CkBAIC00 MzM1LDE0ICs0MzQxLDE2IEBACiAJCQlicmVhazsKIAogCQljYXNlIFRPS19LRUVQU1RBVEU6 CisJCWNhc2UgVE9LX1NUQVRFX09OTFk6CiAJCQlpZiAob3Blbl9wYXIpCi0JCQkJZXJyeChF WF9VU0FHRSwgImtlZXAtc3RhdGUgY2Fubm90IGJlIHBhcnQgIgorCQkJCWVycngoRVhfVVNB R0UsICJrZWVwLXN0YXRlIG9yIGtlZXAtc3RhdGUtb25seSBjYW5ub3QgYmUgcGFydCAiCiAJ CQkJICAgICJvZiBhbiBvciBibG9jayIpOwogCQkJaWYgKGhhdmVfc3RhdGUpCiAJCQkJZXJy eChFWF9VU0FHRSwgIm9ubHkgb25lIG9mIGtlZXAtc3RhdGUgIgogCQkJCQkiYW5kIGxpbWl0 IGlzIGFsbG93ZWQiKTsKIAkJCWhhdmVfc3RhdGUgPSBjbWQ7Ci0JCQlmaWxsX2NtZChjbWQs IE9fS0VFUF9TVEFURSwgMCwgMCk7CisJCQlmaWxsX2NtZChjbWQsIGkgPT0gVE9LX0tFRVBT VEFURSA/CisJCQkJT19LRUVQX1NUQVRFIDogT19TVEFURV9PTkxZLCAwLCAwKTsKIAkJCWJy ZWFrOwogCiAJCWNhc2UgVE9LX0xJTUlUOiB7CkBAIC00NTgwLDEyICs0NTg4LDEzIEBACiAJ LyoKIAkgKiBnZW5lcmF0ZSBPX1BST0JFX1NUQVRFIGlmIG5lY2Vzc2FyeQogCSAqLwotCWlm IChoYXZlX3N0YXRlICYmIGhhdmVfc3RhdGUtPm9wY29kZSAhPSBPX0NIRUNLX1NUQVRFKSB7 CisJaWYgKGhhdmVfc3RhdGUgJiYgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fQ0hFQ0tfU1RB VEUgJiYKKwkgICAgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fU1RBVEVfT05MWSkgewogCQlm aWxsX2NtZChkc3QsIE9fUFJPQkVfU1RBVEUsIDAsIDApOwogCQlkc3QgPSBuZXh0X2NtZChk c3QsICZyYmxlbik7CiAJfQogCi0JLyogY29weSBhbGwgY29tbWFuZHMgYnV0IE9fTE9HLCBP X0tFRVBfU1RBVEUsIE9fTElNSVQsIE9fQUxUUSwgT19UQUcgKi8KKwkvKiBjb3B5IGFsbCBj b21tYW5kcyBidXQgT19MT0csIE9fS0VFUF9TVEFURSwgT19TVEFURV9PTkxZLCBPX0xJTUlU LCBPX0FMVFEsIE9fVEFHICovCiAJZm9yIChzcmMgPSAoaXBmd19pbnNuICopY21kYnVmOyBz cmMgIT0gY21kOyBzcmMgKz0gaSkgewogCQlpID0gRl9MRU4oc3JjKTsKIAkJQ0hFQ0tfUkJV RkxFTihpKTsKQEAgLTQ1OTMsNiArNDYwMiw3IEBACiAJCXN3aXRjaCAoc3JjLT5vcGNvZGUp IHsKIAkJY2FzZSBPX0xPRzoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19TVEFU RV9PTkxZOgogCQljYXNlIE9fTElNSVQ6CiAJCWNhc2UgT19BTFRROgogCQljYXNlIE9fVEFH OgpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3 L2lwZncyLmgJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5oCSh3b3Jr aW5nIGNvcHkpCkBAIC0yMjcsNiArMjI3LDcgQEAKIAlUT0tfTE9DSywKIAlUT0tfVU5MT0NL LAogCVRPS19WTElTVCwKKwlUT0tfU1RBVEVfT05MWSwKIH07CiAKIC8qCkluZGV4OiBzeXMv bmV0aW5ldC9pcF9mdy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L2lwX2Z3LmgJ KHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRpbmV0L2lwX2Z3LmgJKHdvcmtpbmcgY29w eSkKQEAgLTI1Miw2ICsyNTIsOCBAQAogCU9fRFNDUCwJCQkvKiAyIHUzMiA9IERTQ1AgbWFz ayAqLwogCU9fU0VURFNDUCwJCS8qIGFyZzE9RFNDUCB2YWx1ZSAqLwogCU9fSVBfRkxPV19M T09LVVAsCS8qIGFyZzE9dGFibGUgbnVtYmVyLCB1MzI9dmFsdWUJKi8KKwkKKwlPX1NUQVRF X09OTFksCQkvKiBub25lCQkJCSovCiAKIAlPX0xBU1RfT1BDT0RFCQkvKiBub3QgYW4gb3Bj b2RlIQkJKi8KIH07CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3Mi5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHJldmlzaW9uIDI3ODE1MSkK KysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHdvcmtpbmcgY29weSkKQEAgLTIxMDcs OSArMjEwNyw5IEBACiAJCQkgKiBPX1RBRywgT19MT0cgYW5kIE9fQUxUUSBhY3Rpb24gcGFy YW1ldGVyczoKIAkJCSAqICAgcGVyZm9ybSBzb21lIGFjdGlvbiBhbmQgc2V0IG1hdGNoID0g MTsKIAkJCSAqCi0JCQkgKiBPX0xJTUlUIGFuZCBPX0tFRVBfU1RBVEU6IHRoZXNlIG9wY29k ZXMgYXJlCi0JCQkgKiAgIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQgcmln aHQKLQkJCSAqICAgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgorCQkJ ICogT19MSU1JVCwgT19LRUVQX1NUQVRFIGFuZCBPX1NUQVRFX09OTFk6IHRoZXNlCisJCQkg KiAgIG9wY29kZXMgYXJlIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQKKwkJ CSAqICAgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgogCQkJ ICogICBUaGVzZSBvcGNvZGVzIHRyeSB0byBpbnN0YWxsIGFuIGVudHJ5IGluIHRoZQogCQkJ ICogICBzdGF0ZSB0YWJsZXM7IGlmIHN1Y2Nlc3NmdWwsIHdlIGNvbnRpbnVlIHdpdGgKIAkJ CSAqICAgdGhlIG5leHQgb3Bjb2RlIChtYXRjaD0xOyBicmVhazspLCBvdGhlcndpc2UKQEAg LTIxMjYsMTcgKzIxMjYsMzMgQEAKIAkJCSAqICAgZnVydGhlciBpbnN0YW5jZXMgb2YgdGhl c2Ugb3Bjb2RlcyBiZWNvbWUgTk9Qcy4KIAkJCSAqICAgVGhlIGp1bXAgdG8gdGhlIG5leHQg cnVsZSBpcyBkb25lIGJ5IHNldHRpbmcKIAkJCSAqICAgbD0wLCBjbWRsZW49MC4KKwkJCSAq CisJCQkgKiBPX1NUQVRFX09OTFk6IHRoaXMgb3Bjb2RlIGlzIG5vdCByZWFsICdhY3Rpb24n CisJCQkgKiAgdG9vLCBhbmQgaXMgc3RvcmVkIHJpZ2h0IGJlZm9yZSB0aGUgJ2FjdGlvbicK KwkJCSAqICBwYXJ0IG9mIHRoZSBydWxlLCByaWdodCBhZnRlciBPX0tFRVBfU1RBVEUKKwkJ CSAqICBvcGNvZGUuIEl0IGNhdXNlcyBtYXRjaCBmYWlsdXJlIHNvIHJlYWwKKwkJCSAqICAn YWN0aW9uJyBjb3VsZCBiZSBleGVjdXRlZCBvbmx5IGlmIHJ1bGUKKwkJCSAqICBpcyBjaGVj a2VkIHZpYSBkeW5hbWljIHJ1bGUgZnJvbSBzdGF0ZQorCQkJICogIHRhYmxlLCBhcyBpbiBz dWNoIGNhc2UgZXhlY3V0aW9uIHN0YXJ0cworCQkJICogIGZyb20gdHJ1ZSAnYWN0aW9uJyBv cGNvZGUgZGlyZWN0bHkuCisJCQkgKiAgIAogCQkJICovCiAJCQljYXNlIE9fTElNSVQ6CiAJ CQljYXNlIE9fS0VFUF9TVEFURToKLQkJCQlpZiAoaXBmd19pbnN0YWxsX3N0YXRlKGNoYWlu LCBmLAotCQkJCSAgICAoaXBmd19pbnNuX2xpbWl0ICopY21kLCBhcmdzLCB0YWJsZWFyZykp IHsKKwkJCWNhc2UgT19TVEFURV9PTkxZOgorCQkJCWlmIChpcGZ3X2luc3RhbGxfb3JfdXBk YXRlX3N0YXRlKGNoYWluLCBmLAorCQkJCSAgICAoaXBmd19pbnNuX2xpbWl0ICopY21kLCBh cmdzLCB0YWJsZWFyZywKKwkJCQkgICAgcHJvdG8gPT0gSVBQUk9UT19UQ1AgPyBUQ1AodWxw KSA6IE5VTEwpKSB7CiAJCQkJCS8qIGVycm9yIG9yIGxpbWl0IHZpb2xhdGlvbiAqLwogCQkJ CQlyZXR2YWwgPSBJUF9GV19ERU5ZOwogCQkJCQlsID0gMDsJLyogZXhpdCBpbm5lciBsb29w ICovCiAJCQkJCWRvbmUgPSAxOyAvKiBleGl0IG91dGVyIGxvb3AgKi8KIAkJCQl9Ci0JCQkJ bWF0Y2ggPSAxOworCQkJCWlmIChjbWQtPm9wY29kZSA9PSBPX1NUQVRFX09OTFkpIHsKKwkJ CQkJbCA9IDA7CS8qIGV4aXQgaW5uZXIgbG9vcCAqLworCQkJCQltYXRjaCA9IDA7CisJCQkJ fSBlbHNlCisJCQkJCW1hdGNoID0gMTsKIAkJCQlicmVhazsKIAogCQkJY2FzZSBPX1BST0JF X1NUQVRFOgpAQCAtMjE4OCw2ICsyMjA0LDcgQEAKIAkJCQlicmVhazsKIAogCQkJY2FzZSBP X0FDQ0VQVDoKKwogCQkJCXJldHZhbCA9IDA7CS8qIGFjY2VwdCAqLwogCQkJCWwgPSAwOwkJ LyogZXhpdCBpbm5lciBsb29wICovCiAJCQkJZG9uZSA9IDE7CS8qIGV4aXQgb3V0ZXIgbG9v cCAqLwpAQCAtMjUzNyw3ICsyNTU0LDcgQEAKIAkJCQlkb25lID0gMTsJLyogZXhpdCBvdXRl ciBsb29wICovCiAJCQkJYnJlYWs7CiAJCQl9Ci0KKwkJCQogCQkJZGVmYXVsdDoKIAkJCQlw YW5pYygiLS0gdW5rbm93biBvcGNvZGUgJWRcbiIsIGNtZC0+b3Bjb2RlKTsKIAkJCX0gLyog ZW5kIG9mIHN3aXRjaCgpIG9uIG9wY29kZXMgKi8KSW5kZXg6IHN5cy9uZXRwZmlsL2lwZncv aXBfZndfZHluYW1pYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBf ZndfZHluYW1pYy5jCShyZXZpc2lvbiAyNzgxNTEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lw X2Z3X2R5bmFtaWMuYwkod29ya2luZyBjb3B5KQpAQCAtNjY5LDEzICs2NjksMTUgQEAKIAog LyoqCiAgKiBJbnN0YWxsIGR5bmFtaWMgc3RhdGUgZm9yIHJ1bGUgdHlwZSBjbWQtPm8ub3Bj b2RlCisgKiBJZiBydWxlIGV4aXN0cywgdXBkYXRlIGl0IHN0YXRlLgogICoKICAqIFJldHVy bnMgMSAoZmFpbHVyZSkgaWYgc3RhdGUgaXMgbm90IGluc3RhbGxlZCBiZWNhdXNlIG9mIGVy cm9ycyBvciBiZWNhdXNlCiAgKiBzZXNzaW9uIGxpbWl0YXRpb25zIGFyZSBlbmZvcmNlZC4K ICAqLwogaW50Ci1pcGZ3X2luc3RhbGxfc3RhdGUoc3RydWN0IGlwX2Z3X2NoYWluICpjaGFp biwgc3RydWN0IGlwX2Z3ICpydWxlLAotICAgIGlwZndfaW5zbl9saW1pdCAqY21kLCBzdHJ1 Y3QgaXBfZndfYXJncyAqYXJncywgdWludDMyX3QgdGFibGVhcmcpCitpcGZ3X2luc3RhbGxf b3JfdXBkYXRlX3N0YXRlKHN0cnVjdCBpcF9md19jaGFpbiAqY2hhaW4sIHN0cnVjdCBpcF9m dyAqcnVsZSwKKyAgICBpcGZ3X2luc25fbGltaXQgKmNtZCwgc3RydWN0IGlwX2Z3X2FyZ3Mg KmFyZ3MsIHVpbnQzMl90IHRhYmxlYXJnLAorICAgIHN0cnVjdCB0Y3BoZHIgKnRjcCkKIHsK IAlpcGZ3X2R5bl9ydWxlICpxOwogCWludCBpOwpAQCAtNjg2LDcgKzY4OCw3IEBACiAKIAlJ UEZXX0JVQ0tfTE9DSyhpKTsKIAotCXEgPSBsb29rdXBfZHluX3J1bGVfbG9ja2VkKCZhcmdz LT5mX2lkLCBpLCBOVUxMLCBOVUxMKTsKKwlxID0gbG9va3VwX2R5bl9ydWxlX2xvY2tlZCgm YXJncy0+Zl9pZCwgaSwgTlVMTCwgdGNwKTsKIAogCWlmIChxICE9IE5VTEwpIHsJLyogc2hv dWxkIG5ldmVyIG9jY3VyICovCiAJCURFQigKQEAgLTcwOCw2ICs3MTAsNyBAQAogCiAJc3dp dGNoIChjbWQtPm8ub3Bjb2RlKSB7CiAJY2FzZSBPX0tFRVBfU1RBVEU6CS8qIGJpZGlyIHJ1 bGUgKi8KKwljYXNlIE9fU1RBVEVfT05MWToKIAkJcSA9IGFkZF9keW5fcnVsZSgmYXJncy0+ Zl9pZCwgaSwgT19LRUVQX1NUQVRFLCBydWxlKTsKIAkJYnJlYWs7CiAKQEAgLTEzNTcsNiAr MTM2MCw3IEBACiAJCXN3aXRjaCAoY21kLT5vcGNvZGUpIHsKIAkJY2FzZSBPX0xJTUlUOgog CQljYXNlIE9fS0VFUF9TVEFURToKKwkJY2FzZSBPX1NUQVRFX09OTFk6CiAJCWNhc2UgT19Q Uk9CRV9TVEFURToKIAkJY2FzZSBPX0NIRUNLX1NUQVRFOgogCQkJcmV0dXJuICgxKTsKSW5k ZXg6IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfcHJpdmF0ZS5oCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfcHJpdmF0ZS5oCShyZXZpc2lvbiAyNzgxNTEpCisr KyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3ByaXZhdGUuaAkod29ya2luZyBjb3B5KQpAQCAt MTgzLDggKzE4Myw5IEBACiBzdHJ1Y3QgdGNwaGRyOwogc3RydWN0IG1idWYgKmlwZndfc2Vu ZF9wa3Qoc3RydWN0IG1idWYgKiwgc3RydWN0IGlwZndfZmxvd19pZCAqLAogICAgIHVfaW50 MzJfdCwgdV9pbnQzMl90LCBpbnQpOwotaW50IGlwZndfaW5zdGFsbF9zdGF0ZShzdHJ1Y3Qg aXBfZndfY2hhaW4gKmNoYWluLCBzdHJ1Y3QgaXBfZncgKnJ1bGUsCi0gICAgaXBmd19pbnNu X2xpbWl0ICpjbWQsIHN0cnVjdCBpcF9md19hcmdzICphcmdzLCB1aW50MzJfdCB0YWJsZWFy Zyk7CitpbnQgaXBmd19pbnN0YWxsX29yX3VwZGF0ZV9zdGF0ZShzdHJ1Y3QgaXBfZndfY2hh aW4gKmNoYWluLCBzdHJ1Y3QgaXBfZncgKnJ1bGUsCisgICAgaXBmd19pbnNuX2xpbWl0ICpj bWQsIHN0cnVjdCBpcF9md19hcmdzICphcmdzLCB1aW50MzJfdCB0YWJsZWFyZywKKyAgICBz dHJ1Y3QgdGNwaGRyICp0Y3ApOwogaXBmd19keW5fcnVsZSAqaXBmd19sb29rdXBfZHluX3J1 bGUoc3RydWN0IGlwZndfZmxvd19pZCAqcGt0LAogCWludCAqbWF0Y2hfZGlyZWN0aW9uLCBz dHJ1Y3QgdGNwaGRyICp0Y3ApOwogdm9pZCBpcGZ3X3JlbW92ZV9keW5fY2hpbGRyZW4oc3Ry dWN0IGlwX2Z3ICpydWxlKTsKSW5kZXg6IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfc29ja29w dC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZndfc29ja29wdC5j CShyZXZpc2lvbiAyNzgxNTEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQu Ywkod29ya2luZyBjb3B5KQpAQCAtMTQzMyw2ICsxNDMzLDcgQEAKIAkJc3dpdGNoIChjbWQt Pm9wY29kZSkgewogCQljYXNlIE9fUFJPQkVfU1RBVEU6CiAJCWNhc2UgT19LRUVQX1NUQVRF OgorCQljYXNlIE9fU1RBVEVfT05MWToKIAkJY2FzZSBPX1BST1RPOgogCQljYXNlIE9fSVBf U1JDX01FOgogCQljYXNlIE9fSVBfRFNUX01FOgo= --------------020107060303090503050300 Content-Type: application/octet-stream; name="ipfw-state-only-v3.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only-v3.diff.sig" iQJ8BAABCgBmBQJU0eVYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFFQUIwM0M1OEJGREM0 NzhGAAoJEOqwPFi/3EeP2YgQAKCEWSHEP1mmS5S8BHDTV1GsImxOJ64Bj6Zr+tGG2WpRiMIJ /0gr0AcMa7QxxZAQ2U5gYNf9g8/BFAmpNOI54oJKlwL0BuJYLbaL6QM4Si5Sy8mzVIVGdm1a K/PbZ+G7Meg8eHyDv5+VjTErDWN4TH71hgPRZgOIJvZaB5JIcYDUZdYsd6k+Y6trh4QbPxrQ A2neRTyVKtQUuAoTyvpuDbu0eTGVCi/8NWQWzlr9h9jvUO/dGE5vuiDD3f9SBHnEGTaGxk48 Co2E/Xbb2W6n+T8niFKFAq8jdWVCrQuAvZiKIWgPUdha3PKLi32r1gRH9zRK7kPO07Z4JE5F srEJRSVqP0zxeQ/9QkR3+OQ4nyfsjip/jGJk4/7VMsh7L0zcSK5dtrH0G92FkcpVQyPcQx/p c1/d+6n76W35gcjzN+hkY+1vNweaD8in2qNrLwVnlI7DB2q/2l5Ujv9pUOlJY3UwPbSYJjnd pnAmWv/eIL4SawSm/vq/J/3ontgzBQx+hVMNnKy/S6yyh7T7t8uS3zO0HnlMdDLkIE0QojWz S7Cr8fjPiRHbkOf5Df254P7RK5RiuB1Q9YLxF8DQ18rah6fospj5xWOFRiWrVcmOcvNUI9Lh FQjAUYZXba+aAja+qryfoT3IQE6t2OAkPz0jhg0XiH5r5soQsOBa1L3S5H27 --------------020107060303090503050300-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 10:08:36 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B412E81; Wed, 4 Feb 2015 10:08:36 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 580D3A5B; Wed, 4 Feb 2015 10:08:36 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id fa1so1659010pad.8; Wed, 04 Feb 2015 02:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ls3x6uuXzu51t1mo8ymC5rDgGCaSm27DQYaUwMuc0qY=; b=yBQ+P94u7cgxtg7tS2NUR/t2ZaekS9joulKZkEdssGIocM3FMjQAbsNENFq2xbJa+4 jqN/JoPAKy+gPDU/z6b2HS+RG6wD9hJegJL+INNP/oMwLcbj00I/WvywmhocZMFS0PNs f/C9KjwWVRznDFMLhqJCmtZnyrSw44gXE0jl7uLEgCk1c+nsra74ZFzW6GJQZm/OY6iw +N+vfxisN2iJKmU2zht40NZVjbfYvjvx17MP3uvM/qzIXnYudOsfeWyGF1fOBfjp+6Mq dZSbCLXj8I0mx+KIpwbQgt7j45/0GO8IbRwu80gMq5tou3XUDVBJdYRJsTWCmU1HuDVD oUiQ== MIME-Version: 1.0 X-Received: by 10.68.197.72 with SMTP id is8mr14085918pbc.17.1423044515941; Wed, 04 Feb 2015 02:08:35 -0800 (PST) Received: by 10.70.45.228 with HTTP; Wed, 4 Feb 2015 02:08:35 -0800 (PST) In-Reply-To: <54D1E558.1010700@FreeBSD.org> References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> <54D1E558.1010700@FreeBSD.org> Date: Wed, 4 Feb 2015 18:08:35 +0800 Message-ID: Subject: Re: [RFC][patch] New "keep-state-only" option (version 3) From: bycn82 To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ipfw , "Alexander V. Chernikov" , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 10:08:36 -0000 *Cool, But maybe not all people are following this topic, so can you please simplify it by answering below question in order to allow more people to know what is going on here.* *What kind of problem you are facing and how does your patch resolve it?* On 4 February 2015 at 17:24, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 03.02.2015 19:55, Lev Serebryakov wrote: > > >> Ok, "allow-state"/"deny-state" was very limited idea. Here is > >> more universal mechanism: new "keep-state-only" (aliased as > >> "record-only") option, which works exactly as "keep-state" BUT > >> cancel match of rule after state creation. It allows to write > >> stateful + nat firewall as easy as: > > To work as expected, "keep-state-only" should not imply > > "check-state" in opposite to "keep-state". > Re-installation of state (with second, third, etc... packet of > connection) should update TCP state of state (sorry!), or it will die > in 10 seconds. > This version seems to be final (apart from name of new option!). > It works perfectly on my router with 2 uplink ISPs. > > - -- > // Lev Serebryakov AKA Black Lion > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJU0eVYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePOD0P/RwpwF9yMUjyAj/KZnphr/0Y > aXHM040qIocIUqnxH7T/vwdhm2w3Zciry8hwXp9f+r2bTIe8+tTn8OwaJ0M/Wp1j > QBPxW+rjw49hy3rf2eIQbgX7nTwdIZo7YDnT82Kqtje1mImTBR4qdFcSStJac4hE > dJsbpzC6raHUuE8h5V5pWPV/m/OQebK3P5CZzBKKpVTMCX3nVsTnff9qf9L1A0Jd > q4KYfOv+NJBaB8G6vJhDHjcqtzGfEJBmYL8kOAslYhlUuyYe+iAhyGFbcUBsXwk8 > /dqBalUL2iewFaZppszYZ0rTpVOfA4fOV0ECbVmpcw36uocrC2iOEpBl0WRIy+TM > HYIMkIeubF9IT24CwMwiriONpppl8MGynCmL9hyMgu+HiuvHZ/C/vYcVV9/DHFGB > iKkNe9QjX34anP6qVvEvHHmuv26PO7eq7hkdK2PZNlA9dwwNHehN8xG3DxB9N8gG > MPRGtM8yH/C/FXpqKmHoqj6shMGQCSfmZKPfJ0D49Rze8tSjo7kZaSmaELJAjmsc > xLv5umEAg7gym54bMhv8As2lXHnyeDp3uJz6glM72cmtBM5/n8N7NLk6Xga+8eM3 > cZ122dgOqzGpts9TqCGWmTRW+f2Y8hLukzIjOLdzlqLPfQmXVn9pOWmqo9OKHdvD > we0uYcnte/iSltopkVuG > =muco > -----END PGP SIGNATURE----- > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 10:42:41 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62CEF95F for ; Wed, 4 Feb 2015 10:42:41 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E751E2B for ; Wed, 4 Feb 2015 10:42:41 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14AgeFm042297 for ; Wed, 4 Feb 2015 10:42:40 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14AgeI8042296; Wed, 4 Feb 2015 10:42:40 GMT (envelope-from root) Date: Wed, 4 Feb 2015 10:42:40 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <37a9fb336d54797069f76edf2801927d@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTR96A= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 10:42:41 -0000 hiren added a comment. >>! In D1711#60, @hiren wrote: >>>! In D1711#58, @rrs wrote: > >> hiren: >> >> This looks interesting to me, it is definitely something I would like to look at. I assume you >> are on 10.stable like Sean? > > Yes, its plain stable10+D1711. > Also, all 3 panics are from the same system. >>! In D1711#62, @hiren wrote: >>>! In D1711#59, @rrs wrote: >> Hiren: >> >> Ok looking at kern_timeout.c thats a call to >> class->lc_lock(c_lock, lock_status); >> >> If my 10.x matches yours. > > It's not :-( > > Looks like what we have here is not stock stable10 really. I'll check all the details and get back first thing in the morning tomorrow. > > Thanks for checking and sorry for the trouble. My bad. So yes, these machines are indeed stable10+D1711. I'll follow up separately on original comment. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 10:44:29 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50B69A35 for ; Wed, 4 Feb 2015 10:44:29 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D684E54 for ; Wed, 4 Feb 2015 10:44:29 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14AiSd7043694 for ; Wed, 4 Feb 2015 10:44:28 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14AiSc4043693; Wed, 4 Feb 2015 10:44:28 GMT (envelope-from root) Date: Wed, 4 Feb 2015 10:44:28 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTR+Aw= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 10:44:29 -0000 hiren added a comment. >>! In D1711#59, @rrs wrote: > Hiren: > > Ok looking at kern_timeout.c thats a call to > class->lc_lock(c_lock, lock_status); > > If my 10.x matches yours. > > And the call inside that kern_rwlock.c:757 > is > > v = rw->rw_lock; > owner = (struct thread *)RW_OWNER(v); > > I would imagine v is probably a freed lock or some such.. not sure. > If you have a vmcore sending the registers would be helpful. And for that > matter if you have a vmcore if you could get in the frame of kern_timeout > and tell me what > c_lock > c_func > are that would be helpful. I have not tested this with my test framework for locks > that pass in a lock.. If the c_func is not some private thing but something in > BSD I can puzzle out what sub-system is using the callout this way and > try to reproduce a test that will blow up this way on me as well. > > Assuming of course its not the caller that has freed the > lock ahead of the callout system running... panic #3 happened on stable-10+this patch. I've setup a -head box with this patch to reproduce the problem. In any case, I'll try to get vmcore and other details tomorrow. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 11:04:17 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3D3DCF; Wed, 4 Feb 2015 11:04:17 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9448C103; Wed, 4 Feb 2015 11:04:17 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t14B4BFQ043083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Feb 2015 03:04:14 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1FCA5.5030408@freebsd.org> Date: Wed, 04 Feb 2015 19:04:05 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option (version 3) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> <54D1E558.1010700@FreeBSD.org> In-Reply-To: <54D1E558.1010700@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:04:17 -0000 On 2/4/15 5:24 PM, Lev Serebryakov wrote: > -- > Re-installation of state (with second, third, etc... packet of > connection) should update TCP state of state (sorry!), or it will die > in 10 seconds. > This version seems to be final (apart from name of new option!). > It works perfectly on my router with 2 uplink ISPs. can you put it in the code review system so I can annotate and comment on it? From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 11:23:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CAFA902; Wed, 4 Feb 2015 11:23:34 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13CC43FE; Wed, 4 Feb 2015 11:23:33 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t14BNShg043337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Feb 2015 03:23:31 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D2012B.6040906@freebsd.org> Date: Wed, 04 Feb 2015 19:23:23 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: bycn82 , lev@freebsd.org Subject: Re: [RFC][patch] New "keep-state-only" option (version 3) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> <54D1E558.1010700@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ipfw , "Alexander V. Chernikov" , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:23:34 -0000 On 2/4/15 6:08 PM, bycn82 wrote: > /Cool, > But maybe not all people are following this topic, so can you please > simplify it by answering below question in order to allow more > people to know what is going on here. > > / > /What kind of problem you are facing and how does your patch resolve it? > > > / > let me have a go at this: when you write complicated rule sets with state, you start having problems where the state is too broad, or contains things you don't want in the place where you are using it.. sure you want packet/session A to set the state, but you don't want state for session B to trigger there at the same time. this allows you to set a state/action for all future packets in the session without triggering sessions you didn't mean to, or actually doing that action yourself right now. this give you a lot more flexibility in the sets you can create. An example here is combining NAT with session state. You can only have the rule active on one side of the NAT. If you want ot have state on the 'inside' of the NAT then you want outgoing processing to continue on, so that the NAT is then used. However if you try do the check-state on input After the NAT (you need to do NAT on the same 'side' of the NAT for both incoming and outgoing) then you end up having to do various tricks to avoid being diverted into output processing. what you want to do is be able to set a rule that will handle the incoming packets in a way you want but doesn't do the same thing for the outgoing packets. Come to think of it another answer might be the ability to specify different actions for a session for incoming and outgoing, but that would be quite hard to do. at least this way you can specify a rule for input without having to do the same thing on output. there are other drawbackss . like if you have another check-state in the output path, it will still trigger on the packet and do what you didn't expect. but I think this is an improvement. Having said that. I'd REALLY like to have multiple dynamic sets and be able to specify which set I'm looking in. then you could have differnt dynamic rules for NAT'd and unNATed packets, and differnet rules for the same packets as they traverse different interfaces. Lev, I think this is an improvement, but I wonder if we can make it even better. Julian From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 12:55:42 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 212C0FA0 for ; Wed, 4 Feb 2015 12:55:42 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB8A1F61 for ; Wed, 4 Feb 2015 12:55:41 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14Ctf4V078817 for ; Wed, 4 Feb 2015 12:55:41 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14CtfwN078814; Wed, 4 Feb 2015 12:55:41 GMT (envelope-from root) Date: Wed, 4 Feb 2015 12:55:41 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <16f73e21451ca4c5d595809526a4ed2b@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSFs0= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 12:55:42 -0000 rrs added a comment. Ok guys, I have puzzled out what that crash *may* be that was posted by Hiren. The same issue exists in the timeout code rewrite that Han's has up on the board as well. Though the callout_drain_async() may solve it if the user called that instead. Here is what is happening. 1) CPU1 is running the callout from the callout wheel it gets to softclock_call_cc() line 635, its all ready to run and unlocks the callout mutex. It then sees c_lock is populated and thus calls class->c_lock()...) to switch locks. It begins to spin in __rw_wlock_hard() in the while loop waiting to get the lock since its held. 2) lltable_free() has been called on CPU 2, it grabs its AFDATA lock and then goes through each entry and does LIST_FOREACH_SAFE(..) { LLE_WLOCK(lle); <-- this is the lock that CPU 1 is waiting on if(callout_stop(la->la_timer)) LLE_REMREF(lle) llentry_free(lle); } 3) The callout_stop() on CPU 2 does what it is supposed to and sets the cc_cancel bit to true and return 1. This causes callout_stop() to lower the reference count which means when llentry_free() is called the lle *is* freed. This calls into either in_lltable_free() or in6_lltable_free() which unlocks the lock (letting CPU 1 go forward) and then promptly destroys the lock and frees the memory. 4) Finally our spinning CPU 1 loops back around and finds the destroyed mutex and crashes. Now, some interesting notes on this: a) If the lle* code had used MPSAFE instead of passing the lock in, then zero would have been returned since the callout "could not have been stopped". This would have left the reference and *not* freed the memory.. the timer would have done that has it executed. b) If the lle* code just did not stop the timer, and instead let it run off, it would have freed itself on expiration.. of course what you really want here is "stop it if you can" but don't stop it if its already running. Which is why is true since thats what you get if you control the lock. I c) This little hole is also in Han's new code unless we change the user of the code to use the async_drain routine. Which again is changing the KPI something I don't like to do since its in *so* many places ;-) Of course we may want an async-drain I have not thought about that. d) This race has always been there near as I can tell and really is not caused by the migration code that was added like the other code that was fixed. I don't really see an easy way to fix this accept to change the caller to use MPSAFE.. or maybe make a async_drain routine.. but then we still end up changing the caller ;-) INLINE COMMENTS kern/kern_timeout.c:1159 sounds good I will make it so. kern/kern_timeout.c:1234 Imp: Yes, it looks wrong in the kern_timeout.c code.. let me fix it ;-) REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 13:00:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5B1A10D for ; Wed, 4 Feb 2015 13:00:44 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 914E6FB2 for ; Wed, 4 Feb 2015 13:00:44 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14D0ifw086325 for ; Wed, 4 Feb 2015 13:00:44 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14D0iLW086324; Wed, 4 Feb 2015 13:00:44 GMT (envelope-from root) Date: Wed, 4 Feb 2015 13:00:44 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Updated, 79 lines] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <7ca5ff6edc4903043fd3918f2289f452@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTSF/w= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:00:44 -0000 hselasky edited reviewers, added: np; removed: rmacklem hselasky removed a subscriber: np. hselasky updated this revision to Diff 3630. hselasky added a comment. Address comments from imp and np: - Update patch to use IP_MAXPACKET as default for LRO which preserves existing behaviour. - Add to new configuration options to configure VLRO. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1761?vs=3606&id=3630 REVISION DETAIL https://reviews.freebsd.org/D1761 AFFECTED FILES sys/conf/options sys/netinet/ip_input.c sys/netinet/ip_output.c sys/netinet/tcp_input.c sys/netinet/tcp_lro.c sys/sys/mbuf.h To: hselasky, rrs, glebius, gnn, emaste, lstewart, rwatson, bz, adrian, imp, np Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 13:06:58 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AED6736E for ; Wed, 4 Feb 2015 13:06:58 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69FA3138 for ; Wed, 4 Feb 2015 13:06:58 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14D6wC9093246 for ; Wed, 4 Feb 2015 13:06:58 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14D6wj8093245; Wed, 4 Feb 2015 13:06:58 GMT (envelope-from root) Date: Wed, 4 Feb 2015 13:06:58 +0000 To: freebsd-net@freebsd.org From: "julian (JulianElischer)" Subject: [Differential] [Changed Subscribers] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <0453f7b043b66893da264b0a6028bd02@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSGXI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:06:58 -0000 julian added a subscriber: julian. julian added a comment. >>! In D1711#66, @rrs wrote: > 3) The callout_stop() on CPU 2 does what it is supposed to and sets the cc_cancel bit to true and > return 1. This causes callout_stop() to lower the reference count which means when llentry_free() > is called the lle *is* freed. This calls into either in_lltable_free() or in6_lltable_free() which > unlocks the lock (letting CPU 1 go forward) and then promptly destroys the lock > and frees the memory. > Surely the answer is for the other thread to take out a reference so that callout_stop() doesn't get the value to 0 REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 13:15:14 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4915553D for ; Wed, 4 Feb 2015 13:15:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 040E528B for ; Wed, 4 Feb 2015 13:15:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14DFDKY002677 for ; Wed, 4 Feb 2015 13:15:13 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14DFD4D002676; Wed, 4 Feb 2015 13:15:13 GMT (envelope-from root) Date: Wed, 4 Feb 2015 13:15:13 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <15f2265390c9761af1ce2cc1cc72b7c8@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSG2E= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:15:14 -0000 hselasky added a comment. julian: Hence a lock is used, the callback won't be called when callout_stop() returns 1. Only the mutex will still be used. Maybe a callout_reset() having 1 tick as timeout will work instead of callout_stop(). If the callout_reset() returns 0 we add a ref instead of grabbing one. .... REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 13:52:05 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF139F08 for ; Wed, 4 Feb 2015 13:52:05 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AB1295A for ; Wed, 4 Feb 2015 13:52:05 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14Dq5f3041686 for ; Wed, 4 Feb 2015 13:52:05 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14Dq5Jp041685; Wed, 4 Feb 2015 13:52:05 GMT (envelope-from root) Date: Wed, 4 Feb 2015 13:52:05 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <4ecb6f65254e3bbc357bb3033f41a914@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSJAU= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:52:05 -0000 rrs added a comment. Julian: The point is *exactly* that, the callout *has* a reference.. and now that the table is being flushed if the callout_stop returns 1 it thinks the callout has been stopped, which it has, which means it will not run and release its reference. Thus the lowering of the reference count on the return true from the stop. But the issue is the lock used is part of what the thing will free. I have looked through all callout_stops and only the lle code (in three forms) does this. I think the right fix here is to just go ahead and change the callout_init used to one with the MPSAFE flag. When the callout runs all it does is drop the lock and release the reference which causes the free in theory... So I think with a simple change to the init function this problem does not happen. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 14:03:23 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A87B3DE for ; Wed, 4 Feb 2015 14:03:23 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24FFDB11 for ; Wed, 4 Feb 2015 14:03:23 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14E3MF0052898 for ; Wed, 4 Feb 2015 14:03:22 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14E3M4t052897; Wed, 4 Feb 2015 14:03:22 GMT (envelope-from root) Date: Wed, 4 Feb 2015 14:03:22 +0000 To: freebsd-net@freebsd.org From: "julian (JulianElischer)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <57443999a8bd0b310f9bea2e2412360d@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSJqo= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 14:03:23 -0000 julian added a comment. let me see if this is correct.. I'm assuming that the reference count can not change if you hold the lock? if so then before releasing the lock, we can check if the count is 1.. if it is then we are the only person who even knows where this thing is so there can't be any new references added.. having stopped the callout action from happening we inherit it's reference. If it IS 1 then we can drop the lock because no one else can get it, and we can then drop the reference safely. the question is what to do if it is NOT 1? can that happen? who else might hold a reference..? we drop the lock, and wait a moment, and then retake the lock and retry? if it can not be > 1 then maybe an assert to that affect may be a safe thing to add. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 14:06:28 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A2635B3 for ; Wed, 4 Feb 2015 14:06:28 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55B3CB68 for ; Wed, 4 Feb 2015 14:06:28 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14E6Svl055509 for ; Wed, 4 Feb 2015 14:06:28 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14E6SfW055508; Wed, 4 Feb 2015 14:06:28 GMT (envelope-from root) Date: Wed, 4 Feb 2015 14:06:28 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <42226c7ffb93ccedfa0f47e21480db6a@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSJ2Q= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 14:06:28 -0000 hselasky added a comment. julian: What do you mean by "wait a bit". Spinning or sleeping? REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 14:38:14 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7CACD89 for ; Wed, 4 Feb 2015 14:38:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7242CEDC for ; Wed, 4 Feb 2015 14:38:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14EcEd9087739 for ; Wed, 4 Feb 2015 14:38:14 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14EcE5n087738; Wed, 4 Feb 2015 14:38:14 GMT (envelope-from root) Date: Wed, 4 Feb 2015 14:38:14 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Updated, 241 lines] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSLtY= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 14:38:14 -0000 rrs updated this revision to Diff 3631. rrs added a comment. This revision now requires review to proceed. This fixes the comment as imp suggested and the indent... CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1711?vs=3603&id=3631 REVISION DETAIL https://reviews.freebsd.org/D1711 AFFECTED FILES kern/kern_timeout.c sys/callout.h To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 14:45:49 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 865ADFF0 for ; Wed, 4 Feb 2015 14:45:49 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C94BFF2 for ; Wed, 4 Feb 2015 14:45:49 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14EjnTC096346 for ; Wed, 4 Feb 2015 14:45:49 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14Ejn9F096345; Wed, 4 Feb 2015 14:45:49 GMT (envelope-from root) Date: Wed, 4 Feb 2015 14:45:49 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <1a5308ff90013979069e811ef5a52a74@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSMJ0= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 14:45:49 -0000 rrs added a comment. Julian: The simple fix is to change the callout_init_rw -> callout_init(c, 1); That makes it so the callout_stop() in this instance would return 0, not 1. Since the callout could not be stopped. This would then cause the reference count to drop to 1 (it was 2 the original and the callout). It would not free here but when the callout runs it would. Now that all being said, I have put that in some netflix code and will test it.. but there is something strange about this whole lle* path that I don't yet grok. The arp code and nd6 code carefully do reference counting. There are comments in in.c and in6.c that mention that the arp/nd6 code are the callers.. thats fine.. However *if* either callout goes off in the then the in/in6 callout runs which does: UNLOCK(lle) free(la) No reference counting, no nothing.. I don't grok how all this is connected and need to study it more but it just feels wrong. If its doing reference counting I would have thought the callout would have done so too. I need to take a bigger and closer view at the lle/arp code and how it is all supposed to inter-work.. it appears to me broken, but that could be just my mis-understanding of the code.. I should get home tomorrow and besides fixing my mail-server I wills see what Robert, George and Kirk have to say about the lle code paths in there new book, and then dig in and try to puzzle it out. I *think* the simple change callout_init_rw -> callout_init(c, 1) will fix this and of course we have to remove the unlock in the actual callout since the callout code won't be locking it any longer... but I am wondering if there is not a deeper issue with this code. Doing the above will not change the behavior and will get the right results on the flush, but this use/not-use references seems wrong so there may be deeper bugs in the lle code! R REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 15:29:08 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CDD1C9B for ; Wed, 4 Feb 2015 15:29:08 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48CE07AB for ; Wed, 4 Feb 2015 15:29:08 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14FT8Li040535 for ; Wed, 4 Feb 2015 15:29:08 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14FT832040534; Wed, 4 Feb 2015 15:29:08 GMT (envelope-from root) Date: Wed, 4 Feb 2015 15:29:08 +0000 To: freebsd-net@freebsd.org From: "imp (Warner Losh)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <76adf326bedd5400cf7771027a1cc817@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSOsQ= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 15:29:08 -0000 imp added a comment. For the lle* code, it looks like the reference count for the data structure improperly doesn't cover the implicit use of the mutex by the callout system. That seems to be the real bug here, no? Protecting a mutex with a reference count without holding a reference to that mutex until the callout code cannot use it again? Not sure how, however, we can properly drop the reference count to the mutex with the current callout API :( REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 16:17:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13C1290A for ; Wed, 4 Feb 2015 16:17:44 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E431CD3F for ; Wed, 4 Feb 2015 16:17:43 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14GHhTM091091 for ; Wed, 4 Feb 2015 16:17:43 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14GHhu0091090; Wed, 4 Feb 2015 16:17:43 GMT (envelope-from root) Date: Wed, 4 Feb 2015 16:17:43 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Requested Changes To] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <2825bc57cdaf16770866ede812a63b1c@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTSRic= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 16:17:44 -0000 adrian requested changes to this revision. adrian added a comment. This revision now requires changes to proceed. I still don't want to see the hash type stuff polluted with things that aren't hashes, making it more difficult to implement RSS work distribution along with other kinds of features. We need to stash that flag somewhere else. If we've run out of mbuf header flag bits then it's time to think about extending them before 11-REL. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rrs, glebius, gnn, emaste, lstewart, rwatson, bz, imp, np, adrian Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 17:01:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 862E789D for ; Wed, 4 Feb 2015 17:01:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EDFC3C4 for ; Wed, 4 Feb 2015 17:01:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14H1wUC039204 for ; Wed, 4 Feb 2015 17:01:58 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14H1wSC039203; Wed, 4 Feb 2015 17:01:58 GMT (envelope-from root) Date: Wed, 4 Feb 2015 17:01:58 +0000 To: freebsd-net@freebsd.org From: "imp (Warner Losh)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <5646eed617c638419a937e31474d8221@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSUIY= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 17:01:59 -0000 imp added a comment. So why doesn't the lle* code set mpsafe to 1? After re-reading the man page several times, I'm thinking that's the solution here. It already uses other locks and reference counts to synchronize things, so why get Giant involved at all? REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 18:16:39 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D558BEC4 for ; Wed, 4 Feb 2015 18:16:39 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0AD1E7D for ; Wed, 4 Feb 2015 18:16:39 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14IGdvs072390 for ; Wed, 4 Feb 2015 18:16:39 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14IGdrW072389; Wed, 4 Feb 2015 18:16:39 GMT (envelope-from root) Date: Wed, 4 Feb 2015 18:16:39 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <603206cac81180c7f2b1e6f0ed4fb1c9@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSYgc= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 18:16:40 -0000 rrs added a comment. Imp: Ok I have spent a bit of time puzzling this out. First I was mistaken, the callouts being run are either arptimer or nd6timer(function name not right). These are not using giant but the passed in lle structure rw_lock. We need to adjust these so that they check they: 1) get the lock (since the callout system would no longer lock for them the rw_lock) 2) Check the pending bit.. if its set some other place as restarted the callout (there are several places this can happen from). 3) Don't check the !callout_active() flag, since this would mean its not been rescheduled and it actually was cleared by the lle_table_flush (wrong function name here) function, in there its watching the return of the callout (its where the crash was from). So instead now since the "callout can't be stopped" it returns 0 (not lowering the reference) even though the callout can't be stopped, it will have removed the active bit which.. so if we returned here we would leak the memory leaving the reference up, so instead we go ahead and finish processing the callout doing the reference lowering and removal. Its a bit odd from the normal way you do it but I think it will work fine. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 18:16:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AD5AF6E for ; Wed, 4 Feb 2015 18:16:47 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76CD7E8B for ; Wed, 4 Feb 2015 18:16:47 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14IGlB9072635 for ; Wed, 4 Feb 2015 18:16:47 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14IGlCJ072634; Wed, 4 Feb 2015 18:16:47 GMT (envelope-from root) Date: Wed, 4 Feb 2015 18:16:47 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: <9cccd007ca17d842807cc48462a32e55@localhost.localdomain> X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTSYg8= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 18:16:47 -0000 hselasky added a comment. Adrian: We do have one bit left after M_FLOWID was removed. Should I use it for this? And what would be an appropriate name. M_LENGTH_OK ? REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rrs, glebius, gnn, emaste, lstewart, rwatson, bz, imp, np, adrian Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 18:19:23 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2509FD1 for ; Wed, 4 Feb 2015 18:19:23 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02012EBF for ; Wed, 4 Feb 2015 18:19:23 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14IJMGo074587 for ; Wed, 4 Feb 2015 18:19:22 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14IJMnf074586; Wed, 4 Feb 2015 18:19:22 GMT (envelope-from root) Date: Wed, 4 Feb 2015 18:19:22 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFTSYqo= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 18:19:23 -0000 adrian added a comment. I think we should talk to rwatson about his mbuf hijinx and see about extending flags. This isn't the only option to add. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rrs, glebius, gnn, emaste, lstewart, rwatson, bz, imp, np, adrian Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 19:30:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D52B1FE for ; Wed, 4 Feb 2015 19:30:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D2F89E7 for ; Wed, 4 Feb 2015 19:30:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14JUdBR055548 for ; Wed, 4 Feb 2015 19:30:39 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14JUdsp055547; Wed, 4 Feb 2015 19:30:39 GMT (envelope-from root) Date: Wed, 4 Feb 2015 19:30:39 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Request, 51 lines] D1777: Associated fix for arp/nd6 timer usage. Message-ID: X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 19:30:40 -0000 rrs created this revision. rrs added reviewers: jhb, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian. rrs added subscribers: hselasky, julian, hiren, emaste, freebsd-net. REVISION SUMMARY There is a hole in the timer code that when you give it a lock, it will lock that lock and then check to see if its been canceled. If the API user actually deletes the memory out from under the callout has its being processed this could (and did in nd6/arp case) lead to a panic when you try to lock (in the callout code) a lock thats been removed. If you use the MPSAFE version, you don't get that since the non-stoppable timers proceed and does the right thing. TEST PLAN After running witness and invariant I will put this on a couple of netflix caches and make sure I see no adverse results (leaked nd6 or arp entries). REVISION DETAIL https://reviews.freebsd.org/D1777 AFFECTED FILES sys/netinet/if_ether.c sys/netinet/in.c sys/netinet6/in6.c sys/netinet6/nd6.c To: rrs, jhb, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian Cc: freebsd-net, emaste, hiren, julian, hselasky From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 19:31:19 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDF822C0 for ; Wed, 4 Feb 2015 19:31:19 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 994C0A0D for ; Wed, 4 Feb 2015 19:31:19 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14JVJ3g057334 for ; Wed, 4 Feb 2015 19:31:19 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14JVJEe057333; Wed, 4 Feb 2015 19:31:19 GMT (envelope-from root) Date: Wed, 4 Feb 2015 19:31:19 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <5ed3e26a23b24caca9d36c318e5de57d@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTSc4c= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 19:31:20 -0000 rrs added a comment. I have created D1777 to address the nd6/arp crash separately. I am currently in the midst of testing these. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 20:05:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 281A8C90 for ; Wed, 4 Feb 2015 20:05:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03BDBD8E for ; Wed, 4 Feb 2015 20:05:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14K5Xr0093037 for ; Wed, 4 Feb 2015 20:05:33 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14K5XbH093036; Wed, 4 Feb 2015 20:05:33 GMT (envelope-from root) Date: Wed, 4 Feb 2015 20:05:33 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Updated] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <4aad6ae02da7ca3c695cf313a055ddf0@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTSe40= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:05:34 -0000 adrian added a comment. I'm still a little iffy about this kind of fix. It looks more like a lifecycle management thing that we should fix, rather than just moving to MPSAFE. But I unfortunately don't have the time to go look at the lle code and figure out how it should look. :( REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, jhb, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian Cc: freebsd-net, emaste, hiren, julian, hselasky From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 20:13:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00090F5F for ; Wed, 4 Feb 2015 20:13:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE1C8E94 for ; Wed, 4 Feb 2015 20:13:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14KDqgr002459 for ; Wed, 4 Feb 2015 20:13:52 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14KDqxl002458; Wed, 4 Feb 2015 20:13:52 GMT (envelope-from root) Date: Wed, 4 Feb 2015 20:13:52 +0000 To: freebsd-net@freebsd.org From: "bz (Bjoern A. Zeeb)" Subject: [Differential] [Changed Subscribers] D1777: Associated fix for arp/nd6 timer usage. Message-ID: X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTSfYA= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:13:53 -0000 bz added a subscriber: bz. bz added a reviewer: bz. bz added a comment. It smells like a lle_refcnt bug to me and I have send a private email to errs to understand the problem better (and also if other optional kernel options might have been used while this was experienced). REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, jhb, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 22:16:09 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38DF3502; Wed, 4 Feb 2015 22:16:09 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id F1792E74; Wed, 4 Feb 2015 22:16:08 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 7F6D25C002; Thu, 5 Feb 2015 01:15:56 +0300 (MSK) Message-ID: <54D29A21.2080006@FreeBSD.org> Date: Thu, 05 Feb 2015 01:16:01 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: does "nat redirect_port tcp" works for you on -CURRENT? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 22:16:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have such rules in my firewall: nat 9 config redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 22222 nat 1 config ip $EXT_IP same_ports ... // Packets from outer world 11040 nat 9 // Redirection? 11050 nat 1 dst-ip $EXT_IP // De-NAT what should be de-NATed (not redirected by previous) 11060 check-state 11070 skipto 30000 // Allowed local services - common block ... ... 30030 allow proto tcp dst-ip 192.168.134.2 dst-port 22 setup keep-state 30040 allow proto tcp dst-ip 192.168.134.2 dst-port 16881 setup keep-state 30050 allow proto udp dst-ip 192.168.134.2 dst-port 16881 keep-state ... And looks like TCP redirection doesn't work. Counters on rules 30030 and 30040 is strictly zero and "ssh -p 22222 $EXT_IP" (from external host) doesn't work. Rule 30050 (udp one) HAS counters increased, but what is REALLY strange, is that 11040 and 11050 (two NAT actions) always have SAME counters, as if 11040 never change destination address. Nut 30050 sees some packets! Is "nat redirect_port tcp" broken in -CURRENT or do I do something wrong? - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0pohXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePjNkP/3msSEuRm6RWuGGVqIddHzki k2oh5YfbjfXC6hP4XumouqHojbHoHfNqv6yOet31xFwscnX71Q7LVSTF95jhbu9J jJrF2PDkPh+d6XagtuLaAHBvG3PRS61vgW9kl00/IiiemPfA/r10vcXz1TixdLgB bI/N0OFQyz9YXwWWEwZNywAOLaUTYD1FM2F5FtbwGvedlhBcmC08h1D5M1Vk2mF5 P/2ZocAECUeRPW5/JRg6kcnA3nJ8CVJr08I1IqQEsaQifRAOFfYcVSdb9DbK5Hms z6nVaJSwi6D1QtxR4x3BNoqGD8o3oc5YWW8obsV6uYzxfZcew2OoyiRgTMDuoBho 73q6WmUlvlvFB1PCOCGr8YxzHPpQZ7KP8NMKoSM8CiAT0/n5qY9CJGOxcf2Q4EEv tErw/TkjAXmzxGDj0ZZBjjvWE7kIhSk9HgXfzF3XL3FasmcV5Iu+JeSswlPtpHyD RCfB84rUcjmldpGZVs9OXD3+jJpY2JaXNrDmdM7elVr9d/CvM1IDkm62N9b9Pqjr uE4VKyipVrbsb06INchz9Gg5D1LhTbBCWoB6mo/5F1dYBkpSqezVUMsibcKvLbeR 9cBkL+iQif1Q8TmfIMYBwbqcfIx6MhbOxhtAiHR3QECc1IJ6Vn3/hrcVzB/PXc4Y SQU7uy3TpJH320nN1BDV =aAlm -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 22:20:49 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 250DA656; Wed, 4 Feb 2015 22:20:49 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D9A28EB2; Wed, 4 Feb 2015 22:20:48 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 241DA5C002; Thu, 5 Feb 2015 01:20:47 +0300 (MSK) Message-ID: <54D29B44.1060603@FreeBSD.org> Date: Thu, 05 Feb 2015 01:20:52 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: does "nat redirect_port tcp" works for you on -CURRENT? References: <54D29A21.2080006@FreeBSD.org> In-Reply-To: <54D29A21.2080006@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 22:20:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05.02.2015 01:16, Lev Serebryakov wrote: > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > 192.168.134.2:22 22222 Also, if I add "log" to this config: nat 9 config log redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 22222 I could not print this log: # ipfw nat 9 show log ipfw: unknown redir mode ipfw nat 9 config log# Configuration printing is Ok: # ipfw nat 9 show config ipfw nat 9 config log redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.168.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 22222 # - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0ptEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePphIQALKqUuR7wGZGlJaR58arzYZi boLuUxCSoM98UBO58egLeEgn7CKVxt34JRH6OwjDh18KeocfYr92LoYCpt6324dM rjQqy4PdYda91aW+46qUFFY1n3i55AB+WfLDdmUNivqGn+ouKnSHdoFMknvG+bnC n1DZIEiUpbE5ZnlA6XJ3nZUpmmKVTpHBWemEzF/Vn3f8A9ShJlI3fmK3+eh+SH59 B6k4IgcGryDsskCBuRTam+dYq89+a0wSVyzcrNiYLxikPy+wE2bCwY8tE63I5khZ 7MAuSVlgaOq+CvJmKRQ+522h3H5w6eco/wQokq1IyhpBeLNwI55BfY5jZdll9/M8 c6d5yho85VzXbNbTi2XXSWAmi9xYw6Pag4dA8iaLe2Mdoh8klgtOKBVo9uNw7ywX WS7/NyhlmMvJffStdO2t88awEV5NNE5lYeCmCstK3zZ+m7feKDynhHrUqOoXaZux 7tylx0J0rihdULZH1PyceO6y9aGRKfdoes0oiUc3ovumUunmFrTUdkEgodTG2nEo CPSlvy5rthL634b1NSBIrdHPGYo+6IQR3s4MaTs/RvdIVQHoZrl4XtKz8h904Fl4 MuYCfNI4E7I/AV6n3rbidQvfgosu4+wtR+4tZ8iV7gTLNZEZ6DiyXn8Ab3sNKuLC LjOfhudWDkmfumCqIkNE =hZrV -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 22:26:58 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 720AB8BE for ; Wed, 4 Feb 2015 22:26:58 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 325F0F9D for ; Wed, 4 Feb 2015 22:26:58 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14MQvgd042213 for ; Wed, 4 Feb 2015 22:26:57 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14MQvDt042211; Wed, 4 Feb 2015 22:26:57 GMT (envelope-from root) Date: Wed, 4 Feb 2015 22:26:57 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <1e8c87cf7782da9764a3dd929f7e2a43@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTSnLE= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 22:26:58 -0000 rrs added a comment. I don't think this is a refcnt issue bz, the base of this is a hole in the way the callout code works. Basically there is a window when a) The callout_wheel is executing, it sees that a "lock" has been configured, so it goes to release the callout wheel lock and then lock the callout init'd lock b) At that time some other cpu has the lock (that was inited on the callout), and it then runs a callout_stop (not drain). This cause the callout to "stop" the callout from running (which it can do). It sets a flag on the callout and returns to the caller. The caller (lle in this case) proceeds to delete the ref cnt since the callout was stopped (and it is it won't be run). It then in the end purges the memory. c) Now we resume above and it now de-ref's the lock. This window is not avoidable with the way the current callout code is architected. It can only be avoided by the caller getting the lock not the callout system. That way it won't de-ref the lock and blow up when it hits deleted memory. There may be other ways to fix this, but I don't know how we can change the callout system to handle it.. Even Han's re-write has this same problem if you use the callout_stop and not callout_drain* REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, jhb, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 22:44:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10EADC87 for ; Wed, 4 Feb 2015 22:44:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6807254 for ; Wed, 4 Feb 2015 22:44:05 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t14Mi5lV061299 for ; Wed, 4 Feb 2015 22:44:05 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t14Mi5q9061298; Wed, 4 Feb 2015 22:44:05 GMT (envelope-from root) Date: Wed, 4 Feb 2015 22:44:05 +0000 To: freebsd-net@freebsd.org From: "jhb (John Baldwin)" Subject: [Differential] [Updated] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <2a88ee2dc845ecaa0d8b5e153cb37a8e@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTSoLU= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 22:44:06 -0000 jhb added a comment. This is just "How It Works". You are always supposed to do a callout_drain() before freeing the storage belonging to a callout. I don't understand how you are preventing the callout/lock being freed out from under the callout routine in this version either. Now you can have this sequence: a) softclock dequeues callout to run b) other thread grabs lle_lock c) softclock blocks on lle_wlock above d) other thread tears down structure, unlocks lock, zeros memory, 0xdeadc0de, etc. e) softclock wakes up in mutex code and panics becuase the mutex is destroyed and it either triggers an assertion, follows a bad pointer trying to propagate priority or see if the "owner" is running, etc. You have to drain the callout somehow. Hans other solution is to arrange to have a callback function do the free for you if you can't block in the context where you are trying to free the structure. REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 23:14:42 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34086A1; Wed, 4 Feb 2015 23:14:42 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id E93677D3; Wed, 4 Feb 2015 23:14:41 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id AFE5F5C003; Thu, 5 Feb 2015 02:14:35 +0300 (MSK) Message-ID: <54D2A7E1.2020902@FreeBSD.org> Date: Thu, 05 Feb 2015 02:14:41 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: does "nat redirect_port tcp" works for you on -CURRENT? References: <54D29A21.2080006@FreeBSD.org> In-Reply-To: <54D29A21.2080006@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:14:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05.02.2015 01:16, Lev Serebryakov wrote: > I have such rules in my firewall: > > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > 192.168.134.2:22 22222 > > nat 1 config ip $EXT_IP same_ports One more datapoint: if I merge this to one NAT (and change rules accordingly), redirect work as expected. But I have TWO different NATs in full config (for two ISPs) and don't want to duplicate all redirection specifications, but want to use third "common" NAT config. And such usage is shown in ipfw(8)! - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0qfhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePtxMQAMg/YeLuNTP4KzKAGb8Z0AXc RLMdopJaZ81R5f4LnWtcQR1n0hzdLRhsmFvPLuHUdB6RgFbJ+TreMZq4h5IMLivy Wig9Uljhjkd6nS415ca4pQSrd9fzymI69WTLq/WSHwgxv6ngeT1x97cNh20R9VuD 3tPxj70Lf5IhtHB4MePpb3mh+iaLuaB9pizoP57M7YghN5qjvgXnaDRPamWiCfJl moUAXL1OQ0wInz1G9Z08nXJQz33mcJWlBNlPUc6n58nGjJGrgtNQL7sNCbs9yvVg +3+bHVH1e6v0BVuDKfEpYPP9KjCCLPWQvh7IgMpjur4fUBpe2TGVo+PS5i8ndakF KGvhmqJYsENuyh4GbiyQPN6kbDXXWl/PnUDKmtRHAdFMPLYOPkrgH4WJgHOU2zuR +iOmT5pmhG/9lb8yrNy8gmWgoj8XUvA/RlCHNtqzKVX9A6cFk+Tg5XMYSGbFlWYL h/O72zcSc7HQ/bsgj2sDT8ohfyIRCo9PtQPXtC2t0rdrDRQllCGNRALnUk8C0K2+ 4cYN4R3fIEjIBXAl6eCPlBDJEzS+WnXNNea1qIlW54vP5JmtQ7AMaSl0teUxNInU 8V4OUl+R9XMG456Ri370abfFHIr8PN63G9FhfCjWAPzyAYLR48HooGcCZN9Zzz4L vYxM8Xo9xKtuV9G9E8f0 =GIA1 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 04:11:01 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 897D3127 for ; Thu, 5 Feb 2015 04:11:01 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65FA7C9E for ; Thu, 5 Feb 2015 04:11:01 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 8421E1941DD; Thu, 5 Feb 2015 04:10:59 +0000 (UTC) Message-ID: <54D2ED52.7060100@ignoranthack.me> Date: Wed, 04 Feb 2015 20:10:58 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jack Vogel Subject: Re: Intel 82574L (em) References: <54CBF396.3090903@ignoranthack.me> <20150131010014.GB19333@strugglingcoder.info> <2A35EA60C3C77D438915767F458D6568806C25DE@ORSMSX111.amr.corp.intel.com> <54CFB38E.1040408@ignoranthack.me> <2A35EA60C3C77D438915767F458D6568806C268D@ORSMSX111.amr.corp.intel.com> In-Reply-To: <2A35EA60C3C77D438915767F458D6568806C268D@ORSMSX111.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "Pieper, Jeffrey E" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 04:11:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/02/15 09:35, Pieper, Jeffrey E wrote: > In the past we have, yes. This was a few years ago, but iirc the > current implementation is supposed to be the official solution. > > Jeff Jeff: Thanks for you feedback. Jack: I've tried compiling with EM_MULTIQUEUE set to 1 and changing num_queues to 2 and current just for fun. It panics on initialization. Not sure if you guys care or not. diff: Index: sys/dev/e1000/if_em.c =================================================================== - --- sys/dev/e1000/if_em.c (revision 273639) +++ sys/dev/e1000/if_em.c (working copy) @@ -88,6 +88,7 @@ #include "e1000_82571.h" #include "if_em.h" +#define EM_MULTIQUEUE 1 /********************************************************************* * Set this to one to display debug statistics *********************************************************************/ @@ -2438,7 +2439,7 @@ adapter->hw.hw_addr = (u8 *)&adapter->osdep.mem_bus_space_handle; /* Default to a single queue */ - - adapter->num_queues = 1; + adapter->num_queues = 2; /* * Setup MSI/X or MSI if PCI Express panic: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff8093bf6d stack pointer = 0x28:0xfffffe011e3b1b80 frame pointer = 0x28:0xfffffe011e3b1bb0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (em0 rxq) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff8092e150 at kdb_backtrace+0x60 #1 0xffffffff808f76c1 at panic+0x1c1 #2 0xffffffff80cbf93f at trap_fatal+0x38f #3 0xffffffff80cbf59e at trap+0x74e #4 0xffffffff80ca5132 at calltrap+0x8 #5 0xffffffff808ccaa1 at fork_exit+0x71 #6 0xffffffff80ca566e at fork_trampoline+0xe Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU0u1OXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k7nYIAIq91wQcbtQQn/+EFHoiB6+z P0qOT0cytI1x3Bfm38e+CjtoZE2/198xUypAYJlzSIT4MVPVEnqQKEn8m2dRKSmJ bqHES/bA5Ho4M7Io3T5A2/aPBKXPyMFTUt38mYoui94fRezuOu48Q0967cwzR8k0 JTPIBlybfiZfoVv7eX7w+aOOJ2ErTWQC/EBCpnKuESVEi2zHKorvZsZdq+zVMpKh QZTZj//SF+22c1Jaab0AtocwUCM5mjO77kF6sDVRUFXquDCTyMH9/ieS9SeUwVrP F9H4yNoQPHJ9QAV14BRHWoOKOUUvKMEzrTOQOoTgckxxxUiyt2UzajSTsjuffoM= =Zbdu -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 05:08:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A4225DB; Thu, 5 Feb 2015 05:08:22 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA011C2; Thu, 5 Feb 2015 05:08:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t1558FBO061675; Thu, 5 Feb 2015 16:08:17 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 5 Feb 2015 16:08:15 +1100 (EST) From: Ian Smith To: Lev Serebryakov Subject: Re: does "nat redirect_port tcp" works for you on -CURRENT? In-Reply-To: <54D2A7E1.2020902@FreeBSD.org> Message-ID: <20150205160544.D38620@sola.nimnet.asn.au> References: <54D29A21.2080006@FreeBSD.org> <54D2A7E1.2020902@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 05:08:22 -0000 On Thu, 5 Feb 2015 02:14:41 +0300, Lev Serebryakov wrote: > On 05.02.2015 01:16, Lev Serebryakov wrote: > > > I have such rules in my firewall: > > > > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > > 192.168.134.2:22 22222 > > > > nat 1 config ip $EXT_IP same_ports > One more datapoint: if I merge this to one NAT (and change rules > accordingly), redirect work as expected. > > But I have TWO different NATs in full config (for two ISPs) and don't > want to duplicate all redirection specifications, but want to use > third "common" NAT config. And such usage is shown in ipfw(8)! Just curious .. what's your value of net.inet.ip.fw.one_pass? And does all of this really need cross-posting to net@ as well as ipfw@? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 05:24:26 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 150A08C3 for ; Thu, 5 Feb 2015 05:24:26 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAA183D1 for ; Thu, 5 Feb 2015 05:24:25 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t155OPQg083034 for ; Thu, 5 Feb 2015 05:24:25 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t155OPHL083033; Thu, 5 Feb 2015 05:24:25 GMT (envelope-from root) Date: Thu, 5 Feb 2015 05:24:25 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <752ff810e14c92168bbc371f6d01d368@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTS/ok= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 05:24:26 -0000 rrs added a comment. JHB: The scenario you outline is *exactly* the panic that was seen by sbruno. I guess my description was unclear. The existing code in that other thread right now does a callout_stop and tests the return code. If its one its one (which says I canceled a callout) then it lowers the reference count. Then goes on down a few lines later and does a FREE_LLE_LOCKED macro which lowers the reference count again. The one return happens because the callout has a lock associated with it. If you change to MPSAFE then instead there is no lock so the callout_stop() will return zero since the callout can *not* be stopped. This means that the code at *will not* lower the reference count. It then will call FREE_LLE_LOCKED() but it will find a reference of 2 not 1.. since it did not do the extra lower. So it returns without freeing the lle. When soft clock continues, the callout will run and since the reference was not lowered the memory has not been freed. REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 05:28:30 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AF9FA0D for ; Thu, 5 Feb 2015 05:28:30 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1603E3FF for ; Thu, 5 Feb 2015 05:28:30 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t155STMv086131 for ; Thu, 5 Feb 2015 05:28:29 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t155STm4086130; Thu, 5 Feb 2015 05:28:29 GMT (envelope-from root) Date: Thu, 5 Feb 2015 05:28:29 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <988e1f5d3bebb1a327faae9830ece7d3@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTS/30= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 05:28:30 -0000 adrian added a comment. .. except he said callout_drain(). What happens if that's put in as part of the teardown process? REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 05:38:39 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5F85227 for ; Thu, 5 Feb 2015 05:38:39 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A14E0A19 for ; Thu, 5 Feb 2015 05:38:39 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t155cdsL096514 for ; Thu, 5 Feb 2015 05:38:39 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t155cdZV096513; Thu, 5 Feb 2015 05:38:39 GMT (envelope-from root) Date: Thu, 5 Feb 2015 05:38:39 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTTAd8= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 05:38:39 -0000 rrs added a comment. Hmm thinking about your comment jhb, we could easily add the callout_drain_async to the current callout code. If you think its worth while maybe we should add that to D1711 Jhb, if you think its worth doing add that to D1711 and I will work on it ;-) REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 11:58:30 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C519CDA for ; Thu, 5 Feb 2015 11:58:30 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2DC0E65 for ; Thu, 5 Feb 2015 11:58:29 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t15BwToE018696 for ; Thu, 5 Feb 2015 11:58:29 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t15BwTBM018695; Thu, 5 Feb 2015 11:58:29 GMT (envelope-from root) Date: Thu, 5 Feb 2015 11:58:29 +0000 To: freebsd-net@freebsd.org From: "gnn (George Neville-Neil)" Subject: [Differential] [Accepted] D1691: sfxge: using 64-bit access for x86-64 Message-ID: X-Priority: 3 Thread-Topic: D1691: sfxge: using 64-bit access for x86-64 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2Y0Y2ViOWM0MzVmZDk3ZmY2NmFhNTJmMTY1IFTTWuU= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 11:58:30 -0000 gnn accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1691 To: arybchik, gnn Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 12:08:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 703E7288 for ; Thu, 5 Feb 2015 12:08:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 504F3F7A for ; Thu, 5 Feb 2015 12:08:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t15C8p5m029208 for ; Thu, 5 Feb 2015 12:08:51 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t15C8pHl029207; Thu, 5 Feb 2015 12:08:51 GMT (envelope-from root) Date: Thu, 5 Feb 2015 12:08:51 +0000 To: freebsd-net@freebsd.org From: "arybchik (Andrew Rybchenko)" Subject: [Differential] [Commented On] D1691: sfxge: using 64-bit access for x86-64 Message-ID: <7e9f0741b3d1c0a4e2a757d8295bf1f5@localhost.localdomain> X-Priority: 3 Thread-Topic: D1691: sfxge: using 64-bit access for x86-64 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2Y0Y2ViOWM0MzVmZDk3ZmY2NmFhNTJmMTY1IFTTXVM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 12:08:52 -0000 arybchik added a comment. Committed to src head REVISION DETAIL https://reviews.freebsd.org/D1691 To: arybchik, gnn Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 12:09:08 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 109AF318 for ; Thu, 5 Feb 2015 12:09:08 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6CB3F82 for ; Thu, 5 Feb 2015 12:09:07 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t15C97tR029439 for ; Thu, 5 Feb 2015 12:09:07 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t15C97EO029438; Thu, 5 Feb 2015 12:09:07 GMT (envelope-from root) Date: Thu, 5 Feb 2015 12:09:07 +0000 To: freebsd-net@freebsd.org From: "arybchik (Andrew Rybchenko)" Subject: [Differential] [Closed] D1691: sfxge: using 64-bit access for x86-64 Message-ID: <79b60cf9beef97e29e1234aa7ad3bdcb@localhost.localdomain> X-Priority: 3 Thread-Topic: D1691: sfxge: using 64-bit access for x86-64 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2Y0Y2ViOWM0MzVmZDk3ZmY2NmFhNTJmMTY1IFTTXWM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 12:09:08 -0000 arybchik closed this revision. REVISION DETAIL https://reviews.freebsd.org/D1691 To: arybchik, gnn Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 16:37:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BD55F84 for ; Thu, 5 Feb 2015 16:37:53 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFBA06B4 for ; Thu, 5 Feb 2015 16:37:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t15Gbq1v030693 for ; Thu, 5 Feb 2015 16:37:52 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t15GbqiI030692; Thu, 5 Feb 2015 16:37:52 GMT (envelope-from root) Date: Thu, 5 Feb 2015 16:37:52 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTTnGA= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:37:53 -0000 rrs added a comment. Adrian: I know he said callout_drain, but just like in TCP that is *not* always possible. In the case of the arp/nd6 code lock are held (same as TCP) so you can't do a callout_drain. Thats why the original author put ref-counting in with the idea that the timer would kill it if it had to execute.. they just did not anticipate that by having the callout grab the lock, it would then be making references to it after they deleted it in this one case. Maybe I need to go back through the code and using jhb's a-n outline point out the lines of code so everyone can follow along how this fixes it... REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 17:11:48 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D5D2C44 for ; Thu, 5 Feb 2015 17:11:48 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED285A7F for ; Thu, 5 Feb 2015 17:11:47 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t15HBlaU067009 for ; Thu, 5 Feb 2015 17:11:47 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t15HBlvL067006; Thu, 5 Feb 2015 17:11:47 GMT (envelope-from root) Date: Thu, 5 Feb 2015 17:11:47 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <21a6661d2c797185ab16919d528b2b03@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTTpFM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 17:11:48 -0000 rrs added a comment. Jhb/Others So lets go through your scenario with code in arp: a) softclock dequeues callout to run -- Which calls softclock_call_cc We make it to line:676 and see that "yes" the user (arp) init'd with a rw_mtx and run the next line 677 (to get the lock). b) other thread grabs lle_lock -- Our other thread is a call in to flush the table in net/if_llatble.c the lucky winner is line 181. c) softclock blocks on lle_wlock above -- from the call to line 677 right. d) other thread tears down structure, unlocks lock, zeros memory, 0xdeadc0de, etc. -- Now here is where its interesting, the other thread does if (callout_stop(&lle->la_timer)) LLE_REMREF(lle); lleentry_free llentry_free is going to do: - remove the entry from the lists - and in the end call LLE_FREE_LOCKED() - LLE_FREE_LOCKED() is a macro that checks if (lle->lle_refcnt == 1) call free function else { LLE_REMREF(lle) LLE_WUNLOCK() } Since we are a "stoppable callout" and the callout has a lock, it will fall through (even though its not safe) and return 1, yes the callout was stopped. So we hit the call free function which in this case in_lltable_free which does: LLE_WUNLOCK(lle) LLE_LOK_DESTROY(lle) free(lle, M_LLTABLE) e) softclock wakes up in mutex code and panics becuase the mutex is destroyed and it either triggers an assertion, follows a bad pointer trying to propagate priority or see if the "owner" is running, etc. -- And we wake up and boom. However, with the change from callout_init_rw(c,..) -> callout_init(c, 1) things change. Instead you get a 0 return from callout_stop, since the callout can *not* be stopped at this point. We don't do that first reference lower so we hit the else case in llentry_free which just reduces the count to 1 and unlocks and returns. Now our callout proceeds, getting the lock and it will then go through and check only the pending flag (the active has been removed by the stop but we don't care). There we now do the free and all is well. That is how this fix avoids the issue. Would it be better to have callout_async_drain()? Yes probably so, but then this code would have to be restructured a lot more than this small change. I hope that explains how it works here.. unless of course I am missing something??? R REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 19:03:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E92B2AD for ; Thu, 5 Feb 2015 19:03:06 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80994A7D for ; Thu, 5 Feb 2015 19:03:06 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 748511941DD for ; Thu, 5 Feb 2015 19:03:04 +0000 (UTC) Message-ID: <54D3BE67.8060502@ignoranthack.me> Date: Thu, 05 Feb 2015 11:03:03 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Net Subject: Silly experiments with netisr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:03:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Some questions came up around the office and we ended up doing some quite silly things with lo0 and netcat. If one runs a continuous netcat on localhost to another netcat listener on localhost that writes the output to /dev/null, netisr gets super busy doing stuff/things. E.g. -- listener running "nc -k -l 10000 > /dev/null" - sender running in a while loop "nc -N localhost 10000 < /var/tmp/testfile" Interesting things start happening on the machine. top -SH shows netisr eating up about 1/2 of a cpu core. If you drop the MTU on lo0 to 1500 (so that it looks like something in the real world), netisr will peg out a cpu core. This seems logical, in that smaller MTU means busier netisr. Its interesting though. Looking at some pmcstat things, shows that the system is busilly chugging along in tcp_do_segment(). I wonder if this is meaningful in anyway or just "interesting". PMC: [FR_RETIRED_X86_INSTRUCTIONS] Samples: 267614 (100.0%) , 12350 unresolved %SAMP IMAGE FUNCTION CALLERS 5.5 kernel in_cksumdata in_cksum_skip 5.0 kernel tcp_output tcp_do_segment:4.2 tcp_usr_rcvd:0.5= 4.6 kernel __rw_wlock_hard tcp_usr_send:3.7 tcp_usr_rcvd:0.8 3.8 pf.ko pf_test pf_check_in:2.0 pf_check_out:1.8 3.6 kernel sched_idletd fork_exit 3.2 pf.ko pf_test_state_tcp pf_test 3.1 kernel bzero pf_test:0.8 pf_test_state_tcp:0.7 3.1 kernel bcopy m_copydata:1.3 tcp_addoptions:0.7 tcp_dooptions:0.5 2.7 kernel tcp_do_segment tcp_input sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU075kXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kc4kH/02ttXzvapAG2PSML9Ml0Kwf XblpOHnrhUU8jsTauGhh8q4C94rb9hFDCzL4cEAI87QMXoBQHi9CWE0v/XdeR+8M ajpHlNyd78XbmIKOVksesYWzLbVFjC0A3emnkH4dUX1XD6tJoihVaUQVcrAbNm+I p6Z4yXrOXUP9UxBgkCSe5m3Y/K3vcmIPvFSnO/nN/2tckEh6+uuj1n3QyFXkUJJg 9erFanvDXr3nOyR6IWXIKxuy1yta32SpOPxywIl81qSBh1n/IOor41WqpzOnlNdM d0np+ZD/d+Z9OQJZnuJunCrV6Cv2EFKJe5qBzCdOjLj0KvpNDnFXyndWpeXyvgI=3D =3D+FSJ -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 19:13:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AF8A738; Thu, 5 Feb 2015 19:13:27 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23873BC0; Thu, 5 Feb 2015 19:13:27 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id h15so30873389igd.4; Thu, 05 Feb 2015 11:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ATsH0ZSXL834wu1zbB0qDAO6tVtWY7TmdEqCwg1TJ7A=; b=r3D8eQH5W4GH14N2Ai8MeUiYA5oDNy35cMhfqoBnqD1S05ucV3PSnxPtONUC2F9q/a r//7MEwOt27rozkqdthMDeU2fO2Xs1xpB1idtXXLUrDPc3QNhhtHINnT1Ey/k9LDHohN 72B9u+IMyPRFvmQ10NCcuypYMU2eYIKGvNn/HSTxd4nwvvoexzGslvmtXNzGdvv9qVYO RgwBp9hgUqjKX2K0zqxyWpwj6X/Gf8NLQNVcQz9fQT2p7Dsdlf8sDqhjOBQVYAoTJ502 34iLWn99ukhZJewu9Jb4d39L4FqG8mR3PiIaNzrXvb3N3r1BV7i6zaqlzIqYAKVqc5PM Cs8A== MIME-Version: 1.0 X-Received: by 10.50.164.227 with SMTP id yt3mr10722213igb.32.1423163606577; Thu, 05 Feb 2015 11:13:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Thu, 5 Feb 2015 11:13:26 -0800 (PST) In-Reply-To: <54D3BE67.8060502@ignoranthack.me> References: <54D3BE67.8060502@ignoranthack.me> Date: Thu, 5 Feb 2015 11:13:26 -0800 X-Google-Sender-Auth: q3IldNk0uGXgF0XkbnHibWi4yes Message-ID: Subject: Re: Silly experiments with netisr From: Adrian Chadd To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:13:27 -0000 On 5 February 2015 at 11:03, Sean Bruno wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Some questions came up around the office and we ended up doing some > quite silly things with lo0 and netcat. > > If one runs a continuous netcat on localhost to another netcat listener > on localhost that writes the output to /dev/null, netisr gets super busy > doing stuff/things. > > E.g. > -- listener running "nc -k -l 10000 > /dev/null" > - sender running in a while loop "nc -N localhost 10000 < > /var/tmp/testfile" > > Interesting things start happening on the machine. top -SH shows netisr > eating up about 1/2 of a cpu core. If you drop the MTU on lo0 to 1500 > (so that it looks like something in the real world), netisr will peg out > a cpu core. This seems logical, in that smaller MTU means busier > netisr. Its interesting though. > > Looking at some pmcstat things, shows that the system is busilly > chugging along in tcp_do_segment(). I wonder if this is meaningful in > anyway or just "interesting". > > PMC: [FR_RETIRED_X86_INSTRUCTIONS] Samples: 267614 (100.0%) , 12350 > unresolved UHm, on a recent intel, use CPU_CLK_UNHALTED instead, so you get an idea of which instructions are spending the most time doing "stuff". Some instructions are costlier than others (eg things that cause memory bus stalls.) > %SAMP IMAGE FUNCTION CALLERS > 5.5 kernel in_cksumdata in_cksum_skip .. we're checksumming localhost tcp? :) -adrian > 5.0 kernel tcp_output tcp_do_segment:4.2 tcp_usr_rcvd:0.5 > 4.6 kernel __rw_wlock_hard tcp_usr_send:3.7 tcp_usr_rcvd:0.8 > 3.8 pf.ko pf_test pf_check_in:2.0 pf_check_out:1.8 > 3.6 kernel sched_idletd fork_exit > 3.2 pf.ko pf_test_state_tcp pf_test > 3.1 kernel bzero pf_test:0.8 pf_test_state_tcp:0.7 > 3.1 kernel bcopy m_copydata:1.3 tcp_addoptions:0.7 > tcp_dooptions:0.5 > 2.7 kernel tcp_do_segment tcp_input > > > sean > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQF8BAEBCgBmBQJU075kXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx > MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kc4kH/02ttXzvapAG2PSML9Ml0Kwf > XblpOHnrhUU8jsTauGhh8q4C94rb9hFDCzL4cEAI87QMXoBQHi9CWE0v/XdeR+8M > ajpHlNyd78XbmIKOVksesYWzLbVFjC0A3emnkH4dUX1XD6tJoihVaUQVcrAbNm+I > p6Z4yXrOXUP9UxBgkCSe5m3Y/K3vcmIPvFSnO/nN/2tckEh6+uuj1n3QyFXkUJJg > 9erFanvDXr3nOyR6IWXIKxuy1yta32SpOPxywIl81qSBh1n/IOor41WqpzOnlNdM > d0np+ZD/d+Z9OQJZnuJunCrV6Cv2EFKJe5qBzCdOjLj0KvpNDnFXyndWpeXyvgI= > =+FSJ > -----END PGP SIGNATURE----- > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 19:17:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38329BCB for ; Thu, 5 Feb 2015 19:17:51 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE5F0C01 for ; Thu, 5 Feb 2015 19:17:50 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id wp4so8862101obc.10 for ; Thu, 05 Feb 2015 11:17:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=K95H2kG4fYIelkWijHwyARm8dd/bMQ1a98r6W0mDHgI=; b=g029/uq6aj6u6uEGgKCGA66wSm4przHrOtP0rKk6XeRsZ6lOeweXhN+ufZ7rrVG0EY fv2c5Pu472behrdKbi4glZndhvY7INaP2Xfwj11ZtbsR7F5aCRfI7FUNKaXW4uSiScJY 5r7eIBtVqh2gBMwifdCKC508Em1g7L8dbp4fLfXwSo9XWQotA/D2j+xwesEf4FI5qqhF o430ZqTvLJX+POCFQed50q3yFvUQQIY1aR10bFwNyEhp1R/gDJuGQIi+lmApfoWdoQoG d+AKUwzVvhmc9V5Qe4qajxoccMzn7rZBIMerJkE5Wn00vcRKjUvgaopKn8fs1s5F6+Ef 8oTQ== X-Gm-Message-State: ALoCoQmrc8tVsmMEfOBENiJUVbVhtAP4BqlAM96KIYJpEsxubsUEhpiobIxwIOz2yo9BGk75EDuL X-Received: by 10.202.91.138 with SMTP id p132mr3236847oib.47.1423163864172; Thu, 05 Feb 2015 11:17:44 -0800 (PST) Received: from ?IPv6:2610:160:11:33:5d27:42e6:427e:9a76? ([2610:160:11:33:5d27:42e6:427e:9a76]) by mx.google.com with ESMTPSA id mp3sm30398obb.25.2015.02.05.11.17.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 11:17:43 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Silly experiments with netisr From: Jim Thompson In-Reply-To: Date: Thu, 5 Feb 2015 13:17:42 -0600 Message-Id: References: <54D3BE67.8060502@ignoranthack.me> To: Adrian Chadd X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:17:51 -0000 > On Feb 5, 2015, at 1:13 PM, Adrian Chadd wrote: >=20 > On 5 February 2015 at 11:03, Sean Bruno > wrote: >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> Some questions came up around the office and we ended up doing some >> quite silly things with lo0 and netcat. >>=20 >> If one runs a continuous netcat on localhost to another netcat = listener >> on localhost that writes the output to /dev/null, netisr gets super = busy >> doing stuff/things. >>=20 >> E.g. >> -- listener running "nc -k -l 10000 > /dev/null" >> - sender running in a while loop "nc -N localhost 10000 < >> /var/tmp/testfile" >>=20 >> Interesting things start happening on the machine. top -SH shows = netisr >> eating up about 1/2 of a cpu core. If you drop the MTU on lo0 to = 1500 >> (so that it looks like something in the real world), netisr will peg = out >> a cpu core. This seems logical, in that smaller MTU means busier >> netisr. Its interesting though. >>=20 >> Looking at some pmcstat things, shows that the system is busilly >> chugging along in tcp_do_segment(). I wonder if this is meaningful = in >> anyway or just "interesting". >>=20 >> PMC: [FR_RETIRED_X86_INSTRUCTIONS] Samples: 267614 (100.0%) , 12350 >> unresolved >=20 > UHm, on a recent intel, use CPU_CLK_UNHALTED instead, so you get an > idea of which instructions are spending the most time doing "stuff". > Some instructions are costlier than others (eg things that cause > memory bus stalls.) >=20 >> %SAMP IMAGE FUNCTION CALLERS >> 5.5 kernel in_cksumdata in_cksum_skip >=20 > .. we're checksumming localhost tcp? :) Of course we are. The more damning part is the 7.0% of samples that pf consumes. Jim >=20 > -adrian >=20 >> 5.0 kernel tcp_output tcp_do_segment:4.2 = tcp_usr_rcvd:0.5 >> 4.6 kernel __rw_wlock_hard tcp_usr_send:3.7 = tcp_usr_rcvd:0.8 >> 3.8 pf.ko pf_test pf_check_in:2.0 pf_check_out:1.8 >> 3.6 kernel sched_idletd fork_exit >> 3.2 pf.ko pf_test_state_tcp pf_test >> 3.1 kernel bzero pf_test:0.8 = pf_test_state_tcp:0.7 >> 3.1 kernel bcopy m_copydata:1.3 = tcp_addoptions:0.7 >> tcp_dooptions:0.5 >> 2.7 kernel tcp_do_segment tcp_input >>=20 >>=20 >> sean >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >>=20 >> iQF8BAEBCgBmBQJU075kXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w >> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx >> MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kc4kH/02ttXzvapAG2PSML9Ml0Kwf >> XblpOHnrhUU8jsTauGhh8q4C94rb9hFDCzL4cEAI87QMXoBQHi9CWE0v/XdeR+8M >> ajpHlNyd78XbmIKOVksesYWzLbVFjC0A3emnkH4dUX1XD6tJoihVaUQVcrAbNm+I >> p6Z4yXrOXUP9UxBgkCSe5m3Y/K3vcmIPvFSnO/nN/2tckEh6+uuj1n3QyFXkUJJg >> 9erFanvDXr3nOyR6IWXIKxuy1yta32SpOPxywIl81qSBh1n/IOor41WqpzOnlNdM >> d0np+ZD/d+Z9OQJZnuJunCrV6Cv2EFKJe5qBzCdOjLj0KvpNDnFXyndWpeXyvgI=3D >> =3D+FSJ >> -----END PGP SIGNATURE----- >>=20 >>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net = > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org = " From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 19:19:29 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EC1BC6F for ; Thu, 5 Feb 2015 19:19:29 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6AC1FC10 for ; Thu, 5 Feb 2015 19:19:28 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 55E7E1941DD for ; Thu, 5 Feb 2015 19:19:28 +0000 (UTC) Message-ID: <54D3C23F.5090501@ignoranthack.me> Date: Thu, 05 Feb 2015 11:19:27 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: FreeBSD Net Subject: Re: Silly experiments with netisr References: <54D3BE67.8060502@ignoranthack.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:19:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/05/15 11:13, Adrian Chadd wrote: > On 5 February 2015 at 11:03, Sean Bruno > wrote: >> > Some questions came up around the office and we ended up doing > some quite silly things with lo0 and netcat. > > If one runs a continuous netcat on localhost to another netcat > listener on localhost that writes the output to /dev/null, netisr > gets super busy doing stuff/things. > > E.g. -- listener running "nc -k -l 10000 > /dev/null" - sender > running in a while loop "nc -N localhost 10000 < > /var/tmp/testfile" > > Interesting things start happening on the machine. top -SH shows > netisr eating up about 1/2 of a cpu core. If you drop the MTU on > lo0 to 1500 (so that it looks like something in the real world), > netisr will peg out a cpu core. This seems logical, in that > smaller MTU means busier netisr. Its interesting though. > > Looking at some pmcstat things, shows that the system is busilly > chugging along in tcp_do_segment(). I wonder if this is meaningful > in anyway or just "interesting". > > PMC: [FR_RETIRED_X86_INSTRUCTIONS] Samples: 267614 (100.0%) , > 12350 unresolved > >> UHm, on a recent intel, use CPU_CLK_UNHALTED instead, so you get >> an idea of which instructions are spending the most time doing >> "stuff". Some instructions are costlier than others (eg things >> that cause memory bus stalls.) Oh right. Hrm, running this on an AMD system. I should have thought about that one. > > %SAMP IMAGE FUNCTION CALLERS 5.5 kernel > in_cksumdata in_cksum_skip > >> .. we're checksumming localhost tcp? :) > Yeah, and the ipv6 checksumming cannot be turned off apparently. % ifconfig lo0 lo0: flags=8049 metric 0 mtu 1500 options=600000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 groups: lo % ifconfig lo0 -rxcsum6 ifconfig: -rxcsum6: Operation not supported > > >> -adrian > > 5.0 kernel tcp_output tcp_do_segment:4.2 > tcp_usr_rcvd:0.5 4.6 kernel __rw_wlock_hard > tcp_usr_send:3.7 tcp_usr_rcvd:0.8 3.8 pf.ko pf_test > pf_check_in:2.0 pf_check_out:1.8 3.6 kernel sched_idletd > fork_exit 3.2 pf.ko pf_test_state_tcp pf_test 3.1 kernel > bzero pf_test:0.8 pf_test_state_tcp:0.7 3.1 kernel > bcopy m_copydata:1.3 tcp_addoptions:0.7 > tcp_dooptions:0.5 2.7 kernel tcp_do_segment tcp_input > > > sean >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net To >> unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU08I8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kY5MH/jrcOjCOsMSq7Y3iDgqh6m2j 10X2u5i1KlDqxYG09zWQ6PHYxedIrginz95hUQLV8AK/q+Y9Fm+77AFDlceB6Wgf DH9qBIu2guYGpmYfVVE9UXl5QMbCr/75oY8fZYzOaQPbUY2RzCNkMVkUdUVZaKip qcuA335uDbMfR/McFVaH7Q/Brk20wfdMf120AZBv5NPTQ6U3kHQS8lCLb8zdD/sa smccmlt/Ucu2ikFrKtiG+z7YuzmlT2n2wpj8/xi8gpWCGUrj10G4XdRCMobZQdyJ dftuPcCJAm+wGo7t4gYozVyGyeq8EiqGvv+QuKWd6gvzMndDnmxWo4GiBhC6ad4= =zIxK -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 19:32:02 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67DD3428 for ; Thu, 5 Feb 2015 19:32:02 +0000 (UTC) Received: from nm1.bullet.mail.gq1.yahoo.com (nm1.bullet.mail.gq1.yahoo.com [98.136.218.75]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C0DFDCB for ; Thu, 5 Feb 2015 19:32:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423164721; bh=GyHMo1sLu2HcuYDT9ta/cfPh7d70PRmDcZHpDMAWLFI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=KRXBEdxE785a3ZM4iJRITPPj3ggwjpIjgL90rH7Wvprp2HkGNUGZSiXnH8DuCk3iOXIgP8nSfvolqWcObpvWWHXWl0Dq+lj3CnKFIBv+WXj+7xiqeKEwerI6wWOEsb2qK5AQfCciWfPymjw9jYjt7EZbpO38/7HKmZLaeQwX+nNf8XsUWfM5lIdijvtksH6/XF4hoUd7JQ9pzVU59qXyF2TgfaAkPbycpA6eyummrcmr5bsQZpyqAahy0L1cXMQOcoRGe0qKxEPJOrt/VMBdk1pXOa8J6IXJq5zPKjqSLrCURDdxF7/csgszrGyP9/Rt0AeKxH3h1jCimHxqkMjQOQ== Received: from [216.39.60.180] by nm1.bullet.mail.gq1.yahoo.com with NNFMP; 05 Feb 2015 19:32:01 -0000 Received: from [208.71.42.208] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 05 Feb 2015 19:32:01 -0000 Received: from [127.0.0.1] by smtp219.mail.gq1.yahoo.com with NNFMP; 05 Feb 2015 19:32:01 -0000 X-Yahoo-Newman-Id: 100257.22043.bm@smtp219.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kN.Y_o8VM1mKTH7HyaCVR0f93rN2aD1Nm7BcgdVUwrWGTfW pnpDmR3WJQ8bQfq011harEqx257DEtARjAQyipl.aMKyZzczGuqwp03YZC0J LrFPaUwbl0YU4Dnto8KsbBrTQAbzI.6d2Q5qy05SBca0FS.fVX3xnB7kPI0B TQYTDwGYwItIuQRY6cBsXd.EZzbQI7zgSr7XU9Mn5v_uPb.oubo5pHxOL.2A 8yGOniLvER0.8rCFTSZjQR5qqtLgI0DlmUirj.LHNHZ2F9fHzzm6lRxHWNk1 Oc3SWhLg80ezv.VXgdGAmHr0TGEBntyray22Q8spKC9hMjjypNJ8FsNXROa_ PYRVUSuDKb2pKg2G6kPaEM.W5.M9fWm.7xiIZuOJXrG1RTjCmwObfr5eRpjX .6ywewcc5uLt.XkF12mabWvQ9m5PFLprxm3MUq4UvpVOSsuQBOA56ZyTkJm_ aontHQGkJ2w1iE_qAsHEMAjCwmVzwER93Ox4GhYyDO5MH.Hs5KxFsVB_fTVZ ljZhqsobyxyCLEkZ_IddHWnh9i8bNfj1oAzBU X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Subject: Re: Silly experiments with netisr Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0FF2A146-5C2F-4C87-AC39-B784AF05DE53"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b4 From: Scott Long In-Reply-To: <54D3BE67.8060502@ignoranthack.me> Date: Thu, 5 Feb 2015 12:31:57 -0700 Message-Id: <752D84FB-0B65-47CF-973A-91C3697A28DC@yahoo.com> References: <54D3BE67.8060502@ignoranthack.me> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:32:02 -0000 --Apple-Mail=_0FF2A146-5C2F-4C87-AC39-B784AF05DE53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 5, 2015, at 12:03 PM, Sean Bruno = wrote: >=20 >=20 > Signed PGP part > Some questions came up around the office and we ended up doing some > quite silly things with lo0 and netcat. >=20 > If one runs a continuous netcat on localhost to another netcat = listener > on localhost that writes the output to /dev/null, netisr gets super = busy > doing stuff/things. >=20 > E.g. > -- listener running "nc -k -l 10000 > /dev/null" > - sender running in a while loop "nc -N localhost 10000 < > /var/tmp/testfile" >=20 > Interesting things start happening on the machine. top -SH shows = netisr > eating up about 1/2 of a cpu core. If you drop the MTU on lo0 to 1500 > (so that it looks like something in the real world), netisr will peg = out > a cpu core. This seems logical, in that smaller MTU means busier > netisr. Its interesting though. >=20 > Looking at some pmcstat things, shows that the system is busilly > chugging along in tcp_do_segment(). I wonder if this is meaningful in > anyway or just "interesting". Welcome to our workload. Granted, we don=E2=80=99t involve pf, but the = majority of our CPU processing right now is spent in TCP (with the rest = being spent in the VM, but that=E2=80=99s a different matter). FWIW, Randall has some optimizations in this area of the stack. They = aren=E2=80=99t huge, IIRC they=E2=80=99re only a few percent, but worth = looking at. Scott --Apple-Mail=_0FF2A146-5C2F-4C87-AC39-B784AF05DE53 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU08UtAAoJEIxiMIkw8yo426gH/3DciyuCw+07veEWVKeLdZQq X+8qWGAYtVF6ghx4s0YBpHfR1f4xMT/9YFwounm84otn2xLPPSyrLAH258v/gYtb ZJ7Welj7Z+GJOoUJaRbGGvCFIwWd+dwEKb8FcqDyy0yvGI1W8XoLph9w0Y8hIx9o CCvV2Pv4KF/Ftr584gOZtiRtzsw00BsJ0Q/Q+aOBe4sK7M0eE25rpzvAlG82VP2x fQ+iFa4s6B1ckJ+Wo3ArsLIzh2UprFOIxB+ewlinXLWuMVHQ79wm5fXBiPEfQLq/ OUCCdqcmtytUM+XcogGTwGK2ld4sPYDxi9Jp98DnPYcbtKDHsX80mrW/nY6Vt2o= =cVSX -----END PGP SIGNATURE----- --Apple-Mail=_0FF2A146-5C2F-4C87-AC39-B784AF05DE53-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 19:33:10 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E6EB548 for ; Thu, 5 Feb 2015 19:33:10 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0066.outbound.protection.outlook.com [157.56.111.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F373DE6 for ; Thu, 5 Feb 2015 19:33:09 +0000 (UTC) Received: from DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) by DM2PR0801MB651.namprd08.prod.outlook.com (10.242.127.154) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 5 Feb 2015 19:33:01 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) by DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) with mapi id 15.01.0081.018; Thu, 5 Feb 2015 19:33:01 +0000 From: "Sinha, Prokash" To: "freebsd-net@freebsd.org" Subject: configuring bridge to route L2 packets from one interface to the other Thread-Topic: configuring bridge to route L2 packets from one interface to the other Thread-Index: AQHQQXqNKQUHidzDnkOJFlDWLwa16g== Date: Thu, 5 Feb 2015 19:33:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.92.229.68] authentication-results: freebsd.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB651; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB651; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51874003)(53754006)(110136001)(77096005)(229853001)(87936001)(122556002)(92566002)(66066001)(40100003)(2351001)(102836002)(450100001)(62966003)(16236675004)(2656002)(54356999)(77156002)(107886001)(50986999)(86362001)(106116001)(36756003)(2900100001)(99286002)(46102003)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB651; H:DM2PR0801MB652.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2015 19:33:00.6653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB651 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:33:10 -0000 Hi All, I'm trying to come up with a L2 forwarding from one interface to the other.= Is creating a bridge a good idea ? The context: I will have ether_frame coming from client to one NIC port BCM ( the driver= is bge), it will come to an interface, and want to forward to the other in= terface. So what is and how should I get this, so it work like a small scale bridge/= switch ? If I get all traffic coming in ifp 0, and forward to ifp 1 then I= can put a custom filter for the packets of interest to be forwarded. So if I can configure using - 018780222f020b# ifconfig bridge create ifconfig: SIOCIFCREATE2: Invalid argument Not sure what the problem could be in my other configuration. It some have = static lagg - 018780222f020b# ifconfig -a bge0: flags=3D8843 metric 0 mtu 150= 0 options=3D49b ether 00:09:03:01:87:80 media: Ethernet autoselect (1000baseTX ) status: active lagg: laggdev lagg0 bge1: flags=3D8843 metric 0 mtu 150= 0 options=3D49b ether 00:09:03:01:87:81 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=3D8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D49b ether 00:09:03:01:87:80 inet 10.17.26.11 netmask 0xffffff00 broadcast 10.17.26.255 media: Ethernet autoselect status: active laggproto failover laggport: bge0 flags=3D5 lagg1: flags=3D8843 metric 0 mtu 15= 00 ether 00:09:03:01:87:81 media: Ethernet autoselect status: no carrier laggproto failover Thanks in Advance, -prokash From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 20:08:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B29116CD; Thu, 5 Feb 2015 20:08:32 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 790AB269; Thu, 5 Feb 2015 20:08:32 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id a13so604750igq.0; Thu, 05 Feb 2015 12:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8pE0+tH8zHks+LnhcqwRr+3u1BprtnLNoCb6HQcjWBQ=; b=SrnNdn2rHXkKGXu76TFbHFbuHwRdufq8LB6/Mfmon6sNwvIC+FSGTYOLbSXp/P1Zb0 fRqv2UeAE37OUoczeB9lG1b7fpGZWDbyJ/WwNM/qQ4LGoLX+45epAg8JZAUs7mm6ppGa W48iWZkhxe8H50R7i7GP5cqGdOOlrIZsbOA9zzZnZ/GQmLQkZfsKPY6cjROAMvuzmMV3 sxvyx1ItvpVq/DHgwQxo0y1ap30cTXnjIfJSpL3PN9v/rw+FSq1dwdsVoH8rjHMziOHh IgpJJfhUmPRuv+1p8kNvNz2jM4tuuvRGT/x+zRQdyePU/vQZiqyybzNYwVxogxWkyh42 FqPw== MIME-Version: 1.0 X-Received: by 10.42.62.71 with SMTP id x7mr9002676ich.61.1423166911846; Thu, 05 Feb 2015 12:08:31 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Thu, 5 Feb 2015 12:08:31 -0800 (PST) In-Reply-To: <752D84FB-0B65-47CF-973A-91C3697A28DC@yahoo.com> References: <54D3BE67.8060502@ignoranthack.me> <752D84FB-0B65-47CF-973A-91C3697A28DC@yahoo.com> Date: Thu, 5 Feb 2015 12:08:31 -0800 X-Google-Sender-Auth: VVUkTFQdwla6NyGDqHyjLBfdi7s Message-ID: Subject: Re: Silly experiments with netisr From: Adrian Chadd To: Scott Long Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:08:32 -0000 On 5 February 2015 at 11:31, Scott Long via freebsd-net wrote: > >> On Feb 5, 2015, at 12:03 PM, Sean Bruno wrote: >> >> >> Signed PGP part >> Some questions came up around the office and we ended up doing some >> quite silly things with lo0 and netcat. >> >> If one runs a continuous netcat on localhost to another netcat listener >> on localhost that writes the output to /dev/null, netisr gets super busy >> doing stuff/things. >> >> E.g. >> -- listener running "nc -k -l 10000 > /dev/null" >> - sender running in a while loop "nc -N localhost 10000 < >> /var/tmp/testfile" >> >> Interesting things start happening on the machine. top -SH shows netisr >> eating up about 1/2 of a cpu core. If you drop the MTU on lo0 to 1500 >> (so that it looks like something in the real world), netisr will peg out >> a cpu core. This seems logical, in that smaller MTU means busier >> netisr. Its interesting though. >> >> Looking at some pmcstat things, shows that the system is busilly >> chugging along in tcp_do_segment(). I wonder if this is meaningful in >> anyway or just "interesting". > > > Welcome to our workload. Granted, we don=E2=80=99t involve pf, but the m= ajority of our CPU processing right now is spent in TCP (with the rest bein= g spent in the VM, but that=E2=80=99s a different matter). > > FWIW, Randall has some optimizations in this area of the stack. They are= n=E2=80=99t huge, IIRC they=E2=80=99re only a few percent, but worth lookin= g at. Yeah, I see that too in all the TCP concurrency testing I'm doing. The moment TCP TSO drops in effectiveness in any way, the cost of tcp_do_segment() jumps dramatically. :( -adrian From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 20:23:20 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E27B1DDA; Thu, 5 Feb 2015 20:23:20 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC930679; Thu, 5 Feb 2015 20:23:20 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 2ACE8CE3EC; Thu, 5 Feb 2015 12:23:14 -0800 (PST) Date: Thu, 5 Feb 2015 12:23:14 -0800 From: hiren panchasara To: Scott Long Subject: Re: Silly experiments with netisr Message-ID: <20150205202314.GD69733@strugglingcoder.info> References: <54D3BE67.8060502@ignoranthack.me> <752D84FB-0B65-47CF-973A-91C3697A28DC@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NklN7DEeGtkPCoo3" Content-Disposition: inline In-Reply-To: <752D84FB-0B65-47CF-973A-91C3697A28DC@yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:23:21 -0000 --NklN7DEeGtkPCoo3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02/05/15 at 12:31P, Scott Long via freebsd-net wrote: >=20 > > On Feb 5, 2015, at 12:03 PM, Sean Bruno wrote: > >=20 > >=20 > > Signed PGP part > > Some questions came up around the office and we ended up doing some > > quite silly things with lo0 and netcat. > >=20 > > If one runs a continuous netcat on localhost to another netcat listener > > on localhost that writes the output to /dev/null, netisr gets super busy > > doing stuff/things. > >=20 > > E.g. > > -- listener running "nc -k -l 10000 > /dev/null" > > - sender running in a while loop "nc -N localhost 10000 < > > /var/tmp/testfile" > >=20 > > Interesting things start happening on the machine. top -SH shows netisr > > eating up about 1/2 of a cpu core. If you drop the MTU on lo0 to 1500 > > (so that it looks like something in the real world), netisr will peg out > > a cpu core. This seems logical, in that smaller MTU means busier > > netisr. Its interesting though. > >=20 > > Looking at some pmcstat things, shows that the system is busilly > > chugging along in tcp_do_segment(). I wonder if this is meaningful in > > anyway or just "interesting". >=20 >=20 > Welcome to our workload. Granted, we don?t involve pf, but the majority = of our CPU processing right now is spent in TCP (with the rest being spent = in the VM, but that?s a different matter). >=20 > FWIW, Randall has some optimizations in this area of the stack. They are= n?t huge, IIRC they?re only a few percent, but worth looking at. Scott, It'd be great if you guys can share it. And yes, any small persentage would help :-) cheers, Hiren --NklN7DEeGtkPCoo3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJU09ExXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lOMcH/A7LKBCskK8AWfqWDcu6ULGp +8rRSwc0gmE0UlZ8yN+QTwACXMf41Lw8p1KydOBIuyK5HelkumqBiank9Xwecyim AGpNiynsqFmbXQ8NeM6oJuJNbn7JZyVz+bSSKuzSoWT1uJ5I1poXcZDIt3f2E+Si i4FjiTshlec4AqMIC1w4WcbJ73H+AuMVQQEnPEXGWYRTlFEfALLSOBtiLQqOaXqc aFBgv6qtZa4AS5t7Wyf6QxfwcV8wtNfK0HHRxpNyzvQioj0Lgy+tb2SybDL97bWB SRkh9VgU+ymbbJfid6nBZaS6m7dILV4l8e0V4/0L8KvnWyUeWFUmFRsGwcDgw9g= =Nymf -----END PGP SIGNATURE----- --NklN7DEeGtkPCoo3-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 20:29:07 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C9231FE for ; Thu, 5 Feb 2015 20:29:07 +0000 (UTC) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12BCB6E0 for ; Thu, 5 Feb 2015 20:29:06 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id uy5so9261198obc.4 for ; Thu, 05 Feb 2015 12:29:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sdKZVQxnj42CrV1RWFJb8hSwvnFm17kawPYjchRimsk=; b=W12/R0ZdJIHHZ2sENPDAyIvasIWuRAKhXhXPINU//jtinkK9OxKCW1fILXiS/OxN0g xAyFnM3BqlLbTlvyWRYUjbYMGNcXntTWl1jj8976lNBCXZQK5xXdYaOzmm3rpNc8lNWK Q/ovqVJvkVtOK82y76V+hStOiS/Ny49EhD6tR7nFifoZBInR5T0WWlEEmcshzsixvEqt ec7aCM/olcs1BhQS6PQidPhYgYaaoitLSDScYVI8F86W5slhhqobSpE5fZRhw5+MaQFX mPMRWJeBkLOWBsN+ulk7h8CCZj9jsFFK9dZPmXomAAPuKJzis/f84kcJ7H/YPNnO1vUX Jh6A== X-Gm-Message-State: ALoCoQkK5sBTlb8XfFDtzfXmb7iGUxlJoWZA363wOnyLCepWhsycjQPtQelV2tHSArAmlht6L+kA X-Received: by 10.182.19.167 with SMTP id g7mr3599737obe.75.1423168145709; Thu, 05 Feb 2015 12:29:05 -0800 (PST) Received: from ?IPv6:2610:160:11:33:5d27:42e6:427e:9a76? ([2610:160:11:33:5d27:42e6:427e:9a76]) by mx.google.com with ESMTPSA id s10sm136170oeo.3.2015.02.05.12.29.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 12:29:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Silly experiments with netisr From: Jim Thompson In-Reply-To: <20150205202314.GD69733@strugglingcoder.info> Date: Thu, 5 Feb 2015 14:29:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <747BECC7-98A8-4EA4-AFE1-4B1B7039862C@netgate.com> References: <54D3BE67.8060502@ignoranthack.me> <752D84FB-0B65-47CF-973A-91C3697A28DC@yahoo.com> <20150205202314.GD69733@strugglingcoder.info> To: hiren panchasara X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Net , Scott Long X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:29:07 -0000 > On Feb 5, 2015, at 2:23 PM, hiren panchasara = wrote: >=20 > On 02/05/15 at 12:31P, Scott Long via freebsd-net wrote: >>=20 >>=20 >> Welcome to our workload. Granted, we don?t involve pf, but the = majority of our CPU processing right now is spent in TCP (with the rest = being spent in the VM, but that?s a different matter). >>=20 >> FWIW, Randall has some optimizations in this area of the stack. They = aren?t huge, IIRC they?re only a few percent, but worth looking at. > Scott, >=20 > It'd be great if you guys can share it. And yes, any small persentage = would > help :-) As long as it=E2=80=99s not at the expense of forwarding. From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 20:50:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 492EEB83 for ; Thu, 5 Feb 2015 20:50:55 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D24AB97A for ; Thu, 5 Feb 2015 20:50:54 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id k14so9733107wgh.10 for ; Thu, 05 Feb 2015 12:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=55Prjb18fSBi9fKDdsIIyFqDxd4yKtWGKc6cahbsfBQ=; b=GI41FpQ7ZGaElMqjX3OuFngv7QFpSREL++kezEkLm9z0OAjCoTQZQzS8PKTJvc4m+S 7oROpVQ/8F/FTlwUAoQkSD7hgDhjJhhwej3G56SjpIWwjTfk8rfAJRU+/u+E1JgLbAzJ nSsvF3k64h/5yRal9E/NApDgklnML5Bthi3AwbgFxmGCJC1YIEulK7kEuCCPekbLJKT8 +/sTNiMT3lo3osAgK9ZI0qgzuXo+f6+7TxkVzAeM8xWH7dC9h5hzZy9z2t0a9tPwuI6W iuqGnbZXbUMewEN/F5/UPynO4liRljMuWXW3dAjtnU5UnQOU+h84wruv986V3EP3MqV5 KZ+g== X-Received: by 10.194.216.138 with SMTP id oq10mr133wjc.133.1423169453088; Thu, 05 Feb 2015 12:50:53 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.68.37 with HTTP; Thu, 5 Feb 2015 12:50:32 -0800 (PST) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Thu, 5 Feb 2015 21:50:32 +0100 X-Google-Sender-Auth: uniFgyZTEDGRmhd0XzCpRGmgCmw Message-ID: Subject: IEE1588/PTP support for NIC drivers ? To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:50:55 -0000 Hi, Some network cards support IEE1588 hardware timestamp (like some Intel card), but their drivers didn't support this feature. I beleive there is a kernel feature missing for this suppport. Searching on the archive's mailing-list, I've found this post about some legal issue: https://lists.freebsd.org/pipermail/freebsd-net/2007-October/015512.html Is still a legal problem or just a missing feature ? Thanks, Olivier From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 21:09:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3E467E9 for ; Thu, 5 Feb 2015 21:09:34 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0078.outbound.protection.outlook.com [207.46.100.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 953A9BFC for ; Thu, 5 Feb 2015 21:09:33 +0000 (UTC) Received: from DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) by DM2PR0801MB650.namprd08.prod.outlook.com (10.242.127.153) with Microsoft SMTP Server (TLS) id 15.1.75.20; Thu, 5 Feb 2015 21:09:26 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) by DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) with mapi id 15.01.0081.018; Thu, 5 Feb 2015 21:09:26 +0000 From: "Sinha, Prokash" To: "freebsd-net@freebsd.org" Subject: Re: configuring bridge to route L2 packets from one interface to the other Thread-Topic: configuring bridge to route L2 packets from one interface to the other Thread-Index: AQHQQXqNKQUHidzDnkOJFlDWLwa16pziBvaA Date: Thu, 5 Feb 2015 21:09:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.92.229.68] authentication-results: freebsd.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB650; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB650; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(164054003)(51874003)(53754006)(40100003)(87936001)(50986999)(54356999)(76176999)(19580405001)(66066001)(122556002)(19580395003)(106116001)(99286002)(2351001)(107886001)(110136001)(77096005)(2900100001)(102836002)(2950100001)(450100001)(62966003)(77156002)(36756003)(86362001)(2656002)(46102003)(92566002)(16236675004)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB650; H:DM2PR0801MB652.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2015 21:09:25.7824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:09:34 -0000 I got the bridge device created ( kernel config needed to be changed ). But don't know how the add works - Is it because of the lagg ??? 018780222f020d# ifconfig bridge0 addm bge0 addm bge1 ifconfig: BRDGADD bge0: Invalid argument Thanks, -p From: , Prokash Sinha = > Date: Thursday, February 5, 2015 11:32 AM To: "freebsd-net@freebsd.org" > Subject: configuring bridge to route L2 packets from one interface to the o= ther Hi All, I'm trying to come up with a L2 forwarding from one interface to the other.= Is creating a bridge a good idea ? The context: I will have ether_frame coming from client to one NIC port BCM ( the driver= is bge), it will come to an interface, and want to forward to the other in= terface. So what is and how should I get this, so it work like a small scale bridge/= switch ? If I get all traffic coming in ifp 0, and forward to ifp 1 then I= can put a custom filter for the packets of interest to be forwarded. So if I can configure using - 018780222f020b# ifconfig bridge create ifconfig: SIOCIFCREATE2: Invalid argument Not sure what the problem could be in my other configuration. It some have = static lagg - 018780222f020b# ifconfig -a bge0: flags=3D8843 metric 0 mtu 150= 0 options=3D49b ether 00:09:03:01:87:80 media: Ethernet autoselect (1000baseTX ) status: active lagg: laggdev lagg0 bge1: flags=3D8843 metric 0 mtu 150= 0 options=3D49b ether 00:09:03:01:87:81 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=3D8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D49b ether 00:09:03:01:87:80 inet 10.17.26.11 netmask 0xffffff00 broadcast 10.17.26.255 media: Ethernet autoselect status: active laggproto failover laggport: bge0 flags=3D5 lagg1: flags=3D8843 metric 0 mtu 15= 00 ether 00:09:03:01:87:81 media: Ethernet autoselect status: no carrier laggproto failover Thanks in Advance, -prokash From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 21:19:57 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8621FF8E for ; Thu, 5 Feb 2015 21:19:57 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D63ED3C for ; Thu, 5 Feb 2015 21:19:57 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t15LJviq074251 for ; Thu, 5 Feb 2015 21:19:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 186449] ifconfig(8) fails to autoload if_tap.ko when creating vmnet interface Date: Thu, 05 Feb 2015 21:19:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ngie@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:19:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186449 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |ngie@FreeBSD.org CC| |ngie@FreeBSD.org --- Comment #2 from Garrett Cooper,425-314-3911 --- Creating hardlinks for the device drivers is simple and fixing the driver names in head to be consistent across the board (no hardlinks) seems like a relatively straightforward task. Take. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 21:27:42 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD86C264 for ; Thu, 5 Feb 2015 21:27:42 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0056.outbound.protection.outlook.com [65.55.169.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59067E30 for ; Thu, 5 Feb 2015 21:27:41 +0000 (UTC) Received: from DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) by DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 5 Feb 2015 21:27:33 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) by DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) with mapi id 15.01.0081.018; Thu, 5 Feb 2015 21:27:33 +0000 From: "Sinha, Prokash" To: "freebsd-net@freebsd.org" Subject: Re: configuring bridge to route L2 packets from one interface to the other Thread-Topic: configuring bridge to route L2 packets from one interface to the other Thread-Index: AQHQQXqNKQUHidzDnkOJFlDWLwa16pziBvaAgAAFEYA= Date: Thu, 5 Feb 2015 21:27:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.92.229.68] authentication-results: freebsd.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB652; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB652; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(53754006)(164054003)(51874003)(2900100001)(36756003)(46102003)(2950100001)(86362001)(106116001)(99286002)(110136001)(92566002)(122556002)(66066001)(40100003)(450100001)(77156002)(77096005)(50986999)(87936001)(16236675004)(2656002)(62966003)(19580395003)(76176999)(54356999)(19580405001)(102836002)(2351001)(107886001)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB652; H:DM2PR0801MB652.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2015 21:27:33.4480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB652 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:27:43 -0000 Finally able to coax it to get laggs bound to the bridge. Let me see thru k= gdb ... From: , Prokash Sinha = > Date: Thursday, February 5, 2015 1:09 PM To: "freebsd-net@freebsd.org" > Subject: Re: configuring bridge to route L2 packets from one interface to t= he other I got the bridge device created ( kernel config needed to be changed ). But don't know how the add works - Is it because of the lagg ??? 018780222f020d# ifconfig bridge0 addm bge0 addm bge1 ifconfig: BRDGADD bge0: Invalid argument Thanks, -p From: , Prokash Sinha = > Date: Thursday, February 5, 2015 11:32 AM To: "freebsd-net@freebsd.org" > Subject: configuring bridge to route L2 packets from one interface to the o= ther Hi All, I'm trying to come up with a L2 forwarding from one interface to the other.= Is creating a bridge a good idea ? The context: I will have ether_frame coming from client to one NIC port BCM ( the driver= is bge), it will come to an interface, and want to forward to the other in= terface. So what is and how should I get this, so it work like a small scale bridge/= switch ? If I get all traffic coming in ifp 0, and forward to ifp 1 then I= can put a custom filter for the packets of interest to be forwarded. So if I can configure using - 018780222f020b# ifconfig bridge create ifconfig: SIOCIFCREATE2: Invalid argument Not sure what the problem could be in my other configuration. It some have = static lagg - 018780222f020b# ifconfig -a bge0: flags=3D8843 metric 0 mtu 150= 0 options=3D49b ether 00:09:03:01:87:80 media: Ethernet autoselect (1000baseTX ) status: active lagg: laggdev lagg0 bge1: flags=3D8843 metric 0 mtu 150= 0 options=3D49b ether 00:09:03:01:87:81 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=3D8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D49b ether 00:09:03:01:87:80 inet 10.17.26.11 netmask 0xffffff00 broadcast 10.17.26.255 media: Ethernet autoselect status: active laggproto failover laggport: bge0 flags=3D5 lagg1: flags=3D8843 metric 0 mtu 15= 00 ether 00:09:03:01:87:81 media: Ethernet autoselect status: no carrier laggproto failover Thanks in Advance, -prokash From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 21:40:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE189C75; Thu, 5 Feb 2015 21:40:47 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A778BFBB; Thu, 5 Feb 2015 21:40:47 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 29EEBCEAD5; Thu, 5 Feb 2015 13:40:47 -0800 (PST) Date: Thu, 5 Feb 2015 13:40:47 -0800 From: hiren panchasara To: Adrian Chadd Subject: Re: Silly experiments with netisr Message-ID: <20150205214047.GE69733@strugglingcoder.info> References: <54D3BE67.8060502@ignoranthack.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cPi+lWm09sJ+d57q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:40:47 -0000 --cPi+lWm09sJ+d57q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02/05/15 at 11:13P, Adrian Chadd wrote: > On 5 February 2015 at 11:03, Sean Bruno wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Some questions came up around the office and we ended up doing some > > quite silly things with lo0 and netcat. > > > > If one runs a continuous netcat on localhost to another netcat listener > > on localhost that writes the output to /dev/null, netisr gets super busy > > doing stuff/things. > > > > E.g. > > -- listener running "nc -k -l 10000 > /dev/null" > > - sender running in a while loop "nc -N localhost 10000 < > > /var/tmp/testfile" > > > > Interesting things start happening on the machine. top -SH shows netisr > > eating up about 1/2 of a cpu core. If you drop the MTU on lo0 to 1500 > > (so that it looks like something in the real world), netisr will peg out > > a cpu core. This seems logical, in that smaller MTU means busier > > netisr. Its interesting though. > > > > Looking at some pmcstat things, shows that the system is busilly > > chugging along in tcp_do_segment(). I wonder if this is meaningful in > > anyway or just "interesting". > > > > PMC: [FR_RETIRED_X86_INSTRUCTIONS] Samples: 267614 (100.0%) , 12350 > > unresolved >=20 > UHm, on a recent intel, use CPU_CLK_UNHALTED instead, so you get an > idea of which instructions are spending the most time doing "stuff". > Some instructions are costlier than others (eg things that cause > memory bus stalls.) >=20 > > %SAMP IMAGE FUNCTION CALLERS > > 5.5 kernel in_cksumdata in_cksum_skip >=20 > .. we're checksumming localhost tcp? :) We can get rid of it with RXCSUM/TXCSUM flags on lo0 right?=20 =46rom man 4 lo If the transmit checksum offload capability flag is enabled on a loopb= ack interface, checksums will not be generated by IP, UDP, or TCP for pack= ets sent on the interface. Or am I missing something? cheers, Hiren --cPi+lWm09sJ+d57q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJU0+NeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lkl4IAKGAcQf+cVf2nk4BgjKHnbxY xuKz1OuYPzfTx1znFEypkdR5CQCu/jmxttx3QQayM28aghQGMZjVyzw1fEIkVysM hDqozcs9/H59OkmjNSXu365OIrQPhB6zXTdhLoh96UHeYEwFz1mJtH/J2Y//6r9i Ct6jXvsfAfUPYh252FHd/oFqb3M6FVPVMYceONYBqyGOno5stte0jUo67IwoYzzw ROolDGnkFXpK3nZZfc2g4We5jVlcq8daYB27HmllvEULZjpq5uv23fRCYqQDL09l kU+8UxFPXfndLqUI36B7T2ugQ6BbHk542gycGdQuDmfttLTvdcH+hyeFpH40aeA= =b3U8 -----END PGP SIGNATURE----- --cPi+lWm09sJ+d57q-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 21:48:23 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28C3571; Thu, 5 Feb 2015 21:48:23 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 092C513A; Thu, 5 Feb 2015 21:48:22 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 53182CEB9C; Thu, 5 Feb 2015 13:48:22 -0800 (PST) Date: Thu, 5 Feb 2015 13:48:22 -0800 From: hiren panchasara To: sbruno@freebsd.org Subject: Re: Silly experiments with netisr Message-ID: <20150205214822.GF69733@strugglingcoder.info> References: <54D3BE67.8060502@ignoranthack.me> <54D3C23F.5090501@ignoranthack.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AH+kv8CCoFf6qPuz" Content-Disposition: inline In-Reply-To: <54D3C23F.5090501@ignoranthack.me> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:48:23 -0000 --AH+kv8CCoFf6qPuz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02/05/15 at 11:19P, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 02/05/15 11:13, Adrian Chadd wrote: > > On 5 February 2015 at 11:03, Sean Bruno > > wrote: > >>=20 > > Some questions came up around the office and we ended up doing > > some quite silly things with lo0 and netcat. > >=20 > > If one runs a continuous netcat on localhost to another netcat > > listener on localhost that writes the output to /dev/null, netisr > > gets super busy doing stuff/things. > >=20 > > E.g. -- listener running "nc -k -l 10000 > /dev/null" - sender > > running in a while loop "nc -N localhost 10000 <=20 > > /var/tmp/testfile" > >=20 > > Interesting things start happening on the machine. top -SH shows > > netisr eating up about 1/2 of a cpu core. If you drop the MTU on > > lo0 to 1500 (so that it looks like something in the real world), > > netisr will peg out a cpu core. This seems logical, in that > > smaller MTU means busier netisr. Its interesting though. > >=20 > > Looking at some pmcstat things, shows that the system is busilly=20 > > chugging along in tcp_do_segment(). I wonder if this is meaningful > > in anyway or just "interesting". > >=20 > > PMC: [FR_RETIRED_X86_INSTRUCTIONS] Samples: 267614 (100.0%) , > > 12350 unresolved > >=20 > >> UHm, on a recent intel, use CPU_CLK_UNHALTED instead, so you get > >> an idea of which instructions are spending the most time doing > >> "stuff". Some instructions are costlier than others (eg things > >> that cause memory bus stalls.) >=20 > Oh right. Hrm, running this on an AMD system. I should have thought > about that one. >=20 > >=20 > > %SAMP IMAGE FUNCTION CALLERS 5.5 kernel > > in_cksumdata in_cksum_skip > >=20 > >> .. we're checksumming localhost tcp? :) > >=20 >=20 > Yeah, and the ipv6 checksumming cannot be turned off apparently. >=20 > % ifconfig lo0 > lo0: flags=3D8049 metric 0 mtu 1500 > options=3D600000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D21 > groups: lo > % ifconfig lo0 -rxcsum6 > ifconfig: -rxcsum6: Operation not supported https://svnweb.freebsd.org/base?view=3Drevision&revision=3D238871 A workaround, apparently. cheers, Hiren --AH+kv8CCoFf6qPuz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJU0+UlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lEy4H/RvAxYJOjz0XXWoIDBnFb+9/ Tns389eMRtIseu8qZxI6YI6BBHYx37Hu/kk0c+N0tMTqE2eyimIN/yKpRdbEd0/u IMaWRLq/rDG1/vSscTUAA3yN+nYYd3ZJtmZKb0lI6QH5feYIldmDQZwBfgsi49I8 LudUvwX01e921L5EaLgge/nV2yW2j7dsOwKttaHFE080hAZEFDuh8v+L3eQ3XbK2 O+Roqfzw9MRCsd/EPfaJJRqr907dyfTLizVZoJwlgJn6OYxwqeFFaZ+fTWC1QSd4 +qJZz+dpFrLpG2w6s4aiASiyWXZaYx8l26elvtrt5PrQ96zdOPUQsYx7dq797hM= =JsL9 -----END PGP SIGNATURE----- --AH+kv8CCoFf6qPuz-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 16:38:11 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 840B94C6 for ; Fri, 6 Feb 2015 16:38:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B580A41 for ; Fri, 6 Feb 2015 16:38:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t16GcBhp047041 for ; Fri, 6 Feb 2015 16:38:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171524] [ipmi] ipmi driver crashes kernel by reboot or shutdown Date: Fri, 06 Feb 2015 16:38:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:38:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171524 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org Status|In Progress |Closed Resolution|--- |FIXED --- Comment #3 from John Baldwin --- Won't be merged as an EN to 9.1 but is fixed in subsequent releases. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 16:40:03 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6294956D for ; Fri, 6 Feb 2015 16:40:03 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A3C7A64 for ; Fri, 6 Feb 2015 16:40:03 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t16Ge3um048083 for ; Fri, 6 Feb 2015 16:40:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171524] [ipmi] ipmi driver crashes kernel by reboot or shutdown Date: Fri, 06 Feb 2015 16:40:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:40:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171524 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amesbury@oitsec.umn.edu --- Comment #4 from John Baldwin --- *** Bug 176591 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 17:16:30 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07F095A3 for ; Fri, 6 Feb 2015 17:16:30 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E309CF2E for ; Fri, 6 Feb 2015 17:16:29 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t16HGT7Z079297 for ; Fri, 6 Feb 2015 17:16:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194672] [carp] Changing advskew to 0 from another value doesn't work Date: Fri, 06 Feb 2015 17:16:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: loos@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:16:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194672 Luiz Otavio O Souza changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |loos@FreeBSD.org Resolution|--- |FIXED --- Comment #8 from Luiz Otavio O Souza --- The fix was committed to -head and 10-stable. Thanks! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 17:45:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6EE3F11 for ; Fri, 6 Feb 2015 17:45:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1D67314 for ; Fri, 6 Feb 2015 17:45:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t16Hj6ji035643 for ; Fri, 6 Feb 2015 17:45:06 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t16Hj6Dw035642; Fri, 6 Feb 2015 17:45:06 GMT (envelope-from root) Date: Fri, 6 Feb 2015 17:45:06 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <8f1866a74caada2b9bdfe9180bc52cb1@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTU/aI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:45:06 -0000 hiren added a comment. Update from llnw world: Things have been pretty stable here without any panics for 24+ hours with Stable10+D1711+D1777. Thanks a lot, Randall! REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 17:46:14 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49513FFC for ; Fri, 6 Feb 2015 17:46:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0525933B for ; Fri, 6 Feb 2015 17:46:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t16HkDok036655 for ; Fri, 6 Feb 2015 17:46:13 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t16HkDnu036653; Fri, 6 Feb 2015 17:46:13 GMT (envelope-from root) Date: Fri, 6 Feb 2015 17:46:13 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTU/eU= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:46:14 -0000 hiren added a comment. Update from llnw world: Things have been pretty stable here without any panics for 24+ hours with Stable10+D1711+D1777. Thanks a lot, Randall! REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 17:48:50 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5751021E for ; Fri, 6 Feb 2015 17:48:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13E7737D for ; Fri, 6 Feb 2015 17:48:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t16Hmnou038712 for ; Fri, 6 Feb 2015 17:48:49 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t16Hmnm8038711; Fri, 6 Feb 2015 17:48:49 GMT (envelope-from root) Date: Fri, 6 Feb 2015 17:48:49 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <102d7bd7890d7fd49827e978db44946e@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFTU/oE= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:48:50 -0000 hselasky added a comment. Don't forget to add the "MFC after" tag. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Feb 7 20:58:52 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F3C919C for ; Sat, 7 Feb 2015 20:58:52 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id F33F47D5 for ; Sat, 7 Feb 2015 20:58:51 +0000 (UTC) Received: from [10.0.1.100] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 6235B341F8AD for ; Sat, 7 Feb 2015 12:58:51 -0800 (PST) From: Alfred Perlstein Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Nasty bug in startup scripts with interface renaming. Date: Sat, 7 Feb 2015 13:02:51 -0800 Message-Id: To: net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Feb 2015 20:58:52 -0000 If you happen to use interface renaming there is a nasty bug lurking in = the startup scripts, it seems newly introduced, but I am unsure. Specifically the following happens at boot time: /etc/rc.d/netif is run without args. It gets the list of interfaces and for each interface it calls = network_start(). however in network start we have this: # Create cloned interfaces clone_up $cmdifn # Rename interfaces. ifnet_rename $cmdifn # Configure the interface(s). network_common ifn_start $cmdifn Now it doesn't take that much to realize that if 'ifnet_rename' renames = 'cmdifn' then the subsequent call to 'network_common ifn_start $cmdifn' = will be passing a stale interface in as a parameter and causes a bunch = of errors to happen. Example: cmdifn=3D"vtnet0" Therefor: # Rename interfaces. ifnet_rename vtnet0 # <- gets renamed here to derp0 # Configure the interface(s). network_common ifn_start vtnet0 # <- this seems to cause an = error since we're using old name. I looked at fixing ifnet_rename() to take a variable to assign to, so = for instance the call could turn into something like: ifnet_rename cmdifn vtnet0 =20 This way cmdifn would be set to 'derp0' and subsequent stuff would work, = however=85. then I realized that ifnet_rename can take 0 args, or = MULTIPLE args and will act on either all interfaces or the ones passed = in. So passing another var becomes a problem. I then realized that if I threw together a patch to fix it "the alfred = way" people would probably be upset. So I'm asking, any suggestions before I go about just fixing this? -Alfred