From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 00:04:41 2014 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 59868488 for ; Mon, 17 Nov 2014 00:04: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 41699D13 for ; Mon, 17 Nov 2014 00:04: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 sAH04fMm065174 for ; Mon, 17 Nov 2014 00:04:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193579] [axge] axge driver issue with tcp checksum offload with pf nat Date: Mon, 17 Nov 2014 00:04:41 +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 Some People X-Bugzilla-Who: fireball@zerouptime.ch X-Bugzilla-Status: Needs Triage 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, 17 Nov 2014 00:04:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193579 --- Comment #2 from fireball@zerouptime.ch --- I bought another usb ethernet adapter, this time 100 Mbit which is using the axe driver and I have the same problem. That means: - within the DMZ of my pfsense firewall I can transfer files without problems - across the NAT of my pfsense the connection interupts if the transfer goes beyond listing a directory This also makes it look like it's a general uether issue. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 01:05:42 2014 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 12E74390 for ; Mon, 17 Nov 2014 01:05:42 +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 EE64D2E0 for ; Mon, 17 Nov 2014 01:05: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 sAH15fMA034459 for ; Mon, 17 Nov 2014 01:05:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194238] [tcp] Ping attempted with MTU 9000 transmits fragmented packets of size 1500 Date: Mon, 17 Nov 2014 01:05: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.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Needs Triage 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, 17 Nov 2014 01:05:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194238 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: melifaro Date: Mon Nov 17 01:05:32 UTC 2014 New revision: 274611 URL: https://svnweb.freebsd.org/changeset/base/274611 Log: Finish r274175: do control plane MTU tracking. Update route MTU in case of ifnet MTU change. Add new RTF_FIXEDMTU to track explicitly specified MTU. Old behavior: ifconfig em0 mtu 1500->9000 -> all routes traversing em0 do not change MTU. User has to manually update all routes. ifconfig em0 mtu 9000->1500 -> all routes traversing em0 do not change MTU. However, if ip[6]_output finds route with rt_mtu > interface mtu, rt_mtu gets updated. New behavior: ifconfig em0 mtu 1500->9000 -> all interface routes in all fibs gets updated with new MTU unless RTF_FIXEDMTU flag set on them. ifconfig em0 mtu 9000->1500 -> all routes in all fibs gets updated with new MTU unless RTF_FIXEDMTU flag set on them AND rt_mtu is less than ifp mtu. route add ... -mtu XXX automatically sets RTF_FIXEDMTU flag. route change .. -mtu 0 automatically removes RTF_FIXEDMTU flag. PR: 194238 MFC after: 1 month CR: D1125 Changes: head/sbin/route/route.c head/sys/net/if.c head/sys/net/route.c head/sys/net/route.h head/sys/netinet/ip_output.c head/sys/netinet6/ip6_output.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 07:44:25 2014 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 EA3C9F15 for ; Mon, 17 Nov 2014 07:44:25 +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 6A6CDC42 for ; Mon, 17 Nov 2014 07:44:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sAH7i9EC063099; Mon, 17 Nov 2014 18:44:10 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 17 Nov 2014 18:44:09 +1100 (EST) From: Ian Smith To: John-Mark Gurney Subject: Re: Whither ep(4) on 9.3-RELEASE? In-Reply-To: <20141111211530.GQ24601@funkthat.com> Message-ID: <20141113233208.G31139@sola.nimnet.asn.au> References: <20141111203429.I31139@sola.nimnet.asn.au> <20141111211530.GQ24601@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Gary Aitken , 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, 17 Nov 2014 07:44:26 -0000 On Tue, 11 Nov 2014 13:15:30 -0800, John-Mark Gurney wrote: > Ian Smith wrote this message on Tue, Nov 11, 2014 at 21:31 +1100: [..] > > So can anyone confirm that ep(4) is present on 9.3-R, even if only i386? > > Yeh, it looks like ep is in GENERIC on i386.. We also compile ep on > amd64 too, though not sure anyone would ever want to use ep on there... > > On HEAD we only compile the ep modules on i386... so not sure why you > weren't able to find it... 'cos I was relying on the hardware compatibility lists for all versions mentioned, and man.cgi - before and after discovering the 'Default' arch doesn't mean default arch for a given component, but needed searching by just i386 - but those are just docs/web issues, 'scuse the noise here. > I'd just try booting a memstick or other image to confirm that there > is support... So would I, for everything on board .. Thanks, and to Darren and Julian also. cheers, Ian "My friends all drive Xeons, I must make amends." -- janis joytest(6) From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 07:46:35 2014 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 E49A8FC9; Mon, 17 Nov 2014 07:46:34 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 4DEE9C62; Mon, 17 Nov 2014 07:46:34 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id 10so15204176lbg.7 for ; Sun, 16 Nov 2014 23:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=4D2Q1NBEuceahcHQqKbIR7QdoXqzHuxlVhcNZsXbwiQ=; b=zVDesiR8Pp86l8ArcFpf/Ha9qmNOJSTHAgYtrRwxqj+QBdWCqtgtChXfXyKoO4E41V Hr1CHXtRFK0CkXiV/KW2iO7tTHZntcGQ1njy4ubYWYRcv9MOAXsJa/QtfWICOwOwLupj pz2T8778wGGjaX7GtJWCtBFfHUReXomDqqeakAz6fxMINLd2gWnyTYJFJpIjTxDc/OnT DKI+KbB0K+1f8cfO/5BluFz7Kz84TOHS8Dls9rNN9+FwLDvdPQG9ZppSj1hcJVWPReQw 0pxTgELge3VhWtCSDjX25OpWyqN6Kf9TdUfVPYNO/W60JoOS4tU7Hd51CMxEjfWSjHUv M+kw== MIME-Version: 1.0 X-Received: by 10.112.225.225 with SMTP id rn1mr1410596lbc.98.1416210392299; Sun, 16 Nov 2014 23:46:32 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Sun, 16 Nov 2014 23:46:32 -0800 (PST) Date: Sun, 16 Nov 2014 23:46:32 -0800 X-Google-Sender-Auth: 7fMsckax5obPRoH-ujZxjGQN9sg Message-ID: Subject: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: freebsd-arch , FreeBSD Net , "freebsd-virtualization@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: Mon, 17 Nov 2014 07:46:35 -0000 Hi, PROPOSAL ========== I would like to get feedback on the following proposal. In the head branch (CURRENT), I would like to enable VIMAGE with this commit: PATCH ====== Index: sys/conf/NOTES =================================================================== --- sys/conf/NOTES (revision 274300) +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device mn # Munich32x/Falc54 Nx64kbit/sec cards. # Network stack virtualization. -#options VIMAGE -#options VNET_DEBUG # debug for VIMAGE +options VIMAGE +options VNET_DEBUG # debug for VIMAGE # # Network interfaces: I would like to enable VIMAGE for the following reasons: REASONS ======== (1) VIMAGE cannot be enabled off to the side in a separate library or kernel module. When enabled, it is a kernel ABI incompatible change. This has impact on 3rd party code such as the kernel modules which come with VirtualBox. So the time to do it in CURRENT is now, otherwise we can't consider doing it until FreeBSD-12 timeframe, which is quite a while away. (2) VIMAGE is used in some 3rd party products, such as FreeNAS. These 3rd party products are mostly happy with VIMAGE, but sometimes they encounter problems, and FreeBSD doesn't see these problems because it is disabled by default. (3) Most of the major subsystems like ipfw and pf have been fixed for VIMAGE, and the only way to shake out the last few issues is to make it the default and get feedback from the community. ipfilter still needs to be VIMAGE-ified. (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization platform for FreeBSD. Jails are still very popular and performant. VIMAGE makes jails even better by allowing per-jail network stacks. (5) Olivier Cochard-Labbe has provided good network performance results in VIMAGE vs. non-VIMAGE kernels: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html (6) Certain people like Vitaly "wishmaster" have been running VIMAGE jails in a production environment for quite a while, and would like to see it be the default. ACTION PLAN =========== (1) Coordinate/communicate with portmgr, since this has kernel ABI implications (2) Work with clusteradm@, and try to get a test instance of one of the PF firewalls in the cluster working with a VIMAGE enabled kernel. (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet and try to clean things up. Get help from net@ developers to do this. (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from the ipfilter maintainers for this and some net@ developers. (5) Enable VIMAGE by default in CURRENT on January 5, 2015. This will *not* be enabled in STABLE. What do people think? Thanks. -- Craig From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 07:48:16 2014 Return-Path: Delivered-To: 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 358891CA for ; Mon, 17 Nov 2014 07:48:16 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 ABEFAC76 for ; Mon, 17 Nov 2014 07:48:15 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id gq15so2081106lab.6 for ; Sun, 16 Nov 2014 23:48:13 -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:content-type; bh=66QEe9lhYCwW1KQkKf5X9cw4c7t9CLYHwndLbdMz+Gs=; b=ZHHst36SUXS1pmJyCi0FNnVJ0rSMTpTC+6oA/zZYj50wMZ+tQ6MyyRBN9cLoPbZcRp 5zh5mcEmks6HCJpGzOJTQRJG/GRhVZH5cJjPj4HJl72N5TNsjs5Cujr1g1mMWTj+HcTf XzQv+AU06i0WDgmDp+kWzzjxMlGAp8r03veJfhbec2YX6BHSH2c1QKCAgLyHCgoarvR1 qGAYiJZaQGP12lQ0daBxBEW9fc5IXay+H9h5oPkJUkWH9xbdfxueVtODmILBf50qQhlf iF8iPLHSQ9TSqr+svSqY8e+9Jnisxk5S7mB7ZTyprqn705uXTjAJHReo0Rv1BDcbc5Tj sW6Q== MIME-Version: 1.0 X-Received: by 10.152.87.171 with SMTP id az11mr24812384lab.37.1416210493610; Sun, 16 Nov 2014 23:48:13 -0800 (PST) Received: by 10.112.99.36 with HTTP; Sun, 16 Nov 2014 23:48:13 -0800 (PST) Date: Mon, 17 Nov 2014 15:48:13 +0800 Message-ID: Subject: dragonflybsd's ipfw From: Sato Kentney To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 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: Mon, 17 Nov 2014 07:48:16 -0000 I saw a email in dragonflybsd email list, someone is doing this! http://www.dragonflybsd.org/docs/ipfw2/ --=20 =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 Sato K. From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 09:07:53 2014 Return-Path: Delivered-To: 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 1357C193 for ; Mon, 17 Nov 2014 09:07:53 +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 674F8770 for ; Mon, 17 Nov 2014 09:07:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sAH97gxH065980; Mon, 17 Nov 2014 20:07:42 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 17 Nov 2014 20:07:42 +1100 (EST) From: Ian Smith To: Sato Kentney Subject: Re: dragonflybsd's ipfw In-Reply-To: Message-ID: <20141117193354.T31139@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 17 Nov 2014 09:07:53 -0000 On Mon, 17 Nov 2014 15:48:13 +0800, Sato Kentney wrote: > I saw a email in dragonflybsd email list, someone is doing this! > http://www.dragonflybsd.org/docs/ipfw2/ We've had 'ipfw2' for a very long while. I couldn't help wondering why DF wouldn't just import our many years of development and experience rather than using bycn82's 'rewrite'? .. but DF already has ipfw2: http://leaf.dragonflybsd.org/cgi/web-man?command=ipfw§ion=ANY man page dated October 2008. Before tables, in-kernel NAT, later dummynet updates and no doubt more. So why not start from there? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 11:09:32 2014 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 6B3E8B89 for ; Mon, 17 Nov 2014 11:09:32 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (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 3856635B for ; Mon, 17 Nov 2014 11:09:31 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id y10so2225127pdj.6 for ; Mon, 17 Nov 2014 03:09:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LoaI3nAt93fTZvdmmEn2YhsbR0P0/uMmmTNQfu/MLWw=; b=cBpKlioxEwOd0xNWs1Mc9fnGYWEgt++lhdECIWz9wlYgfBmyNNpyVR/tDaW/e5LPqq 10prv7PVCAtDHpjBhKFtsvdxBybR/nb5wtgStuu/4C8oNlfuqj+ZkJQ4qS7P7+2QQj0t WAJ0REtQAkJyJe6TMBu1jJNJGc91iiemnz3wHEKEObcvuc9Fl4sxkACMvz7k/SOrF3yV Fgf6/r5V/rjQeWMUQsHtMhNi+xv5pTKWdrUfbW3/aJKzGbTbdlXKFvKtP2y0Dn26Vkcg shEmBtDPzl/o3wi9NqqT02uXe+0pG706MDDIgjfQwptPGzslR6zapsJIuXrcWeDzJNdP aBkg== X-Gm-Message-State: ALoCoQkXEb8ZmV8DH6OwE2B47zI3WFvVzx+bEtVeh7R3oavex2SJMPlw0bs6u6Gjr9fTGA+3sWFz X-Received: by 10.70.63.9 with SMTP id c9mr29020132pds.104.1416222169244; Mon, 17 Nov 2014 03:02:49 -0800 (PST) Received: from lgwl-achen.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id h1sm34979301pat.6.2014.11.17.03.02.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 03:02:48 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_F38375C2-112A-4E06-9440-FCEC35A46B7E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Warner Losh In-Reply-To: Date: Mon, 17 Nov 2014 04:02:38 -0700 Message-Id: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 17 Nov 2014 11:09:32 -0000 --Apple-Mail=_F38375C2-112A-4E06-9440-FCEC35A46B7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 17, 2014, at 12:46 AM, Craig Rodrigues = wrote: > Hi, >=20 > PROPOSAL > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I would like to get feedback on the following proposal. > In the head branch (CURRENT), I would like to enable > VIMAGE with this commit: >=20 >=20 > PATCH > =3D=3D=3D=3D=3D=3D >=20 > Index: sys/conf/NOTES > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/conf/NOTES (revision 274300) > +++ sys/conf/NOTES (working copy) > @@ -784,8 +784,8 @@ > device mn # Munich32x/Falc54 Nx64kbit/sec cards. >=20 > # Network stack virtualization. > -#options VIMAGE > -#options VNET_DEBUG # debug for VIMAGE > +options VIMAGE > +options VNET_DEBUG # debug for VIMAGE >=20 > # > # Network interfaces: >=20 >=20 >=20 > I would like to enable VIMAGE for the following reasons: >=20 > REASONS > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > (1) VIMAGE cannot be enabled off to the side in a separate library or > kernel module. When enabled, it is a kernel ABI incompatible = change. > This has impact on 3rd party code such as the kernel modules > which come with VirtualBox. > So the time to do it in CURRENT is now, otherwise we can't = consider > doing it until FreeBSD-12 timeframe, which is quite a while = away. >=20 > (2) VIMAGE is used in some 3rd party products, such as FreeNAS. > These 3rd party products are mostly happy with VIMAGE, > but sometimes they encounter problems, and FreeBSD doesn't > see these problems because it is disabled by default. >=20 > (3) Most of the major subsystems like ipfw and pf have been fixed for > VIMAGE, and the only > way to shake out the last few issues is to make it the default = and > get feedback from the community. ipfilter still needs to be > VIMAGE-ified. >=20 >=20 > (4) Not everyone uses bhyve. FreeBSD jails are an excellent = virtualization > platform for FreeBSD. Jails are still very popular and > performant. VIMAGE makes jails even better by allowing per-jail > network stacks. >=20 > (5) Olivier Cochard-Labbe has provided good network performance = results > in VIMAGE vs. non-VIMAGE kernels: >=20 >=20 > = https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html >=20 > (6) Certain people like Vitaly "wishmaster" have = been > running VIMAGE > jails in a production environment for quite a while, and would = like > to see it > be the default. >=20 >=20 > ACTION PLAN > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > (1) Coordinate/communicate with portmgr, since this has kernel ABI > implications >=20 > (2) Work with clusteradm@, and try to get a test instance of one of = the > PF firewalls in the cluster working with a VIMAGE enabled = kernel. >=20 > (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO > and > = https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=3Dvimage%20or%20= vnet > and try to clean things up. Get help from net@ developers to = do > this. And if these don=92t get cleaned up? > (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help = from > the ipfilter maintainers for this and some net@ developers. And if this doesn=92t happen? > (5) Enable VIMAGE by default in CURRENT on January 5, 2015. > This will *not* be enabled in STABLE. >=20 > What do people think? How do you plan to address the problems seen by FreeNAS in #2 above? I = don=92t see that in the action plan. Without it, we=92re enabling an = option that has know, serious issue making 11 potentially a more = unstable release. Warner --Apple-Mail=_F38375C2-112A-4E06-9440-FCEC35A46B7E 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 iQIcBAEBCgAGBQJUadXPAAoJEGwc0Sh9sBEAvYAP/iwf6hIRHekLe0WOXLKpmJJG 5Do3lUbWaKSsUMPQUVhrZCEqaktFvNl3KXREGz3vIYir6/VKUD9pHm2aKWHaH4Dh ug7BwaGnX0F+Lrs+ztE09oqkMM2e/IRYPlpXFtBkfYssSEPTVekWu5nyCeJ2/bfC fyobYns+3PvpfoLSo9NZolDT5FwwuireoAJcpQ8XDXzdRd94IQOxoXw3OZSI+uig yP076NgBxe0hfVsREUU4NoPEsmWX5EW9RXO4PcucnvoovPsUj5eGECIinpeKr+70 k9+qyhZfvuUg1bgwy33Xn+r1mVj7BYpLb2RLERfsf5C154r0ULAEzkszo16T+B8x e+JajoSRxQtjpw7VQtZLKmLzJk1xfKbndL1bKEmmq3BNyOU6U8lsb1cbQ/WamxBp SbRlx/h9viK9xIyZ0lpqtkvn5zeTSHTG6BTQMdI4e5t02lmsNB3kSE3ioMyCCNSI 5UOlDPRolosCWfyswWkLA47JE54x938SQdRcSSDXhxCCTeXRXMlyNTH0MtQKx1Ui vfINNqg95ohsLjtfdFvGKpJNTJ7t0glvtnkusNvcZc/45aO0n3s4wN8qIo+J10WA kryjtn2OyaeBL2x961vE91r3OBBH+s6RcywbLH4gfA3Lu+ACP7hI93CunwXDO80D vItyld7BvOsjk+e7pdkA =NjCp -----END PGP SIGNATURE----- --Apple-Mail=_F38375C2-112A-4E06-9440-FCEC35A46B7E-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 11:20:22 2014 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 00847E4A; Mon, 17 Nov 2014 11:20:21 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 9C2B7640; Mon, 17 Nov 2014 11:20:21 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 22EF3153408; Mon, 17 Nov 2014 12:20:13 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfIreQrOjHzi; Mon, 17 Nov 2014 12:20:01 +0100 (CET) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 4226E153416; Mon, 17 Nov 2014 12:20:01 +0100 (CET) Message-ID: <5469D9E1.2060400@digiware.nl> Date: Mon, 17 Nov 2014 12:20:01 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh , Craig Rodrigues Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> In-Reply-To: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 17 Nov 2014 11:20:22 -0000 On 17-11-2014 12:02, Warner Losh wrote: > > On Nov 17, 2014, at 12:46 AM, Craig Rodrigues > wrote: > >> Hi, >> >> PROPOSAL ========== I would like to get feedback on the following >> proposal. In the head branch (CURRENT), I would like to enable >> VIMAGE with this commit: >> >> >> PATCH ====== >> >> Index: sys/conf/NOTES >> =================================================================== >> >> --- sys/conf/NOTES (revision 274300) >> +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device >> mn # Munich32x/Falc54 Nx64kbit/sec cards. >> >> # Network stack virtualization. -#options VIMAGE -#options >> VNET_DEBUG # debug for VIMAGE +options VIMAGE +options >> VNET_DEBUG # debug for VIMAGE >> >> # # Network interfaces: >> >> >> >> I would like to enable VIMAGE for the following reasons: >> >> REASONS ======== >> >> (1) VIMAGE cannot be enabled off to the side in a separate library >> or kernel module. When enabled, it is a kernel ABI incompatible >> change. This has impact on 3rd party code such as the kernel >> modules which come with VirtualBox. So the time to do it in CURRENT >> is now, otherwise we can't consider doing it until FreeBSD-12 >> timeframe, which is quite a while away. >> >> (2) VIMAGE is used in some 3rd party products, such as FreeNAS. >> These 3rd party products are mostly happy with VIMAGE, but >> sometimes they encounter problems, and FreeBSD doesn't see these >> problems because it is disabled by default. >> >> (3) Most of the major subsystems like ipfw and pf have been fixed >> for VIMAGE, and the only way to shake out the last few issues is to >> make it the default and get feedback from the community. ipfilter >> still needs to be VIMAGE-ified. >> >> >> (4) Not everyone uses bhyve. FreeBSD jails are an excellent >> virtualization platform for FreeBSD. Jails are still very popular >> and performant. VIMAGE makes jails even better by allowing >> per-jail network stacks. >> >> (5) Olivier Cochard-Labbe has provided good network performance >> results in VIMAGE vs. non-VIMAGE kernels: >> >> >> https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html >> >> >> (6) Certain people like Vitaly "wishmaster" have been >> running VIMAGE jails in a production environment for quite a while, >> and would like to see it be the default. >> >> >> ACTION PLAN =========== >> >> (1) Coordinate/communicate with portmgr, since this has kernel >> ABI implications >> >> (2) Work with clusteradm@, and try to get a test instance of one >> of the PF firewalls in the cluster working with a VIMAGE enabled >> kernel. >> >> (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and >> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet >> >> and try to clean things up. Get help from net@ developers to do >> this. > > And if these don’t get cleaned up? > >> (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help >> from the ipfilter maintainers for this and some net@ developers. > > And if this doesn’t happen? > >> (5) Enable VIMAGE by default in CURRENT on January 5, 2015. This >> will *not* be enabled in STABLE. >> >> What do people think? > > How do you plan to address the problems seen by FreeNAS in #2 above? > I don’t see that in the action plan. Without it, we’re enabling an > option that has know, serious issue making 11 potentially a more > unstable release. Hi Warner, I think I understand your critique, but then on the other hand I wonder where the reluctance is.... As I read it, things are going to be enabled in CURRENT only (for the time). Which is exactly for the reasons you worry about: Is it going to be reliable enough?? But for that it needs exposure... So I would expect it to be turned off as a default IF things are not in a stable state that warrants a default enabling of the options. Things need to move forward, and taking this step is going to be required.. Otherwise I see a big risk of bit-rot somewhere down in the dungeons. --Willem Jan From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 11:43:02 2014 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 5506A9D8; Mon, 17 Nov 2014 11:43:02 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 078F7961; Mon, 17 Nov 2014 11:43:01 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3928125D388C; Mon, 17 Nov 2014 11:42:57 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C81F6C770D8; Mon, 17 Nov 2014 11:42:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id noVUGNh3OCde; Mon, 17 Nov 2014 11:42:53 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 17AE1C77042; Mon, 17 Nov 2014 11:42:47 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: "Bjoern A. Zeeb" In-Reply-To: <5469D9E1.2060400@digiware.nl> Date: Mon, 17 Nov 2014 11:42:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <5469D9E1.2060400@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , Warner Losh , freebsd-arch 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, 17 Nov 2014 11:43:02 -0000 On 17 Nov 2014, at 11:20 , Willem Jan Withagen wrote: > I think I understand your critique, but then on the other hand I = wonder > where the reluctance is.... As I read it, things are going to be = enabled > in CURRENT only (for the time). Which is exactly for the reasons you > worry about: Is it going to be reliable enough?? No, the answer to that still is =93no=94 in it=92s current state and we = know that. I think one of the main problems is that no one has been able to pull = the thing to the end in the last three years. Why should it happen within 6 = weeks now? I think it would be a really good idea to do that but the current TODO = list, I think, is by far not sufficing. There=92s a second problem we=92ll hit in that same timeframe: general = network stack breakage; we=92ll hit the times when we=92ll not be sure if = things broke because of VIMAGE or are also broken in the normal network stack. = There=92ll be a lot of regression test writing and debugging to be done. That all said, I=92d like to see it happen as well, but I=92d love to = have a lot of the issues being addressed first before putting a date on it to = enable it in GENERIC in HEAD. /bz =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 12:42:51 2014 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 0C932B87; Mon, 17 Nov 2014 12:42:51 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 916F1EFF; Mon, 17 Nov 2014 12:42:50 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id A6FBC153448; Mon, 17 Nov 2014 13:42:46 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh6hyyq0wydl; Mon, 17 Nov 2014 13:42:37 +0100 (CET) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 9A4C4153413; Mon, 17 Nov 2014 13:42:37 +0100 (CET) Message-ID: <5469ED3D.2060307@digiware.nl> Date: Mon, 17 Nov 2014 13:42:37 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <5469D9E1.2060400@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 17 Nov 2014 12:42:51 -0000 On 17-11-2014 12:42, Bjoern A. Zeeb wrote: > On 17 Nov 2014, at 11:20 , Willem Jan Withagen wrote: > >> I think I understand your critique, but then on the other hand I wonder >> where the reluctance is.... As I read it, things are going to be enabled >> in CURRENT only (for the time). Which is exactly for the reasons you >> worry about: Is it going to be reliable enough?? > > No, the answer to that still is “no” in it’s current state and we know that. > > I think one of the main problems is that no one has been able to pull the > thing to the end in the last three years. Why should it happen within 6 weeks now? > > I think it would be a really good idea to do that but the current TODO list, > I think, is by far not sufficing. > > There’s a second problem we’ll hit in that same timeframe: general network > stack breakage; we’ll hit the times when we’ll not be sure if things broke > because of VIMAGE or are also broken in the normal network stack. There’ll > be a lot of regression test writing and debugging to be done. > > > That all said, I’d like to see it happen as well, but I’d love to have a lot > of the issues being addressed first before putting a date on it to enable > it in GENERIC in HEAD. Hi Bjoern, The constraints as you put them are indeed rather tight. There is little to be done about it. I was not aware of the fact that 11.0 is planned for release in such short time. Somewhere in the back op my head is: planning is start release cycle around Q2 2015. And I took the liberty to add some testing & QA time to that, so I expect it after summer holidays in 2015. Now I admit: I don't write code for this, nor do I have the knowledge to so. But do run CURRENT to test exactly all these visualization options... Have not (yet) found a requirement to put VIMAGE to good use, so I never switched it on. The down side of all this, is that if we cannot turn it on during the 11-STABLE lifetime. Then it is going to take a full version release cycle to make it to the front. Which I find a pity, since it misses the opportunity for FreeBSD to add another distinctive element to their visualization possibilities. I prefer not to take this into a debate about the way things should go. Over time I've seen too many of these discussions turn in to shouting wars/bikesheds/and what not.... So given the fact I'm not going to do it, I'll leave the rest of the discussion to those that are actual doing all the work... (for which already 20 year of thanks) --WjW From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 15:37:19 2014 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 ED9E8CC5; Mon, 17 Nov 2014 15:37:19 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA91485E; Mon, 17 Nov 2014 15:37:19 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id BE9C5A982; Mon, 17 Nov 2014 15:37:18 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 07A301B9C; Mon, 17 Nov 2014 16:37:17 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Willem Jan Withagen Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <5469D9E1.2060400@digiware.nl> <5469ED3D.2060307@digiware.nl> Date: Mon, 17 Nov 2014 16:37:17 +0100 In-Reply-To: <5469ED3D.2060307@digiware.nl> (Willem Jan Withagen's message of "Mon, 17 Nov 2014 13:42:37 +0100") Message-ID: <86lhn96doy.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Craig Rodrigues , "Bjoern A. Zeeb" , freebsd-arch , "freebsd-virtualization@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: Mon, 17 Nov 2014 15:37:20 -0000 Willem Jan Withagen writes: > The constraints as you put them are indeed rather tight. There is little > to be done about it. I was not aware of the fact that 11.0 is planned > for release in such short time. It isn't. ISTR that the target is 2015Q4. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 17:47:53 2014 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 B8DFAF99; Mon, 17 Nov 2014 17:47:53 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 9D325B9E; Mon, 17 Nov 2014 17:47:53 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 177B7341F872; Mon, 17 Nov 2014 09:47:53 -0800 (PST) Message-ID: <546A34C8.6060004@freebsd.org> Date: Mon, 17 Nov 2014 09:47:52 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh , Craig Rodrigues Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> In-Reply-To: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 17 Nov 2014 17:47:53 -0000 On 11/17/14, 3:02 AM, Warner Losh wrote: > On Nov 17, 2014, at 12:46 AM, Craig Rodrigues wrote: > >> Hi, >> >> PROPOSAL >> ========== >> I would like to get feedback on the following proposal. >> In the head branch (CURRENT), I would like to enable >> VIMAGE with this commit: >> >> >> PATCH >> ====== >> >> Index: sys/conf/NOTES >> =================================================================== >> --- sys/conf/NOTES (revision 274300) >> +++ sys/conf/NOTES (working copy) >> @@ -784,8 +784,8 @@ >> device mn # Munich32x/Falc54 Nx64kbit/sec cards. >> >> # Network stack virtualization. >> -#options VIMAGE >> -#options VNET_DEBUG # debug for VIMAGE >> +options VIMAGE >> +options VNET_DEBUG # debug for VIMAGE >> >> # >> # Network interfaces: >> >> >> >> I would like to enable VIMAGE for the following reasons: >> >> REASONS >> ======== >> >> (1) VIMAGE cannot be enabled off to the side in a separate library or >> kernel module. When enabled, it is a kernel ABI incompatible change. >> This has impact on 3rd party code such as the kernel modules >> which come with VirtualBox. >> So the time to do it in CURRENT is now, otherwise we can't consider >> doing it until FreeBSD-12 timeframe, which is quite a while away. >> >> (2) VIMAGE is used in some 3rd party products, such as FreeNAS. >> These 3rd party products are mostly happy with VIMAGE, >> but sometimes they encounter problems, and FreeBSD doesn't >> see these problems because it is disabled by default. >> >> (3) Most of the major subsystems like ipfw and pf have been fixed for >> VIMAGE, and the only >> way to shake out the last few issues is to make it the default and >> get feedback from the community. ipfilter still needs to be >> VIMAGE-ified. >> >> >> (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization >> platform for FreeBSD. Jails are still very popular and >> performant. VIMAGE makes jails even better by allowing per-jail >> network stacks. >> >> (5) Olivier Cochard-Labbe has provided good network performance results >> in VIMAGE vs. non-VIMAGE kernels: >> >> >> https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html >> >> (6) Certain people like Vitaly "wishmaster" have been >> running VIMAGE >> jails in a production environment for quite a while, and would like >> to see it >> be the default. >> >> >> ACTION PLAN >> =========== >> >> (1) Coordinate/communicate with portmgr, since this has kernel ABI >> implications >> >> (2) Work with clusteradm@, and try to get a test instance of one of the >> PF firewalls in the cluster working with a VIMAGE enabled kernel. >> >> (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO >> and >> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet >> and try to clean things up. Get help from net@ developers to do >> this. > And if these don’t get cleaned up? If they are not cleaned/stable up by 11-RELEASE then we turn it off. That is simple. > >> (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from >> the ipfilter maintainers for this and some net@ developers. > And if this doesn’t happen? Well we do have 2 other firewalls in the kernel to pick, but we do need VIMAGE so I will let you draw your own conclusions. -Alfred From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 20:57:10 2014 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 E39DABA4; Mon, 17 Nov 2014 20:57:10 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 9F220392; Mon, 17 Nov 2014 20:57:10 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id DFFD9153416; Mon, 17 Nov 2014 21:57:05 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFBhL4hyRQjE; Mon, 17 Nov 2014 21:57:04 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:daa2:5eff:fe4e:36d2] (unknown [IPv6:2001:4cb8:3:1:daa2:5eff:fe4e:36d2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPS id B4137153413; Mon, 17 Nov 2014 21:57:04 +0100 (CET) References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <5469D9E1.2060400@digiware.nl> <5469ED3D.2060307@digiware.nl> <86lhn96doy.fsf@nine.des.no> In-Reply-To: <86lhn96doy.fsf@nine.des.no> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <17C50DD9-B155-478C-B5E1-61F0A01616EC@digiware.nl> X-Mailer: iPad Mail (9B206) From: Willem Jan Withagen Subject: Re: RFC: Enabling VIMAGE in GENERIC Date: Mon, 17 Nov 2014 21:57:12 +0100 To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: Craig Rodrigues , "Bjoern A. Zeeb" , freebsd-arch , "freebsd-virtualization@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: Mon, 17 Nov 2014 20:57:11 -0000 Op 17 nov. 2014 om 16:37 heeft Dag-Erling Sm=C3=B8rgrav het vol= gende geschreven: > Willem Jan Withagen writes: >> The constraints as you put them are indeed rather tight. There is little >> to be done about it. I was not aware of the fact that 11.0 is planned >> for release in such short time. >=20 > It isn't. ISTR that the target is 2015Q4. >=20 So even further in the future than what I expected. But still, somebody(tm) needs to do the actual work. So they get the say. --WjW= From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 01:38:31 2014 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 3142FE06 for ; Tue, 18 Nov 2014 01:38:31 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (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 A5023665 for ; Tue, 18 Nov 2014 01:38:30 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id mc6so2067706lab.24 for ; Mon, 17 Nov 2014 17:38:28 -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=4KcpcaQXkxTsMPmdOaVRkmw1/kaflRQLU8LovjNY8Xc=; b=tBoylUUPzDg9NUVLyw3zHFwv9JGfCgo8oN/lU3EwBER4h0i/cWmSFSOrp8EJRfKXmH q3Az0/539DeOSQakjOwP37zINCeRMKDqRG3Jvf89OLUfnkxOsL7je0FePeTDlX1RGtCz Z1H8X5+srp9n4JqnDAXMvNJvemBIuQ6Kj4xBikF3f5IqBKl2zqIuzhKfV+j/hVhguA2x H2mpRLkJxx4SasDwsrFaiEmAH+WwLkV4H0X0CorW8DepUgmn5nVeZ8KN5S/dGhznIxr5 E8AtaEEgTt4koWX1pB7mh/n9x21nsv5VKlbmtki4NM7U6kQREsQAFUAjywYspBg52gOi e6Tw== MIME-Version: 1.0 X-Received: by 10.152.29.41 with SMTP id g9mr14860878lah.83.1416274708622; Mon, 17 Nov 2014 17:38:28 -0800 (PST) Received: by 10.112.99.36 with HTTP; Mon, 17 Nov 2014 17:38:28 -0800 (PST) In-Reply-To: <20141117193354.T31139@sola.nimnet.asn.au> References: <20141117193354.T31139@sola.nimnet.asn.au> Date: Tue, 18 Nov 2014 09:38:28 +0800 Message-ID: Subject: Re: dragonflybsd's ipfw From: Sato Kentney To: Ian Smith Content-Type: text/plain; charset=UTF-8 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: Tue, 18 Nov 2014 01:38:31 -0000 i agree, i am not good in english as networking administor from Tokyo. but when i read the page, i see that the main idea is so call "modular design" and there is a long way to catch up the freebsd's ipfw anyway, i dont think it can compare to freebsd's ipfw, as Smith said their ipfw is the version without in-kernel NAT and tables .all these important features On Mon, Nov 17, 2014 at 5:07 PM, Ian Smith wrote: > On Mon, 17 Nov 2014 15:48:13 +0800, Sato Kentney wrote: > > > I saw a email in dragonflybsd email list, someone is doing this! > > http://www.dragonflybsd.org/docs/ipfw2/ > > We've had 'ipfw2' for a very long while. I couldn't help wondering why > DF wouldn't just import our many years of development and experience > rather than using bycn82's 'rewrite'? .. but DF already has ipfw2: > > http://leaf.dragonflybsd.org/cgi/web-man?command=3Dipfw§ion=3DANY > > man page dated October 2008. Before tables, in-kernel NAT, later > dummynet updates and no doubt more. So why not start from there? > > cheers, Ian > --=20 =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 Sato K. From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 03:07:33 2014 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 6AEEBA18; Wed, 19 Nov 2014 03:07:33 +0000 (UTC) Received: from mail1.bur200.uecomm.net.au (mail1.bur200.uecomm.net.au [218.185.0.70]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD6FD22; Wed, 19 Nov 2014 03:07:32 +0000 (UTC) Received: from mail.flexibledrive.com.au (unknown [115.186.196.106]) by mail1.bur200.uecomm.net.au (Postfix) with ESMTP id 7BE89D400; Wed, 19 Nov 2014 14:07:28 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.flexibledrive.com.au (Postfix) with ESMTP id D8BA3E6C0D; Wed, 19 Nov 2014 14:07:27 +1100 (EST) X-Virus-Scanned: amavisd-new at fdrive.com.au Received: from mail.flexibledrive.com.au ([127.0.0.1]) by localhost (mail.flexibledrive.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J42y4+f5yYhY; Wed, 19 Nov 2014 14:07:19 +1100 (EST) Received: from ws-pross.vv.fda (ws-pross.vv.fda [192.168.50.199]) by mail.flexibledrive.com.au (Postfix) with ESMTPS id 64597E623B; Wed, 19 Nov 2014 14:07:19 +1100 (EST) Date: Wed, 19 Nov 2014 14:07:18 +1100 (AEDT) From: Peter Ross X-X-Sender: petros@linux-vic-05.vv.fda To: Craig Rodrigues Subject: Re: RFC: Enabling VIMAGE in GENERIC Message-ID: User-Agent: Alpine 2.11 (LRH 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch@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, 19 Nov 2014 03:07:33 -0000 On Sun, 16 Nov 2014, Craig Rodrigues wrote: > (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization > platform for FreeBSD. Jails are still very popular and > performant. VIMAGE makes jails even better by allowing per-jail > network stacks. I am using jails and VIMAGE for ca. 4 years, btw. On the other side of the fence (see Linux) containers became quite popular with Docker and are also used for process management and separation (systemd e.g.) Just to add this as a motivation for using jails and possibly VIMAGE, from a sysadmin perspective. Regards Peter From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 03:28:08 2014 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 01086F50; Wed, 19 Nov 2014 03:28:07 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (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 70949F09; Wed, 19 Nov 2014 03:28:07 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id s18so7259758lam.15 for ; Tue, 18 Nov 2014 19:28:05 -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=AaS3LXE8s4tueoBKaQu1DRvqPKO2t73RzBNcmRfqN5A=; b=R8KqIplC7EQjD9z4qWUFT6jo0oqhB/n9huMPO5v5gLKJSy9RlI2HWYfr197Lpxj5sz Qr/JjME0F2/ruHHZ8SP8USg+3YtaSniqPTlMgsgInhNeL2ODZB/CHMz6UXrYkZOlCzeE I0PJfg51NYlRBehYRLBiBjWehY/0D4rnc//1CP+rpSG+YS2CWhFnEwWAFnzL8TJNfUY0 rAEjAkKmJtdGegmcq5dlL+aMmLTtJ7XMzDcbCK0PQ263W+nFfJCYY+1bIwnvPfWHL38I EJdaI+BNaStA2C7W8UEm0IeRXMrY/LTUdZevILgvTyuqDLfCo4S2sToZYd5K/9CuSm5L 2Zkg== MIME-Version: 1.0 X-Received: by 10.112.135.229 with SMTP id pv5mr2928817lbb.52.1416367685372; Tue, 18 Nov 2014 19:28:05 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Tue, 18 Nov 2014 19:28:05 -0800 (PST) In-Reply-To: <546A34C8.6060004@freebsd.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> Date: Tue, 18 Nov 2014 19:28:05 -0800 X-Google-Sender-Auth: TTScpdATYtYmx9Wo88nvuv4WoVY Message-ID: Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Alfred Perlstein , "freebsd-virtualization@freebsd.org" , Warner Losh , freebsd-arch 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, 19 Nov 2014 03:28:08 -0000 On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein wrote: > > On 11/17/14, 3:02 AM, Warner Losh wrote: > >> On Nov 17, 2014, at 12:46 AM, Craig Rodrigues >> wrote: >> >> >>> (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO >>> and >>> https://bugs.freebsd.org/bugzilla/buglist.cgi? >>> quicksearch=vimage%20or%20vnet >>> and try to clean things up. Get help from net@ developers to >>> do >>> this. >>> >> And if these don't get cleaned up? >> > If they are not cleaned/stable up by 11-RELEASE then we turn it off. That > is simple. > Yes, I agree with Alfred that we can turn VIMAGE back off before 11-RELEASE if things don't get cleaned up. We have approximately until the end of 2015, so that gives us time. > > >> (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from >>> the ipfilter maintainers for this and some net@ developers. >>> >> And if this doesn't happen? >> > > Well we do have 2 other firewalls in the kernel to pick, but we do need > VIMAGE so I will let you draw your own conclusions. > Again, I agree with Alfred on this. Darren Reed originally imported ipfilter into FreeBSD, but hasn't actively maintained it (in FreeBSD) in a while. Cy Schubert has recently expressed interest in ipfilter and has committed some fixes in the past year, but has not fixed the VIMAGE problems ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176992 ). I can take an initial effort at trying to fix VIMAGE + ipfilter. In the past, I've delved into areas I'm not so familiar with in order to fix VIMAGE + Bluetooth. If Cy can provide any knowledge or guidance, that will be great. A lot of bug fixes have gone into VIMAGE in the past 2 years, and I have received multiple reports of people using it in production environments. See the latest post by Peter Ross. To flush out the last few issues and corner cases, I think we need to turn VIMAGE on by default and get feedback and help from the FreeBSD user community and developers to identify and fix the problems. We have about 1 year until 11-RELEASE, so I think it is OK to do this. I would also add two items to my action plan. (6) Ask clusteradm to run one of the machines they use for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide feedback. (7) Ask for help with testing from companies who have more involvement with the network stack. Two of the people in the CC: line of this e-mail work for such places. :) -- Craig -- Craig From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 07:44:54 2014 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 25030D0 for ; Wed, 19 Nov 2014 07:44:54 +0000 (UTC) Received: from smtp.sitkom.cz (smtp.sitkom.cz [IPv6:2a03:3a00:1:2::4:b]) by mx1.freebsd.org (Postfix) with ESMTP id A9888C99 for ; Wed, 19 Nov 2014 07:44:53 +0000 (UTC) Received: from spamd.smtp.sitkom.cz (unknown [10.13.127.4]) by smtp.sitkom.cz (Postfix) with ESMTP id B0CD34209 for ; Wed, 19 Nov 2014 08:44:42 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on smtp.sfn X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from avscan.smtp.sitkom.cz (unknown [10.13.127.4]) by spamd.smtp.sitkom.cz (Postfix) with ESMTP id 8A1CA4204 for ; Wed, 19 Nov 2014 08:44:42 +0100 (CET) Received: from wopr.admini.uzel.sfn (unknown [IPv6:2a03:3a00:2:d14:4261:86ff:fec9:7bf]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.sitkom.cz (Postfix) with ESMTPSA id 6B5054203 for ; Wed, 19 Nov 2014 08:44:42 +0100 (CET) Message-ID: <546C4A6A.4060401@borsice.net> Date: Wed, 19 Nov 2014 08:44:42 +0100 From: Michal Buchtik User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: netmap-ipfw IPv6 problem? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on smtp.sitkom.cz 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, 19 Nov 2014 07:44:54 -0000 Hello, I try netmap-ipfw and have problem with IPv6 rule Running on FreeBSD 10.1-RELEASE (compiled from source, kernel with option NETMAP added) $ ipfw/ipfw add 00100 allow ipv6 from any to any connected to 127.0.0.1:5555 ipfw: getsockopt(IP_FW_ADD): Protocol not supported and on kipfw output i see ipfw: no IPv6 support in kernel ipv6-icmp works $ ipfw/ipfw add 00100 allow ipv6-icmp from any to any connected to 127.0.0.1:5555 00100 allow ipv6-icmp from any to any $ ipfw/ipfw list connected to 127.0.0.1:5555 nalloc 2248 nbytes 176 ptr 0x0 00100 allow ipv6-icmp from any to any 65535 allow ip from any to any but when try kernel ipfw, it works # ipfw add 10001 allow ip6 from any to any 10001 allow ip6 from any to any # ipfw list 10000 allow ip from any to any 10001 allow ip6 from any to any 65535 deny ip from any to any kipfw start output $ ./kipfw netmap:igb0 netmap:igb1 [ 589.405494] missing.c:main [724] initializing tick to 200 [ 589.405508] missing.c:callout_startup [361] start init_children mod_idx value 9 +++ start module 0 ipfw ipfw at 0x61e3c0 order 0x1 +++ start module 1 sy_ipfw SYSINIT at 0x0 order 0x2 ipfw2 initialized, divert loadable, nat loadable, default to accept, logging disabled +++ start module 2 sy_Vnet_ipfw SYSINIT at 0x0 order 0x3 [ 589.405545] missing.c:callout_init [308] c 0x61e990 mpsafe 8 [ 589.405580] missing.c:pfil_head_get [89] called [ 589.405583] missing.c:pfil_add_hook [96] called +++ start module 3 dummynet dummynet at 0x61e418 order 0x4 DUMMYNET 0x0 with IPv6 initialized (100409) [ 589.405594] missing.c:taskqueue_create_fast [427] start dummynet fn 0x4154c0 ctx 0x61ea08 [ 589.405598] missing.c:taskqueue_start_threads [435] tqp 0x61ea08 count 1 (dummy) [ 589.405600] missing.c:callout_init [308] c 0x61e9d0 mpsafe 8 +++ start module 4 dn_fifo dn_fifo at 0x61e448 order 0x5 [ 589.405605] ip_dummynet.c:load_dn_sched [2245] dn_sched FIFO loaded +++ start module 5 dn_wf2qp dn_wf2qp at 0x61e4f8 order 0x6 [ 589.405610] ip_dummynet.c:load_dn_sched [2245] dn_sched WF2Q+ loaded +++ start module 6 dn_rr dn_rr at 0x61e5a8 order 0x7 [ 589.405614] ip_dummynet.c:load_dn_sched [2245] dn_sched RR loaded +++ start module 7 dn_qfq dn_qfq at 0x61e658 order 0x8 [ 589.405618] ip_dummynet.c:load_dn_sched [2245] dn_sched QFQ loaded +++ start module 8 dn_prio dn_prio at 0x61e708 order 0x9 [ 589.405622] ip_dummynet.c:load_dn_sched [2245] dn_sched PRIO loaded *** Global Sysctl Table entries = 41, total size = 2144 *** [ 589.405660] session.c:do_server [541] +++ listening tcp 127.0.0.1:5555 [ 589.405675] netmap_io.c:netmap_add_port [310] opening netmap device netmap:igb0 [ 589.548909] netmap_io.c:netmap_add_port [326] --- mem_id 1 [ 589.548926] netmap_io.c:netmap_add_port [329] create sess 0x801449070 my_netmap_port 0x801429580 [ 589.548929] netmap_io.c:netmap_add_port [310] opening netmap device netmap:igb1 [ 589.692204] netmap_io.c:netmap_add_port [326] --- mem_id 1 [ 589.692220] netmap_io.c:netmap_add_port [329] create sess 0x8014490a0 my_netmap_port 0x801429800 [ 589.692223] netmap_io.c:netmap_add_port [342] 0x801429800 igb1 1 <-> 0x801429580 igb0 1 SWAP [ 589.692463] missing.c:callout_run [378] running 0x61e9d0 due at 1 now 1434 [ 589.692479] session.c:mainloop [624] callouts 1 skipped 0 Can someone suggest me what's wrong? Regards, Michal From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 12:08:16 2014 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 6DD28988; Wed, 19 Nov 2014 12:08:16 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (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 0400EC86; Wed, 19 Nov 2014 12:08:16 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xr02N-00044f-0h; Wed, 19 Nov 2014 11:50:51 +0400 Message-ID: <546C8812.2070904@FreeBSD.org> Date: Wed, 19 Nov 2014 16:07:46 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Craig Rodrigues , FreeBSD Net Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , Warner Losh , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 19 Nov 2014 12:08:16 -0000 On 19.11.2014 07:28, Craig Rodrigues wrote: > On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein > wrote: > >> On 11/17/14, 3:02 AM, Warner Losh wrote: >> >>> On Nov 17, 2014, at 12:46 AM, Craig Rodrigues >>> wrote: >>> >>> >>>> (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO >>>> and >>>> https://bugs.freebsd.org/bugzilla/buglist.cgi? >>>> quicksearch=vimage%20or%20vnet >>>> and try to clean things up. Get help from net@ developers to >>>> do >>>> this. >>>> >>> And if these don't get cleaned up? >>> >> If they are not cleaned/stable up by 11-RELEASE then we turn it off. That >> is simple. >> > Yes, I agree with Alfred that we can turn VIMAGE back off before > 11-RELEASE if things don't get cleaned up. > We have approximately until the end of 2015, so that gives > us time. > > > >> >>> (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from >>>> the ipfilter maintainers for this and some net@ developers. >>>> >>> And if this doesn't happen? >>> >> Well we do have 2 other firewalls in the kernel to pick, but we do need >> VIMAGE so I will let you draw your own conclusions. >> > > Again, I agree with Alfred on this. Darren Reed originally imported > ipfilter into FreeBSD, but hasn't actively maintained it (in FreeBSD) in a > while. Cy Schubert has recently expressed interest in ipfilter and has > committed some fixes in the past year, but has not fixed the VIMAGE problems > ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176992 ). > I can take an initial effort at trying to fix VIMAGE + ipfilter. > In the past, I've delved into areas I'm not so familiar with in > order to fix VIMAGE + Bluetooth. If Cy can provide any knowledge or > guidance, that will be great. > > A lot of bug fixes have gone into VIMAGE in the past 2 years, > and I have received multiple reports of people using it in production > environments. See the latest post by Peter Ross. > > To flush out the last few issues and corner cases, I think we > need to turn VIMAGE on by default and get feedback and help from > the FreeBSD user community and developers to identify and fix the problems. Can we have some wiki/man/docs on how particular subsystem should interact with VNET first? This can probably help to make proper vnet fixes in less number of attempts :) For example, even attach/detach is handled differently in different places: tcp_subr.c: /* Skip initialization of globals for non-default instances. */ if (!IS_DEFAULT_VNET(curvnet)) return; in6_rmx.c: /* * Initialize our routing tree. */ static VNET_DEFINE(int, _in6_rt_was_here); #define V__in6_rt_was_here VNET(_in6_rt_was_here) if (V__in6_rtwas_here == 0) { callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE); in6_mtutimo(curvnet); /* kick off timeout first time */ V__in6_rt_was_here = 1; } return (1); } It would be great to get a bit more details on the following (at least from my point of view): * what is the proper procedure of handling non-default VNET attach/detach (locking mostly) * how can one properly cache needed VNET context (e.g. is it safe just to save "struct vnet *" pointer) and is this right thing to do at all? * Is it safe to to CURVNET_SET without holding any VNET locks ? P.S. I'm not against VIMAGE in any kind, I think we really should move forward towards making it stable. However, "just turn it on" concept with a bunch of known (and unresolved issues) is not the best thing IMO. > > We have about 1 year until 11-RELEASE, so I think it is OK to do this. > > I would also add two items to my action plan. > > > (6) Ask clusteradm to run one of the machines they use > for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide > feedback. > > (7) Ask for help with testing from companies who have more involvement > with the network stack. Two of the people in the CC: line of this > e-mail work for such places. :) > > -- > Craig > > > -- > Craig > _______________________________________________ > 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 Wed Nov 19 12:58:05 2014 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 E8FBAAAE; Wed, 19 Nov 2014 12:58:04 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1361F3; Wed, 19 Nov 2014 12:58:03 +0000 (UTC) Received: from x23 (31.147.125.196) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 19 Nov 2014 13:56:50 +0100 Date: Wed, 19 Nov 2014 13:56:51 +0100 From: Marko Zec To: "Alexander V. Chernikov" Subject: Re: RFC: Enabling VIMAGE in GENERIC Message-ID: <20141119135651.789c6766@x23> In-Reply-To: <546C8812.2070904@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.125.196] Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , Warner Losh , freebsd-arch 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, 19 Nov 2014 12:58:05 -0000 On Wed, 19 Nov 2014 16:07:46 +0400 "Alexander V. Chernikov" wrote: ... > Can we have some wiki/man/docs on how particular subsystem should > interact with VNET first? > This can probably help to make proper vnet fixes in less number of > attempts :) > > For example, even attach/detach is handled differently in different > places: > > tcp_subr.c: > /* Skip initialization of globals for non-default instances. > */ if (!IS_DEFAULT_VNET(curvnet)) > return; > in6_rmx.c: > /* > * Initialize our routing tree. > */ > static VNET_DEFINE(int, _in6_rt_was_here); > #define V__in6_rt_was_here VNET(_in6_rt_was_here) > > if (V__in6_rtwas_here == 0) { > callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE); > in6_mtutimo(curvnet); /* kick off timeout first > time */ V__in6_rt_was_here = 1; > } > > return (1); > } > > It would be great to get a bit more details on the following (at > least from my point of view): > * what is the proper procedure of handling non-default VNET > attach/detach (locking mostly) In general, VNET_SYSINIT() / VNET_SYSUNINIT() macros should be used to invoke per-subsystem ctors / dtors on per-vnet basis. > * how can one properly cache needed VNET context (e.g. is it safe > just to save "struct vnet *" pointer) and is this right thing to do > at all? Caching a VNET context should be avoided, as it yields similar problems as queuing mbufs does (in dummynet or similar queues) pointing to rcvifs which may disappear by the time the mbuf gets dequeued. > * Is it safe to to CURVNET_SET without holding any VNET locks ? Yes, if the VNET context is derived from some of the arguments in the current call graph. > P.S. I'm not against VIMAGE in any kind, I think we really should > move forward towards making it stable. > However, "just turn it on" concept with a bunch of known (and > unresolved issues) is not the best thing IMO. > > > > We have about 1 year until 11-RELEASE, so I think it is OK to do > > this. > > > > I would also add two items to my action plan. > > > > > > (6) Ask clusteradm to run one of the machines they use > > for PF firewalls + IPv6 with a VIMAGE enabled kernel, and > > provide feedback. > > > > (7) Ask for help with testing from companies who have more > > involvement with the network stack. Two of the people in the CC: > > line of this e-mail work for such places. :) > > > > -- > > Craig > > > > > > -- > > Craig > > _______________________________________________ > > 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-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 14:05:41 2014 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 64E92E2A; Wed, 19 Nov 2014 14:05:41 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A1F2BAE; Wed, 19 Nov 2014 14:05:41 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6BC1725D37D1; Wed, 19 Nov 2014 14:05:37 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 723E2C76FD7; Wed, 19 Nov 2014 14:05:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id wJgvp_sLs7Mu; Wed, 19 Nov 2014 14:05:35 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3DD82C76FCE; Wed, 19 Nov 2014 14:05:32 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: "Bjoern A. Zeeb" In-Reply-To: Date: Wed, 19 Nov 2014 14:05:29 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <362F742A-BA6F-483A-947C-62D4C5510F31@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 19 Nov 2014 14:05:41 -0000 On 19 Nov 2014, at 03:28 , Craig Rodrigues wrote: >=20 > (6) Ask clusteradm to run one of the machines they use > for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide > feedback. For people to use pf with VIMAGE we first MUST have the security fix = imported that I pointed out a couple of times in the past. It won=92t matter on the firewalls with just a VIMAGE enabled kernel but = using VIMAGE + pf inside a jail (once that really works if it doesn=92t = already) will allow everyone how can administer pf inside the jail to = take over the entire machine otherwise. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 16:13:02 2014 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 ED0FDCC0; Wed, 19 Nov 2014 16:13:02 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 8A552D20; Wed, 19 Nov 2014 16:13:02 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id w7so774364lbi.29 for ; Wed, 19 Nov 2014 08:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=2/7JRz0TRbLQGfbBgHDfFFOXB02uEcEsZ8xO67W+JuQ=; b=cXJ5GPCWAy8EORLgq4T2tkQrUcgK+vqs+O6bWHiQRYXcWWuqgbdn3WP+0jjgdSGON9 Wd0Ft0c4TNzRBKMu2wEwp2my0dBJczmTmvqax+6GixsdFgp9S+COsfyDzNcudgmF+pzU GHzdK80T+BmnsB9/aG1BxWkhb6E/1ynBJwn7dvqpRocafpYlRGMoBG1HcHXWqc3nA7Er /PRi13uZS4RxkUM8TrxeZlzCEVajNTibRLc6ziy1uMWufYCN6kDRtg/4nVJ56W9YTAjR gbI9oCm1i8RDfEYhVm8FxJC7FGMBPtqtq1l1xjNkuR4Ng1ljpW3TmCBK8X9ZClueUglz PQnw== MIME-Version: 1.0 X-Received: by 10.112.225.225 with SMTP id rn1mr2574328lbc.98.1416413580724; Wed, 19 Nov 2014 08:13:00 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Wed, 19 Nov 2014 08:13:00 -0800 (PST) Date: Wed, 19 Nov 2014 08:13:00 -0800 X-Google-Sender-Auth: W2J0wNW61x7WCwIA2QaJCymcE5I Message-ID: Subject: VIMAGE + ipfilter fix From: Craig Rodrigues To: Cy Schubert Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 19 Nov 2014 16:13:03 -0000 Hi, Can folks take a look at this? https://reviews.freebsd.org/D1191 It fixes a crash in ipfilter when a VIMAGE kernel is booted. Thanks. -- Craig From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 16:19:42 2014 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 94799236; Wed, 19 Nov 2014 16:19:42 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 492F6D8F; Wed, 19 Nov 2014 16:19:42 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jjTkM607Cz14J; Wed, 19 Nov 2014 17:19:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:organization:subject:subject:from:from :date:date:content-transfer-encoding:content-type:content-type :mime-version:received:received:received:received; s=jakla4; t= 1416413976; x=1419005977; bh=+plmnk8uodeRCIj/NJoYgD8YCymZqdTJeuZ vFAgp8Cg=; b=jwAjt2gQJWhhOe40L2Iva6CmoUhdsCUlmZ4pSxS5VSeZ6gRsOrU BaQ6LkBEh5QERNPhE9NUpzobWnvCGYEmE91xw1VboX+DnU1Un+5t3f0b5OUJS3W6 SlYvJZAnq7bX0OEfaFPCIi22u0gzzcYF/CEdsnYQcKvudYa9YzhffR8g= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id 9WtRZ9Yezewr; Wed, 19 Nov 2014 17:19:36 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Wed, 19 Nov 2014 17:19:35 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3jjTkH5hNTzns; Wed, 19 Nov 2014 17:19:35 +0100 (CET) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Wed, 19 Nov 2014 17:19:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 19 Nov 2014 17:19:35 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: DANE & DNSSEC @ freebsd.org - good job! Organization: J. Stefan Institute Message-ID: <8337e5521768bdf3cd959fc0e063dd83@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.3 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, 19 Nov 2014 16:19:42 -0000 Just want to say I was pleasantly surprised seeing that the mailer at freebsd.org now supports DANE [1]. Good job guys and gals!!! Nov 19 16:07:05 dorothy postfix/smtp[68423]: Verified TLS connection established to mx1.freebsd.org[2001:1900:2254:206a::19:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) (sorry for not being able to find a better ML for this posting) Mark [1] http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 19:59:26 2014 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 3D41DAB0; Wed, 19 Nov 2014 19:59:26 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E9093B9A; Wed, 19 Nov 2014 19:59:25 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAJJxNJG080874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2014 11:59:23 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAJJxNGh080873; Wed, 19 Nov 2014 11:59:23 -0800 (PST) (envelope-from jmg) Date: Wed, 19 Nov 2014 11:59:23 -0800 From: John-Mark Gurney To: "Alexander V. Chernikov" Subject: Re: RFC: Enabling VIMAGE in GENERIC Message-ID: <20141119195923.GS24601@funkthat.com> Mail-Followup-To: "Alexander V. Chernikov" , Craig Rodrigues , FreeBSD Net , Alfred Perlstein , Warner Losh , "freebsd-virtualization@freebsd.org" , freebsd-arch References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546C8812.2070904@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 19 Nov 2014 11:59:23 -0800 (PST) Cc: Craig Rodrigues , "freebsd-virtualization@freebsd.org" , FreeBSD Net , Alfred Perlstein , freebsd-arch , Warner Losh 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, 19 Nov 2014 19:59:26 -0000 Alexander V. Chernikov wrote this message on Wed, Nov 19, 2014 at 16:07 +0400: > Can we have some wiki/man/docs on how particular subsystem should > interact with VNET first? Yes, we need a man page talking about this feature first, how to enable it, compile it into the kernel, how to manage it, what subsystems it interacts w/, what sysctl nodes it provides, etc. W/o man page(s) the feature is not complete. $ man -k vnet revnetgroup(8) - generate reverse netgroup data $ man -k vimage XvCreateImage(3), XvShmCreateImage(3) - create an XvImage XvPutImage(3), XvShmPutImage(3) - display an XvImage hmm.. nope... jail has something about vnets, but not nearly enough to be useful... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 23:14:07 2014 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 87CB18F2; Wed, 19 Nov 2014 23:14:07 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 F2D3367C; Wed, 19 Nov 2014 23:14:06 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so1370883lbv.24 for ; Wed, 19 Nov 2014 15:14:04 -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:content-type; bh=BrzUgkBksN2yvMlbd+anLBQC1tHhDjVGNHLtzyXveRw=; b=ityUjPieOr8zRykYuLY39pBz1+JT9t62I4AZT10rFx3b6123hrKH5u0Dt4O/6rWZVG q5HcJb0OiNp63OCu/gOgAC4DvqC59aCtjF+euW2y2d5o2sJhywjF88rxSBtGBJiamzna 75sX+IusRNTWMulaaufKQhNE0Bpjjewujgk8du05cq4sS/57CvBj5C5QrombybsezPt7 S5lA9WFDEF22udNQEjt8oQuyloBkhMlVI/gsc9pIqoA+2GTirRQyuaxWs24qspHR8I5K VsDv60zqIJtjFYPU8fd+lyTTFFZe0V0RhZT/8kpIlJNrg53/vyYzVxOQqp3cKKcujggk AJ+Q== MIME-Version: 1.0 X-Received: by 10.112.169.106 with SMTP id ad10mr44624026lbc.13.1416438843958; Wed, 19 Nov 2014 15:14:03 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Wed, 19 Nov 2014 15:14:03 -0800 (PST) In-Reply-To: <20141119195923.GS24601@funkthat.com> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> Date: Wed, 19 Nov 2014 15:14:03 -0800 X-Google-Sender-Auth: XhhWaC7yBsuP3aIDpEKdaZYuYv0 Message-ID: Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: Marko Zec , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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: Wed, 19 Nov 2014 23:14:07 -0000 On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney wrote: > > Yes, we need a man page talking about this feature first, how to enable > it, compile it into the kernel, how to manage it, what subsystems it > interacts w/, what sysctl nodes it provides, etc. > Marko, Do you have any text which can be put into a vnet(9) man page? It doesn't have to be perfect, but just something that we can start from. I tried looking at some of the notes and presentations that you have done on VIMAGE: https://wiki.freebsd.org/?action=fullsearch&context=180&value=VIMAGE&titlesearch=Titles but didn't see anything that could be readily turned into a man page. -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 00:33:26 2014 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 17068FA0; Thu, 20 Nov 2014 00:33:26 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B5F3AEB3; Thu, 20 Nov 2014 00:33:25 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1DC3725D3A05; Thu, 20 Nov 2014 00:33:13 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id BD343C76FE5; Thu, 20 Nov 2014 00:33:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id voukIar2mHY2; Thu, 20 Nov 2014 00:33:11 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 35A8CC76FCE; Thu, 20 Nov 2014 00:33:09 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 20 Nov 2014 00:33:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , Marko Zec , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 20 Nov 2014 00:33:26 -0000 On 19 Nov 2014, at 23:14 , Craig Rodrigues wrote: > On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney = wrote: >=20 >>=20 >> Yes, we need a man page talking about this feature first, how to = enable >> it, compile it into the kernel, how to manage it, what subsystems it >> interacts w/, what sysctl nodes it provides, etc. >>=20 >=20 > Marko, >=20 > Do you have any text which can be put into a vnet(9) man page? > It doesn't have to be perfect, but just something that we can start = from. >=20 > I tried looking at some of the notes and presentations that you have = done > on VIMAGE: > = https://wiki.freebsd.org/?action=3Dfullsearch&context=3D180&value=3DVIMAGE= &titlesearch=3DTitles >=20 > but didn=92t see anything that could be readily turned into a man = page. https://people.freebsd.org/~bz/20100530-02.vnet.9.html The man page should be in that perforce branch you converted to github. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 02:32:59 2014 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 DC245313; Thu, 20 Nov 2014 02:32:59 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-03.shaw.ca [64.59.136.139]) by mx1.freebsd.org (Postfix) with ESMTP id 950B3BD3; Thu, 20 Nov 2014 02:32:58 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=tLeJwtg1FCvAouMblIYY1Z5/U6XdMrtw4y2B9g+QINc= c=1 sm=1 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=3ipGdL6DPzm70_8MlLMA:9 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 19 Nov 2014 19:32:51 -0700 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 8C3129C2E; Wed, 19 Nov 2014 18:32:51 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id sAK2Wowd015275; Wed, 19 Nov 2014 18:32:50 -0800 (PST) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id sAK2Wo2E015272; Wed, 19 Nov 2014 18:32:50 -0800 (PST) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201411200232.sAK2Wo2E015272@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Craig Rodrigues Subject: Re: VIMAGE + ipfilter fix In-Reply-To: Message from Craig Rodrigues of "Wed, 19 Nov 2014 08:13:00 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Nov 2014 18:32:50 -0800 Cc: FreeBSD Net , Cy Schubert 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, 20 Nov 2014 02:33:00 -0000 In message , Craig Rodrigues writes: > Hi, > > Can folks take a look at this? > > https://reviews.freebsd.org/D1191 > > It fixes a crash in ipfilter when a VIMAGE kernel is booted. Tested here. It addresses the issue. Looking at pf however, global variables were made VIMAGE aware. I've been working on the global variables since yesterday afternoon (fixing other issues along the way). If you want I can commit or you can. I'll continue to work on completing the work I started. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 08:21:01 2014 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 3F798598; Thu, 20 Nov 2014 08:21:01 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (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 AA620FD; Thu, 20 Nov 2014 08:21:00 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id s18so2034931lam.1 for ; Thu, 20 Nov 2014 00:20: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=HC8k3sf1yl1013ly/RhyhHoDqd61uBL5oJF5jCMXjJk=; b=Q8TYRHNMLnC6fqc1qhlhjtHBBklEpmhgwtFCVGqi2wSGDer+E0Zrog1t3yXX4E/jKw 3aJwXUzw2f/9MJhsSgwH/8LtHgCzzXF7ind3+DqCroQeIJhjeDqtARrWcI/GXBRk+6hQ zCaP6c4dzV2aHdDVNMCiv1IvxNlZW3WEPuCuEhwivfhwMq/elboiG9ccSf0BOw+nRDl2 AM1zAr31APlHZUZIHWMAZG1oGkSvvXu/6D+gj7euUNwOJuFxJ2qwE+Ad1/j9ojvHd5Yy LnDurWmVLtT/gHe1yUvKDILuVAws1m0N90FfhJ6p4kTg7kpPnj56hMf65MI7CBy3Q0LU dTVg== MIME-Version: 1.0 X-Received: by 10.152.28.193 with SMTP id d1mr4878344lah.17.1416471658691; Thu, 20 Nov 2014 00:20:58 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Thu, 20 Nov 2014 00:20:58 -0800 (PST) In-Reply-To: <201411200232.sAK2Wo2E015272@slippy.cwsent.com> References: <201411200232.sAK2Wo2E015272@slippy.cwsent.com> Date: Thu, 20 Nov 2014 00:20:58 -0800 X-Google-Sender-Auth: D_PobwYUiSFK86vjE_cB9IXF5ek Message-ID: Subject: Re: VIMAGE + ipfilter fix From: Craig Rodrigues To: Cy Schubert Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Cy Schubert 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, 20 Nov 2014 08:21:01 -0000 On Wed, Nov 19, 2014 at 6:32 PM, Cy Schubert wrote: > In message > om> > , Craig Rodrigues writes: > > Hi, > > > > Can folks take a look at this? > > > > https://reviews.freebsd.org/D1191 > > > > It fixes a crash in ipfilter when a VIMAGE kernel is booted. > > Tested here. It addresses the issue. > > Looking at pf however, global variables were made VIMAGE aware. I've been > working on the global variables since yesterday afternoon (fixing other > issues along the way). If you want I can commit or you can. I'll continue > to work on completing the work I started. > There are two issues here: (1) Eliminating kernel panics that occur when someone boots a VIMAGE kernel, and uses ipfilter but not inside a vnet jail. (2) Virtualizing the variables inside ipfilter so that ipfilter can be used inside a vnet jail. With this patch, I made good headway on fixing (1). I am definitely not signing up to do (2). However, since you are working on it, that is good, so at least some progress. Thanks for doing the review, and taking on the task of fixing ipfilter. I appreciate your help, and efforts. I have done the commit. -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 10:08:26 2014 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 41001F26; Thu, 20 Nov 2014 10:08:26 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 AF9F0F23; Thu, 20 Nov 2014 10:08:25 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id f15so544924lbj.27 for ; Thu, 20 Nov 2014 02:08:23 -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=ekyEPaGHxvs0/gVvVYUMMOj/Eb6uRdJcntP4d89m2Zk=; b=Al/dYUuZsJbQ4Yq0ciaxa4DnUg79Dsw5Mm1nKaZzOaA0t1F02fp1iR+goz2g5nbzBU nzW4uwz7rfyWn0YBlPfQ81PmNlarv9mYj83Bw2osXoFnSevfDPybLB+yfiVAtbAyuKoo dt4xIXAL2M5un/Q5mCRbS7V+1RdWLCTn0+YbXw65JCcMO7EUZgLl5r+xyKUwMh8P9qVc F13eIrLvDCIsiDqkwV5d9zaIVFnq7tHXODzki0mlaojgoqT11w5EzjEchEoM1OYuxpAr rS2lruwkUQ6BpJ9fghe6E3qRjRoweYVC29qhZadQ6mrUV/n2sT88M39Ku6YwiKF8OncN PMoA== MIME-Version: 1.0 X-Received: by 10.152.179.1 with SMTP id dc1mr1227131lac.88.1416478103851; Thu, 20 Nov 2014 02:08:23 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Thu, 20 Nov 2014 02:08:23 -0800 (PST) In-Reply-To: <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> Date: Thu, 20 Nov 2014 02:08:23 -0800 X-Google-Sender-Auth: jAvs6Val3Yu-p9qKy2mJbwKpEtk Message-ID: Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Marko Zec , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 20 Nov 2014 10:08:26 -0000 On Wed, Nov 19, 2014 at 4:33 PM, Bjoern A. Zeeb wrote: > > > https://people.freebsd.org/~bz/20100530-02.vnet.9.html > > The man page should be in that perforce branch you converted to github. > Thank you for pointing that out. It is indeed in github: https://github.com/rodrigc/bz-vimage/tree/master/share/man/man9 I committed it to HEAD: https://lists.freebsd.org/pipermail/svn-src-all/2014-November/095037.html I used the textproc/igor port ( http://www.wonkity.com/~wblock/igor/ ) to check the syntax of the man page. It's a great new utility written by wblock@ and I encourage anyone creating or modifying man pages should run it. -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 15:58:03 2014 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 6C96C29A for ; Thu, 20 Nov 2014 15:58: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 541DFE09 for ; Thu, 20 Nov 2014 15:58: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 sAKFw3fj014447 for ; Thu, 20 Nov 2014 15:58:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194264] race between unp_dispose (called from sofree) and unp_gc Date: Thu, 20 Nov 2014 15:58:03 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- 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: Thu, 20 Nov 2014 15:58:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194264 Andriy Gapon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 17:33:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35E1B610; Thu, 20 Nov 2014 17:33:42 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 7C59C706; Thu, 20 Nov 2014 17:33:40 +0000 (UTC) Message-ID: <546E25D1.7020900@FreeBSD.org> Date: Thu, 20 Nov 2014 20:33:05 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org, "freebsd-net@freebsd.org" Subject: [RFC] add macros for ifnet statistic accounting 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, 20 Nov 2014 17:33:42 -0000 Hi All, we already did some changes in network stack in head/, that made ability for merging changes into stable branches much harder. What you think about adding the following macro to head/: --- if_var.h (revision 274736) +++ if_var.h (working copy) @@ -111,6 +111,10 @@ typedef enum { IFCOUNTERS /* Array size. */ } ift_counter; +#define IFSTAT_ADD(ifp, name, value) \ + if_inc_counter((ifp), IFCOUNTER_ ## name, (value)) +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) + typedef struct ifnet * if_t; typedef void (*if_start_fn_t)(if_t); And then make a direct commit to stable/* branches like this: --- if_var.h (revision 274750) +++ if_var.h (working copy) @@ -104,6 +104,23 @@ VNET_DECLARE(struct pfil_head, link_pfil_hook); /* #define V_link_pfil_hook VNET(link_pfil_hook) #endif /* _KERNEL */ +#define IFSTAT_ADD(ifp, name, value) \ + IFSTAT_ ## name ## _ADD(ifp, value) +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) + +#define IFSTAT_IPACKETS_ADD(ifp, inc) (ifp)->if_ipackets += (inc) +#define IFSTAT_IERRORS_ADD(ifp, inc) (ifp)->if_ierrors += (inc) +#define IFSTAT_OPACKETS_ADD(ifp, inc) (ifp)->if_opackets += (inc) +#define IFSTAT_OERRORS_ADD(ifp, inc) (ifp)->if_oerrors += (inc) +#define IFSTAT_COLLISIONS_ADD(ifp, inc) (ifp)->if_collisions += (inc) +#define IFSTAT_IBYTES_ADD(ifp, inc) (ifp)->if_ibytes += (inc) +#define IFSTAT_OBYTES_ADD(ifp, inc) (ifp)->if_obytes += (inc) +#define IFSTAT_IMCASTS_ADD(ifp, inc) (ifp)->if_imcasts += (inc) +#define IFSTAT_OMCASTS_ADD(ifp, inc) (ifp)->if_omcasts += (inc) +#define IFSTAT_IQDROPS_ADD(ifp, inc) (ifp)->if_iqdrops += (inc) +#define IFSTAT_OQDROPS_ADD(ifp, inc) /* NOP */ +#define IFSTAT_NOPROTO_ADD(ifp, inc) (ifp)->if_noproto += (inc) + /* * Structure defining a queue for a network interface. */ This can make merging a little bit easier, at least for generic code in the network stack. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 17:38:15 2014 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 5510D8AD; Thu, 20 Nov 2014 17:38:15 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (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 DC6F9CD7; Thu, 20 Nov 2014 17:38:14 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id k14so4327879wgh.23 for ; Thu, 20 Nov 2014 09:38:13 -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=q50DR4LGOujL0xdyTYIedS3eA7gTH85frbwPt9RIlkc=; b=EPgtGo7yIsB5sI7cFEUl0gniTrZohTnH1rQFzNPqkXivhqYgj/4w7/+SMr8c6Coe3g LSbtvw3TBxHFMB9ufOVYuVrCZOPharJYVSzusEM0wN05aCMoHu/s4f7p2UijVHbLOiRX jpeGbsVhGtVnvppv5JMgAErCCqnn223yrlclizFFT15RxbdM1hWWAFHF8Irvt7G3usEV ZJ1N083pGbGuMQBFNe0Xd5EZjX1U69I/jLNwh8aMuSrU3iznZGdOPKcBnA4mzeCr0Z7V GA9B96FFsiXnXSRhtF635bf6RciRf3XTyxLY+ovART/i3LY3JJivDXmFrw8S2nerLgbf uFiw== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr72135090wjz.20.1416505093204; Thu, 20 Nov 2014 09:38:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 20 Nov 2014 09:38:13 -0800 (PST) In-Reply-To: <546E25D1.7020900@FreeBSD.org> References: <546E25D1.7020900@FreeBSD.org> Date: Thu, 20 Nov 2014 09:38:13 -0800 X-Google-Sender-Auth: hw_kjtOUwa-S-BmMEWPQyxWsnx4 Message-ID: Subject: Re: [RFC] add macros for ifnet statistic accounting From: Adrian Chadd To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , "freebsd-arch@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, 20 Nov 2014 17:38:15 -0000 I like accessor things like this. It'll make the general porting of things across places more feasible. +1 from me. -adrian On 20 November 2014 09:33, Andrey V. Elsukov wrote: > Hi All, > > we already did some changes in network stack in head/, that made ability > for merging changes into stable branches much harder. > > What you think about adding the following macro to head/: > > --- if_var.h (revision 274736) > +++ if_var.h (working copy) > @@ -111,6 +111,10 @@ typedef enum { > IFCOUNTERS /* Array size. */ > } ift_counter; > > +#define IFSTAT_ADD(ifp, name, value) \ > + if_inc_counter((ifp), IFCOUNTER_ ## name, (value)) > +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) > + > typedef struct ifnet * if_t; > > typedef void (*if_start_fn_t)(if_t); > > > And then make a direct commit to stable/* branches like this: > > --- if_var.h (revision 274750) > +++ if_var.h (working copy) > @@ -104,6 +104,23 @@ VNET_DECLARE(struct pfil_head, link_pfil_hook); /* > #define V_link_pfil_hook VNET(link_pfil_hook) > #endif /* _KERNEL */ > > +#define IFSTAT_ADD(ifp, name, value) \ > + IFSTAT_ ## name ## _ADD(ifp, value) > +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) > + > +#define IFSTAT_IPACKETS_ADD(ifp, inc) (ifp)->if_ipackets += (inc) > +#define IFSTAT_IERRORS_ADD(ifp, inc) (ifp)->if_ierrors += (inc) > +#define IFSTAT_OPACKETS_ADD(ifp, inc) (ifp)->if_opackets += (inc) > +#define IFSTAT_OERRORS_ADD(ifp, inc) (ifp)->if_oerrors += (inc) > +#define IFSTAT_COLLISIONS_ADD(ifp, inc) (ifp)->if_collisions += (inc) > +#define IFSTAT_IBYTES_ADD(ifp, inc) (ifp)->if_ibytes += (inc) > +#define IFSTAT_OBYTES_ADD(ifp, inc) (ifp)->if_obytes += (inc) > +#define IFSTAT_IMCASTS_ADD(ifp, inc) (ifp)->if_imcasts += (inc) > +#define IFSTAT_OMCASTS_ADD(ifp, inc) (ifp)->if_omcasts += (inc) > +#define IFSTAT_IQDROPS_ADD(ifp, inc) (ifp)->if_iqdrops += (inc) > +#define IFSTAT_OQDROPS_ADD(ifp, inc) /* NOP */ > +#define IFSTAT_NOPROTO_ADD(ifp, inc) (ifp)->if_noproto += (inc) > + > /* > * Structure defining a queue for a network interface. > */ > > This can make merging a little bit easier, at least for generic code in > the network stack. > > -- > WBR, Andrey V. Elsukov > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 18:02:49 2014 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 54F618BB for ; Thu, 20 Nov 2014 18:02:49 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 CB87D7D for ; Thu, 20 Nov 2014 18:02:48 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id w7so2758968lbi.33 for ; Thu, 20 Nov 2014 10:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=fXBDrUTpMCVhGaZ+9rt7lVDuB1MRHlxhBhuQzOuDuZ0=; b=0ceopcSkoqcuG7M7IOaXhh/2N3EIrpmKvyDzwnR4we2urls2uJZ/a5TrgrrAanTxDU kKDoJENa60KN5eI5PW6EAGqV+MLKQ4A29wS9MShcauEANcS0hbEqMy1X0OodyCC3iE48 VuxB7taDgTmXcZIucdYvXEuB6xVNtPiIBpJrWnWJbo26L5kYw1jSoap4MsDlcURBViBL w2REhcEyewK35YDOC7hWdbVePr5Ait0fNrAs/HQJlKOuGZtYSgFgsw7t3R9rEf7vDSgU ykVqBrbrIvotmGR5rTsLqhsFxYY8E+LaFzU3u1wV3fcWX4aP7H8daIolOXFy7sBciXoW E7Xw== MIME-Version: 1.0 X-Received: by 10.112.199.40 with SMTP id jh8mr49758086lbc.5.1416506566835; Thu, 20 Nov 2014 10:02:46 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Thu, 20 Nov 2014 10:02:46 -0800 (PST) Date: Thu, 20 Nov 2014 10:02:46 -0800 X-Google-Sender-Auth: l4eVybHkhGdXIKxilrHM0DY-BR8 Message-ID: Subject: VIMAGE UDP memory leak fix From: Craig Rodrigues To: FreeBSD Net 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, 20 Nov 2014 18:02:49 -0000 Hi, Can folks take a look at this? https://reviews.freebsd.org/D1201 -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 18:07:36 2014 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 2F58DA53; Thu, 20 Nov 2014 18:07:36 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 A46BED2; Thu, 20 Nov 2014 18:07:35 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id hz20so2821554lab.20 for ; Thu, 20 Nov 2014 10:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=tFFKI6JR2xalCMzQyjPJ2FLLwUoR7ngwdpMvbVZZIZs=; b=yZlm9h4q1MmPeMw8SfFWYUKOfPdckoeyhVFGSubIGhb0uLYP7iQHmS1+vYSd1WNERz kJXNhoRtqtX8GRdxIThApc5I0NfRNzF1yFcJpgr7D2U8Bct22h8f157iY8odCzJ0MEuI /OVjiWp1RKPT2WoOmY6ZOEts7C4izzX54H10PfElmBCapYvqvKHTIHUVALUpN3FBkFWk alb/QS82HVqRli1J2IUGxy/lFWbS0jAgARvKxMjcq16Kooo3Xu2h/YjcHUyscO9XT+rd 1OOdPbrdrGUwQC0Z0nAkziENGCMPtogPl0BCC9dwlQNZBDPoZBq0MbjrLNf9tRGmKFTg UwwQ== MIME-Version: 1.0 X-Received: by 10.112.137.39 with SMTP id qf7mr12556323lbb.47.1416506853187; Thu, 20 Nov 2014 10:07:33 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Thu, 20 Nov 2014 10:07:33 -0800 (PST) Date: Thu, 20 Nov 2014 10:07:33 -0800 X-Google-Sender-Auth: FuQzAL6KAc12PdfjdXlO_eFU5Lo Message-ID: Subject: VIMAGE + pf security fix? From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 20 Nov 2014 18:07:36 -0000 On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote: > > For people to use pf with VIMAGE we first MUST have the security fix > imported that I pointed out a couple of times in the past. > At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830 I see the security issue mentioned, but I can't find the patch that fixes the problem. Where is the patch? Thanks. -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 21:35:33 2014 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 B1F74433; Thu, 20 Nov 2014 21:35:33 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 923ACF9D; Thu, 20 Nov 2014 21:35:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAKLZQGr098565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 13:35:27 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAKLZQk2098564; Thu, 20 Nov 2014 13:35:26 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 13:35:26 -0800 From: John-Mark Gurney To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Subject: IPsec is very broken... Message-ID: <20141120213526.GH24601@funkthat.com> Mail-Followup-To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 20 Nov 2014 13:35:27 -0800 (PST) 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, 20 Nov 2014 21:35:33 -0000 As I'm about to commit my AES-GCM work, I've been trying to do some testing to make sure I didn't break IPsec. The first major issue I ran across was transport mode... ae@ has been nice enough to get ICMP working in transport mode for IPv4 and IPv6, but it looks like TCP is still broken. I haven't tested UDP yet... So, IPsec even w/o crypto is fundamentally broken here... It's clear that not many people run transport mode... If someone could create a good test suite that ensures makes sure basic IPsec traffic passes, that would be a huge win for us. The tests should test a complete cross product of: { tunnel, transport } x { TCP, UDP, ICMP, any others? } x { IPv4, IPv6 }. Please add to this list. There is a lock order reversal which someone should look at: # setkey -DP lock order reversal: 1st 0xffffffff817fc658 sptree (fast ipsec security policy database) @ netipsec/key.c:2453 2nd 0xffffffff818bd920 rawcb (rawcb) @ netipsec/keysock.c:303 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de9d330 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de9d3e0 witness_checkorder() at witness_checkorder+0xdad/frame 0xfffffe001de9d470 __mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfffffe001de9d4c0 key_sendup_mbuf() at key_sendup_mbuf+0xb0/frame 0xfffffe001de9d500 key_spddump() at key_spddump+0x188/frame 0xfffffe001de9d540 key_parse() at key_parse+0x8fa/frame 0xfffffe001de9d740 key_output() at key_output+0xeb/frame 0xfffffe001de9d7a0 sosend_generic() at sosend_generic+0x405/frame 0xfffffe001de9d850 kern_sendit() at kern_sendit+0x20b/frame 0xfffffe001de9d900 sendit() at sendit+0x129/frame 0xfffffe001de9d950 sys_sendto() at sys_sendto+0x4d/frame 0xfffffe001de9d9a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe001de9dab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de9dab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b5c5aa, rsp = 0x7fffffff6ae8, rbp = 0x7fffffffeb50 --- The following is more OpenCrypto or aesni related, but as IPsec is a consumer, they are related. It also looks like OpenCrypto session management wasn't on anyone's list, partly because the docs for it aren't very good, and until AES-NI came along, if you provided an explicit IV, the software stack would "magicly" work. Now w/ AES-NI, that is no longer the case... Currently, the aesni driver only has one FPU context allocated per session, but IPsec will reuse the same session for different requests from different threads. This means that you can get panics like: panic: System call sendto returing with kernel FPU ctx leaked or: panic: dummy ctx As the same session fpu context will be assigned to different kernel threads stomping on each other's state. Both transport and tunnel mode suffer (panics) from this issue. I'm working w/ kib on a possible solution to this. There are other issues, such as all the session management code is looked up via linked lists... This isn't good for performance... One of the reasons why this was done was to allow migrating sessions between capable devices, such that if one was overloaded/busy, you could use another one that isn't as busy... There are better solutions/patterns now that weren't used back then that should get us around this issue.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 22:21:13 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AA475D9; Thu, 20 Nov 2014 22:21:13 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id C16AC1F7A; Thu, 20 Nov 2014 22:21:12 +0000 (UTC) Message-ID: <546E6931.20406@FreeBSD.org> Date: Fri, 21 Nov 2014 01:20:33 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Subject: Re: IPsec is very broken... References: <20141120213526.GH24601@funkthat.com> In-Reply-To: <20141120213526.GH24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="09FKR9v2hpJiJmT7vEP5u19xTMXe8to3d" 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, 20 Nov 2014 22:21:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --09FKR9v2hpJiJmT7vEP5u19xTMXe8to3d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 21.11.2014 00:35, John-Mark Gurney wrote: > As I'm about to commit my AES-GCM work, I've been trying to do > some testing to make sure I didn't break IPsec. >=20 > The first major issue I ran across was transport mode... ae@ has been > nice enough to get ICMP working in transport mode for IPv4 and IPv6, > but it looks like TCP is still broken. I haven't tested UDP yet... > So, IPsec even w/o crypto is fundamentally broken here... It's clear > that not many people run transport mode... >=20 > If someone could create a good test suite that ensures makes sure basic= > IPsec traffic passes, that would be a huge win for us. The tests > should test a complete cross product of: { tunnel, transport } x > { TCP, UDP, ICMP, any others? } x { IPv4, IPv6 }. Please add to this > list. I usually do tests for both transport and tunnel modes with and without gif(4)/gre(4). So, just tried between two CURRENT hosts and it works. I use racoon and isakmpd for IKE. ICMP, TCP (ssh) and UDP (ike) works for me. How do you test? Do you use software crypto or aesni? --=20 WBR, Andrey V. Elsukov --09FKR9v2hpJiJmT7vEP5u19xTMXe8to3d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUbmk1AAoJEAHF6gQQyKF6lhQIALjov+pssuB8eYB3YTCIo02q RN9OzxW4nwbbEs82q3UqAxRR+oZlgEwDkVvORieJeWguBA0uhaILegiQGnG4WhXD TTITHC0upzoSKJ/mcEglCmBZcBTZX4CQ9lgSrNShgRwHPlrihmARz3PlxtswtXqE zioNtUaKAcC0aBRDiMbAK1/ODgoJvp4GCfKYlhkUxsoG3GiGM2uxstHXSzPh8hwZ ev4K0YmVgPUdB0orlQ6GpYIii3nclllNyi7hHnYqfkMupsDJ2EqH8WYYOMvUAhuy eInkcULgx67euruZ+enxtMlf2PxmZFVOxTDS+vfqqRdLN8tZE1/BYa+zhvviRb0= =x6EG -----END PGP SIGNATURE----- --09FKR9v2hpJiJmT7vEP5u19xTMXe8to3d-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 22:38:18 2014 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 E7132AA7; Thu, 20 Nov 2014 22:38:18 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E37F945; Thu, 20 Nov 2014 22:38:18 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAKMcHOu099333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 14:38:17 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAKMcHce099332; Thu, 20 Nov 2014 14:38:17 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 14:38:17 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: IPsec is very broken... Message-ID: <20141120223816.GJ24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-net@freebsd.org, freebsd-security@freebsd.org References: <20141120213526.GH24601@funkthat.com> <546E6931.20406@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546E6931.20406@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 20 Nov 2014 14:38:17 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-security@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, 20 Nov 2014 22:38:19 -0000 Andrey V. Elsukov wrote this message on Fri, Nov 21, 2014 at 01:20 +0300: > On 21.11.2014 00:35, John-Mark Gurney wrote: > > As I'm about to commit my AES-GCM work, I've been trying to do > > some testing to make sure I didn't break IPsec. > > > > The first major issue I ran across was transport mode... ae@ has been > > nice enough to get ICMP working in transport mode for IPv4 and IPv6, > > but it looks like TCP is still broken. I haven't tested UDP yet... > > So, IPsec even w/o crypto is fundamentally broken here... It's clear > > that not many people run transport mode... > > > > If someone could create a good test suite that ensures makes sure basic > > IPsec traffic passes, that would be a huge win for us. The tests > > should test a complete cross product of: { tunnel, transport } x > > { TCP, UDP, ICMP, any others? } x { IPv4, IPv6 }. Please add to this > > list. > > I usually do tests for both transport and tunnel modes with and without > gif(4)/gre(4). So, just tried between two CURRENT hosts and it works. > I use racoon and isakmpd for IKE. ICMP, TCP (ssh) and UDP (ike) works > for me. How do you test? Do you use software crypto or aesni? Hmm... weird... Just tested again and TCP seems to be working now... Not sure what changed... It could be that I didn't retest after fixing AES-NI's mbuf issue, but I thought I had... Though I thought I had tested a clean HEAD too... I've only been testing w/ static associations to make testing easier.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 23:29:40 2014 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 EA6A1B05; Thu, 20 Nov 2014 23:29:40 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E55CE4C; Thu, 20 Nov 2014 23:29:40 +0000 (UTC) Received: from x23 (31.147.126.92) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 21 Nov 2014 00:29:36 +0100 Date: Fri, 21 Nov 2014 00:29:37 +0100 From: Marko Zec To: Craig Rodrigues Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121002937.4f82daea@x23> In-Reply-To: References: X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.126.92] Cc: FreeBSD Net , "Bjoern A.Zeeb" , Robert Watson 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, 20 Nov 2014 23:29:41 -0000 On Thu, 20 Nov 2014 10:02:46 -0800 Craig Rodrigues wrote: > Hi, > > Can folks take a look at this? > > https://reviews.freebsd.org/D1201 All UMA zones used in the network stack have been marked as UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it might not hurt to provide more insight why and how it suddenly became safe to remove that flag? One possible alternative is to de-virtualize V_udbinfo, V_udpcb_zone etc. which I have suggested a few times in the past but those proposals have been rejected based on expectations that one day our network stack may benefit from more parallelism of decoupled UMA zones for each VNET, though I'm not aware of further developments in that direction. The primary (and in many cases only) reason I have virtualized network stack zones was to simplify tracking of inter-VNET leaks. As bugs that caused such leaks seem to have been cleaned up some 7 years ago or so, I see no technical reason to maintain separate UMA zones for each VNET, especially not those which are size-limited to maxsockets global limit anyhow. Marko From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 07:50:18 2014 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 7EF96DBE; Fri, 21 Nov 2014 07:50:18 +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 4A77B7C6; Fri, 21 Nov 2014 07:50:18 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id rd3so4329121pab.7 for ; Thu, 20 Nov 2014 23:50:17 -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=gBjZP8/z0kWpf4B4OSBMSijxxUZ6Sbrh4w3+5CXQJDw=; b=d4zOTjPjaz4Qm7jamU34xW97AVz3tIgaxmpzMdLF+OgKXh5xcz9ul6gHHxsffZnwWv uaEKu55xwaT2/KtEKqPw2adLq4S0Br2LZkdrV13Xbc3EzBWM+KCPTeE9NUOYOq9Nzxqw MwDP2fomh/4sAGvTsHyGlSc92AUt3aO24f1DsdvIWeXT9aolLcHjQoeglyVcFE15Mb3P xi9oIpbo6SgDYuBvpj8skCSIz2SFAhYZP00kJj9s/w2BxpHItu8DOpPgmvl7yyM1U9A/ Swno1VAvoOLnU29r17GgO4fggmG9VX3YznUH+BlJ7lxgr0ohChd3csoGkFi3+I6rxpwy uWdQ== MIME-Version: 1.0 X-Received: by 10.66.241.239 with SMTP id wl15mr4388381pac.15.1416556217854; Thu, 20 Nov 2014 23:50:17 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.70.166 with HTTP; Thu, 20 Nov 2014 23:50:17 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Nov 2014 08:50:17 +0100 X-Google-Sender-Auth: oYKMc_0f6wmYX4NTIA8ivYej6t4 Message-ID: Subject: Re: VIMAGE + pf security fix? From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "Bjoern A. Zeeb" , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 21 Nov 2014 07:50:18 -0000 The fix for that was imported with the new import of pf(4) AFARIR. On Thu, Nov 20, 2014 at 7:07 PM, Craig Rodrigues wrote: > On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote: > > > > > For people to use pf with VIMAGE we first MUST have the security fix > > imported that I pointed out a couple of times in the past. > > > > At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830 > > I see the security issue mentioned, but I can't find the patch that fixes > the problem. > Where is the patch? > > Thanks. > -- > Craig > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 08:07:00 2014 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 A5E1AEC; Fri, 21 Nov 2014 08:07:00 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (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 3FA7196F; Fri, 21 Nov 2014 08:07:00 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id gf13so3786685lab.14 for ; Fri, 21 Nov 2014 00:06: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=R6NaaR9sUPaIWwpNqAZOXjKSZ2hiSD7+wU7brstTvew=; b=lwGL8fO4IZs2Q789fdDJNV1LczNaheEFzY6b6BfP5Vn664k9nbzseGUb1Ml8gP3EB7 dJe7GBkC6j5xKuZxEuWUXpmGuMW2UB5T+or/6wBwilmmQApzYHgoJa/2CL7217/bqJbP duFq1EGpiPAwssx5qqu3hyUFpqaLL1qGv4NOYGWMQuKMiejkfAnN2qbIt62qgBD6eNOP 0gIXz3lfyZP7bEhFpQ7XL2cTD/64cGosjwvzSCDAHuFzD7Nv4HbKgfOS8hq0ZqHNahGo KFb6hHzpU/57q/9HKSjGQ2BN6rk56rI88NbteHGZpwyTpCwEjMLJ0Ra093yr1mlAH4RH wlmQ== MIME-Version: 1.0 X-Received: by 10.112.16.39 with SMTP id c7mr2550923lbd.19.1416557218197; Fri, 21 Nov 2014 00:06:58 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Fri, 21 Nov 2014 00:06:58 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Nov 2014 00:06:58 -0800 X-Google-Sender-Auth: NvEn0fM3QA5OFreLz0ufAqhcRlg Message-ID: Subject: Re: VIMAGE + pf security fix? From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 21 Nov 2014 08:07:00 -0000 On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues wrote: > On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote: > >> >> For people to use pf with VIMAGE we first MUST have the security fix >> imported that I pointed out a couple of times in the past. >> > > At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830 > > I see the security issue mentioned, but I can't find the patch that fixes > the problem. > Where is the patch? > I read this link: http://esec-lab.sogeti.com/post/2010/12/09/CVE-2010-3830-iOS-4.2.1-packet-filter-local-kernel-vulnerability and I think this is the fix: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_ioctl.c?rev=1.236&content-type=text/x-cvsweb-markup but I can't even apply that patch to our pf_ioctl.c. -- Craig From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 08:25:54 2014 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 742B0125; Fri, 21 Nov 2014 08:25:54 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD0CBA2; Fri, 21 Nov 2014 08:25:54 +0000 (UTC) Received: from [10.0.1.18] (host86-132-108-5.range86-132.btcentralplus.com [86.132.108.5]) by cyrus.watson.org (Postfix) with ESMTPSA id 213B846B46; Fri, 21 Nov 2014 03:25:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <20141121002937.4f82daea@x23> Date: Fri, 21 Nov 2014 08:25:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141121002937.4f82daea@x23> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" 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, 21 Nov 2014 08:25:54 -0000 On 20 Nov 2014, at 23:29, Marko Zec wrote: >> Can folks take a look at this? >>=20 >> https://reviews.freebsd.org/D1201 >=20 > All UMA zones used in the network stack have been marked as > UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it might > not hurt to provide more insight why and how it suddenly became safe = to > remove that flag? Historically, this was (if I recall) a property of the way data was = exported for netstat, which depended on memory stability of various data = types. We have worked quite hard to remove the causes of those sorts of = dependencies by introducing stronger reference and memory ownership = models throughout the stack -- in the case of inpcbs, for example, we = introduced a true reference model during the multiprocessing scalability = work (which, it should be pointed out, was enormously painful and took = years to shake the bugs out of due to complexity/subtlety). It may be = that it is now safe to remove UMA_ZONE_NOFREE for some of the types = where it was previously required -- but it's definitely something you = want to do intentionally and in the context of a careful analysis to = convince yourself that all the causes have been addressed. A fair amount = of stress testing in low-memory conditions wouldn't hurt either... Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 08:58:48 2014 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 DBE3BE20; Fri, 21 Nov 2014 08:58:48 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E98AF0B; Fri, 21 Nov 2014 08:58:47 +0000 (UTC) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 21 Nov 2014 09:58:45 +0100 Date: Fri, 21 Nov 2014 09:58:47 +0100 From: Marko Zec To: "Robert N. M. Watson" Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121095847.11601640@x23> In-Reply-To: References: <20141121002937.4f82daea@x23> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" 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, 21 Nov 2014 08:58:49 -0000 On Fri, 21 Nov 2014 08:25:48 +0000 "Robert N. M. Watson" wrote: > > On 20 Nov 2014, at 23:29, Marko Zec wrote: > > >> Can folks take a look at this? > >> > >> https://reviews.freebsd.org/D1201 > > > > All UMA zones used in the network stack have been marked as > > UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it might > > not hurt to provide more insight why and how it suddenly became > > safe to remove that flag? > > Historically, this was (if I recall) a property of the way data was > exported for netstat, which depended on memory stability of various > data types. We have worked quite hard to remove the causes of those > sorts of dependencies by introducing stronger reference and memory > ownership models throughout the stack -- in the case of inpcbs, for > example, we introduced a true reference model during the > multiprocessing scalability work (which, it should be pointed out, > was enormously painful and took years to shake the bugs out of due to > complexity/subtlety). It may be that it is now safe to remove > UMA_ZONE_NOFREE for some of the types where it was previously > required -- but it's definitely something you want to do > intentionally and in the context of a careful analysis to convince > yourself that all the causes have been addressed. A fair amount of > stress testing in low-memory conditions wouldn't hurt either... If data stability for userland export was the only factor mandating UMA_ZONE_NOFREE flagging then indeed it may be safe to remove that flag, since the VNET / prison referencing model guarantees that no VNET teardown can commence as long as there are processes, sockets or ifnets attached to a particular VNET. But as you said that change would affect both VIMAGE and non-VIMAGE builds, so extensive testing would be warranted here. Nevertheless, I'd prefer most of network stack UMA zones to be de-virtualized, at least those which cannot cause interference between VNETs, and that excludes syncache, reassembly, hostcache and the likes. De-virtualization doesn't require touching the UMA_ZONE_NOFREE flag, so doesn't affect non-VIMAGE builds. Any objections to that approach? Marko From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 09:05:26 2014 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 7B743FE7; Fri, 21 Nov 2014 09:05:26 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 55E50FD6; Fri, 21 Nov 2014 09:05:26 +0000 (UTC) Received: from [10.0.1.18] (host86-132-108-5.range86-132.btcentralplus.com [86.132.108.5]) by cyrus.watson.org (Postfix) with ESMTPSA id 7478646B46; Fri, 21 Nov 2014 04:05:24 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <20141121095847.11601640@x23> Date: Fri, 21 Nov 2014 09:05:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> References: <20141121002937.4f82daea@x23> <20141121095847.11601640@x23> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" 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, 21 Nov 2014 09:05:26 -0000 On 21 Nov 2014, at 08:58, Marko Zec wrote: > Nevertheless, I'd prefer most of network stack UMA zones to be > de-virtualized, at least those which cannot cause interference between > VNETs, and that excludes syncache, reassembly, hostcache and the = likes. > De-virtualization doesn't require touching the UMA_ZONE_NOFREE flag, = so > doesn't affect non-VIMAGE builds. Any objections to that approach? To my mind, the only real concern is whether or not you lose access to = resource allocation limits that would previously have been present. On = the whole, we've tried to centralise resource limitations on kernel = memory allocation in UMA, and it would be great if we could find a nice = approach to implementing both per-vimage and per-system allocation = limits. One thing I'd pondered in the past was whether we could move to = a single zone, with its own limits/etc, but also the ability to pass an = optional uma_resourcepool_t that allowed additional limits to be imposed = based on some other criteria -- e.g., vimage membership. That strikes me = as a somewhat complex proposal that would bring new = performance/synchronisation concerns, so isn't necessarily something to = act on. However, the upshot is that, although I do not oppose combining = the zones, we should be aware that we're eliminating a form of resource = partitioning between vimages that we may want to find some other = solution for (ideally, an elegant one). Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 09:07:37 2014 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 0AA6C157; Fri, 21 Nov 2014 09:07:37 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id D4CADFF3; Fri, 21 Nov 2014 09:07:36 +0000 (UTC) Received: from [10.0.1.18] (host86-132-108-5.range86-132.btcentralplus.com [86.132.108.5]) by cyrus.watson.org (Postfix) with ESMTPSA id F21E646B2A; Fri, 21 Nov 2014 04:07:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> Date: Fri, 21 Nov 2014 09:07:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141121002937.4f82daea@x23> <20141121095847.11601640@x23> <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" 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, 21 Nov 2014 09:07:37 -0000 On 21 Nov 2014, at 09:05, Robert N. M. Watson = wrote: > To my mind, the only real concern is whether or not you lose access to = resource allocation limits that would previously have been present. On = the whole, we've tried to centralise resource limitations on kernel = memory allocation in UMA, and it would be great if we could find a nice = approach to implementing both per-vimage and per-system allocation = limits. One thing I'd pondered in the past was whether we could move to = a single zone, with its own limits/etc, but also the ability to pass an = optional uma_resourcepool_t that allowed additional limits to be imposed = based on some other criteria -- e.g., vimage membership. That strikes me = as a somewhat complex proposal that would bring new = performance/synchronisation concerns, so isn't necessarily something to = act on. However, the upshot is that, although I do not oppose combining = the zones, we should be aware that we're eliminating a form of resource = partitioning between vimages that we may want to find some other = solution for (ideally, an elegant one). And, to respond to your more general comment: I agree that a decision = about removing the NOFREE flag should be made independently of choices = about devirtualisation. The former probably should be sorted out at this = point, as eliminating NOFREE zones has more general benefits to the = kernel, but it would be nice not to depend on that to resolve other = problems. It could be that a few of us scratching our heads for a few = hours each can resolve whether NOFREE can now be safely removed, in = which case we should do so (and then allow quite a lot of baking time = before it ships in a release). Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 09:45:39 2014 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 A83C8773; Fri, 21 Nov 2014 09:45:39 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D3B9648; Fri, 21 Nov 2014 09:45:38 +0000 (UTC) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 21 Nov 2014 10:45:36 +0100 Date: Fri, 21 Nov 2014 10:45:38 +0100 From: Marko Zec To: "Robert N. M. Watson" Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121104538.5eed0567@x23> In-Reply-To: References: <20141121002937.4f82daea@x23> <20141121095847.11601640@x23> <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" 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, 21 Nov 2014 09:45:39 -0000 On Fri, 21 Nov 2014 09:07:28 +0000 "Robert N. M. Watson" wrote: > > On 21 Nov 2014, at 09:05, Robert N. M. Watson > wrote: > > > To my mind, the only real concern is whether or not you lose access > > to resource allocation limits that would previously have been > > present. On the whole, we've tried to centralise resource > > limitations on kernel memory allocation in UMA, and it would be > > great if we could find a nice approach to implementing both > > per-vimage and per-system allocation limits. One thing I'd pondered > > in the past was whether we could move to a single zone, with its > > own limits/etc, but also the ability to pass an optional > > uma_resourcepool_t that allowed additional limits to be imposed > > based on some other criteria -- e.g., vimage membership. That > > strikes me as a somewhat complex proposal that would bring new > > performance/synchronisation concerns, so isn't necessarily > > something to act on. However, the upshot is that, although I do not > > oppose combining the zones, we should be aware that we're > > eliminating a form of resource partitioning between vimages that we > > may want to find some other solution for (ideally, an elegant one). > > And, to respond to your more general comment: I agree that a decision > about removing the NOFREE flag should be made independently of > choices about devirtualisation. The former probably should be sorted > out at this point, as eliminating NOFREE zones has more general > benefits to the kernel, but it would be nice not to depend on that to > resolve other problems. It could be that a few of us scratching our > heads for a few hours each can resolve whether NOFREE can now be > safely removed, in which case we should do so (and then allow quite a > lot of baking time before it ships in a release). The important thing here is not to loose the momentum and energy which Craig is putting in cleaning up VIMAGE, so if we take the route of eliminating the UMA_ZONE_NOFREE flag (or not), that should be decided with rough consensus and without too much delays, and without too much bikeshed re. what could be nice to have in some distant future and whatnot. The current goal is cleaning up VIMAGE and making it palatable for 11.0, without taking too much risk at breaking other things. I'm strongly opposed to even thinking aloud about any new VNET-related features or concepts until VIMAGE finally becomes enabled in /head. Marko From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 10:19:24 2014 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 9BCD810B; Fri, 21 Nov 2014 10:19:24 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 722AC9CE; Fri, 21 Nov 2014 10:19:24 +0000 (UTC) Received: from [10.108.126.128] (unknown [46.233.116.131]) by cyrus.watson.org (Postfix) with ESMTPSA id 6A0D246B2C; Fri, 21 Nov 2014 05:19:20 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <20141121104538.5eed0567@x23> Date: Fri, 21 Nov 2014 10:19:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8FC3AD80-7605-4D88-BF4E-D33E449B30FF@FreeBSD.org> References: <20141121002937.4f82daea@x23> <20141121095847.11601640@x23> <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> <20141121104538.5eed0567@x23> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" 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, 21 Nov 2014 10:19:24 -0000 On 21 Nov 2014, at 09:45, Marko Zec wrote: >> And, to respond to your more general comment: I agree that a decision >> about removing the NOFREE flag should be made independently of >> choices about devirtualisation. The former probably should be sorted >> out at this point, as eliminating NOFREE zones has more general >> benefits to the kernel, but it would be nice not to depend on that to >> resolve other problems. It could be that a few of us scratching our >> heads for a few hours each can resolve whether NOFREE can now be >> safely removed, in which case we should do so (and then allow quite a >> lot of baking time before it ships in a release). >=20 > The important thing here is not to loose the momentum and energy which > Craig is putting in cleaning up VIMAGE, so if we take the route of > eliminating the UMA_ZONE_NOFREE flag (or not), that should be decided > with rough consensus and without too much delays, and without too much > bikeshed re. what could be nice to have in some distant future and > whatnot. The current goal is cleaning up VIMAGE and making it > palatable for 11.0, without taking too much risk at breaking other > things. I'm strongly opposed to even thinking aloud about any new > VNET-related features or concepts until VIMAGE finally becomes enabled > in /head. In the long list of things that are hard in operating systems, reasoning = about data-structure reference counting and memory models in the = presence of concurrency is pretty high on the list. I think you would = not want to rush that sort of thing, and hence my feeling that you want = to disentangle these two concerns. Throwing the switch on the = UMA_ZONE_NOFREE flag setting is easy, but debugging race conditions = involving use-after-free in the field is incredibly hard. If you can = avoid depending on this, especially if we throw the switch and then = discover in a few weeks or months that it wasn't as simple as we = thought, then you put other more concrete goals substantially less at = risk. We can go away and think hard about UMA_ZONE_NOFREE for a few = weeks, and follow up, but I recommend you find another solution in the = mean time if you are worried about stalling VIMAGE cleanups. Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 10:21:01 2014 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 785C51B3; Fri, 21 Nov 2014 10:21:01 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4E785A6B; Fri, 21 Nov 2014 10:21:01 +0000 (UTC) Received: from [10.108.126.128] (unknown [46.233.116.131]) by cyrus.watson.org (Postfix) with ESMTPSA id 251B046B64; Fri, 21 Nov 2014 05:20:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <8FC3AD80-7605-4D88-BF4E-D33E449B30FF@FreeBSD.org> Date: Fri, 21 Nov 2014 10:20:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8DBEE2B1-3801-4722-B648-BD5B7B04D4C6@FreeBSD.org> References: <20141121002937.4f82daea@x23> <20141121095847.11601640@x23> <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> <20141121104538.5eed0567@x23> <8FC3AD80-7605-4D88-BF4E-D33E449B30FF@FreeBSD.org> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" 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, 21 Nov 2014 10:21:01 -0000 On 21 Nov 2014, at 10:19, Robert N. M. Watson = wrote: >> The important thing here is not to loose the momentum and energy = which >> Craig is putting in cleaning up VIMAGE, so if we take the route of >> eliminating the UMA_ZONE_NOFREE flag (or not), that should be decided >> with rough consensus and without too much delays, and without too = much >> bikeshed re. what could be nice to have in some distant future and >> whatnot. The current goal is cleaning up VIMAGE and making it >> palatable for 11.0, without taking too much risk at breaking other >> things. I'm strongly opposed to even thinking aloud about any new >> VNET-related features or concepts until VIMAGE finally becomes = enabled >> in /head. >=20 > In the long list of things that are hard in operating systems, = reasoning about data-structure reference counting and memory models in = the presence of concurrency is pretty high on the list. I think you = would not want to rush that sort of thing, and hence my feeling that you = want to disentangle these two concerns. Throwing the switch on the = UMA_ZONE_NOFREE flag setting is easy, but debugging race conditions = involving use-after-free in the field is incredibly hard. If you can = avoid depending on this, especially if we throw the switch and then = discover in a few weeks or months that it wasn't as simple as we = thought, then you put other more concrete goals substantially less at = risk. We can go away and think hard about UMA_ZONE_NOFREE for a few = weeks, and follow up, but I recommend you find another solution in the = mean time if you are worried about stalling VIMAGE cleanups. (Alternatively, as I suggested in an earlier e-mail, you can convince us = that you've done that analysis already by citing the revision history = where all the pertinent problems were resolved, along with an informal = argument that no other problems remain, which would mean much less = waiting for us to try to make that argument for you. However, making the = NOFREE change without going through that process is a recipe for = disaster that we'd all rather avoid!) Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 10:37:44 2014 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 0115B5EA; Fri, 21 Nov 2014 10:37:43 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A7FB1BA9; Fri, 21 Nov 2014 10:37:43 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 937EB25D385E; Fri, 21 Nov 2014 10:37:33 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id AF2B1C76FDF; Fri, 21 Nov 2014 10:37:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id LRip8V1tjkoL; Fri, 21 Nov 2014 10:37:31 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BD23BC76FDA; Fri, 21 Nov 2014 10:37:29 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Bjoern A. Zeeb" In-Reply-To: Date: Fri, 21 Nov 2014 10:37:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> References: <20141121002937.4f82daea@x23> To: "Robert N. M. Watson" X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , Marko Zec 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, 21 Nov 2014 10:37:44 -0000 On 21 Nov 2014, at 08:25 , Robert N. M. Watson = wrote: >=20 > On 20 Nov 2014, at 23:29, Marko Zec wrote: >=20 >>> Can folks take a look at this? >>>=20 >>> https://reviews.freebsd.org/D1201 >>=20 >> All UMA zones used in the network stack have been marked as >> UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it might >> not hurt to provide more insight why and how it suddenly became safe = to >> remove that flag? >=20 > Historically, this was (if I recall) a property of the way data was = exported for netstat, which depended on memory stability of various data = types. We have worked quite hard to remove the causes of those sorts of = dependencies by introducing stronger reference and memory ownership = models throughout the stack -- in the case of inpcbs, for example, we = introduced a true reference model during the multiprocessing scalability = work (which, it should be pointed out, was enormously painful and took = years to shake the bugs out of due to complexity/subtlety). It may be = that it is now safe to remove UMA_ZONE_NOFREE for some of the types = where it was previously required -- but it's definitely something you = want to do intentionally and in the context of a careful analysis to = convince yourself that all the causes have been addressed. A fair amount = of stress testing in low-memory conditions wouldn't hurt either... I had convinced myself for UDP many years ago that it was ok to remove = it. People have touched the code however so it=92s definitively worth = re-checking again. For TCP we clearly cannot do it (yet, and couldn=92t back then). But = TCP was the only of the few cases I had left unfixed back then. Can=92t = remember what the others were (was like 3 or 4 of them; could also be = some of the fixes were indeed committed back then. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 10:52:14 2014 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 8BBA38F7; Fri, 21 Nov 2014 10:52:14 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E7EFD54; Fri, 21 Nov 2014 10:52:13 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C817425D3AB1; Fri, 21 Nov 2014 10:52:10 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0511FC76FCE; Fri, 21 Nov 2014 10:52:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id S2Zsv9uDAm70; Fri, 21 Nov 2014 10:52:08 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3AD78C76FE0; Fri, 21 Nov 2014 10:52:06 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE + pf security fix? From: "Bjoern A. Zeeb" In-Reply-To: Date: Fri, 21 Nov 2014 10:52:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 21 Nov 2014 10:52:14 -0000 On 21 Nov 2014, at 08:06 , Craig Rodrigues wrote: > On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues = > wrote: >=20 >> On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb = wrote: >>=20 >>>=20 >>> For people to use pf with VIMAGE we first MUST have the security fix >>> imported that I pointed out a couple of times in the past. >>>=20 >>=20 >> At this link: = http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2010-3830 >>=20 >> I see the security issue mentioned, but I can't find the patch that = fixes >> the problem. >> Where is the patch? >>=20 >=20 > I read this link: > = http://esec-lab.sogeti.com/post/2010/12/09/CVE-2010-3830-iOS-4.2.1-packet-= filter-local-kernel-vulnerability >=20 > and I think this is the fix: > = http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_ioctl.c?rev=3D1.23= 6&content-type=3Dtext/x-cvsweb-markup >=20 > but I can=92t even apply that patch to our pf_ioctl.c. to my best knowledge we have never pulled a fix for this in. The last = =93sync=94 of pf was way before that vulnerability (unless I completely = missed something). =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 10:57:43 2014 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 9595ADF5 for ; Fri, 21 Nov 2014 10:57:43 +0000 (UTC) Received: from fallback7.mail.ru (fallback7.mail.ru [94.100.181.128]) by mx1.freebsd.org (Postfix) with ESMTP id 19CBED9F for ; Fri, 21 Nov 2014 10:57:42 +0000 (UTC) Received: from smtp31.i.mail.ru (smtp31.i.mail.ru [94.100.177.91]) by fallback7.mail.ru (mPOP.Fallback_MX) with ESMTP id 3E91511F28882 for ; Fri, 21 Nov 2014 13:57:34 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=FHIko+6xA+sVqIOjhmBLGAQoIrrH8erGKpFQkF6EeUo=; b=bvCRpvWoh6Tl6wdjh7eoy/2qsZPBu/Ga59V+4A5R99lGFwBRet9VP4UurAR1tq87nVXMZixfEazP4UjSCEcZEEwWCVyfUI+pNZa9HSAFWGzGGELB4XzL/zGqKzqn04Fb7akcpDYGVqWLDqHyG36gRnMckdXTuUDHAmvGZbVzZhU=; Received: from [2001:67c:13e4:1000::37] (port=18986 helo=work.lehis.ru) by smtp31.i.mail.ru with esmtpa (envelope-from ) id 1Xrlu2-0004db-62; Fri, 21 Nov 2014 13:57:26 +0300 Message-ID: <546F1A96.1060309@mail.ru> Date: Fri, 21 Nov 2014 13:57:26 +0300 From: "Alexey V. Panfilov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPMI stops respond if boot in single user mode Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok 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, 21 Nov 2014 10:57:43 -0000 Hi, My IBM System x3250 M5 has IPMI. It shares onboard NIC Broadcom BCM5719. I'm setup it and IPMI works perfectly. But when server boots in single user mode IPMI's IP becomes unreachable. It occures when bge0 init. Any hints? Thanks. Details are: FreeBSD 10.1-STABLE (r274690) amd64 /boot/loader.conf hw.bge.allow_asf=1 bge0: mem 0x82a50000-0x82a5ffff,0x82a40000-0x82a4ffff,0x82a30000-0x82a3ffff irq 16 at device 0.0 on pci6 bge0: APE FW version: NCSI v1.2.33.0 bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Using defaults for TSO: 65518/35/2048 bge0: Ethernet address: 6c:ae:8b:5b:74:98 bge0@pci0:6:0:0: class=0x020000 card=0x04911014 chip=0x165714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe' class = network subclass = ethernet bar [10] = type Prefetchable Memory, range 64, base 0x82a50000, size 65536, enabled bar [18] = type Prefetchable Memory, range 64, base 0x82a40000, size 65536, enabled bar [20] = type Prefetchable Memory, range 64, base 0x82a30000, size 65536, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit enabled with 1 message cap 11[a0] = MSI-X supports 17 messages Table in map 0x20[0x0], PBA in map 0x20[0x1000] cap 10[ac] = PCI-Express 2 endpoint max data 128(256) FLR link x2(x4) speed 5.0(5.0) ASPM disabled(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[13c] = Serial 1 00006cae8b5b7498 ecap 0004[150] = Power Budgeting 1 ecap 0002[160] = VC 1 max VC0 -- Best regards, Alexey V. Panfilov From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 10:58:22 2014 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 ECC11E89 for ; Fri, 21 Nov 2014 10:58:22 +0000 (UTC) Received: from umail.aei.mpg.de (umail.aei.mpg.de [194.94.224.6]) (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 97888DAA for ; Fri, 21 Nov 2014 10:58:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by umail.aei.mpg.de (Postfix) with ESMTP id 92496200581 for ; Fri, 21 Nov 2014 11:49:03 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at aei.mpg.de Received: from umail.aei.mpg.de ([127.0.0.1]) by localhost (umail.aei.mpg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgOmVcGWUfGY for ; Fri, 21 Nov 2014 11:49:03 +0100 (CET) Received: from mailgate.aei.mpg.de (mailgate.aei.mpg.de [194.94.224.5]) by umail.aei.mpg.de (Postfix) with ESMTP id 79BAC20055A for ; Fri, 21 Nov 2014 11:49:03 +0100 (CET) Received: from mailgate.aei.mpg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 30D99405889 for ; Fri, 21 Nov 2014 11:49:03 +0100 (CET) Received: from intranet.aei.uni-hannover.de (ahin1.aei.uni-hannover.de [130.75.117.40]) by mailgate.aei.mpg.de (Postfix) with ESMTP id D81BE406AF1 for ; Fri, 21 Nov 2014 11:49:02 +0100 (CET) Received: from arc.aei.uni-hannover.de ([10.117.15.110]) by intranet.aei.uni-hannover.de (Lotus Domino Release 8.5.3FP6HF1016) with ESMTP id 2014112111485249-15185 ; Fri, 21 Nov 2014 11:48:52 +0100 Date: Fri, 21 Nov 2014 11:48:52 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-net@freebsd.org Subject: igb Could not setup receive structures (again) Message-Id: <20141121114852.8b7d9a6c071c3e0799d5f30c@aei.mpg.de> Organization: Max Planck Gesellschaft X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 21.11.2014 11:48:52, Serialize by Router on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 21.11.2014 11:49:02, Serialize complete at 21.11.2014 11:49:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-PMX-Version: 6.0.2.2308539, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.103919 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, __ANY_URI 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_START 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ' 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, 21 Nov 2014 10:58:23 -0000 Hi all, I get the error message above when trying to go for jumbo frames (mtu 9000) on a system here. I found a lot of comments on this, but they all state that this is due to a too low setting for mbufs in FreeBSD8/9 settings. However, I have 10-stable here, and the settings look rather high to me: kern.ipc.nmbclusters: 1014856 kern.ipc.maxmbufmem: 8313700352 kern.ipc.nmbufs: 6495090 kern.ipc.nmbjumbop: 507428 kern.ipc.nmbjumbo9: 451047 kern.ipc.nmbjumbo16: 338284 FreeBSD mclane 10.0-STABLE FreeBSD 10.0-STABLE #5 r261710: Mon Feb 10 16:55:29 CET 2014 root@mclane.rt.aei.uni-hannover.de:/usr/obj/usr/src/sys/GENERIC amd64 Is this still too low? I have a 6core machine with 6 igb interfaces, and I cannot even get one of these set to mtu 9000 without getting "Could not setup receive structures". cu Gerrit From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 11:02:02 2014 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 2C26DFD3; Fri, 21 Nov 2014 11:02:02 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 857CEE58; Fri, 21 Nov 2014 11:02:00 +0000 (UTC) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 21 Nov 2014 12:01:59 +0100 Date: Fri, 21 Nov 2014 12:02:01 +0100 From: Marko Zec To: "Bjoern A. Zeeb" Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121120201.6c77ea5b@x23> In-Reply-To: <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [161.53.63.210] Cc: Craig Rodrigues , FreeBSD Net , "Robert N. M. Watson" 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, 21 Nov 2014 11:02:02 -0000 On Fri, 21 Nov 2014 10:37:25 +0000 "Bjoern A. Zeeb" wrote: > > On 21 Nov 2014, at 08:25 , Robert N. M. Watson > wrote: > > > > > On 20 Nov 2014, at 23:29, Marko Zec wrote: > > > >>> Can folks take a look at this? > >>> > >>> https://reviews.freebsd.org/D1201 > >> > >> All UMA zones used in the network stack have been marked as > >> UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it > >> might not hurt to provide more insight why and how it suddenly > >> became safe to remove that flag? > > > > Historically, this was (if I recall) a property of the way data was > > exported for netstat, which depended on memory stability of various > > data types. We have worked quite hard to remove the causes of those > > sorts of dependencies by introducing stronger reference and memory > > ownership models throughout the stack -- in the case of inpcbs, for > > example, we introduced a true reference model during the > > multiprocessing scalability work (which, it should be pointed out, > > was enormously painful and took years to shake the bugs out of due > > to complexity/subtlety). It may be that it is now safe to remove > > UMA_ZONE_NOFREE for some of the types where it was previously > > required -- but it's definitely something you want to do > > intentionally and in the context of a careful analysis to convince > > yourself that all the causes have been addressed. A fair amount of > > stress testing in low-memory conditions wouldn't hurt either... > > I had convinced myself for UDP many years ago that it was ok to > remove it. People have touched the code however so it’s definitively > worth re-checking again. > > For TCP we clearly cannot do it (yet, and couldn’t back then). But > TCP was the only of the few cases I had left unfixed back then. > Can’t remember what the others were (was like 3 or 4 of them; could > also be some of the fixes were indeed committed back then. Now that we've found ourselves in this discussion, I'm really becoming curious why exactly do we need UMA_ZONE_NOFREE for network stack zones at all? Admittedly, I always thought that the primary purpose of UMA_ZONE_NOFREE was to prevent uma_reclaim() from paging out _used_ zone pages, but reviewing the uma code reveals that this might not be the case, i.e. that NOFREE only prevents _unused_ pages to be freed by uma_reclaim(). Moreover, all uma_zalloc() calls as far as I can see are flagged as M_NOWAIT and are followed by checks for allocation failures, so that part seems to be covered. So, what's really the problem which UMA_ZONE_NOFREE flagging is supposed to solve these days? (you claim that we clearly need it for TCP - why)? Marko From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 11:22:29 2014 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 C20F8956; Fri, 21 Nov 2014 11:22:29 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 78AEFAE; Fri, 21 Nov 2014 11:22:29 +0000 (UTC) Received: from [10.108.126.128] (unknown [46.233.116.131]) by cyrus.watson.org (Postfix) with ESMTPSA id 8EB8146B85; Fri, 21 Nov 2014 06:22:21 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <20141121120201.6c77ea5b@x23> Date: Fri, 21 Nov 2014 11:22:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <597BD146-88B1-47E6-A373-7004CFF8AEBA@FreeBSD.org> References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> <20141121120201.6c77ea5b@x23> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A. Zeeb" 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, 21 Nov 2014 11:22:30 -0000 On 21 Nov 2014, at 11:02, Marko Zec wrote: > Now that we've found ourselves in this discussion, I'm really > becoming curious why exactly do we need UMA_ZONE_NOFREE for network > stack zones at all? Admittedly, I always thought that the primary > purpose of UMA_ZONE_NOFREE was to prevent uma_reclaim() from paging = out > _used_ zone pages, but reviewing the uma code reveals that this might > not be the case, i.e. that NOFREE only prevents _unused_ pages to be > freed by uma_reclaim(). >=20 > Moreover, all uma_zalloc() calls as far as I can see are flagged as > M_NOWAIT and are followed by checks for allocation failures, so that > part seems to be covered. >=20 > So, what's really the problem which UMA_ZONE_NOFREE flagging is = supposed > to solve these days? (you claim that we clearly need it for TCP - = why)? UMA_ZONE_NOFREE tells UMA that it can't reclaim unused slabs for the = zone to be returned to the VM system for reuse elsewhere under memory = pressure. UMA memory isn't pageable, so there's no link to paging = policy: although soft-TLB systems might experience TLB miss exceptions = on UMA-allocated kernel memory, you should never experience a page fault = against it (in absence of a bug). Reclaim of unused slabs can happen, = for example, if VM discovers it is low on free pages, in which case it = notifies various kernel subsystems that it is feeling a bit cramped -- = that same mechanism that, for example, triggers TCP to throw away = reassembly buffers that haven't yet been ACK'd (although might have been = SACK'd). You might expect this to happen in situations where first a = large load spike happens for a particular UMA type (e.g., a DDoS opens = lots of TCP connections), and then they are freed, leading to lots of = socket/incpb slabs lying around unused, which eventually VM will ask be = returned. It is highly desirable for UMA_ZONE_NOFREE to be removed from = zones wherever possible so that memory can be returned under such = circumstances, and it is not a good feature that the flag is present = anywhere. Subsystems pick up a dependence on UMA_ZONE_NOFREE if freed objects = might be referenced after free. My understanding is that this is pretty = old inherited behaviour from prior kernel memory allocators that didn't = know how to return memory to VM. Given that property, it was safe to = write code that might, for the purposes of efficiency, assume that it = could walk data structures of the type with fewer synchronisation = overheads -- or where synchronisation isn't possible (e.g., for direct = access to kernel memory via /dev/kmem). We have been attempting to = expunge those assumptions wherever possible -- these days, netstat uses = sysctl()s that acquire references to all live inpcbs keeping them valid = while they are copied out (you can't hold low-level locks during = copyout() as sysctl might encounter a paging event writing to user = memory). Convincing yourself that all such assumptions have been removed = is a moderate amount of work, and if you get it wrong, you get = use-after-free races that occur only in low-memory conditions, which are = quite hard to figure out (read: almost impossible). Bjoern can say more about what motivated his specific comment -- I had = hoped that we'd quietly lost dependence on NOFREE over the last decade = and could finally garbage collect it, but perhaps not! Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 11:28:06 2014 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 1B266B33; Fri, 21 Nov 2014 11:28:06 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7D40ED; Fri, 21 Nov 2014 11:28:05 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C55FB25D3892; Fri, 21 Nov 2014 11:28:02 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 02184C76FE0; Fri, 21 Nov 2014 11:28:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id oS7gXTuralSA; Fri, 21 Nov 2014 11:28:00 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D3303C76FD9; Fri, 21 Nov 2014 11:27:59 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: IPsec is very broken... From: "Bjoern A. Zeeb" In-Reply-To: <20141120213526.GH24601@funkthat.com> Date: Fri, 21 Nov 2014 11:27:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <785031F3-7563-4314-A9A5-79666723C3E2@lists.zabbadoz.net> References: <20141120213526.GH24601@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@FreeBSD.org, freebsd-security@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: Fri, 21 Nov 2014 11:28:06 -0000 On 20 Nov 2014, at 21:35 , John-Mark Gurney wrote: > The first major issue I ran across was transport mode... ae@ has been > nice enough to get ICMP working in transport mode for IPv4 and IPv6, > but it looks like TCP is still broken. I haven't tested UDP yet... > So, IPsec even w/o crypto is fundamentally broken here... It's clear > that not many people run transport mode=85 Or that some people lately broke the code. > If someone could create a good test suite that ensures makes sure = basic > IPsec traffic passes, that would be a huge win for us. The tests > should test a complete cross product of: { tunnel, transport } x > { TCP, UDP, ICMP, any others? } x { IPv4, IPv6 }. Please add to this > list. + SCTP + IPcomp + IPv4/IPv6 mixes inside/outside + properly working = enc(4) If you get all that then add IPIP (gif) and GRE on the inside as well. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 15:01:20 2014 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 BCCEA4CA; Fri, 21 Nov 2014 15:01:20 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 95AEDC05; Fri, 21 Nov 2014 15:01:20 +0000 (UTC) Received: from c0198.aw.cl.cam.ac.uk (c0198.aw.cl.cam.ac.uk [128.232.100.198]) by cyrus.watson.org (Postfix) with ESMTPSA id F3EE946B3F; Fri, 21 Nov 2014 10:01:15 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <20141121120201.6c77ea5b@x23> Date: Fri, 21 Nov 2014 15:01:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> <20141121120201.6c77ea5b@x23> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A. Zeeb" 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, 21 Nov 2014 15:01:20 -0000 On 21 Nov 2014, at 11:02, Marko Zec wrote: >> I had convinced myself for UDP many years ago that it was ok to >> remove it. People have touched the code however so it=92s = definitively >> worth re-checking again. >>=20 >> For TCP we clearly cannot do it (yet, and couldn=92t back then). = But >> TCP was the only of the few cases I had left unfixed back then. >> Can=92t remember what the others were (was like 3 or 4 of them; = could >> also be some of the fixes were indeed committed back then. >=20 > Now that we've found ourselves in this discussion, I'm really > becoming curious why exactly do we need UMA_ZONE_NOFREE for network > stack zones at all? Admittedly, I always thought that the primary > purpose of UMA_ZONE_NOFREE was to prevent uma_reclaim() from paging = out > _used_ zone pages, but reviewing the uma code reveals that this might > not be the case, i.e. that NOFREE only prevents _unused_ pages to be > freed by uma_reclaim(). >=20 > Moreover, all uma_zalloc() calls as far as I can see are flagged as > M_NOWAIT and are followed by checks for allocation failures, so that > part seems to be covered. >=20 > So, what's really the problem which UMA_ZONE_NOFREE flagging is = supposed > to solve these days? (you claim that we clearly need it for TCP - = why)? Bjoern and I chatted for the last twenty or so minutes about the code, = and believe that as things stand, it is *not* safe to turn off = UMA_ZONE_NOFREE for TCP due to a teardown race in TCP that has been = known about and discussed for several years, but is some work to resolve = and that we've not yet found time to do so. The XXXRW's in tcp_timer.c = are related to this. We're pondering ways to fix it but think this is = not something that can be rushed. Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 15:20:50 2014 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 9E817B7E; Fri, 21 Nov 2014 15:20:50 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F6CDE27; Fri, 21 Nov 2014 15:20:49 +0000 (UTC) Received: from x23 (31.147.127.91) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 21 Nov 2014 16:20:40 +0100 Date: Fri, 21 Nov 2014 16:20:42 +0100 From: Marko Zec To: "Robert N. M. Watson" Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121162042.449b22dc@x23> In-Reply-To: References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> <20141121120201.6c77ea5b@x23> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [31.147.127.91] Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A. Zeeb" 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, 21 Nov 2014 15:20:50 -0000 On Fri, 21 Nov 2014 15:01:13 +0000 "Robert N. M. Watson" wrote: > > On 21 Nov 2014, at 11:02, Marko Zec wrote: > > >> I had convinced myself for UDP many years ago that it was ok to > >> remove it. People have touched the code however so it’s > >> definitively worth re-checking again. > >> > >> For TCP we clearly cannot do it (yet, and couldn’t back then). > >> But TCP was the only of the few cases I had left unfixed back then. > >> Can’t remember what the others were (was like 3 or 4 of them; > >> could also be some of the fixes were indeed committed back then. > > > > Now that we've found ourselves in this discussion, I'm really > > becoming curious why exactly do we need UMA_ZONE_NOFREE for network > > stack zones at all? Admittedly, I always thought that the primary > > purpose of UMA_ZONE_NOFREE was to prevent uma_reclaim() from paging > > out _used_ zone pages, but reviewing the uma code reveals that this > > might not be the case, i.e. that NOFREE only prevents _unused_ > > pages to be freed by uma_reclaim(). > > > > Moreover, all uma_zalloc() calls as far as I can see are flagged as > > M_NOWAIT and are followed by checks for allocation failures, so that > > part seems to be covered. > > > > So, what's really the problem which UMA_ZONE_NOFREE flagging is > > supposed to solve these days? (you claim that we clearly need it > > for TCP - why)? > > Bjoern and I chatted for the last twenty or so minutes about the > code, and believe that as things stand, it is *not* safe to turn off > UMA_ZONE_NOFREE for TCP due to a teardown race in TCP that has been > known about and discussed for several years, but is some work to > resolve and that we've not yet found time to do so. The XXXRW's in > tcp_timer.c are related to this. We're pondering ways to fix it but > think this is not something that can be rushed. OK fair enough - thanks a lot for looking into this! Skimming through a bunch of hosts with moderately loaded hosts with reasonably high uptime I couldn't find one where net.inet.tcp.timer_race was not zero. A ny suggestions how to best reproduce the race(s) in tcp_timer.c? Marko From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 15:32:58 2014 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 86082FE; Fri, 21 Nov 2014 15:32:58 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5C11FF57; Fri, 21 Nov 2014 15:32:58 +0000 (UTC) Received: from c0198.aw.cl.cam.ac.uk (c0198.aw.cl.cam.ac.uk [128.232.100.198]) by cyrus.watson.org (Postfix) with ESMTPSA id B18BF46B2A; Fri, 21 Nov 2014 10:32:56 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <20141121162042.449b22dc@x23> Date: Fri, 21 Nov 2014 15:32:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <072B7B0F-4DE3-4D37-BC94-1DEA38CF3B12@FreeBSD.org> References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> <20141121120201.6c77ea5b@x23> <20141121162042.449b22dc@x23> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A. Zeeb" 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, 21 Nov 2014 15:32:58 -0000 On 21 Nov 2014, at 15:20, Marko Zec wrote: >> Bjoern and I chatted for the last twenty or so minutes about the >> code, and believe that as things stand, it is *not* safe to turn off >> UMA_ZONE_NOFREE for TCP due to a teardown race in TCP that has been >> known about and discussed for several years, but is some work to >> resolve and that we've not yet found time to do so. The XXXRW's in >> tcp_timer.c are related to this. We're pondering ways to fix it but >> think this is not something that can be rushed. >=20 > OK fair enough - thanks a lot for looking into this! >=20 > Skimming through a bunch of hosts with moderately loaded hosts with > reasonably high uptime I couldn't find one where = net.inet.tcp.timer_race > was not zero. A ny suggestions how to best reproduce the race(s) in > tcp_timer.c? They would likely occur only on very highly loaded hosts, as they = require race conditions to arise between TCP timers and TCP close. I = think I did manage to reproduce it at one stage, and left the counter in = to see if we could spot it in production, and I have had (multiple) = reports of it in deployed systems. I'm not sure it's worth trying to = reproduce them, given that knowledge -- we should simply fix them. Robert= From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 15:58:43 2014 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 AAC8BCC9; Fri, 21 Nov 2014 15:58:43 +0000 (UTC) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 62ACA21C; Fri, 21 Nov 2014 15:58:43 +0000 (UTC) Received: from mx.elandsys.com (IDENT:logan@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id sALFweOF008023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 07:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1416585521; x=1416671921; bh=GUTTJGAZaS3KWrR2LQmcTiY1Gvfb/C7LGwVwlD/eLnw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=j8hEZBV8UvlULwgCiamh3qGNiLnoRTTEj6Mgng5zbiD1WYxUF5EzzDL56H5l8fk6U 4/RzUCxcZAiTkRE3HJpK5E9ERcjJImZD7cT4f7PlqCEIrbi6xNhiMu1CZMFhh49gN+ Pxf/tNbOZnnMt++ucoYkxnE7gU2BWHFu6zsefL/w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1416585521; x=1416671921; i=@elandsys.com; bh=GUTTJGAZaS3KWrR2LQmcTiY1Gvfb/C7LGwVwlD/eLnw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UEidzyoOco0RtOHoWObL3Eyvb2Qr5eKUZhcf2bVU9SgUoPv3Ux6YF6+vuBTnF0unc zCzAs1ifbwWPdcwt/URkaIfqVfWuj+gtd8UdBVYuw5V0Ksj3VMa+SOGE976ZI4Z9GV uzKw1FIWz80VBAMJfDyMRM2S+x36VScaG1Uq5tBM= Received: (from logan@localhost) by mx.elandsys.com (8.14.5/8.14.5/Submit) id sALFwd0Z016967; Fri, 21 Nov 2014 07:58:39 -0800 (PST) X-Authentication-Warning: mx.elandsys.com: logan set sender to logan@elandsys.com using -f Date: Fri, 21 Nov 2014 07:58:39 -0800 From: Loganaden Velvindron To: "Bjoern A. Zeeb" Subject: Re: VIMAGE + pf security fix? Message-ID: <20141121155839.GA15001@mx.elandsys.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 21 Nov 2014 15:58:43 -0000 On Fri, Nov 21, 2014 at 10:52:05AM +0000, Bjoern A. Zeeb wrote: > > On 21 Nov 2014, at 08:06 , Craig Rodrigues wrote: > > > On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues > > wrote: > > > >> On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote: > >> > >>> > >>> For people to use pf with VIMAGE we first MUST have the security fix > >>> imported that I pointed out a couple of times in the past. > >>> > >> > >> At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830 > >> > >> I see the security issue mentioned, but I can't find the patch that fixes > >> the problem. > >> Where is the patch? > >> > > > > I read this link: > > http://esec-lab.sogeti.com/post/2010/12/09/CVE-2010-3830-iOS-4.2.1-packet-filter-local-kernel-vulnerability > > > > and I think this is the fix: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_ioctl.c?rev=1.236&content-type=text/x-cvsweb-markup > > > > but I can?t even apply that patch to our pf_ioctl.c. > > to my best knowledge we have never pulled a fix for this in. The last ?sync? of pf was way before that vulnerability (unless I completely missed something). I'd be interested in helping to fix this, as I depend on this. > > ? > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 > > _______________________________________________ > 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 Fri Nov 21 16:22:36 2014 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 A7DBAAED for ; Fri, 21 Nov 2014 16:22:36 +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 3949C783 for ; Fri, 21 Nov 2014 16:22:36 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id l15so9442803wiw.10 for ; Fri, 21 Nov 2014 08:22:33 -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=dSWxNvIJMZQ20mtMtp9k3tEhrSMAUp2o7nIU7+fLSus=; b=R+yUxHXpMCk2L9/1QWyaXnsrRAKZ3I87jnbyXQZtHvIMb01BAl1+3ypQBInhSovZT1 cfG6JK8Q+FgrJTxm1Fsm6E0XzIYgpAKcu4jHjFSjX9Ky4qtDqUw0WYpJMxnhzKMA4GUV 8vjWKmqOAIMPcW0DWLTCDsJD8fGiQ9YBpEMvjH2zRvffBwIDfK0bz9B0XWJzGSm4Xc46 TQjGi21K1vPSqf4pQy49N0B1xQiT9kFZxGH4jGXt2EgvRTNHT9nnPRSrvCRlkl14hzV8 +PuwUaTOV16iA6TD9/uoUdgmZiG4gDI5Cs6vPOO1nBCrt+0xY3oePF4pVMTxrICPz/sS Sn8Q== MIME-Version: 1.0 X-Received: by 10.180.92.234 with SMTP id cp10mr16020794wib.16.1416586951731; Fri, 21 Nov 2014 08:22:31 -0800 (PST) Received: by 10.194.76.34 with HTTP; Fri, 21 Nov 2014 08:22:31 -0800 (PST) In-Reply-To: <20141121114852.8b7d9a6c071c3e0799d5f30c@aei.mpg.de> References: <20141121114852.8b7d9a6c071c3e0799d5f30c@aei.mpg.de> Date: Fri, 21 Nov 2014 08:22:31 -0800 Message-ID: Subject: Re: igb Could not setup receive structures (again) From: Jack Vogel To: =?ISO-8859-1?Q?Gerrit_K=FChn?= Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 21 Nov 2014 16:22:36 -0000 The message is pretty straightforward, its only cause is the inability of the driver to get the necessary clusters to populate the RX rings. After you get the error do a `netstat -m` and see what the state of the 9K jumbo pool is, for that is the size you would be using. Depending on the specific device type you may have up to 8 rings per interface, and with a ring size of 1K... It does seem like you should have enough, but maybe something else in your system is using the pool? As I said, look at netstat, it should giv= e you the truth, and then adjust the allocated size to fit your needs. Jack On Fri, Nov 21, 2014 at 2:48 AM, Gerrit K=FChn wrote: > Hi all, > > I get the error message above when trying to go for jumbo frames (mtu > 9000) on a system here. I found a lot of comments on this, but they all > state that this is due to a too low setting for mbufs in FreeBSD8/9 > settings. > However, I have 10-stable here, and the settings look rather high to me: > > kern.ipc.nmbclusters: 1014856 > kern.ipc.maxmbufmem: 8313700352 > kern.ipc.nmbufs: 6495090 > kern.ipc.nmbjumbop: 507428 > kern.ipc.nmbjumbo9: 451047 > kern.ipc.nmbjumbo16: 338284 > > FreeBSD mclane 10.0-STABLE FreeBSD 10.0-STABLE #5 r261710: Mon Feb 10 > 16:55:29 CET 2014 root@mclane.rt.aei.uni-hannover.de:/usr/obj/usr/src/sys= /GENERIC > amd64 > > > Is this still too low? I have a 6core machine with 6 igb interfaces, and = I > cannot even get one of these set to mtu 9000 without getting "Could not > setup receive structures". > > > cu > Gerrit > _______________________________________________ > 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 Fri Nov 21 17:33:21 2014 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 2B69FE99 for ; Fri, 21 Nov 2014 17:33:21 +0000 (UTC) Received: from umail.aei.mpg.de (umail.aei.mpg.de [194.94.224.6]) (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 9E07EF9C for ; Fri, 21 Nov 2014 17:33:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by umail.aei.mpg.de (Postfix) with ESMTP id 32F9C20074D; Fri, 21 Nov 2014 18:33:17 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at aei.mpg.de Received: from umail.aei.mpg.de ([127.0.0.1]) by localhost (umail.aei.mpg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6tPB4JZZrSD; Fri, 21 Nov 2014 18:33:17 +0100 (CET) Received: from mailgate.aei.mpg.de (mailgate.aei.mpg.de [194.94.224.5]) by umail.aei.mpg.de (Postfix) with ESMTP id 0D73F20074A; Fri, 21 Nov 2014 18:33:17 +0100 (CET) Received: from mailgate.aei.mpg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F2B47405889; Fri, 21 Nov 2014 18:33:16 +0100 (CET) Received: from intranet.aei.uni-hannover.de (ahin1.aei.uni-hannover.de [130.75.117.40]) by mailgate.aei.mpg.de (Postfix) with ESMTP id C43B3406AF1; Fri, 21 Nov 2014 18:33:16 +0100 (CET) Received: from arc.aei.uni-hannover.de ([10.117.15.110]) by intranet.aei.uni-hannover.de (Lotus Domino Release 8.5.3FP6HF1016) with ESMTP id 2014112118330659-15686 ; Fri, 21 Nov 2014 18:33:06 +0100 Date: Fri, 21 Nov 2014 18:33:06 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jack Vogel Subject: Re: igb Could not setup receive structures (again) Message-Id: <20141121183306.d057ff1743e2a1e04ae55f93@aei.mpg.de> In-Reply-To: References: <20141121114852.8b7d9a6c071c3e0799d5f30c@aei.mpg.de> Organization: Max Planck Gesellschaft X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 21.11.2014 18:33:06, Serialize by Router on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 21.11.2014 18:33:16, Serialize complete at 21.11.2014 18:33:16 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-PMX-Version: 6.0.2.2308539, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.172719 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ' 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: Fri, 21 Nov 2014 17:33:21 -0000 On Fri, 21 Nov 2014 08:22:31 -0800 Jack Vogel wrote about Re: igb Could not setup receive structures (again): JV> After you get the error do a `netstat -m` and see what the state of the JV> 9K jumbo pool is, for that is the size you would be using. Hm... --- root@mclane:~ # netstat -m 20472/33783/54255 mbufs in use (current/cache/total) 20461/31381/51842/1014856 mbuf clusters in use (current/cache/total/max) 20461/29764 mbuf+clusters out of packet secondary zone in use (current/cache) 0/191/191/507428 4k (page size) jumbo clusters in use (current/cache/total/max) 0/3425/3425/150349 9k jumbo clusters in use (current/cache/total/max) 0/0/0/84571 16k jumbo clusters in use (current/cache/total/max) 46040K/102796K/148836K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/10/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile root@mclane:~ # ifconfig igb1 mtu 9000 root@mclane:~ # netstat -m 16373/37882/54255 mbufs in use (current/cache/total) 16369/35473/51842/1014856 mbuf clusters in use (current/cache/total/max) 16369/33856 mbuf+clusters out of packet secondary zone in use (current/cache) 0/191/191/507428 4k (page size) jumbo clusters in use (current/cache/total/max) 0/3425/3425/150349 9k jumbo clusters in use (current/cache/total/max) 0/0/0/84571 16k jumbo clusters in use (current/cache/total/max) 36831K/112005K/148836K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/12/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile --- JV> Depending on the specific device type you may have up to 8 rings JV> per interface, and with a ring size of 1K... JV> It does seem like you should have enough, but maybe something else JV> in your system is using the pool? As I said, look at netstat, it JV> should give you the truth, and then adjust the allocated size to fit JV> your needs. I must admit that I cannot make much of this output... looks all fine to me? cu Gerrit From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 17:40:32 2014 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 838816D0; Fri, 21 Nov 2014 17:40:32 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 0FE2212; Fri, 21 Nov 2014 17:40:32 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id b13so7228730wgh.18 for ; Fri, 21 Nov 2014 09:40:29 -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=aq4Ls6SifHN5qltdps2kYF4R97tTeQt6JfZK1rSYKWU=; b=EkLv+OlPfp+B18HyMoXI/dIAUHKRzzdSeIvnZQrBKi9UbQnXiHpftcUy5AJWXzk+8R +gEAYb0KYcQVD4/2PUw/0X9O0CDKfKeXr3tRLbpYlfclA8lVL2nk2CsACKxjo2+xlut0 Z8kXF2Xg7AUO8iYuo/0rEcKjM11IgHbgDgmKbhEcBfwqNVePHS9gi6H+ORXk9ohjLFOd wmgGEtqQGSrQ95AERmodMn0qaZHasWr2FrRozicANI1QK4khEPw72TE6M7Zen15qmy+g nuRn6hQp+NL6J5AIkrP18FZ7LCr5Rz8aRfihwxL+bUxbM0OjWDMwzc6CvoKE+3Dh50yE U7Vg== MIME-Version: 1.0 X-Received: by 10.194.80.100 with SMTP id q4mr9886754wjx.15.1416591627754; Fri, 21 Nov 2014 09:40:27 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 21 Nov 2014 09:40:27 -0800 (PST) In-Reply-To: <072B7B0F-4DE3-4D37-BC94-1DEA38CF3B12@FreeBSD.org> References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> <20141121120201.6c77ea5b@x23> <20141121162042.449b22dc@x23> <072B7B0F-4DE3-4D37-BC94-1DEA38CF3B12@FreeBSD.org> Date: Fri, 21 Nov 2014 09:40:27 -0800 X-Google-Sender-Auth: chQnu6RMPUxTN6Gkm2aGhZ7pz68 Message-ID: Subject: Re: VIMAGE UDP memory leak fix From: Adrian Chadd To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A. Zeeb" , Marko Zec 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, 21 Nov 2014 17:40:32 -0000 On 21 November 2014 07:32, Robert N. M. Watson wrote: > > On 21 Nov 2014, at 15:20, Marko Zec wrote: > >>> Bjoern and I chatted for the last twenty or so minutes about the >>> code, and believe that as things stand, it is *not* safe to turn off >>> UMA_ZONE_NOFREE for TCP due to a teardown race in TCP that has been >>> known about and discussed for several years, but is some work to >>> resolve and that we've not yet found time to do so. The XXXRW's in >>> tcp_timer.c are related to this. We're pondering ways to fix it but >>> think this is not something that can be rushed. >> >> OK fair enough - thanks a lot for looking into this! >> >> Skimming through a bunch of hosts with moderately loaded hosts with >> reasonably high uptime I couldn't find one where net.inet.tcp.timer_race >> was not zero. A ny suggestions how to best reproduce the race(s) in >> tcp_timer.c? > > They would likely occur only on very highly loaded hosts, as they require= race conditions to arise between TCP timers and TCP close. I think I did m= anage to reproduce it at one stage, and left the counter in to see if we co= uld spot it in production, and I have had (multiple) reports of it in deplo= yed systems. I'm not sure it's worth trying to reproduce them, given that k= nowledge -- we should simply fix them. > Wasn't this just fixed by Julien @ Verisign? As for the vimage stability side of things - I'd really like to see some VIMAGE torture tests written. Stuff like "do a high rate TCP connection test whilst creating and destroying VIMAGEs." -adrian From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 20:58:48 2014 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 EA185520 for ; Fri, 21 Nov 2014 20:58:48 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 6D9FAAE1 for ; Fri, 21 Nov 2014 20:58:48 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id l18so7447856wgh.26 for ; Fri, 21 Nov 2014 12:58:46 -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=ju2FayDWYjdLXEo/zg6VIcvppgvKNwnKSwrLYtmzA4I=; b=riUYAI0QbnoClSVLeaFxqQK0x6SJmWQnYeGykvphtTlIUvd7mPwAgJFqtzhCnRr+Aa RPhS8RtuSDWYQ0du03m3bsMmcGMW40a+h99AWEy4jcS0tLkSuaHh3tfXprODmX50opyQ hI1KTSAmZfbxvM9lJaxjSSthKTx6/n89P0m+7nvsSPBF/uGnZV9hXdd0xmlt9zZgqP4d g6BOeYdAGsyhWN8RXde4WMXuQ7j/Zv6BYmncDZYSQX7PWPyXWR6xR3JnkNaGk+1GWgMd H69M0c6l1KIFg0J7Ot3ZqznUvQ/Vx4x5wCHCYb5N77K16xxwzyr8RrUnh/J46Wrp8aw+ adHg== MIME-Version: 1.0 X-Received: by 10.180.99.1 with SMTP id em1mr286487wib.29.1416603526831; Fri, 21 Nov 2014 12:58:46 -0800 (PST) Received: by 10.194.76.34 with HTTP; Fri, 21 Nov 2014 12:58:46 -0800 (PST) In-Reply-To: <4a92a47b86474b92b5b4fd7601df9cc2@BLUPR0801MB674.namprd08.prod.outlook.com> References: <20141121114852.8b7d9a6c071c3e0799d5f30c@aei.mpg.de> <4a92a47b86474b92b5b4fd7601df9cc2@BLUPR0801MB674.namprd08.prod.outlook.com> Date: Fri, 21 Nov 2014 12:58:46 -0800 Message-ID: Subject: Re: igb Could not setup receive structures (again) From: Jack Vogel To: David DeSimone Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 21 Nov 2014 20:58:49 -0000 The driver does not calculate what it needs, it just keeps taking :) Hmmm, well it would be difficult to calculate a real total, as each instance of the driver (one per port) has no idea about other instances. I suppose there could be a display of the total needed per port? Jack On Fri, Nov 21, 2014 at 12:34 PM, David DeSimone wrote: > Would it be possible for the driver to report how many clusters it > calculated that it needs, whenever it runs into this memory shortage duri= ng > attach? That way an administrator might have some idea how much to > increase their tunables in order to meet the driver's requirements. > > As it is, it's merely a guessing game or requires digging into driver > source to come up with the right numbers. > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org= ] > On Behalf Of Jack Vogel > Sent: Friday, November 21, 2014 10:23 AM > To: Gerrit K=FChn > Cc: FreeBSD Net > Subject: Re: igb Could not setup receive structures (again) > > The message is pretty straightforward, its only cause is the inability > of the driver to get the necessary clusters to populate the RX rings. > > After you get the error do a `netstat -m` and see what the state of the > 9K jumbo pool is, for that is the size you would be using. > > Depending on the specific device type you may have up to 8 rings > per interface, and with a ring size of 1K... > > It does seem like you should have enough, but maybe something else > in your system is using the pool? As I said, look at netstat, it should > give > you the truth, and then adjust the allocated size to fit your needs. > > Jack > > > On Fri, Nov 21, 2014 at 2:48 AM, Gerrit K=FChn > wrote: > > > Hi all, > > > > I get the error message above when trying to go for jumbo frames (mtu > > 9000) on a system here. I found a lot of comments on this, but they all > > state that this is due to a too low setting for mbufs in FreeBSD8/9 > > settings. > > However, I have 10-stable here, and the settings look rather high to me= : > > > > kern.ipc.nmbclusters: 1014856 > > kern.ipc.maxmbufmem: 8313700352 > > kern.ipc.nmbufs: 6495090 > > kern.ipc.nmbjumbop: 507428 > > kern.ipc.nmbjumbo9: 451047 > > kern.ipc.nmbjumbo16: 338284 > > > > FreeBSD mclane 10.0-STABLE FreeBSD 10.0-STABLE #5 r261710: Mon Feb 10 > > 16:55:29 CET 2014 root@mclane.rt.aei.uni-hannover.de: > /usr/obj/usr/src/sys/GENERIC > > amd64 > > > > > > Is this still too low? I have a 6core machine with 6 igb interfaces, an= d > I > > cannot even get one of these set to mtu 9000 without getting "Could not > > setup receive structures". > > > > > > cu > > Gerrit > > _______________________________________________ > > 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" > This email message is intended for the use of the person to whom it has > been sent, and may contain information that is confidential or legally > protected. If you are not the intended recipient or have received this > message in error, you are not authorized to copy, distribute, or otherwis= e > use this message or its attachments. Please notify the sender immediately > by return e-mail and permanently delete this message and any attachments. > Verio Inc. makes no warranty that this email is error or virus free. Than= k > you. > From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 21:01:26 2014 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 4594F681 for ; Fri, 21 Nov 2014 21:01:26 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 BED10B9E for ; Fri, 21 Nov 2014 21:01:25 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so7568357wgg.36 for ; Fri, 21 Nov 2014 13:01:23 -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=/ysosHi00YHKKEodxE6WieKYUSfmlYt01c/gO1pNv8I=; b=qt5DXlEoMKcyTT+95JlOZEEmw679huqNE2er+yb0kwoyY7oIcP5+T2a2V9/2jwQd9T GrZRCyZfvSFqkPl8gz1JWXw9Hx2BcbGSq6Di5Z2V+3kYUn1LltT1TP1mR0B3SAVf71Qz Rr9PDLdCDkIysPLCmSZklq0PktU8yVAhw1bsIT4c2VaqAmSclba0ltBGFdH54H5T81Tq YMnC3rysPkelNTPF7M7LEz4+Hi84keXa7aModzGDihA6o2BNrK0TaytyZoLKaoSZHY+N OPaTgNZZvU0NokrjCPuXiM8iEdDd96o4xyGUEnECgtZiXnB+4g0XFPRHCiyGhfSDFEp3 P76Q== MIME-Version: 1.0 X-Received: by 10.180.99.1 with SMTP id em1mr303049wib.29.1416603683769; Fri, 21 Nov 2014 13:01:23 -0800 (PST) Received: by 10.194.76.34 with HTTP; Fri, 21 Nov 2014 13:01:23 -0800 (PST) In-Reply-To: <20141121183306.d057ff1743e2a1e04ae55f93@aei.mpg.de> References: <20141121114852.8b7d9a6c071c3e0799d5f30c@aei.mpg.de> <20141121183306.d057ff1743e2a1e04ae55f93@aei.mpg.de> Date: Fri, 21 Nov 2014 13:01:23 -0800 Message-ID: Subject: Re: igb Could not setup receive structures (again) From: Jack Vogel To: =?ISO-8859-1?Q?Gerrit_K=FChn?= Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 21 Nov 2014 21:01:26 -0000 Yes, its strange, the mbuf resources look fine. Can you show the dmesg record from a boot that includes the failure please? Jack On Fri, Nov 21, 2014 at 9:33 AM, Gerrit K=FChn wrote: > On Fri, 21 Nov 2014 08:22:31 -0800 Jack Vogel wrote > about Re: igb Could not setup receive structures (again): > > JV> After you get the error do a `netstat -m` and see what the state of t= he > JV> 9K jumbo pool is, for that is the size you would be using. > > Hm... > > --- > root@mclane:~ # netstat -m > 20472/33783/54255 mbufs in use (current/cache/total) > 20461/31381/51842/1014856 mbuf clusters in use (current/cache/total/max) > 20461/29764 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/191/191/507428 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/3425/3425/150349 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/84571 16k jumbo clusters in use (current/cache/total/max) > 46040K/102796K/148836K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/10/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > > root@mclane:~ # ifconfig igb1 mtu 9000 > > root@mclane:~ # netstat -m > 16373/37882/54255 mbufs in use (current/cache/total) > 16369/35473/51842/1014856 mbuf clusters in use (current/cache/total/max) > 16369/33856 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/191/191/507428 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/3425/3425/150349 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/84571 16k jumbo clusters in use (current/cache/total/max) > 36831K/112005K/148836K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/12/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > > --- > > > JV> Depending on the specific device type you may have up to 8 rings > JV> per interface, and with a ring size of 1K... > JV> It does seem like you should have enough, but maybe something else > JV> in your system is using the pool? As I said, look at netstat, it > JV> should give you the truth, and then adjust the allocated size to fit > JV> your needs. > > I must admit that I cannot make much of this output... looks all fine to > me? > > > cu > Gerrit > From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 21:05:48 2014 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 8D8338F2 for ; Fri, 21 Nov 2014 21:05:48 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0056.outbound.protection.outlook.com [65.55.169.56]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (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 47343BDE for ; Fri, 21 Nov 2014 21:05:47 +0000 (UTC) Received: from BLUPR0801MB674.namprd08.prod.outlook.com (10.141.255.11) by BLUPR0801MB673.namprd08.prod.outlook.com (10.141.254.27) with Microsoft SMTP Server (TLS) id 15.1.26.15; Fri, 21 Nov 2014 20:34:03 +0000 Received: from BLUPR0801MB674.namprd08.prod.outlook.com ([10.141.255.11]) by BLUPR0801MB674.namprd08.prod.outlook.com ([10.141.255.11]) with mapi id 15.01.0026.003; Fri, 21 Nov 2014 20:34:03 +0000 From: David DeSimone To: Jack Vogel Subject: RE: igb Could not setup receive structures (again) Thread-Topic: igb Could not setup receive structures (again) Thread-Index: AQHQBXofby0q0CluWU+mfdV7RVj30JxrQ76AgABFyGA= Date: Fri, 21 Nov 2014 20:34:03 +0000 Message-ID: <4a92a47b86474b92b5b4fd7601df9cc2@BLUPR0801MB674.namprd08.prod.outlook.com> References: <20141121114852.8b7d9a6c071c3e0799d5f30c@aei.mpg.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.74.209.33] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR0801MB673; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR0801MB673; x-forefront-prvs: 0402872DA1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(53754006)(189002)(377454003)(24454002)(51704005)(13464003)(199003)(51884002)(97736003)(108616004)(40100003)(95666004)(105586002)(106116001)(106356001)(31966008)(122556002)(99396003)(15202345003)(77156002)(62966003)(99286002)(4396001)(21056001)(1411001)(107046002)(92566001)(66066001)(33646002)(110136001)(120916001)(46102003)(101416001)(76576001)(19580405001)(19580395003)(87936001)(2656002)(50986999)(86362001)(20776003)(64706001)(74316001)(76176999)(15975445006)(54356999)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0801MB673; H:BLUPR0801MB674.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: verio.net 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: Fri, 21 Nov 2014 21:05:48 -0000 Would it be possible for the driver to report how many clusters it calculat= ed that it needs, whenever it runs into this memory shortage during attach?= That way an administrator might have some idea how much to increase their= tunables in order to meet the driver's requirements. As it is, it's merely a guessing game or requires digging into driver sourc= e to come up with the right numbers. -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Jack Vogel Sent: Friday, November 21, 2014 10:23 AM To: Gerrit K=FChn Cc: FreeBSD Net Subject: Re: igb Could not setup receive structures (again) The message is pretty straightforward, its only cause is the inability of the driver to get the necessary clusters to populate the RX rings. After you get the error do a `netstat -m` and see what the state of the 9K jumbo pool is, for that is the size you would be using. Depending on the specific device type you may have up to 8 rings per interface, and with a ring size of 1K... It does seem like you should have enough, but maybe something else in your system is using the pool? As I said, look at netstat, it should giv= e you the truth, and then adjust the allocated size to fit your needs. Jack On Fri, Nov 21, 2014 at 2:48 AM, Gerrit K=FChn wrote: > Hi all, > > I get the error message above when trying to go for jumbo frames (mtu > 9000) on a system here. I found a lot of comments on this, but they all > state that this is due to a too low setting for mbufs in FreeBSD8/9 > settings. > However, I have 10-stable here, and the settings look rather high to me: > > kern.ipc.nmbclusters: 1014856 > kern.ipc.maxmbufmem: 8313700352 > kern.ipc.nmbufs: 6495090 > kern.ipc.nmbjumbop: 507428 > kern.ipc.nmbjumbo9: 451047 > kern.ipc.nmbjumbo16: 338284 > > FreeBSD mclane 10.0-STABLE FreeBSD 10.0-STABLE #5 r261710: Mon Feb 10 > 16:55:29 CET 2014 root@mclane.rt.aei.uni-hannover.de:/usr/obj/usr/src/sys= /GENERIC > amd64 > > > Is this still too low? I have a 6core machine with 6 igb interfaces, and = I > cannot even get one of these set to mtu 9000 without getting "Could not > setup receive structures". > > > cu > Gerrit > _______________________________________________ > 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" This email message is intended for the use of the person to whom it has bee= n sent, and may contain information that is confidential or legally protect= ed. If you are not the intended recipient or have received this message in = error, you are not authorized to copy, distribute, or otherwise use this me= ssage or its attachments. Please notify the sender immediately by return e-= mail and permanently delete this message and any attachments. Verio Inc. ma= kes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 22:06:21 2014 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 93FDFD24 for ; Fri, 21 Nov 2014 22:06:21 +0000 (UTC) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (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 472E4215 for ; Fri, 21 Nov 2014 22:06:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416607574; bh=NbQq93uy9UAv0Hp0Fq5bVxQCwo1+BlDPcOwXRMatzDA=; h=Date:From:Reply-To:To:Subject:From:Subject; b=cXk2zBWND8GCADp3iRYjLNMfdU2dF4Ab0cLAg5Jdfx4zv6o6xw1bueQ1VgJfSaOwozdwZNk8P4qXfFdCd5ukm9z1+jinMmkSy6c9Yh6/OS8BazoGPasXnHhOuOdNGcTcQv9Yd1a9eYvFnGil5wOp59temaY/cHNZQ4VmYrPPo2xE+NEd6Qv7ALQuH5xgR3yKL8N/j8Lby+0oLa7f2JwyZYcj3kE9KwAenZiiFPv5t+uaDOzVRe+iS26QtagUvQBaxWwvdSbGmaHC7Qh2vAP7Rw3CbHJdpNCNsNH8LzK93Nxq2JZGDi+ZbOnUuYoaEu9yET+fdKYu2p6bnqgPuA0tqQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=eKW2WFlsCUNoJLI7aXQwT15Sah4Q2KogW8vyFW+3EZZSAD+EJnxQdSjNko3tiuQPVRk1I679Quq+MYaqy8byRCqafMFgYglMDGA2CLZcmRsKRymwYgyxZA8QQnP5VKf8fH3fpiN6GerqM8G7+T0iEp/NtVQczZSAbcl8AaipWLFsDsm03eJLAf84V53NTHIeHlpJ03qEO8ziE++EAeVEXCR3EQAZHcdnpuA8wq8HW7a5UEzBGebIhLGBQR3/mhQ/gKWgs7Pq2c7cYxg4yS0UaL0u1vUJYoTxJ4y13E/s65qvKpICjQYyZwANQ1jtcPYcoqFApmAtwpaUhMv/TwbPnQ==; Received: from [98.139.214.32] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:06:14 -0000 Received: from [98.139.212.233] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:06:14 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:06:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 544767.30592.bm@omp1042.mail.bf1.yahoo.com X-YMail-OSG: RN6taeEVM1nFnb1P4KkWIh9VxLZvpbnOUTcnyMQMs3KU5e6M0azn_ST5pUMOQTc piKjWf4olCoSqchoXT_BtTWVT66iDNllW3.6EIUPQ5vigm03cgVsH8DtjvTogzpWD77Ikw6MY7.2 rFuAspyj3e8iF6H6WYOF5BBp2KQdLewZGIjYbTugCsBD0nrQHJ0sYrB2jDWg.VFwkI_UqdC4Ufbu vfnqTSd_20Jx4Bg6lLE7AMFZ704pFWozAEma..d36pQvqoG6GRZfkciem0KBMUy4wgN0cVY5._EQ _t9wPKqvinCfJ_Z60y_cZddUSiODSZP1KlDw1irQKpCUcYK4Rqto7cVeDyvbS0Mfj.egHqEhlZO6 6adrPmdTqo_9BOCPp4jUmBqGyUYKsoxy4LaOTyRkxMVYhHleLrUNg5yXorxwb6FeUxepr7ts1jy3 D9HgJ0AMjimlRwIDfrtQHVErf5CtxaKO1CtL0PfMwU4uAlGjsGQoDqoqN8l0s4XPGxu9cifT1sRH gNXIXkg0bfttyBPHqi1Qr37pYO7NJQ_qQigNN6kcyGANWq9xLh28JjnZnLZmRRDmuF7jvdAtiB.s wq8M3Q.8CC2QPxUUBtctlc2ExT3Eq7qkd6WNZTuVCOWY- Received: by 76.13.26.79; Fri, 21 Nov 2014 22:06:14 +0000 Date: Fri, 21 Nov 2014 22:06:13 +0000 (UTC) From: eclectic 923 Reply-To: eclectic 923 To: "net@freebsd.org" Message-ID: <1960028583.3815364.1416607573474.JavaMail.yahoo@jws10669.mail.bf1.yahoo.com> Subject: Patches for linux virtio_net driver MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3815363_1763837088.1416607573474" 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, 21 Nov 2014 22:06:21 -0000 ------=_Part_3815363_1763837088.1416607573474 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I know this is the Freebsd mailing list, but http://info.iet.unipi.it/~luigi/netmap/#85cb indicates that discussion should be sent to this list. I recently added netmap to a 3.10 LINUX kernel for use in a KVM guest. The virtio driver didn't work. There were two problems. On the 3.10.60 kernel from kernel.org, the patch to virtio_net.c didn't work, one part of the patch was rejected. This is easily fixed. More serious, was that the virtio initialization code didn't work, nor did the packet receive code. The basic problem was failure to initialize the indices properly and failure to maintain a 1 slot separation between head/tail indices. (Same problem 2 locations in the code.) This problem is easily seen by creating a KVM guest with a netmap/virtio_net driver, and simply pinging the guest from the host. The receive traffic can easily be monitored using the pkt-gen tool on the guest. The first 255 pings will work fine, when the index hits 255, then the packet receive will fail, and will continue to fail every time on slot 255. I've included patches for both problems in the hopes that the source code will be updated and others won't have to find these problems. If the source code won't be updated, then I'd appreciate suggestions on the best place to post these patches so others can find them. -- Joe Garvey ------=_Part_3815363_1763837088.1416607573474 Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=virtio_net_3.10.60.patch Content-ID: <610aa3c4-5c02-7702-ee86-313ccf041d34@yahoo.com> IyBUaGUgbmV0bWFwIDMuMTAgcGF0Y2ggZm9yIHRoZSB2aXJ0aW9fbmV0IGRyaXZlciBmYWlscyB0 byBhcHBseS4gVGhpcwojIHBhdGNoIGlzIHRoZSB3aG9sZSBuZXRtYXAgdmlydGlvIGRyaXZlciBw YXRjaCBmb3IgMy4xMC42MCAoZnJvbQojIGtlcm5lbC5vcmcpLCBhbmQgaXQgYXBwbGllcyBjb3Jy ZWN0bHkuCiMKSW5kZXg6IGxpbnV4LTMuMTAuNjAvZHJpdmVycy9uZXQvdmlydGlvX25ldC5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIGxpbnV4LTMuMTAuNjAub3JpZy9kcml2ZXJzL25ldC92aXJ0aW9fbmV0LmMJ MjAxNC0xMS0xNCAxMTo0ODoyMy4wMDAwMDAwMDAgLTA1MDAKKysrIGxpbnV4LTMuMTAuNjAvZHJp dmVycy9uZXQvdmlydGlvX25ldC5jCTIwMTQtMTEtMjEgMTI6NTQ6MjkuNzUxNzYwMDk1IC0wNTAw CkBAIC0xMzEsNiArMTMxLDEwIEBACiAJc3RydWN0IG5vdGlmaWVyX2Jsb2NrIG5iOwogfTsKIAor I2lmIGRlZmluZWQoQ09ORklHX05FVE1BUCkgfHwgZGVmaW5lZChDT05GSUdfTkVUTUFQX01PRFVM RSkKKyNpbmNsdWRlIDx2aXJ0aW9fbmV0bWFwLmg+CisjZW5kaWYKKwogc3RydWN0IHNrYl92bmV0 X2hkciB7CiAJdW5pb24gewogCQlzdHJ1Y3QgdmlydGlvX25ldF9oZHIgaGRyOwpAQCAtMjEwLDYg KzIxNCwxMCBAQAogCS8qIFN1cHByZXNzIGZ1cnRoZXIgaW50ZXJydXB0cy4gKi8KIAl2aXJ0cXVl dWVfZGlzYWJsZV9jYih2cSk7CiAKKyNpZmRlZiBERVZfTkVUTUFQCisgICAgICAgIGlmIChuZXRt YXBfdHhfaXJxKHZpLT5kZXYsIHZxMnR4cSh2cSkpKQorCQlyZXR1cm47CisjZW5kaWYKIAkvKiBX ZSB3ZXJlIHByb2JhYmx5IHdhaXRpbmcgZm9yIG1vcmUgb3V0cHV0IGJ1ZmZlcnMuICovCiAJbmV0 aWZfd2FrZV9zdWJxdWV1ZSh2aS0+ZGV2LCB2cTJ0eHEodnEpKTsKIH0KQEAgLTY0Niw3ICs2NTQs MTYgQEAKIAlzdHJ1Y3QgdmlydG5ldF9pbmZvICp2aSA9IHJxLT52cS0+dmRldi0+cHJpdjsKIAl2 b2lkICpidWY7CiAJdW5zaWduZWQgaW50IHIsIGxlbiwgcmVjZWl2ZWQgPSAwOworI2lmZGVmIERF Vl9ORVRNQVAKKwlpbnQgd29ya19kb25lID0gMDsKKyAKKwlpZiAobmV0bWFwX3J4X2lycSh2aS0+ ZGV2LCB2cTJyeHEocnEtPnZxKSwgJndvcmtfZG9uZSkpIHsKKwkJbmFwaV9jb21wbGV0ZShuYXBp KTsKKwkJTkQoImNhbGxlZCBuZXRtYXBfcnhfaXJxIik7CiAKKwkJcmV0dXJuIDE7CisJfQorI2Vu ZGlmCiBhZ2FpbjoKIAl3aGlsZSAocmVjZWl2ZWQgPCBidWRnZXQgJiYKIAkgICAgICAgKGJ1ZiA9 IHZpcnRxdWV1ZV9nZXRfYnVmKHJxLT52cSwgJmxlbikpICE9IE5VTEwpIHsKQEAgLTY3OSw2ICs2 OTYsMTYgQEAKIHsKIAlzdHJ1Y3QgdmlydG5ldF9pbmZvICp2aSA9IG5ldGRldl9wcml2KGRldik7 CiAJaW50IGk7CisjaWZkZWYgREVWX05FVE1BUAorICAgICAgICBpbnQgb2sgPSB2aXJ0aW9fbmV0 bWFwX2luaXRfYnVmZmVycyh2aSk7CisKKyAgICAgICAgbmV0bWFwX2VuYWJsZV9hbGxfcmluZ3Mo ZGV2KTsKKyAgICAgICAgaWYgKG9rKSB7CisgICAgICAgICAgICBmb3IgKGkgPSAwOyBpIDwgdmkt Pm1heF9xdWV1ZV9wYWlyczsgaSsrKQorCQl2aXJ0bmV0X25hcGlfZW5hYmxlKCZ2aS0+cnFbaV0p OworICAgICAgICAgICAgcmV0dXJuIDA7CisgICAgICAgIH0KKyNlbmRpZgogCiAJZm9yIChpID0g MDsgaSA8IHZpLT5tYXhfcXVldWVfcGFpcnM7IGkrKykgewogCQlpZiAoaSA8IHZpLT5jdXJyX3F1 ZXVlX3BhaXJzKQpAQCAtOTcyLDYgKzk5OSw5IEBACiAJc3RydWN0IHZpcnRuZXRfaW5mbyAqdmkg PSBuZXRkZXZfcHJpdihkZXYpOwogCWludCBpOwogCisjaWZkZWYgREVWX05FVE1BUAorICAgICAg ICBuZXRtYXBfZGlzYWJsZV9hbGxfcmluZ3MoZGV2KTsKKyNlbmRpZgogCS8qIE1ha2Ugc3VyZSBy ZWZpbGxfd29yayBkb2Vzbid0IHJlLWVuYWJsZSBuYXBpISAqLwogCWNhbmNlbF9kZWxheWVkX3dv cmtfc3luYygmdmktPnJlZmlsbCk7CiAKQEAgLTE2NDQsNiArMTY3NCwxMCBAQAogCQlnb3RvIGZy ZWVfcmVjdl9idWZzOwogCX0KIAorI2lmZGVmIERFVl9ORVRNQVAKKyAgICAgICAgdmlydGlvX25l dG1hcF9hdHRhY2godmkpOworI2VuZGlmCisKIAkvKiBBc3N1bWUgbGluayB1cCBpZiBkZXZpY2Ug Y2FuJ3QgcmVwb3J0IGxpbmsgc3RhdHVzLAogCSAgIG90aGVyd2lzZSBnZXQgbGluayBzdGF0dXMg ZnJvbSBjb25maWcuICovCiAJaWYgKHZpcnRpb19oYXNfZmVhdHVyZSh2aS0+dmRldiwgVklSVElP X05FVF9GX1NUQVRVUykpIHsKQEAgLTE2OTAsNiArMTcyNCw5IEBACiB7CiAJc3RydWN0IHZpcnRu ZXRfaW5mbyAqdmkgPSB2ZGV2LT5wcml2OwogCisjaWZkZWYgREVWX05FVE1BUAorICAgICAgICBu ZXRtYXBfZGV0YWNoKHZpLT5kZXYpOworI2VuZGlmCiAJdW5yZWdpc3Rlcl9ob3RjcHVfbm90aWZp ZXIoJnZpLT5uYik7CiAKIAkvKiBQcmV2ZW50IGNvbmZpZyB3b3JrIGhhbmRsZXIgZnJvbSBhY2Nl c3NpbmcgdGhlIGRldmljZS4gKi8K ------=_Part_3815363_1763837088.1416607573474 Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=virtio_netmap.patch Content-ID: <81b1efd9-9c11-fbc2-07e4-5d6d076218cc@yahoo.com> IyBUaGlzIGZpbGUgaXMgYSBwYXRjaCB0byB0aGUgbmV0bWFwIHZpcnRpb19uZXQgZHJpdmVyIGlu Y2x1ZGUgZmlsZS4KIyBUaGVyZSBpcyBhIHByb2JsZW0gd2l0aCB0aGUgaW5pdGlhbGl6YXRpb24s IGFuZCBkdXJpbmcgcmVhZCBwYWNrZXQgd2l0aAojIGNvbnRyb2wgb2YgdGhlIGluZGljaWVzIC4K IwojIFRoaXMgcHJvYmxlbSBpcyBlYXNpbHkgc2VlbiBieSBidWlsZGluZyBhIEtWTSBuZXRtYXAv dmlydGlvX25ldCBkcml2ZXIsIGFuZAojIHNpbXBseSBwaW5naW5nIGl0IChob3N0IHBpbmdzIEtW TSBndWVzdCkuIEFsbCBnb2VzIHdlbGwsIHVudGlsIHJpbmcgYnVmZmVyCiMgcmVhY2hlcyBpbmRl eCAyNTUsIGFuZCBubyBwYWNrZXQgaXMgYWN0dWFsbHkgcmVjZWl2ZWQuIFRoaXMgd2lsbCBmaXgg dGhhdAojIHByb2JsZW0gYW5kIHJlc3VsdGVkIGluIGEgd29ya2luZyBkcml2ZXIuCiMKSW5kZXg6 IGIvTElOVVgvdmlydGlvX25ldG1hcC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGEvTElOVVgvdmlydGlvX25l dG1hcC5oCTIwMTQtMTEtMjEgMTY6MjY6MDMuOTUxMjc4MDIxIC0wNTAwCisrKyBiL0xJTlVYL3Zp cnRpb19uZXRtYXAuaAkyMDE0LTExLTIxIDE2OjI2OjI1LjQ1MTM4NjY2NSAtMDUwMApAQCAtMzk4 LDggKzM5OCw4IEBACiAJICogU2Vjb25kIHBhcnQ6IHNraXAgcGFzdCBwYWNrZXRzIHRoYXQgdXNl cnNwYWNlIGhhcyByZWxlYXNlZC4KIAkgKi8KIAlubV9pID0ga3JpbmctPm5yX2h3Y3VyOyAvKiBu ZXRtYXAgcmluZyBpbmRleCAqLwotCWlmIChubV9pICE9IGhlYWQpIHsKLQkJZm9yIChuID0gMDsg bm1faSAhPSBoZWFkOyBuKyspIHsKKwlpZiAobm1fbmV4dChubV9pLCBsaW0pICE9IGhlYWQpIHsK KwkJZm9yIChuID0gMDsgbm1fbmV4dChubV9pLCBsaW0pICE9IGhlYWQ7IG4rKykgewogCQkJc3Ry dWN0IG5ldG1hcF9zbG90ICpzbG90ID0gJnJpbmctPnNsb3Rbbm1faV07CiAJCQl2b2lkICphZGRy ID0gTk1CKHNsb3QpOwogICAgICAgICAgICAgICAgICAgICAgICAgaW50IGVycjsKQEAgLTQyMSw3 ICs0MjEsNyBAQAogICAgICAgICAgICAgICAgICAgICAgICAgdmlydHF1ZXVlX2tpY2sodnEpOwog CQkJbm1faSA9IG5tX25leHQobm1faSwgbGltKTsKIAkJfQotCQlrcmluZy0+bnJfaHdjdXIgPSBo ZWFkOworCQlrcmluZy0+bnJfaHdjdXIgPSBubV9pOwogCX0KIAogCS8qIFdlIGhhdmUgZmluaXNo ZWQgcHJvY2Vzc2luZyB1c2VkIFJYIGJ1ZmZlcnMsIHNvIHdlIGhhdmUgdG8gdGVsbApAQCAtNDU0 LDYgKzQ1NCw3IEBACiAJZm9yIChyID0gMDsgciA8IG5hLT5udW1fcnhfcmluZ3M7IHIrKykgewog CQlDT01QQVRfREVDTF9TRwogICAgICAgICAgICAgICAgIHN0cnVjdCBuZXRtYXBfcmluZyAqcmlu ZyA9IG5hLT5yeF9yaW5nc1tyXS5yaW5nOworCQlzdHJ1Y3QgbmV0bWFwX2tyaW5nICprcmluZyA9 ICZuYS0+cnhfcmluZ3Nbcl07CiAJCXN0cnVjdCB2aXJ0cXVldWUgKnZxID0gR0VUX1JYX1ZRKHZp LCByKTsKIAkJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZyA9IEdFVF9SWF9TRyh2aSwgcik7CiAJICAg ICAgICBzdHJ1Y3QgbmV0bWFwX3Nsb3QqIHNsb3Q7CkBAIC00ODUsNiArNDg2LDcgQEAKIAkJCWlm IChWUV9GVUxMKHZxLCBlcnIpKQogCQkJCWJyZWFrOwogCQl9CisJCWtyaW5nLT5ucl9od2N1ciA9 IGk7CiAJCUQoImFkZGVkICVkIGluYnVmcyBvbiBxdWV1ZSAlZCIsIGksIHIpOwogCQl2aXJ0cXVl dWVfa2ljayh2cSk7CiAJfQo= ------=_Part_3815363_1763837088.1416607573474-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 22:51:58 2014 Return-Path: Delivered-To: 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 CAC58C62 for ; Fri, 21 Nov 2014 22:51:58 +0000 (UTC) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) (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 7403392C for ; Fri, 21 Nov 2014 22:51:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416610317; bh=xj2HDgWevz+rfWw06VatkW3e6HQQlJ645gBLbbtfar4=; h=Date:From:Reply-To:To:Subject:From:Subject; b=dzSqRWFqinwhqJDGa1eAXDWNpMDpZ0Ym0JTwnEmRnlXEDrfSbBFF80r9qTwvNsHTPl4N7MtmjO8YJWpnWAzMyh+CMkD/K3KmBKvsbMXD2rYeIWzrjSdtMj48UxSz4sYdwAi31RJCKhSxU//vp7LdWhX5Sj6eWxR2k1TYUIVggn46PadWQlLBPwlRDXgYQxE+W3/NveLGwokPRzUKCl2N6zt+nrjW/IUVO5ES8895OlFVAyQ0DLlWweumv9889vyt+Bg8GCkywcwJ6xFGY3E1J/1j+ztk03Q5EJBWf1NGA6qtM6Lj0S0ziKG4lbQUZQ9+XcWxxKxkMrFZHhvK3dsrLA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=IhpJnLzT0uvUXBfT5gJVy2PphokTOi5kthWg19IbONMKuWfoMbsK97bq3/UjqG9HbhA7kAFaKq6A7oceV1fia0TDzYvv9Toa3J4ZKvYtgNNdrKG6Xp7iBh9eEILKH6wpEikKyjoNztNFWoklhuWW5QPSBXU5KcjHDMfu3lPnX9lc0bD4wPYJVgGWvKI4SvIgsVYZu8dqwRkaztZOiMy04F4fKnk1gn87+l9c0pTK5tPdGkmzkxdG1wZOoADx7sgA8WTXTeli2vpPthr38K+9abFFSLZCpbAxG/ihaqbEWV4ZFP8JvfLVNS7celTSzV+yU6Nirf8AaGd+cnf9Ag4Nxg==; Received: from [66.196.81.171] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:51:56 -0000 Received: from [98.139.212.237] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:51:56 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:51:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 950366.8426.bm@omp1046.mail.bf1.yahoo.com X-YMail-OSG: dza3XRAVM1lxFQVp1Rvevxeev7qJzYqW3gqGgJTGqcCCOJlY2kjcdaPe2eVbsqR ro3R6rnrZdunuj4qZ8e3YFcxjSIb62hiwJ5F8R3_2mvi709bg.d6Wt.Uzygj8x9YVgzYxLywfPEV IbQbQfKWATIas6IaSlN7uqWHLYHGiYim5BKBwcpiqdiR.MGX9YN9WJJQ9vSJ02wH52I3G8_TCANh tfd_VrOzTqpsD7M_LXAYhat3tEfvO3Xnq1eaoaCgXXJBUEYlHnyakGwCnE7KEaGHUNepfgUbchGW Da6JCK48fiH9xqTxrTKa3SNpNcSl4MnNFGzdNbJmKbkpjMHQEMNYKX3j6x69AXHH9CXnJdFzjmBX B4q0zZmWmFUcdwJAmR2bMVoJEHiH8ctY352lXHUQgXhgfAaxcSfWadvzY9Xl4Cm1YesNrdLtF8w6 J5LxcKyIA6OSggqxRIXxwe1l4QN6KIwMdyOPC54WlzhE.z31FqsDDwEUsVCdf4YTaaHy1elWYKQ-- Received: by 66.196.80.114; Fri, 21 Nov 2014 22:51:56 +0000 Date: Fri, 21 Nov 2014 22:51:56 +0000 (UTC) From: eclectic 923 Reply-To: eclectic 923 To: "net@freebsd.org" Message-ID: <30479248.2784505.1416610316088.JavaMail.yahoo@jws106129.mail.bf1.yahoo.com> Subject: Re: Patches for linux virtio_net driver MIME-Version: 1.0 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: Fri, 21 Nov 2014 22:51:59 -0000 Sorry, having problems sending attachments as plain text. Here's virtio_netmap.patch: # This file is a patch to the netmap virtio_net driver include file. # There is a problem with the initialization, and during read packet with # control of the indicies . # # This problem is easily seen by building a KVM netmap/virtio_net driver, and # simply pinging it (host pings KVM guest). All goes well, until ring buffer # reaches index 255, and no packet is actually received. This will fix that # problem and resulted in a working driver. # Index: b/LINUX/virtio_netmap.h =================================================================== --- a/LINUX/virtio_netmap.h 2014-11-21 16:26:03.951278021 -0500 +++ b/LINUX/virtio_netmap.h 2014-11-21 16:26:25.451386665 -0500 @@ -398,8 +398,8 @@ * Second part: skip past packets that userspace has released. */ nm_i = kring->nr_hwcur; /* netmap ring index */ - if (nm_i != head) { - for (n = 0; nm_i != head; n++) { + if (nm_next(nm_i, lim) != head) { + for (n = 0; nm_next(nm_i, lim) != head; n++) { struct netmap_slot *slot = &ring->slot[nm_i]; void *addr = NMB(slot); int err; @@ -421,7 +421,7 @@ virtqueue_kick(vq); nm_i = nm_next(nm_i, lim); } - kring->nr_hwcur = head; + kring->nr_hwcur = nm_i; } /* We have finished processing used RX buffers, so we have to tell @@ -454,6 +454,7 @@ for (r = 0; r < na->num_rx_rings; r++) { COMPAT_DECL_SG struct netmap_ring *ring = na->rx_rings[r].ring; + struct netmap_kring *kring = &na->rx_rings[r]; struct virtqueue *vq = GET_RX_VQ(vi, r); struct scatterlist *sg = GET_RX_SG(vi, r); struct netmap_slot* slot; @@ -485,6 +486,7 @@ if (VQ_FULL(vq, err)) break; } + kring->nr_hwcur = i; D("added %d inbufs on queue %d", i, r); virtqueue_kick(vq); } From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 22:52:19 2014 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 64BB1CF9 for ; Fri, 21 Nov 2014 22:52:19 +0000 (UTC) Received: from nm37-vm8.bullet.mail.bf1.yahoo.com (nm37-vm8.bullet.mail.bf1.yahoo.com [72.30.238.220]) (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 0CDAD93B for ; Fri, 21 Nov 2014 22:52:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416610227; bh=axSMCiUPsQIoHYohLC4QSvgW9671bhaPSkKx/Xeuwo8=; h=Date:From:Reply-To:To:Subject:From:Subject; b=TadrW1TcYn888/M8Q/lobZpfex3jFeT7aKAzk1sl0Z5CRITJApGMsiZtXLseERNJmgy8UtUUsUiPsOfuBmbGi58CPg+xf4k0+y4WAeTt1pcQw9wNvKXO0KI6zrWe+NjWrAo1/YFaMMQ7RtX0J5UlRBoGOFJ3nWWc8Tucu+RWsP44wXy7JzAV4FN5sAiDuXmt8271wWT5rhAMna9uSQL5ZVmLX3CG9gRvDDh6zyRnRSQvAUXkBGaymf64eGBUXU4Ivor1AK1G3ItU4k0Folnjla0mBb2of2eq/lKta4Leaxx4owTvCfp8fPYyCctotPP+rK+RZAO4xRKJu4gJuRktHA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=W/C6Sp2GUGJdw9JAcYbVLacPvsXRnYgHdKVvvDmWh6j5pOsClaG87NPgiU9PrSH4ilCsqLiknZ9JOdyoQ+PMdirW/y7kJ3WLmEj/DMAiwTeFzbg81ggnQ7njy4eKJdI9FS5UdnGUt7mydONa2EnDttcHCU4HiA+K7oPjTyT4etPhI2Tco8WJXBNDckvHltkId16VAK5aH6AuW3KPWuRsmc+ftQnqccsBpXIvsApeRtblYL3dpV5/v/DqoCkUkkcRWI5qEtis6cwIm1twJIuOFjkJDStTJcKtqaQPDGz8oetUUK27UG636Vyct0fVcqRv+yQX+A0fVPmhqnfaZpYS2Q==; Received: from [98.139.215.141] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:50:27 -0000 Received: from [98.139.212.246] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:50:27 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 21 Nov 2014 22:50:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 70409.17267.bm@omp1055.mail.bf1.yahoo.com X-YMail-OSG: s_qpe_cVM1lwyyUTfPTTskUUsFkj.xHh.7c6saa9llcsNJ67vY13hzY8QMvpwUz ZPdzJle0HLfEcEGjSV8H_saOjzoDelp5yj6rlVFZRMbylFaZ.Ga.h4dMEGDToEaDSqUuFPtZ_rg4 7CrC.xkzbHpHuSQQtBWSSrcd2QKf5bT4yrP15OpvHR1XxWL160gf9s4iI.hLkwu.XsZ2C8eikU_P tltYmwVCpIVXI2mpmcRdRTJH6RE1..AJBH2cniLGX5lMZsS_8CaEhc_aZPhgBm1Oh77qvRtIySdx p6WswDg0zkzxEIPliD.JySrwnh0f6KwxIPxwHGC0ujtt8.F0qKkYK2a_p8RfhEJukR5_qbhJ0xvu znpgkrpPNVfqF51vyVrRePABSjwtAosx3Orh0lfd2ws8kpHtv1VDj797Tltgv7tGr2mD3UDvfIv. N.EP3oHxRth4AMOWXNQS55kkWW2kawRctr9qT3WQGuZX9ZWP9XbBrKXtSl6EjyKJ.F3RHO9NiEaD 1q6OnRskZfj54pK5j8uZ60mTVqQwyaGi2KvvI_9HrFUhUezbOYQ-- Received: by 66.196.80.148; Fri, 21 Nov 2014 22:50:26 +0000 Date: Fri, 21 Nov 2014 22:50:21 +0000 (UTC) From: eclectic 923 Reply-To: eclectic 923 To: "net@freebsd.org" Message-ID: <1737441065.3841217.1416610221856.JavaMail.yahoo@jws10674.mail.bf1.yahoo.com> Subject: Re: Patches for linux virtio_net driver MIME-Version: 1.0 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: Fri, 21 Nov 2014 22:52:19 -0000 Sorry, having problems sending attachments as plain text. Here's virtio_net_3.10.60.patch: # The netmap 3.10 patch for the virtio_net driver fails to apply. This # patch is the whole netmap virtio driver patch for 3.10.60 (from # kernel.org), and it applies correctly. # Index: linux-3.10.60/drivers/net/virtio_net.c =================================================================== --- linux-3.10.60.orig/drivers/net/virtio_net.c 2014-11-14 11:48:23.000000000 -0500 +++ linux-3.10.60/drivers/net/virtio_net.c 2014-11-21 12:54:29.751760095 -0500 @@ -131,6 +131,10 @@ struct notifier_block nb; }; +#if defined(CONFIG_NETMAP) || defined(CONFIG_NETMAP_MODULE) +#include +#endif + struct skb_vnet_hdr { union { struct virtio_net_hdr hdr; @@ -210,6 +214,10 @@ /* Suppress further interrupts. */ virtqueue_disable_cb(vq); +#ifdef DEV_NETMAP + if (netmap_tx_irq(vi->dev, vq2txq(vq))) + return; +#endif /* We were probably waiting for more output buffers. */ netif_wake_subqueue(vi->dev, vq2txq(vq)); } @@ -646,7 +654,16 @@ struct virtnet_info *vi = rq->vq->vdev->priv; void *buf; unsigned int r, len, received = 0; +#ifdef DEV_NETMAP + int work_done = 0; + + if (netmap_rx_irq(vi->dev, vq2rxq(rq->vq), &work_done)) { + napi_complete(napi); + ND("called netmap_rx_irq"); + return 1; + } +#endif again: while (received < budget && (buf = virtqueue_get_buf(rq->vq, &len)) != NULL) { @@ -679,6 +696,16 @@ { struct virtnet_info *vi = netdev_priv(dev); int i; +#ifdef DEV_NETMAP + int ok = virtio_netmap_init_buffers(vi); + + netmap_enable_all_rings(dev); + if (ok) { + for (i = 0; i < vi->max_queue_pairs; i++) + virtnet_napi_enable(&vi->rq[i]); + return 0; + } +#endif for (i = 0; i < vi->max_queue_pairs; i++) { if (i < vi->curr_queue_pairs) @@ -972,6 +999,9 @@ struct virtnet_info *vi = netdev_priv(dev); int i; +#ifdef DEV_NETMAP + netmap_disable_all_rings(dev); +#endif /* Make sure refill_work doesn't re-enable napi! */ cancel_delayed_work_sync(&vi->refill); @@ -1644,6 +1674,10 @@ goto free_recv_bufs; } +#ifdef DEV_NETMAP + virtio_netmap_attach(vi); +#endif + /* Assume link up if device can't report link status, otherwise get link status from config. */ if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) { @@ -1690,6 +1724,9 @@ { struct virtnet_info *vi = vdev->priv; +#ifdef DEV_NETMAP + netmap_detach(vi->dev); +#endif unregister_hotcpu_notifier(&vi->nb); /* Prevent config work handler from accessing the device. */ From owner-freebsd-net@FreeBSD.ORG Sat Nov 22 17:09:24 2014 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 0E89ADF0; Sat, 22 Nov 2014 17:09:24 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id D7D0B976; Sat, 22 Nov 2014 17:09:23 +0000 (UTC) Received: from [10.108.122.253] (unknown [46.233.116.248]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B1E846B38; Sat, 22 Nov 2014 12:09:14 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: Date: Sat, 22 Nov 2014 17:09:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <85C7A32E-121D-495F-93C7-9D2B2F134FF6@FreeBSD.org> References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> <20141121120201.6c77ea5b@x23> <20141121162042.449b22dc@x23> <072B7B0F-4DE3-4D37-BC94-1DEA38CF3B12@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A. Zeeb" , Marko Zec 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, 22 Nov 2014 17:09:24 -0000 On 21 Nov 2014, at 17:40, Adrian Chadd wrote: >>> Skimming through a bunch of hosts with moderately loaded hosts with >>> reasonably high uptime I couldn't find one where = net.inet.tcp.timer_race >>> was not zero. A ny suggestions how to best reproduce the race(s) in >>> tcp_timer.c? >>=20 >> They would likely occur only on very highly loaded hosts, as they = require race conditions to arise between TCP timers and TCP close. I = think I did manage to reproduce it at one stage, and left the counter in = to see if we could spot it in production, and I have had (multiple) = reports of it in deployed systems. I'm not sure it's worth trying to = reproduce them, given that knowledge -- we should simply fix them. >=20 > Wasn't this just fixed by Julien @ Verisign? I don't believe so, although it's the kind of thing Julien is very good = at fixing! The issue here is that we can't call callout_drain() from contexts where = we finalise TCP connection close and attempt to free the inpcb. The = 'easy' fix is to create a taskqueue thread to do the callout_drain() in = the event that we discover that callout_stop() isn't able to guarantee = that pending callouts are neither in execution nor scheduled. We'd then = defer the very tail of TCP teardown to that asynchronous context rather = than trying to do it to completion in the current (and rather more = sensitive) one. This would happen only very in frequently so have little = overhead in practice, although one would want to carefully look at the = sync behaviour to make sure it wasn't frequently enough that a backlog = might build up. > As for the vimage stability side of things - I'd really like to see > some VIMAGE torture tests written. Stuff like "do a high rate TCP > connection test whilst creating and destroying VIMAGEs." ... and even for non-VIMAGE. :-) Robert