From owner-freebsd-net@freebsd.org Sun Jan 22 11:38:06 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B06EBCBC3FA for ; Sun, 22 Jan 2017 11:38:06 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC90BF3 for ; Sun, 22 Jan 2017 11:38:06 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 2D9A82621F; Sun, 22 Jan 2017 11:38:06 +0000 (UTC) Date: Sun, 22 Jan 2017 11:38:06 +0000 To: freebsd-net@freebsd.org From: "julian (JulianElischer)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE Message-ID: <7c371956d087a86cc30f34c2dbbc410f@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFiEmZ4= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 11:38:06 -0000 anVsaWFuIGFkZGVkIGEgY29tbWVudC4KCgogIENvbnNpZGVyaW5nIGhvdyBtdWNoIHdvcmsgd2Vu dCBpbnRvIHdyaXRpbmcgdGhpcyBhbmQgdGhlIGZhY3QgdGhhdCB3ZSBoYWQgdG8gZ2V0IGl0IGFw cHJvdmVkIGJ5IHZlcml6b24gKG9yIHdoYXRldmVyIHRoZXkgd2VyZSBjYWxsZWQgYXQgdGhlIHRp bWUpIGl0cyBhbWF6aW5nIHRoYXQgSSByZW1lbWJlciBhbG1vc3Qgbm90aGluZyBhYm91dCBob3cg aXQgd29ya3MuCgpJTkxJTkUgQ09NTUVOVFMKCj4gbmdfcHBwb2UuNDoxMTEKPiArVG8gc2V0IGEg YmluYXJ5IEhvc3QtVW5pcSwgaXQgbXVzdCBiZSBlbmNvZGVkIGFzIGEgaGV4YWRlY2ltYWwgbG93 ZXJjYXNlCj4gK3N0cmluZyBhbmQgcHJlZml4ZWQgd2l0aCAiMHgiLgo+ICBBIHNlc3Npb24gcmVx dWVzdCBwYWNrZXQgd2lsbCBiZSBicm9hZGNhc3RlZCBvbiB0aGUgRXRoZXJuZXQuCgpUaGVyZSBh cmUgd2F5cyB0byBzZXQgYmluYXJ5IHZhbHVlcy4gdGhvdWdoIHRoaXMgd2lsbCBkby4gSSBmIHdl IGRlY2lkZSBpdCdzIGxpbWl0aW5nLCB3ZSBjYW4gaW1wcm92ZSBpdC4KCj4gbmdfcHBwb2UuYzo4 NTUKPiAgCQkJICogU3RvcmUgdGhlIG9yaWdpbmF0b3Igb2YgdGhpcyBtZXNzYWdlIHNvIHdlIGNh biBzZW5kCj4gIAkJCSAqIGEgc3VjY2VzcyBvZiBmYWlsIG1lc3NhZ2UgdG8gdGhlbSBsYXRlci4K PiAgCQkJICogTW92ZSB0aGUgc2Vzc2lvbiB0byBTSU5JVC4KCmNhbiB5b3UgZml4IHRoZSB0eXBv IGhlcmUgd2hpbGUgeW91IGFyZSBoZXJlLi4gb2YgLT4gb3IKClJFUE9TSVRPUlkKICByUyBGcmVl QlNEIHNyYyByZXBvc2l0b3J5CgpSRVZJU0lPTiBERVRBSUwKICBodHRwczovL3Jldmlld3MuZnJl ZWJzZC5vcmcvRDkyNzAKCkVNQUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVi c2Qub3JnL3NldHRpbmdzL3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvCgpUbzogYWxlLCAjbmV0d29y aywgI21hbnBhZ2VzLCBqdWxpYW4KQ2M6IG1hbmRyZWUsIGltcCwgZnJlZWJzZC1uZXQtbGlzdAo= From owner-freebsd-net@freebsd.org Sun Jan 22 12:20:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78171CBC65B for ; Sun, 22 Jan 2017 12:20:00 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 5536082F for ; Sun, 22 Jan 2017 12:20:00 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 8E2C6369F6; Sun, 22 Jan 2017 12:19:59 +0000 (UTC) Date: Sun, 22 Jan 2017 12:19:59 +0000 To: freebsd-net@freebsd.org From: "julian (JulianElischer)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , Thread-Topic: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFiEo28= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 12:20:00 -0000 anVsaWFuIGFjY2VwdGVkIHRoaXMgcmV2aXNpb24uCmp1bGlhbiBhZGRlZCBhIGNvbW1lbnQuClRo aXMgcmV2aXNpb24gaGFzIGEgcG9zaXRpdmUgcmV2aWV3LgoKCiAgYXMgZmFyIGFzIEkgY2FuIHNl ZSBpdCBsb29rcyBnb29kLiBTYW1lIGRlZmF1bHQgdmFsdWUgYXMgYmVmb3JlLi4KCklOTElORSBD T01NRU5UUwoKPiBuZ19wcHBvZS5jOjk1Mgo+ICAJCQkgKiBTdG9yZSB0aGUgb3JpZ2luYXRvciBv ZiB0aGlzIG1lc3NhZ2Ugc28gd2UgY2FuIHNlbmQKPiAgCQkJICogYSBzdWNjZXNzIG9mIGZhaWwg bWVzc2FnZSB0byB0aGVtIGxhdGVyLgo+ICAJCQkgKiBTdG9yZSB0aGUgQUMtTmFtZSBnaXZlbiBh bmQgZ28gdG8gUFJJTUVELgoKc2FtZSB0eXBvLi5ndWVzcyBJIGNvcGllZCBpdAoKUkVQT1NJVE9S WQogIHJTIEZyZWVCU0Qgc3JjIHJlcG9zaXRvcnkKClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8v cmV2aWV3cy5mcmVlYnNkLm9yZy9EOTI3MAoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jl dmlld3MuZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBh bGUsICNuZXR3b3JrLCAjbWFucGFnZXMsIGp1bGlhbgpDYzogbWFuZHJlZSwgaW1wLCBmcmVlYnNk LW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Sun Jan 22 12:35:32 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5525DCB0061 for ; Sun, 22 Jan 2017 12:35:32 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 30EA57BB for ; Sun, 22 Jan 2017 12:35:32 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id ED6F936260; Sun, 22 Jan 2017 12:35:31 +0000 (UTC) Date: Sun, 22 Jan 2017 12:35:31 +0000 To: freebsd-net@freebsd.org From: "mandree (Matthias Andree)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE Message-ID: <75770ff5389e1c4f82f306fab70a4d0a@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFiEpxM= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 12:35:32 -0000 bWFuZHJlZSBhZGRlZCBhIGNvbW1lbnQuCgoKICBDb3VsZCB3ZSBoYXZlIGNvbmNyZXRlIGV4YW1w bGVzIGZvciB0aGUgYWRkZWQgSE9TVC1VTklRIHRhZ3MsIG9uZSB3b3JraW5nIGV4YW1wbGUgcGVy IHBvc3NpYmxlIHN5bnRheCAoYW5kIHBvc3NpYmx5IGFub255bWl6ZWQgZnJvbSBhbGVAJ3MgcGFy dGljdWxhciBJU1AsIGJ1dCBtYWludGFpbmluZyBzeW50YXgpPyBQbGVhc2U/CgpSRVBPU0lUT1JZ CiAgclMgRnJlZUJTRCBzcmMgcmVwb3NpdG9yeQoKUkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9y ZXZpZXdzLmZyZWVic2Qub3JnL0Q5MjcwCgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2 aWV3cy5mcmVlYnNkLm9yZy9zZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IGFs ZSwgI25ldHdvcmssICNtYW5wYWdlcywganVsaWFuCkNjOiBtYW5kcmVlLCBpbXAsIGZyZWVic2Qt bmV0LWxpc3QK From owner-freebsd-net@freebsd.org Sun Jan 22 14:16:19 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B394CBC45F for ; Sun, 22 Jan 2017 14:16:19 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 72B04BC4 for ; Sun, 22 Jan 2017 14:16:19 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 4B1FD36FD7; Sun, 22 Jan 2017 14:16:19 +0000 (UTC) Date: Sun, 22 Jan 2017 14:16:19 +0000 To: freebsd-net@freebsd.org From: "ale (Alex Dupre)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFiEvrM= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_b9769decec42fae7a2acb0902167e279" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 14:16:19 -0000 --b1_b9769decec42fae7a2acb0902167e279 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 YWxlIHVwZGF0ZWQgdGhpcyByZXZpc2lvbiB0byBEaWZmIDI0MzE0LgphbGUgYWRkZWQgYSBjb21t ZW50LgpUaGlzIHJldmlzaW9uIG5vdyByZXF1aXJlcyByZXZpZXcgdG8gcHJvY2VlZC4KCgogIEZp eGVkIHR5cG9zIGFuZCBpbXByb3ZlZCBtYW4gcGFnZS4KClJFUE9TSVRPUlkKICByUyBGcmVlQlNE IHNyYyByZXBvc2l0b3J5CgpDSEFOR0VTIFNJTkNFIExBU1QgVVBEQVRFCiAgaHR0cHM6Ly9yZXZp ZXdzLmZyZWVic2Qub3JnL0Q5MjcwP3ZzPTI0MjY0JmlkPTI0MzE0CgpSRVZJU0lPTiBERVRBSUwK ICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDkyNzAKCkFGRkVDVEVEIEZJTEVTCiAgc2hh cmUvbWFuL21hbjQvbmdfcHBwb2UuNAogIHN5cy9uZXRncmFwaC9uZ19wcHBvZS5jCgpFTUFJTCBQ UkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9zZXR0aW5ncy9wYW5lbC9l bWFpbHByZWZlcmVuY2VzLwoKVG86IGFsZSwgI25ldHdvcmssICNtYW5wYWdlcywganVsaWFuCkNj OiBtYW5kcmVlLCBpbXAsIGZyZWVic2QtbmV0LWxpc3QK --b1_b9769decec42fae7a2acb0902167e279 Content-Type: text/x-patch; charset=utf-8; name="D9270.24314.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D9270.24314.patch" ZGlmZiAtLWdpdCBhL3N5cy9uZXRncmFwaC9uZ19wcHBvZS5jIGIvc3lzL25ldGdyYXBoL25nX3Bw cG9lLmMKLS0tIGEvc3lzL25ldGdyYXBoL25nX3BwcG9lLmMKKysrIGIvc3lzL25ldGdyYXBoL25n X3BwcG9lLmMKQEAgLTIyNiw5ICsyMjYsMTEgQEAKIAljb25zdCBzdHJ1Y3QgcHBwb2VfdGFnCSp0 YWdzW05VTVRBR1NdOwogCXVfaW50CQkJc2VydmljZV9sZW47CiAJdV9pbnQJCQlhY19uYW1lX2xl bjsKKwl1X2ludAkJCWhvc3RfdW5pcV9sZW47CiAKIAlzdHJ1Y3QgZGF0YXRhZwkJc2VydmljZTsK IAlzdHJ1Y3QgZGF0YXRhZwkJYWNfbmFtZTsKKwlzdHJ1Y3QgZGF0YXRhZwkJaG9zdF91bmlxOwog fTsKIHR5cGVkZWYgc3RydWN0IHNlc3NfbmVnICpuZWdwOwogCkBAIC01ODksMTggKzU5MSwyMCBA QAogcHBwb2VfZmluZHVuaXEobm9kZV9wIG5vZGUsIGNvbnN0IHN0cnVjdCBwcHBvZV90YWcgKnRh ZykKIHsKIAlob29rX3AJaG9vayA9IE5VTEw7Ci0JdW5pb24gdW5pcSB1bmlxOworCXNlc3NwCXNw OwogCi0JYmNvcHkodGFnICsgMSwgdW5pcS5ieXRlcywgc2l6ZW9mKHZvaWQgKikpOwogCS8qIEN5 Y2xlIHRocm91Z2ggYWxsIGtub3duIGhvb2tzLiAqLwogCUxJU1RfRk9SRUFDSChob29rLCAmbm9k ZS0+bmRfaG9va3MsIGhrX2hvb2tzKSB7CiAJCS8qIFNraXAgYW55IG5vbnNlc3Npb24gaG9vay4g Ki8KIAkJaWYgKE5HX0hPT0tfUFJJVkFURShob29rKSA9PSBOVUxMKQogCQkJY29udGludWU7Ci0J CWlmICh1bmlxLnBvaW50ZXIgPT0gTkdfSE9PS19QUklWQVRFKGhvb2spKQorCQlzcCA9IE5HX0hP T0tfUFJJVkFURShob29rKTsKKwkJaWYgKHNwLT5uZWctPmhvc3RfdW5pcV9sZW4gPT0gbnRvaHMo dGFnLT50YWdfbGVuKSAmJgorCQkgICAgYmNtcChzcC0+bmVnLT5ob3N0X3VuaXEuZGF0YSwgKGNv bnN0IGNoYXIgKikodGFnICsgMSksCisJCSAgICAgc3AtPm5lZy0+aG9zdF91bmlxX2xlbikgPT0g MCkKIAkJCWJyZWFrOwogCX0KLQlDVFIzKEtUUl9ORVQsICIlMjBzOiBtYXRjaGVkICVwIGZvciAl cCIsIF9fZnVuY19fLCBob29rLCB1bmlxLnBvaW50ZXIpOworCUNUUjMoS1RSX05FVCwgIiUyMHM6 IG1hdGNoZWQgJXAgZm9yICVwIiwgX19mdW5jX18sIGhvb2ssIHNwKTsKIAogCXJldHVybiAoaG9v ayk7CiB9CkBAIC04NDgsMjggKzg1Miw3MiBAQAogCQkJICogQ2hlY2sgdGhlIGhvb2sgZXhpc3Rz IGFuZCBpcyBVbmluaXRpYWxpc2VkLgogCQkJICogU2VuZCBhIFBBREkgcmVxdWVzdCwgYW5kIHN0 YXJ0IHRoZSB0aW1lb3V0IGxvZ2ljLgogCQkJICogU3RvcmUgdGhlIG9yaWdpbmF0b3Igb2YgdGhp cyBtZXNzYWdlIHNvIHdlIGNhbiBzZW5kCi0JCQkgKiBhIHN1Y2Nlc3Mgb2YgZmFpbCBtZXNzYWdl IHRvIHRoZW0gbGF0ZXIuCisJCQkgKiBhIHN1Y2Nlc3Mgb3IgZmFpbCBtZXNzYWdlIHRvIHRoZW0g bGF0ZXIuCiAJCQkgKiBNb3ZlIHRoZSBzZXNzaW9uIHRvIFNJTklULgogCQkJICogU2V0IHVwIHRo ZSBzZXNzaW9uIHRvIHRoZSBjb3JyZWN0IHN0YXRlIGFuZAogCQkJICogc3RhcnQgaXQuCiAJCQkg Ki8KLQkJCWludAlpLCBhY25sZW4gPSAwLCBhY25zZXAgPSAwLCBzcnZsZW47CisJCQlpbnQJYWNu cG9zLCBhY25sZW4gPSAwLCBhY25zZXAgPSAwOworCQkJaW50CWh1cG9zLCBodWxlbiA9IDAsIGh1 c2VwID0gMDsKKwkJCWludAlpLCBzcnZwb3MsIHNydmxlbjsKKwkJCWFjbnBvcyA9IDA7CiAJCQlm b3IgKGkgPSAwOyBpIDwgb3VybXNnLT5kYXRhX2xlbjsgaSsrKSB7CiAJCQkJaWYgKG91cm1zZy0+ ZGF0YVtpXSA9PSAnXFwnKSB7CiAJCQkJCWFjbmxlbiA9IGk7CiAJCQkJCWFjbnNlcCA9IDE7CiAJ CQkJCWJyZWFrOwogCQkJCX0KIAkJCX0KLQkJCXNydmxlbiA9IG91cm1zZy0+ZGF0YV9sZW4gLSBh Y25sZW4gLSBhY25zZXA7CisJCQlodXBvcyA9IGFjbmxlbiArIGFjbnNlcDsKKwkJCWZvciAoaSA9 IGh1cG9zOyBpIDwgb3VybXNnLT5kYXRhX2xlbjsgaSsrKSB7CisJCQkJaWYgKG91cm1zZy0+ZGF0 YVtpXSA9PSAnfCcpIHsKKwkJCQkJaHVsZW4gPSBpIC0gaHVwb3M7CisJCQkJCWh1c2VwID0gMTsK KwkJCQkJYnJlYWs7CisJCQkJfQorCQkJfQorCQkJc3J2cG9zID0gaHVwb3MgKyBodWxlbiArIGh1 c2VwOworCQkJc3J2bGVuID0gb3VybXNnLT5kYXRhX2xlbiAtIHNydnBvczsKIAotCQkJYmNvcHko b3VybXNnLT5kYXRhLCBuZWctPmFjX25hbWUuZGF0YSwgYWNubGVuKTsKKwkJCWJjb3B5KG91cm1z Zy0+ZGF0YSArIGFjbnBvcywgbmVnLT5hY19uYW1lLmRhdGEsIGFjbmxlbik7CiAJCQluZWctPmFj X25hbWVfbGVuID0gYWNubGVuOwogCisJCQluZWctPmhvc3RfdW5pcS5oZHIudGFnX3R5cGUgPSBQ VFRfSE9TVF9VTklROworCQkJaWYgKGh1bGVuID09IDApIHsKKwkJCQkvKiBOb3QgcHJvdmlkZWQs IGdlbmVyYXRlIG9uZSAqLworCQkJCW5lZy0+aG9zdF91bmlxLmhkci50YWdfbGVuID0gaHRvbnMo c2l6ZW9mKHNwKSk7CisJCQkJYmNvcHkoJnNwLCBuZWctPmhvc3RfdW5pcS5kYXRhLCBzaXplb2Yo c3ApKTsKKwkJCQluZWctPmhvc3RfdW5pcV9sZW4gPSBzaXplb2Yoc3ApOworCQkJfSBlbHNlIGlm IChodWxlbiA+IDIgJiYgb3VybXNnLT5kYXRhW2h1cG9zXSA9PSAnMCcgJiYKKwkJCSAgb3VybXNn LT5kYXRhW2h1cG9zICsgMV0gPT0gJ3gnICYmIGh1bGVuICUgMiA9PSAwKSB7CisJCQkJLyogSGV4 IGVuY29kZWQgKi8KKwkJCQlzdGF0aWMgY29uc3QgY2hhciBoZXhkaWdbMTZdID0gIjAxMjM0NTY3 ODlhYmNkZWYiOworCQkJCWludCBqOworCisJCQkJbmVnLT5ob3N0X3VuaXEuaGRyLnRhZ19sZW4g PSBodG9ucygodWludDE2X3QpKGh1bGVuIC8gMiAtIDEpKTsKKwkJCQlmb3IgKGkgPSAwOyBpIDwg aHVsZW4gLSAyOyBpKyspIHsKKwkJCQkJZm9yIChqID0gMDsKKwkJCQkJICAgICBqIDwgMTYgJiYK KwkJCQkJICAgICBvdXJtc2ctPmRhdGFbaHVwb3MgKyAyICsgaV0gIT0gaGV4ZGlnW2pdOworCQkJ CQkgICAgIGorKyk7CisJCQkJCWlmIChqID09IDE2KQorCQkJCQkJTEVBVkUoRUlOVkFMKTsKKwkJ CQkJaWYgKGkgJSAyID09IDApCisJCQkJCQluZWctPmhvc3RfdW5pcS5kYXRhW2kgLyAyXSA9IGog PDwgNDsKKwkJCQkJZWxzZQorCQkJCQkJbmVnLT5ob3N0X3VuaXEuZGF0YVtpIC8gMl0gfD0gajsK KwkJCQl9CisJCQkJbmVnLT5ob3N0X3VuaXFfbGVuID0gaHVsZW4gLyAyIC0gMTsKKwkJCX0gZWxz ZSB7CisJCQkJLyogUGxhaW4gc3RyaW5nICovCisJCQkJbmVnLT5ob3N0X3VuaXEuaGRyLnRhZ19s ZW4gPSBodG9ucygodWludDE2X3QpaHVsZW4pOworCQkJCWJjb3B5KG91cm1zZy0+ZGF0YSArIGh1 cG9zLCBuZWctPmhvc3RfdW5pcS5kYXRhLCBodWxlbik7CisJCQkJbmVnLT5ob3N0X3VuaXFfbGVu ID0gaHVsZW47CisJCQl9CisKIAkJCW5lZy0+c2VydmljZS5oZHIudGFnX3R5cGUgPSBQVFRfU1JW X05BTUU7CiAJCQluZWctPnNlcnZpY2UuaGRyLnRhZ19sZW4gPSBodG9ucygodWludDE2X3Qpc3J2 bGVuKTsKLQkJCWJjb3B5KG91cm1zZy0+ZGF0YSArIGFjbmxlbiArIGFjbnNlcCwKLQkJCSAgICBu ZWctPnNlcnZpY2UuZGF0YSwgc3J2bGVuKTsKKwkJCWJjb3B5KG91cm1zZy0+ZGF0YSArIHNydnBv cywgbmVnLT5zZXJ2aWNlLmRhdGEsIHNydmxlbik7CiAJCQluZWctPnNlcnZpY2VfbGVuID0gc3J2 bGVuOwogCQkJcHBwb2Vfc3RhcnQoc3ApOwogCQkJYnJlYWs7CkBAIC04NzksNyArOTI3LDcgQEAK IAkJCSAqIENoZWNrIHRoZSBob29rIGV4aXN0cyBhbmQgaXMgVW5pbml0aWFsaXNlZC4KIAkJCSAq IEluc3RhbGwgdGhlIHNlcnZpY2UgbWF0Y2hpbmcgc3RyaW5nLgogCQkJICogU3RvcmUgdGhlIG9y aWdpbmF0b3Igb2YgdGhpcyBtZXNzYWdlIHNvIHdlIGNhbiBzZW5kCi0JCQkgKiBhIHN1Y2Nlc3Mg b2YgZmFpbCBtZXNzYWdlIHRvIHRoZW0gbGF0ZXIuCisJCQkgKiBhIHN1Y2Nlc3Mgb3IgZmFpbCBt ZXNzYWdlIHRvIHRoZW0gbGF0ZXIuCiAJCQkgKiBNb3ZlIHRoZSBob29rIHRvICdMSVNURU5JTkcn CiAJCQkgKi8KIAkJCW5lZy0+c2VydmljZS5oZHIudGFnX3R5cGUgPSBQVFRfU1JWX05BTUU7CkBA IC0xMDYxLDEwICsxMTA5LDYgQEAKIAlub2RlX3AJbm9kZSA9IE5HX0hPT0tfTk9ERShob29rKTsK IAlwcml2X3AJcHJpdnAgPSBOR19OT0RFX1BSSVZBVEUobm9kZSk7CiAJbmVncAluZWcgPSBzcC0+ bmVnOwotCXN0cnVjdCB7Ci0JCXN0cnVjdCBwcHBvZV90YWcgaGRyOwotCQl1bmlvbgl1bmlxCWRh dGE7Ci0JfSBfX3BhY2tlZCB1bmlxdGFnOwogCXN0cnVjdCAgbWJ1ZiAqbTA7CiAJaW50CWVycm9y OwogCkBAIC0xMDgwLDExICsxMTI0LDggQEAKIAltZW1jcHkoKHZvaWQgKikmbmVnLT5wa3QtPnBr dF9oZWFkZXIuZWgsICZwcml2cC0+ZWgsCiAJICAgIHNpemVvZihzdHJ1Y3QgZXRoZXJfaGVhZGVy KSk7CiAJbmVnLT5wa3QtPnBrdF9oZWFkZXIucGguY29kZSA9IFBBRElfQ09ERTsKLQl1bmlxdGFn Lmhkci50YWdfdHlwZSA9IFBUVF9IT1NUX1VOSVE7Ci0JdW5pcXRhZy5oZHIudGFnX2xlbiA9IGh0 b25zKCh1X2ludDE2X3Qpc2l6ZW9mKHVuaXF0YWcuZGF0YSkpOwotCXVuaXF0YWcuZGF0YS5wb2lu dGVyID0gc3A7CiAJaW5pdF90YWdzKHNwKTsKLQlpbnNlcnRfdGFnKHNwLCAmdW5pcXRhZy5oZHIp OworCWluc2VydF90YWcoc3AsICZuZWctPmhvc3RfdW5pcS5oZHIpOwogCWluc2VydF90YWcoc3As ICZuZWctPnNlcnZpY2UuaGRyKTsKIAlpZiAocHJpdnAtPm1heF9wYXlsb2FkLmRhdGEgIT0gMCkK IAkJaW5zZXJ0X3RhZyhzcCwgJnByaXZwLT5tYXhfcGF5bG9hZC5oZHIpOwpAQCAtMTQzOCw4ICsx NDc5LDcgQEAKIAkJCSAqIEZvciBub3cgc2ltcGx5IGFjY2VwdCB0aGUgZmlyc3Qgd2UgcmVjZWl2 ZS4KIAkJCSAqLwogCQkJdXRhZyA9IGdldF90YWcocGgsIFBUVF9IT1NUX1VOSVEpOwotCQkJaWYg KCh1dGFnID09IE5VTEwpIHx8Ci0JCQkgICAgKG50b2hzKHV0YWctPnRhZ19sZW4pICE9IHNpemVv ZihzcCkpKSB7CisJCQlpZiAodXRhZyA9PSBOVUxMKSB7CiAJCQkJbG9nKExPR19OT1RJQ0UsICJu Z19wcHBvZVsleF06IG5vIGhvc3QgIgogCQkJCSAgICAidW5pcXVlIGZpZWxkXG4iLCBub2RlLT5u ZF9JRCk7CiAJCQkJTEVBVkUoRU5FVFVOUkVBQ0gpOwpAQCAtMTYwNSw4ICsxNjQ1LDcgQEAKIAkJ CSAqIHNldCB1cyBpbnRvIFNlc3Npb24gbW9kZS4KIAkJCSAqLwogCQkJdXRhZyA9IGdldF90YWco cGgsIFBUVF9IT1NUX1VOSVEpOwotCQkJaWYgKCh1dGFnID09IE5VTEwpIHx8Ci0JCQkgICAgKG50 b2hzKHV0YWctPnRhZ19sZW4pICE9IHNpemVvZihzcCkpKSB7CisJCQlpZiAodXRhZyA9PSBOVUxM KSB7CiAJCQkJTEVBVkUgKEVORVRVTlJFQUNIKTsKIAkJCX0KIAkJCXNlbmRob29rID0gcHBwb2Vf ZmluZHVuaXEobm9kZSwgdXRhZyk7CmRpZmYgLS1naXQgYS9zaGFyZS9tYW4vbWFuNC9uZ19wcHBv ZS40IGIvc2hhcmUvbWFuL21hbjQvbmdfcHBwb2UuNAotLS0gYS9zaGFyZS9tYW4vbWFuNC9uZ19w cHBvZS40CisrKyBiL3NoYXJlL21hbi9tYW40L25nX3BwcG9lLjQKQEAgLTM1LDcgKzM1LDcgQEAK IC5cIiAkRnJlZUJTRCQKIC5cIiAkV2hpc3RsZTogbmdfcHBwb2UuOCx2IDEuMSAxOTk5LzAxLzI1 IDIzOjQ2OjI3IGFyY2hpZSBFeHAgJAogLlwiCi0uRGQgU2VwdGVtYmVyIDE1LCAyMDE1CisuRGQg SmFudWFyeSAyMCwgMjAxNwogLkR0IE5HX1BQUE9FIDQKIC5PcwogLlNoIE5BTUUKQEAgLTEwNCwx MiArMTA0LDIyIEBACiBJdCBtdXN0IGJlIG5ld2x5IGNyZWF0ZWQgYW5kIGEgc2VydmljZSBuYW1l IGNhbiBiZSBnaXZlbiBhcyBhbiBhcmd1bWVudC4KIEl0IGlzIGxlZ2FsIHRvIHNwZWNpZnkgYSB6 ZXJvLWxlbmd0aCBzZXJ2aWNlIG5hbWUsIHRoaXMgaXMgY29tbW9uCiBvbiBzb21lIERTTCBzZXR1 cHMuCi1JdCBpcyBwb3NzaWJsZSB0byByZXF1ZXN0IGEgY29ubmVjdGlvbiB0byBhIHNwZWNpZmlj Ci1hY2Nlc3MgY29uY2VudHJhdG9yIGJ5IGl0cyBuYW1lIHVzaW5nIHRoZSAiQUMtTmFtZVxcU2Vy dmljZS1OYW1lIiBzeW50YXguCitJdCBpcyBwb3NzaWJsZSB0byByZXF1ZXN0IGEgY29ubmVjdGlv biB0byBhIHNwZWNpZmljIGFjY2VzcyBjb25jZW50cmF0b3IsCithbmQvb3Igc2V0IGEgc3BlY2lm aWMgaG9zdCB1bmlxIHRhZywgcmVxdWlyZWQgYnkgc29tZSBJbnRlcm5ldCBwcm92aWRlcnMsCit1 c2luZyB0aGUgIltBQy1OYW1lXFxdW0hvc3QtVW5pcXxdU2VydmljZS1OYW1lIiBzeW50YXguCitU byBzZXQgYSBiaW5hcnkgSG9zdC1VbmlxLCBpdCBtdXN0IGJlIGVuY29kZWQgYXMgYSBoZXhhZGVj aW1hbCBsb3dlcmNhc2UKK3N0cmluZyBhbmQgcHJlZml4ZWQgd2l0aCAiMHgiLCBlZy4gIjB4NmQ3 OTJkNzQ2MTY3IiBpcyBlcXVpdmFsZW50IHRvCisibXktdGFnIi4KIEEgc2Vzc2lvbiByZXF1ZXN0 IHBhY2tldCB3aWxsIGJlIGJyb2FkY2FzdGVkIG9uIHRoZSBFdGhlcm5ldC4KIFRoaXMgY29tbWFu ZCB1c2VzIHRoZQogLkR2IG5ncHBwb2VfaW5pdF9kYXRhCiBzdHJ1Y3R1cmUgc2hvd24gYmVsb3cu CitGb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBpbml0IGRhdGEgYXJndW1lbnQgY2FuIGJlIHVz ZWQgdG8KK2Nvbm5lY3QgdG8gIm15LWlzcCIgc2VydmljZSB3aXRoICJteS1ob3N0IiB1bmlxIHRh ZywgYWNjZXB0aW5nIG9ubHkKKyJyZW1vdGUtYWMiIGFzIGFjY2VzcyBjb25jZW50cmF0b3I6Cisu QmQgLWxpdGVyYWwgLW9mZnNldCBpbmRlbnQKKyJyZW1vdGUtYWNcXG15LWhvc3R8bXktaXNwIgor LkVkCiAuSXQgRHYgTkdNX1BQUE9FX0xJU1RFTiBQcSBJYyBwcHBvZV9saXN0ZW4KIFRlbGwgYSBu b21pbmF0ZWQgbmV3bHkgY3JlYXRlZCBob29rIHRoYXQgaXRzIHNlc3Npb24gc2hvdWxkIGVudGVy CiB0aGUgc3RhdGUgbWFjaGluZSBhcyBhIHNlcnZlciBsaXN0ZW5lci4KCg== --b1_b9769decec42fae7a2acb0902167e279-- From owner-freebsd-net@freebsd.org Sun Jan 22 14:17:49 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BA88CBC525 for ; Sun, 22 Jan 2017 14:17:49 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 194B3DC0 for ; Sun, 22 Jan 2017 14:17:49 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id DD092300F3; Sun, 22 Jan 2017 14:17:48 +0000 (UTC) Date: Sun, 22 Jan 2017 14:17:48 +0000 To: freebsd-net@freebsd.org From: "ale (Alex Dupre)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFiEvww= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 14:17:49 -0000 YWxlIG1hcmtlZCAyIGlubGluZSBjb21tZW50cyBhcyBkb25lLgoKUkVQT1NJVE9SWQogIHJTIEZy ZWVCU0Qgc3JjIHJlcG9zaXRvcnkKClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5m cmVlYnNkLm9yZy9EOTI3MAoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmlld3MuZnJl ZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBhbGUsICNuZXR3 b3JrLCAjbWFucGFnZXMsIGp1bGlhbgpDYzogbWFuZHJlZSwgaW1wLCBmcmVlYnNkLW5ldC1saXN0 Cg== From owner-freebsd-net@freebsd.org Sun Jan 22 19:25:34 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 201FECBDC3D for ; Sun, 22 Jan 2017 19:25:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 103086BD for ; Sun, 22 Jan 2017 19:25:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0MJPXlo060382 for ; Sun, 22 Jan 2017 19:25:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216304] Adding xn0 to bridge0 causes kernel panic Date: Sun, 22 Jan 2017 19:25:33 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 19:25:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216304 --- Comment #3 from Kristof Provost --- Proposed patch: https://reviews.freebsd.org/D9290 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Jan 22 21:00:34 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F051DCBC0C4 for ; Sun, 22 Jan 2017 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 E729110A3 for ; Sun, 22 Jan 2017 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0ML01Nt074051 for ; Sun, 22 Jan 2017 21:00:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201701222100.v0ML01Nt074051@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 22 Jan 2017 21:00:34 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 21:00:35 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 165622 | [ndis][panic][patch] Unregistered use of FPU in k In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 In Progress | 206581 | bxe_ioctl_nvram handler is faulty New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic New | 213410 | [carp] service netif restart causes hang only whe New | 215874 | [patch] [icmp] [mbuf_tags] teach icmp_error() opt Open | 148807 | [panic] "panic: sbdrop" and "panic: sbsndptr: soc Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211031 | [panic] in ng_uncallout when argument is NULL Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ Open | 212018 | Enable IPSEC_NAT_T in GENERIC kernel configuratio Open | 213257 | Crash in IGB driver with ALTQ 19 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Jan 22 22:47:59 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 828EACBD841 for ; Sun, 22 Jan 2017 22:47:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 6EFC0925 for ; Sun, 22 Jan 2017 22:47:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0MMlxP2032052 for ; Sun, 22 Jan 2017 22:47:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216185] [tun] When I using Openconnect periodically tun device change state to DOWN. Date: Sun, 22 Jan 2017 22:47:59 +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-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc short_desc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 22:47:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216185 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-i386@FreeBSD.org | Summary|When I using Openconnect |[tun] When I using |periodically tun device |Openconnect periodically |change state to DOWN. |tun device change state to | |DOWN. Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 23 02:43:51 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99DFECBC0C2 for ; Mon, 23 Jan 2017 02:43:51 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F34A362; Mon, 23 Jan 2017 02:43:51 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id v0N2hg1k037081 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 22 Jan 2017 19:43:42 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id v0N2hgiG037078; Sun, 22 Jan 2017 19:43:42 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 22 Jan 2017 19:43:42 -0700 (MST) From: Warren Block To: Kristof Provost cc: =?ISO-8859-15?Q?Ermal_Lu=E7i?= , Bakul Shah , FreeBSD Net , Alan Somers Subject: Re: pf & NAT issue In-Reply-To: Message-ID: References: <20170120083555.ACCF9124AEA4@mail.bitblocks.com> <7C29D00C-94C0-4550-B1B2-CE307482B544@FreeBSD.org> <20170120203106.CD2C8124AEA4@mail.bitblocks.com> <20170120205933.8948A124AEA3@mail.bitblocks.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (wonkity.com [127.0.0.1]); Sun, 22 Jan 2017 19:43:43 -0700 (MST) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Jan 2017 02:43:51 -0000 On Fri, 20 Jan 2017, Kristof Provost wrote: > On 20 Jan 2017, at 22:12, Ermal Luçi wrote: >> Most probably your timeouts are aggressive on states garbage collection. >> Give a look to those state limit teardown it might improve things. >> > Less than 30 seconds seems extremely quick to time out. > I also wouldn’t expect pf to set up NAT state in the middle of a TCP > connection. > > It’s certainly worth a try to play with the timeouts though. > > It might be interesting to see what they’re set to right now. `pfctl -s all` > should show them. I had the defaults as shown by others, except src.track was zero by default. Setting this to 30 suddenly let some static content sites work, like img.bbstatic.com for BestBuy's website. From owner-freebsd-net@freebsd.org Mon Jan 23 15:39:06 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E8ADCBEB69 for ; Mon, 23 Jan 2017 15:39:06 +0000 (UTC) (envelope-from abs.kaher@oxfordknight.co.uk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 65AB59A3 for ; Mon, 23 Jan 2017 15:39:06 +0000 (UTC) (envelope-from abs.kaher@oxfordknight.co.uk) Received: by mailman.ysv.freebsd.org (Postfix) id 64EB6CBEB68; Mon, 23 Jan 2017 15:39:06 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 647C7CBEB67 for ; Mon, 23 Jan 2017 15:39:06 +0000 (UTC) (envelope-from abs.kaher@oxfordknight.co.uk) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0058.outbound.protection.outlook.com [104.47.0.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A47A9A2 for ; Mon, 23 Jan 2017 15:39:04 +0000 (UTC) (envelope-from abs.kaher@oxfordknight.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oxfordknightlimited.onmicrosoft.com; s=selector1-oxfordknight-co-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pCFAW+opyvvKSOR6i7UTG88iwXRWLnZIQ5oPvX8cGo0=; b=zfUT7vCx8mARYK05tikGZEfc6g3h705JTJy2P5WUwpXY+53m0HG1zxz3BeNwMofoOfSerREIrG7/77jmXzhbkwu8pLUZsN7JADB0++rXDHNgV2QCjlUb2TJzYkG3IPW7NSuJQNj8Ozt6wxfigqxpQfm4DuofP1nwkvrvmkcDQYs= Received: from AM4PR0202MB2929.eurprd02.prod.outlook.com (10.171.83.8) by AM4PR0202MB2929.eurprd02.prod.outlook.com (10.171.83.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 15:39:02 +0000 Received: from AM4PR0202MB2929.eurprd02.prod.outlook.com ([10.171.83.8]) by AM4PR0202MB2929.eurprd02.prod.outlook.com ([10.171.83.8]) with mapi id 15.01.0860.021; Mon, 23 Jan 2017 15:39:02 +0000 From: Abs Kaher To: "net@freebsd.org" Subject: Thread-Index: AdJ1jtGGqxNycwejRiC4fZQ4UN2FRw== Date: Mon, 23 Jan 2017 15:39:02 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=abs.kaher@oxfordknight.co.uk; x-originating-ip: [5.148.90.180] x-ms-office365-filtering-correlation-id: 1dc232fa-024c-4ef2-4a2c-08d443a5f4e6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0202MB2929; x-microsoft-exchange-diagnostics: 1; AM4PR0202MB2929; 7:mthgTuHjrPD28QhtLSSIqeuU4E3W9NlpvGQm2e29mMqBO9CN5w8AIVXU7Q830yj395CABOMw+OUHeiufYc130P/HW+gyqKJWTqJiMxMYSx62Yei/pgFO1M054DTYYbbkKI/mYtccNuyxz5pRVJwhaitOjTHhksyXoE8YexipGL7aX54vbdDMJFoiSIJS9w/D5fZuj/IvmX2x0N1YWgc52Nj29x6y/mbhuIuc7fN05AHgdl/T9grWiZib3Yu7CSJf1oR/nz6fnvyvjV5A9/5e/zi+T4/n0KvSuE0H+tNZHpVEjxnI4K7LnW/Hz87OrV5lfSPsTlg26tObr6MyNawP3VSsxq7a1GvQ1Y2ulZuzUG+uM6YVXPOQDOGb80EHNEQV9j5BVXdVg5JCJyG/VSFOwt2iuGHhJhLmI1OwKrGybZ7t7HrTgnsIBJ/6xRdEfROm6dcAiMFuLrfZvM8Vc3S4Ig== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(268783453032223)(22689398316574)(81160342030619)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(2016111802025)(6072148)(6043046); SRVR:AM4PR0202MB2929; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0202MB2929; x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39410400002)(39450400003)(39840400002)(189002)(199003)(99936001)(861006)(33656002)(790700001)(3280700002)(102836003)(5416004)(6116002)(3846002)(38730400001)(189998001)(54356999)(106356001)(50986999)(2351001)(236005)(105586002)(8936002)(101416001)(81156014)(25636003)(1730700003)(81166006)(2906002)(74482002)(53936002)(66066001)(77096006)(92566002)(122556002)(450100001)(6436002)(110136003)(7696004)(2900100001)(7906003)(107886002)(97736004)(2501003)(5890100001)(6916009)(71446004)(5640700003)(25786008)(9686003)(5406001)(606005)(42882006)(5630700001)(6306002)(55016002)(54556002)(99286003)(54896002)(86362001)(7736002)(74316002)(3660700001)(6506006)(733005)(68736007)(5660300001)(7099028)(15669805003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0202MB2929; H:AM4PR0202MB2929.eurprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: oxfordknight.co.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: oxfordknight.co.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 15:39:02.2459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b7ae72d-47e9-45d3-bacf-abc2032d6352 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0202MB2929 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Jan 2017 15:39:06 -0000 Abs Kaher | Consultant Oxford Knight Mobile: +44 7463 949962 abs.kaher@oxfordknight.co.uk www.oxfordknight.co.uk Follow us for roles, news and market updates: [cid:image001.png@01CED3C6.E78D1010][cid= :image002.png@01CED3C6.E78D1010] NOTICE: This email and any attachments to it may be confidential and are in= tended solely for the use of the individual to whom it was addressed. Any v= iews or opinions expressed are solely the views of the author and do not ne= cessarily represent those of Oxford Knight Limited. If you are not the inte= nded recipient of this email, you must neither take any action based upon i= ts contents, nor copy or show it to anyone. Please notify us immediately an= d delete it from your computer. Thank you. Oxford Knight Limited. Principal= place of business: Oxford Knight Limited, 4th Floor, 33 Cannon Street, Lon= don, EC4M 5SB. Company No. 7261762 NOTICE: This email and any attachments to it may be confidential and are in= tended solely for the use of the individual to whom it was addressed. Any v= iews or opinions expressed are solely the views of the author and do not ne= cessarily represent those of Oxford Knight Limited. If you are not the inte= nded recipient of this email, you must neither take any action based upon i= ts contents, nor copy or show it to anyone. Please notify us immediately an= d delete it from your computer. Thank you. Oxford Knight Limited. Principal= place of business: Oxford Knight Limited, 4th Floor, 33 Cannon Street, Lon= don, EC4M 5SB. Company No. 7261762 From owner-freebsd-net@freebsd.org Mon Jan 23 15:47:38 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4A10CBEFB9 for ; Mon, 23 Jan 2017 15:47:38 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from out.smtpout.orange.fr (out03.smtpout.orange.fr [193.252.22.212]) by mx1.freebsd.org (Postfix) with ESMTP id 4037D3A0 for ; Mon, 23 Jan 2017 15:47:37 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-yw0-f178.google.com ([209.85.161.178]) by mwinf5d52 with ME id brfx1u00x3rEd8Z03rfy6i; Mon, 23 Jan 2017 16:39:59 +0100 X-ME-Helo: mail-yw0-f178.google.com X-ME-Auth: Y29jaGFyZC1sYWJiZS5vbGl2aWVyQG9yYW5nZS5mcg== X-ME-Date: Mon, 23 Jan 2017 16:39:59 +0100 X-ME-IP: 209.85.161.178 Received: by mail-yw0-f178.google.com with SMTP id w75so138937118ywg.1; Mon, 23 Jan 2017 07:39:58 -0800 (PST) X-Gm-Message-State: AIkVDXJDNMef4P9MiFXpXnLBLQ6aVAMGk2ySpbYdo4aiyc3NJlz4zCnu0trJ3r4zr3UWzIr5mX4lRig99kNTtA== X-Received: by 10.55.151.199 with SMTP id z190mr26400127qkd.166.1485185997280; Mon, 23 Jan 2017 07:39:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.49.99 with HTTP; Mon, 23 Jan 2017 07:39:36 -0800 (PST) In-Reply-To: <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Mon, 23 Jan 2017 16:39:36 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending To: Matthew Macy Cc: Sean Bruno , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Jan 2017 15:47:39 -0000 On Thu, Jan 12, 2017 at 1:54 AM, Matthew Macy wrote: > > A flame graph for the core cycle count and a flame graph with cache > miss stats from pmc would be a great start. > > > > > > =E2=80=8BI didn't know the exact event name to use for cache miss stat= s, but > here are the flame graphs for CPU_CLK_UNHALTED_CORE: > > http://dev.bsdrp.net/netgate.r311848.CPU_CLK_UNHALTED_CORE.svg > > http://dev.bsdrp.net/netgate.r311849.CPU_CLK_UNHALTED_CORE.svg > > Thanks. Having twice as many txqs would definitely help. It's also clear > that there may be some sort of peformance issue in iflib_txq_drain. > Although it could just be non-stop cache misses on the packet headers. > > > =E2=80=8BAny news about the performance issue in iflib_txq_drain ? On a different hardware (PC Engine APU2), I've got -20% performance drop: x head r311848: packets per second + head r311849: packets per second +--------------------------------------------------------------------------= + | ++ x= | |+++ x xx x= | | |_A_|= | ||A| = | +--------------------------------------------------------------------------= + N Min Max Median Avg Stddev x 5 580021 588650 585676 585406.1 3550.8673 + 5 463865 467599 465428 465638.6 1437.9347 Difference at 95.0% confidence -119768 +/- 3950.78 -20.4589% +/- 0.558328% (Student's t, pooled s =3D 2708.9) =E2=80=8B =E2=80=8BBecause it's an AMD processor I didn't found the pmc equivalent of CPU_CLK_UNHALTED_CORE, then I've used BU_CPU_CLK_UNHALTED but I've no idea if it's the good one. http://dev.bsdrp.net/apu2.r311848.BU_CPU_CLK_UNHALTED.svg http://dev.bsdrp.net/apu2.r311849.BU_CPU_CLK_UNHALTED.svg =E2=80=8B =E2=80=8BThanks=E2=80=8B From owner-freebsd-net@freebsd.org Mon Jan 23 18:54:56 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BD37CBE971 for ; Mon, 23 Jan 2017 18:54:56 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 08C1BC5 for ; Mon, 23 Jan 2017 18:54:56 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id B1FCB362AD; Mon, 23 Jan 2017 18:54:55 +0000 (UTC) Date: Mon, 23 Jan 2017 18:54:55 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE Message-ID: <93a6f67060964cd00b603e5468b53836@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFiGUX8= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:54:56 -0000 YWRyaWFuIGFjY2VwdGVkIHRoaXMgcmV2aXNpb24uCmFkcmlhbiBhZGRlZCBhIHJldmlld2VyOiBh ZHJpYW4uClRoaXMgcmV2aXNpb24gaGFzIGEgcG9zaXRpdmUgcmV2aWV3LgoKUkVQT1NJVE9SWQog IHJTIEZyZWVCU0Qgc3JjIHJlcG9zaXRvcnkKClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2 aWV3cy5mcmVlYnNkLm9yZy9EOTI3MAoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmll d3MuZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBhbGUs ICNtYW5wYWdlcywganVsaWFuLCAjbmV0d29yaywgYWRyaWFuCkNjOiBtYW5kcmVlLCBpbXAsIGZy ZWVic2QtbmV0LWxpc3QK From owner-freebsd-net@freebsd.org Mon Jan 23 20:06:40 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2054DCBE943 for ; Mon, 23 Jan 2017 20:06:40 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCBDBAE7 for ; Mon, 23 Jan 2017 20:06:39 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd13.aul.t-online.de (fwd13.aul.t-online.de [172.20.27.62]) by mailout04.t-online.de (Postfix) with SMTP id 7AC9141B61F6 for ; Mon, 23 Jan 2017 21:06:31 +0100 (CET) Received: from [192.168.10.43] (GFMXG6Z-wh4u0zFeL0qEhNr4MSoDSsZD0BlAmI+2Q2swFt0K7p6oPg3eBqivyMkZNL@[86.56.56.128]) by fwd13.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cVksm-317VOy0; Mon, 23 Jan 2017 21:06:28 +0100 To: freebsd-net@freebsd.org From: diffusae Subject: RTL8153 Gigabit Ethernet USB Adapter Message-ID: <59a929e6-5d6d-5f15-6ff6-4c61bf4a14c0@t-online.de> Date: Mon, 23 Jan 2017 21:06:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: GFMXG6Z-wh4u0zFeL0qEhNr4MSoDSsZD0BlAmI+2Q2swFt0K7p6oPg3eBqivyMkZNL X-TOI-MSGID: 9da22525-9816-42d0-b32a-de1f339b76fb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Jan 2017 20:06:40 -0000 Hi! Maybe a noobs question but I am mostly familiar with Linux. Currently there is no driver for the RTL8153 Gigabit Ethernet Adapter. Bus 001 Device 004: ID 0bda:8153 Realtek Semiconductor Corp. https://www.freebsd.org/relnotes/CURRENT/hardware/support.html RealTek has a Unix (Linux) driver here: http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=56&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false#RTL8153 How can I compile a custome kernel with this driver? I am using FreeBSD 11.0-STABLE (RPI-B) #0 r308738 Regards, From owner-freebsd-net@freebsd.org Mon Jan 23 20:09:02 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8ED64CBE9C7 for ; Mon, 23 Jan 2017 20:09:02 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 596D2BCE for ; Mon, 23 Jan 2017 20:09:02 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-io0-x236.google.com with SMTP id v96so55899880ioi.0 for ; Mon, 23 Jan 2017 12:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=6w0xhGBnA1heVstYZ/gM+M2GFzWyywAOUBBUithVI+Q=; b=MTIlNkWAfRYDx92Z8HhqwFe5uSHRiCLiUxfwMJsPQ7gEHR4e2zjRHzOEXdA/kKU+gv Mo2fZgmpQcRA+PYaKrkxCqN5EDr5J25/bLAPKeY9DtQTrjXjDFZeNaIN4ixRY5/l2fsq ZP36UL2IzjsAVxfc7xeFo3yzwBVbszytel0RULAqxFNEAUT+oE4vru3b418zQ8kJGIU5 c7wTiqR5SzeSSzMVhVST7LnzuFo5FJrVlswIz+/CZASinXnb72sRQmLWNUSEERP9M902 7Msul+vZX+uat2SM2zk7tODmuMD1IW2rHAoUuqABlU/DdSHzKzuft923zbGaQ0kSQkbQ jIJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=6w0xhGBnA1heVstYZ/gM+M2GFzWyywAOUBBUithVI+Q=; b=SHBmw/8n0iQ9RiXTw4YwnKeeobIch55jb60Ifp/Zr3JM9C/nvPdU3TEbs3kSkE98LW 3g2COowjLLAtmaHbYCAavfefd0jSF5Ig8aPgZXvkbR4/UbURe/j60QqET/TjxvKoOGfl lZjPp4Vcj+wP1nw0Ej+RM8xFuB+l6o21sTgi5FdFpeVuTRWGNxG5zD2JfDRmWisEDRsP aH/mKvt6/yklZR57OeMGL4vPmip87d3lGQ3zZMbRUIkRh6sAmIGJukqLj4MaAURo9ZA/ qlT5xde47iic46H5LJDYSWHZxpEHsXjF2syx+YNlyjICp322318vLvdoH3xZN+u4tsnI 0n3A== X-Gm-Message-State: AIkVDXKOyePu3dKXnsqLMsvKkyn/ERhdo177wEceZh4j1y5ZDhO+x+9JGNMvVSwe+gdtTmBizV9wBkpm/cKt3A== X-Received: by 10.107.136.195 with SMTP id s64mr23346752ioi.51.1485202141619; Mon, 23 Jan 2017 12:09:01 -0800 (PST) MIME-Version: 1.0 Sender: sunxiaoye07@gmail.com Received: by 10.64.213.98 with HTTP; Mon, 23 Jan 2017 12:09:01 -0800 (PST) From: Xiaoye Sun Date: Mon, 23 Jan 2017 14:09:01 -0600 X-Google-Sender-Auth: BL0H9Kgq8fR8BMCCole6xxP5Siw Message-ID: Subject: High priority for the tx queue in netmap To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Jan 2017 20:09:02 -0000 Hi, In my application, there are multiple tx queues in the OS, and the netmap program uses one tx queue. I wondering if I can give the netmap tx queue higher priority so that the NIC always sends the packets from this queue if netmap put any packet to it. I am using Linux 3.16. Thanks! Best, Xiaoye From owner-freebsd-net@freebsd.org Mon Jan 23 20:25:24 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CC55CBEE4B for ; Mon, 23 Jan 2017 20:25:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 299E87F2 for ; Mon, 23 Jan 2017 20:25:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EC1C71FE100; Mon, 23 Jan 2017 21:24:55 +0100 (CET) Subject: Re: RTL8153 Gigabit Ethernet USB Adapter To: diffusae , freebsd-net@freebsd.org References: <59a929e6-5d6d-5f15-6ff6-4c61bf4a14c0@t-online.de> From: Hans Petter Selasky Message-ID: Date: Mon, 23 Jan 2017 21:24:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <59a929e6-5d6d-5f15-6ff6-4c61bf4a14c0@t-online.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Jan 2017 20:25:24 -0000 On 01/23/17 21:06, diffusae wrote: > Hi! > > Maybe a noobs question but I am mostly familiar with Linux. > > Currently there is no driver for the RTL8153 Gigabit Ethernet Adapter. > > Bus 001 Device 004: ID 0bda:8153 Realtek Semiconductor Corp. > > https://www.freebsd.org/relnotes/CURRENT/hardware/support.html > > RealTek has a Unix (Linux) driver here: > > http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=56&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false#RTL8153 > > How can I compile a custome kernel with this driver? > > I am using FreeBSD 11.0-STABLE (RPI-B) #0 r308738 > Hi, Have a look in sys/dev/usb/net and see if you find any similar devices. I think your driver is already supported. You need to: 1) kldload usb_quirk 2) kldload if_ure 3) replug your device and it should attach (FreeBSD-12 at least) grep -r 8153 /usr/src/sys/dev/usb --HPS From owner-freebsd-net@freebsd.org Tue Jan 24 01:31:29 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94FCDCBDE4E for ; Tue, 24 Jan 2017 01:31:29 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7545662D for ; Tue, 24 Jan 2017 01:31:29 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v0O1VMcu005208 for ; Mon, 23 Jan 2017 17:31:26 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201701240131.v0O1VMcu005208@gw.catspoiler.org> Date: Mon, 23 Jan 2017 17:31:22 -0800 (PST) From: Don Lewis Subject: inheriting fib from an interface To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 01:31:29 -0000 Let's say that I have an application running on a server that is connected to the Internet via two different ISPs and is using IP addresses (ISP A:10.0.0.10 and ISP B:192.168.1.10) delegated by those two ISPs on it's two interfaces. Responses to requests sent to 10.0.0.10 should be sent via ISP A, and responses to requests sent to 192.168.1.10 should be ISB B. There are a couple of different ways that I can think of to do this: 1) Put the server behind another FreeBSD box that uses policy-based routing to forward the outbound packets to the desired ISP. My understanding is that this only works for packet forwarding and not for locally generated packets. 2) Set net.fibs=2, set separate default routes for the two fibs, modify the application to create and bind sockets to both IP addresses, and call setsockopt(..., SO_SETFIB, ...) on each. This is a bit of a headache because it requires maintaining source code changes for the application. Also the SO_SETFIB settings in the application need to be kept synchronized to the system configuration, which looks like it could be error-prone. Running two instances of the application under setfib might be undesirable. FreeBSD can also associate a fib with an interface. From the brief reading that I've done, it looks like this is only used to tag incoming packets with the fib of the interface that they are received on and thus influence the routing decisions made when forwarding them. It seems like it would be useful for a socket to inherit the fib of the matching interface when bind() is called on it. Since connect() may also do a bind, perhaps the fib should be inherited then as well. Also when a TCP socket listening on INADDR_ANY receives a connection request and returns a new socket via accept(), perhaps that socket should have its fib set as well. Thoughts? From owner-freebsd-net@freebsd.org Tue Jan 24 01:40:49 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A23B7CBE4A1; Tue, 24 Jan 2017 01:40:49 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B3DEB87; Tue, 24 Jan 2017 01:40:48 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-248-244.albq.qwest.net [67.0.248.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id EF9941928BA; Tue, 24 Jan 2017 01:40:46 +0000 (UTC) Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending To: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= , Matthew Macy References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" From: Sean Bruno Message-ID: <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> Date: Mon, 23 Jan 2017 18:40:43 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4kX657crq1w9S5xfNFjXBVMHRSJKhxwCR" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 01:40:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4kX657crq1w9S5xfNFjXBVMHRSJKhxwCR Content-Type: multipart/mixed; boundary="Ix9TlJ5t959KvkbWH2LshuUEiAmGO6UVL"; protected-headers="v1" From: Sean Bruno To: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= , Matthew Macy Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Message-ID: <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> In-Reply-To: --Ix9TlJ5t959KvkbWH2LshuUEiAmGO6UVL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/23/17 08:39, Olivier Cochard-Labb=C3=A9 wrote: >=20 > On Thu, Jan 12, 2017 at 1:54 AM, Matthew Macy > wrote: >=20 > > A flame graph for the core cycle count and a flame graph with > cache miss stats from pmc would be a great start. > > > > > > =E2=80=8BI didn't know the exact event name to use for cache mis= s stats, > but here are the flame graphs for CPU_CLK_UNHALTED_CORE: > > http://dev.bsdrp.net/netgate.r311848.CPU_CLK_UNHALTED_CORE.svg > > > http://dev.bsdrp.net/netgate.r311849.CPU_CLK_UNHALTED_CORE.svg > >=20 > Thanks. Having twice as many txqs would definitely help. It's also > clear that there may be some sort of peformance issue in > iflib_txq_drain. Although it could just be non-stop cache misses on= > the packet headers. >=20 >=20 > =E2=80=8BAny news about the performance issue in iflib_txq_drain ? >=20 > On a different hardware (PC Engine APU2), I've got -20% performance dro= p: >=20 > x head r311848: packets per second > + head r311849: packets per second > +----------------------------------------------------------------------= ----+ > | ++ = x| > |+++ x = xx x| > | |= _A_|| > ||A| = | > +----------------------------------------------------------------------= ----+ > N Min Max Median Avg St= ddev > x 5 580021 588650 585676 585406.1 3550.= 8673 > + 5 463865 467599 465428 465638.6 1437.= 9347 > Difference at 95.0% confidence > -119768 +/- 3950.78 > -20.4589% +/- 0.558328% > (Student's t, pooled s =3D 2708.9) > =E2=80=8B > =20 > =E2=80=8BBecause it's an AMD processor I didn't found the pmc equivalen= t of > CPU_CLK_UNHALTED_CORE, then I've used BU_CPU_CLK_UNHALTED but I've no > idea if it's the good one. >=20 > http://dev.bsdrp.net/apu2.r311848.BU_CPU_CLK_UNHALTED.svg > http://dev.bsdrp.net/apu2.r311849.BU_CPU_CLK_UNHALTED.svg > =E2=80=8B > =E2=80=8BThanks=E2=80=8B >=20 >=20 Olivier: Which set of configs from your test suite are you using for this? Specifically, what packet size are you slamming across? https://github.com/ocochard/netbenches/tree/master/pktgen.configs sean --Ix9TlJ5t959KvkbWH2LshuUEiAmGO6UVL-- --4kX657crq1w9S5xfNFjXBVMHRSJKhxwCR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAliGsJtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y fmT5fgf7B9ORzSHAo7OzfCsB+pYIvU2hEcQt1CIf3+OFE4/0WdkIbkhGqVNZlbRI q+qK3CYoGCo/82HLR8mo2CAk17auFN+/MtWcCi8u5so87RYyl8bbMpNvmKXA5V+f EMCxQOSF41Z2t3Jmk/JmK27hQ2VFHxntmiqHlbx4rhSpysRmqgVVDHpi3zIaqOT2 Upzqvd+rdpBl5pPQUO+FrjpFnGUPyMt1MzDJNU2uJwe5U1SDbZEzC8PP3huJOrwI 0G4o05bJ9herkro1+y+cSH5wlE6mnJ8FGLzP7VxHH6AapBe3WJ4l9lfyx+O6tWdQ fyaglB/fRbGG/eS984pbmhF07bMkhQ== =c8G7 -----END PGP SIGNATURE----- --4kX657crq1w9S5xfNFjXBVMHRSJKhxwCR-- From owner-freebsd-net@freebsd.org Tue Jan 24 06:39:08 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D087CBCA24 for ; Tue, 24 Jan 2017 06:39:08 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7B0116 for ; Tue, 24 Jan 2017 06:39:06 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-qt0-f172.google.com ([209.85.216.172]) by mwinf5d64 with ME id c6XS1u00o3jlGMd036XTTe; Tue, 24 Jan 2017 07:31:28 +0100 X-ME-Helo: mail-qt0-f172.google.com X-ME-Auth: Y29jaGFyZC1sYWJiZS5vbGl2aWVyQG9yYW5nZS5mcg== X-ME-Date: Tue, 24 Jan 2017 07:31:28 +0100 X-ME-IP: 209.85.216.172 Received: by mail-qt0-f172.google.com with SMTP id l7so166530083qtd.1; Mon, 23 Jan 2017 22:31:27 -0800 (PST) X-Gm-Message-State: AIkVDXJrZhBfUoV5fPgNON84ztsCgM1Oav6hVo4EDz0K8XOpjkea4o6Zh++4+lgavccWYwo8xjQZ4WZMwzvwXA== X-Received: by 10.200.1.11 with SMTP id e11mr26112945qtg.85.1485239486391; Mon, 23 Jan 2017 22:31:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.49.99 with HTTP; Mon, 23 Jan 2017 22:31:05 -0800 (PST) In-Reply-To: <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Tue, 24 Jan 2017 07:31:05 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending To: Sean Bruno Cc: Matthew Macy , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 06:39:08 -0000 On Tue, Jan 24, 2017 at 2:40 AM, Sean Bruno wrote: > > > Which set of configs from your test suite are you using for this? > Specifically, what packet size are you slamming across? > > https://github.com/ocochard/netbenches/tree/master/pktgen.configs > =E2=80=8BBecause I'm in the point of view of a Telco, I'm measuring the =C2= =ABworst=C2=BB case, this mean with the smallest frame size. Here is the exact pkt-gen command line I'm using: - 60 byte Ethernet frame size (excluding the 4 CRC bytes) - 2000 UDP flows (20 IP sources * 100 IP destinations) pkt-gen -U -i igb2 -f tx -n 80000000 -l 60 -d 198.19.10.1:2000-198.19.10.20 -D 00:0d:b9:41:ca:3d -s 198.18.10.1:2000-198.18.10.100 -w 4 =E2=80=8BOption -U is available on a patched netmap version [1]: It fix the checksum calculation when using source/destination IP range on NIC that didn't enable HW CHKSUM in netmap mode and IPv6 support. [1] https://github.com/ocochard/BSDRP/blob/master/BSDRPcur/patches/freebsd.pkt-= gen.ae-ipv6.patch From owner-freebsd-net@freebsd.org Tue Jan 24 06:57:14 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E1A3CBF09D for ; Tue, 24 Jan 2017 06:57:14 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 441C7C62 for ; Tue, 24 Jan 2017 06:57:14 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-vk0-x22e.google.com with SMTP id k127so106073068vke.0 for ; Mon, 23 Jan 2017 22:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1FUbCV4KloSrpGR5qJfCxD0X4yIKAlbK89vEOhJAfF4=; b=UUwRQQJdRxTeiiGFHWsy9eg2c5RD7oeMaHbeB6DHRf9yIJWtg0p8oZz7QNIkMuF++y Ok/p0Bs1bJymsDMm+SgBS3WaWRZqDtOghLNDSz3yx/pos0BjTNQf7N1Z4IrV612mGhUX OvvtfjCCpzrtlbB1vshWbMDrwI+jxPNxyFiCUYWcFw1AN56ogkdfNrSRt7gl8NulpYkB q1ULYzWH2wvEbxZ7O5jyUe0VifO4IfVTPRiPfAJ6dtAiXT1S0JD8+qQmXUNwaITdQ1rR A91zFOIfcdbNgzB25cF1C8hlFSv7w9Wiywus1cJyLHTcrcakTCcIoQsEiXpxA7ZW3eXB tjoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1FUbCV4KloSrpGR5qJfCxD0X4yIKAlbK89vEOhJAfF4=; b=bxeJ9Ee+h23UbZW2mnyw1J8HKHEZ8GSLj6WCvs+GuNQwTaTiXTbCQlHoI1PCxObWBE f1CttB14bGNaDQohunZpukogh1ENZUKC39HHtc/I3iqGCsMFEzTUScMJg5kIubb/TTZP OvpLMRdFoUvv7SvJ39J7oOQHpGQkZR2GPkS7hw9vVUcU0A45CCt1c80S2XjpPgYqXwfK ZPyCmvCJ+e8JMKtbh1aS+TzOVpOj99QzWr84vhHGiuReCpUMmdQcURmAWeUuccVvIUxW URy0vCNRmmCIhqmfdMlsl75V/LTA2hA7Y1vrYUebegfMvvNQMrHmGje7hYRQzWhRsN9W pAUw== X-Gm-Message-State: AIkVDXInKj7G78GkXkQ0b/cbI6hZIM3tvgib1iiv1uQ4pBdsem4VfnQzEzKd+uMBnZOu2oJkb4vDNKhIw3mYOQ== X-Received: by 10.31.168.145 with SMTP id r139mr15050050vke.148.1485241033301; Mon, 23 Jan 2017 22:57:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.10 with HTTP; Mon, 23 Jan 2017 22:57:12 -0800 (PST) In-Reply-To: References: From: Sepherosa Ziehau Date: Tue, 24 Jan 2017 14:57:12 +0800 Message-ID: Subject: Re: High priority for the tx queue in netmap To: Xiaoye Sun Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 06:57:14 -0000 On Tue, Jan 24, 2017 at 4:09 AM, Xiaoye Sun wrote: > Hi, > > In my application, there are multiple tx queues in the OS, and the netmap > program uses one tx queue. I wondering if I can give the netmap tx queue > higher priority so that the NIC always sends the packets from this queue if > netmap put any packet to it. You need to check your NIC chip vendor for this. Thanks, sephe From owner-freebsd-net@freebsd.org Tue Jan 24 07:17:37 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9938CBF5AA for ; Tue, 24 Jan 2017 07:17:37 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93FC06C0 for ; Tue, 24 Jan 2017 07:17:37 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id x75so106462851vke.2 for ; Mon, 23 Jan 2017 23:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bluPNxkojiTZUR2GjkSIQNDWVZiuB1P8EwpwzTBo4L0=; b=FvSIPnd+HylDzfKJJvNzLnZuwCzORNOjX0gKohI1mesmNAQdRRQzn7Mjt1TEEP2c5P ZenrNLxcoGD/ujskqekdhumPdPCzgEBkVtogu1zAcu8epznXkovHJoC5Ude58heLJyPr j53OuY56m/3juPOag5tkw8XO4EfNGInuRpZSSTeLB+HYfiVQrh3Q3mJUH05jDoDqU8ZH kpXEQjD04MuevkBvhtnUtxY6Q96uUMIOcW4AQYnS2XCIwGYKdsypIfJEV89NVhJWPPyq Tbx9iYMAkI5zRODJhI09tcWYwbNXu33dyymkPg8L6Tu5CzmQtE8Uour0S7pNEssADE0f 199w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bluPNxkojiTZUR2GjkSIQNDWVZiuB1P8EwpwzTBo4L0=; b=CgyHdV9qy73lPzp4x/k/N9drbWBnH+PwJXTjGu2npeQ3SCWXeNHIYdJpOOpbIJXx/T o45hM0LGTV2sKIQ/ojw21XrbHSztNYBDV+/tPJMTS0rc/yYPQmq9atP9utj+UEmkOsaT WOZKD2q5wrhg4MdOFEUOkW/LQwwM96iyNKd5J1gE3FvpjmngW8OPk62kx9qQbiYoJz8p 8qHRqEADP5yPkC8OxjDhFgCffAF684mCRFDpwXRE8zks0FfwU5wVSWc8V4B+GIO+dqWB ZfhZsj9zP/q6PqE5a0/DXGRB6Gh5+FWEaoy/ud0vL3dL2FUYuZuva6uv0PLxIE+iw6O3 FQ7A== X-Gm-Message-State: AIkVDXJZ+kPyXhpcvI6LOWmiR1Jo7AiVqz/ZCyulg9JKZoBeeL659h2iUZFXScrbaGb2v3rxavZOYxz5Bvs4Zw== X-Received: by 10.31.14.142 with SMTP id 136mr15590846vko.56.1485242255709; Mon, 23 Jan 2017 23:17:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.10 with HTTP; Mon, 23 Jan 2017 23:17:35 -0800 (PST) In-Reply-To: References: From: Sepherosa Ziehau Date: Tue, 24 Jan 2017 15:17:35 +0800 Message-ID: Subject: Re: High priority for the tx queue in netmap To: Xiaoye Sun Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 07:17:37 -0000 On Tue, Jan 24, 2017 at 3:00 PM, Xiaoye Sun wrote: > I'm using the typical intel 10 Gbps nic. > Does ethtool have related configuration command? You can check Intel's spec on their website for the chip you use. They have very good documentation. IIRC, the default behavior is to round-robin TX queue on packet boundary (after TSO segementation). Don't know about Linux driver's state, but you have the detailed document, you can always change the code as you like for your own stuffs. Thanks, sephe -- Tomorrow Will Never Die From owner-freebsd-net@freebsd.org Tue Jan 24 08:23:17 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E0CFCBFEFB for ; Tue, 24 Jan 2017 08:23:17 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61B82E5F for ; Tue, 24 Jan 2017 08:23:17 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x236.google.com with SMTP id w204so94972003oiw.0 for ; Tue, 24 Jan 2017 00:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cdrdmn7rZ5cMvBLSlkPgcACb9HkBxwLROC6KqpgobO0=; b=vYYO/zW4VkNWzrcoNaGLZYJkJlU6L0jbG2ueujmzYQpDUAHZY1Krs6UK3FROktgvFD QSzQTRFiL/jbYdJ99ngkc3GtkhAOsg6FfZcaD5ONL/a7Yu4btj8XmYvynObGVtY0iDVn /KMCGsQWKAiL974lJnzUeKpD93Q1aUmTJabocW+SxAYLevvCeslO2d5IsYNes29TZu2h 8Y4NibB5IbIfuSp/gdA4FlY1AWdQlWzdoTshpCa12TGo1RzH7BKfr9CnAh0tDnIKXSgL lTgd2ApjFoDVxYne1U+4jYguUEpv8ONFKAHM4pZi/nxAXgb/3VlFKUo4bjSl9tDITNbn Aguw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cdrdmn7rZ5cMvBLSlkPgcACb9HkBxwLROC6KqpgobO0=; b=qo7JRg2yE22O8fy9ZCiqlevDQDm1Ssn6ZxK1nDbRkL9yHsPdjWDw/W785fnxaDy8Vv bS8Lhz4dVjZRaWTtPTGhwCdDya7+t9vnWDxCKJfiuqrTdtaYS/lC4nCsp+FwV0BQ9kNh nmprRXEhjabYHwMxAXmCGpOHaY9R9Kp7tzS2l9Z7VCMsZFMKWu3M/jy2/xq9BG/VeXX7 Csbeg/QQhdi7UxxWg8JclwSMh/0yJT/oVcbqCsnLc/FeilpKJnObO3Vbb0WJvGg6KBDL U/KAktsBUE5SblIbPJ8Aamd3L140d2AF9VzcrT9zBhR59RwLYOfvux6qB2WrA/4x1R9w kgmg== X-Gm-Message-State: AIkVDXJFWHXjoVpDISCFtu+nkDsXvS7qcmpkTyuupJzKK+14xPTOXyLyJEey0ROmZDY/QZtXJJC5iQz5S9XQIw== X-Received: by 10.202.95.5 with SMTP id t5mr14984338oib.103.1485246196819; Tue, 24 Jan 2017 00:23:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.6.166 with HTTP; Tue, 24 Jan 2017 00:23:16 -0800 (PST) In-Reply-To: References: From: Vincenzo Maffione Date: Tue, 24 Jan 2017 09:23:16 +0100 Message-ID: Subject: Re: High priority for the tx queue in netmap To: Sepherosa Ziehau Cc: Xiaoye Sun , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 08:23:17 -0000 Hi, I think with ethtool on Linux you can play at least with the weight to give to each TX queue for the round-robin algorithm. Of course not all the cards implement this. I think Intel 10Gbit cards support it. Cheers, VIncenzo 2017-01-24 8:17 GMT+01:00 Sepherosa Ziehau : > On Tue, Jan 24, 2017 at 3:00 PM, Xiaoye Sun wrote: > > I'm using the typical intel 10 Gbps nic. > > Does ethtool have related configuration command? > > You can check Intel's spec on their website for the chip you use. > They have very good documentation. IIRC, the default behavior is to > round-robin TX queue on packet boundary (after TSO segementation). > > Don't know about Linux driver's state, but you have the detailed > document, you can always change the code as you like for your own > stuffs. > > Thanks, > sephe > > -- > Tomorrow Will Never Die > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Tue Jan 24 09:20:04 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CD04CBD41E for ; Tue, 24 Jan 2017 09:20:04 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id BDB01637 for ; Tue, 24 Jan 2017 09:20:03 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id F12B836600; Tue, 24 Jan 2017 09:20:02 +0000 (UTC) Date: Tue, 24 Jan 2017 09:20:02 +0000 To: freebsd-net@freebsd.org From: Phabricator Reply-to: D8963+325+d689c69326b9ae09@reviews.freebsd.org Subject: [Differential] D8963: ifnet: introduce event handlers for ifup/ifdown events Message-ID: <2a47387418f6a714560673bb0d6b8b10@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D8963: ifnet: introduce event handlers for ifup/ifdown events X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: Y2E4NDdjNWVjOGM5NzQ0Mjk1ZTMzMGM0ZDY2IFiHHEI= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_2a47387418f6a714560673bb0d6b8b10" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 09:20:04 -0000 --b1_2a47387418f6a714560673bb0d6b8b10 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 VGhpcyByZXZpc2lvbiB3YXMgYXV0b21hdGljYWxseSB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIGNv bW1pdHRlZCBjaGFuZ2VzLgpDbG9zZWQgYnkgY29tbWl0IHJTMzEyNjg3OiBpZm5ldDogaW50cm9k dWNlIGV2ZW50IGhhbmRsZXJzIGZvciBpZnVwL2lmZG93biBldmVudHMgKGF1dGhvcmVkIGJ5IGRl eHVhbikuCgpDSEFOR0VEIFBSSU9SIFRPIENPTU1JVAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNk Lm9yZy9EODk2Mz92cz0yMzY1MiZpZD0yNDM3NCN0b2MKClJFUE9TSVRPUlkKICByUyBGcmVlQlNE IHNyYyByZXBvc2l0b3J5CgpDSEFOR0VTIFNJTkNFIExBU1QgVVBEQVRFCiAgaHR0cHM6Ly9yZXZp ZXdzLmZyZWVic2Qub3JnL0Q4OTYzP3ZzPTIzNjUyJmlkPTI0Mzc0CgpSRVZJU0lPTiBERVRBSUwK ICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDg5NjMKCkFGRkVDVEVEIEZJTEVTCiAgaGVh ZC9zeXMvbmV0L2lmLmMKICBoZWFkL3N5cy9zeXMvZXZlbnRoYW5kbGVyLmgKCkVNQUlMIFBSRUZF UkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3NldHRpbmdzL3BhbmVsL2VtYWls cHJlZmVyZW5jZXMvCgpUbzogZGVjdWlfbWljcm9zb2Z0LmNvbSwgaHNlbGFza3ksIGNlbSwgbnAs IGttYWN5LCBraWIsIGhvbnpoYW5fbWljcm9zb2Z0LmNvbSwgaG93YXJkMHN1X2dtYWlsLmNvbSwg amhiLCBhZSwgZGVscGhpaiwgcm95Z2VyLCBnbGViaXVzLCBnbm4sIHJ3YXRzb24sIHNlcGhlcm9z YV9nbWFpbC5jb20KQ2M6IGdhcmdhLCBmcmVlYnNkLW5ldC1saXN0Cg== --b1_2a47387418f6a714560673bb0d6b8b10 Content-Type: text/x-patch; charset=utf-8; name="D8963.24374.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D8963.24374.patch" ZGlmZiAtLWdpdCBhL2hlYWQvc3lzL3N5cy9ldmVudGhhbmRsZXIuaCBiL2hlYWQvc3lzL3N5cy9l dmVudGhhbmRsZXIuaAotLS0gYS9oZWFkL3N5cy9zeXMvZXZlbnRoYW5kbGVyLmgKKysrIGIvaGVh ZC9zeXMvc3lzL2V2ZW50aGFuZGxlci5oCkBAIC0yODQsNCArMjg0LDExIEBACiBFVkVOVEhBTkRM RVJfREVDTEFSRShzd2Fwb24sIHN3YXBvbl9mbik7CiBFVkVOVEhBTkRMRVJfREVDTEFSRShzd2Fw b2ZmLCBzd2Fwb2ZmX2ZuKTsKIAorLyogaWZ1cC9pZmRvd24gZXZlbnRzICovCisjZGVmaW5lIElG TkVUX0VWRU5UX1VQCQkwCisjZGVmaW5lIElGTkVUX0VWRU5UX0RPV04JMQorc3RydWN0IGlmbmV0 OwordHlwZWRlZiB2b2lkICgqaWZuZXRfZXZlbnRfZm4pKHZvaWQgKiwgc3RydWN0IGlmbmV0ICpp ZnAsIGludCBldmVudCk7CitFVkVOVEhBTkRMRVJfREVDTEFSRShpZm5ldF9ldmVudCwgaWZuZXRf ZXZlbnRfZm4pOworCiAjZW5kaWYgLyogX1NZU19FVkVOVEhBTkRMRVJfSF8gKi8KZGlmZiAtLWdp dCBhL2hlYWQvc3lzL25ldC9pZi5jIGIvaGVhZC9zeXMvbmV0L2lmLmMKLS0tIGEvaGVhZC9zeXMv bmV0L2lmLmMKKysrIGIvaGVhZC9zeXMvbmV0L2lmLmMKQEAgLTU5LDYgKzU5LDcgQEAKICNpbmNs dWRlIDxzeXMvZG9tYWluLmg+CiAjaW5jbHVkZSA8c3lzL2phaWwuaD4KICNpbmNsdWRlIDxzeXMv cHJpdi5oPgorI2luY2x1ZGUgPHN5cy9ldmVudGhhbmRsZXIuaD4KIAogI2luY2x1ZGUgPG1hY2hp bmUvc3RkYXJnLmg+CiAjaW5jbHVkZSA8dm0vdW1hLmg+CkBAIC0yMjE4LDYgKzIyMTksNyBAQAog aWZfZG93bihzdHJ1Y3QgaWZuZXQgKmlmcCkKIHsKIAorCUVWRU5USEFORExFUl9JTlZPS0UoaWZu ZXRfZXZlbnQsIGlmcCwgSUZORVRfRVZFTlRfRE9XTik7CiAJaWZfdW5yb3V0ZShpZnAsIElGRl9V UCwgQUZfVU5TUEVDKTsKIH0KIApAQCAtMjIzMCw2ICsyMjMyLDcgQEAKIHsKIAogCWlmX3JvdXRl KGlmcCwgSUZGX1VQLCBBRl9VTlNQRUMpOworCUVWRU5USEFORExFUl9JTlZPS0UoaWZuZXRfZXZl bnQsIGlmcCwgSUZORVRfRVZFTlRfVVApOwogfQogCiAvKgoK --b1_2a47387418f6a714560673bb0d6b8b10-- From owner-freebsd-net@freebsd.org Tue Jan 24 10:13:38 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 494F0CBF80C for ; Tue, 24 Jan 2017 10:13:38 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BF6871D80; Tue, 24 Jan 2017 10:13:35 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v0O9tiUl096705 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Jan 2017 10:55:45 +0100 (CET) (envelope-from eugen@eg.sd.rdtc.ru) X-Envelope-From: eugen@eg.sd.rdtc.ru X-Envelope-To: truckman@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id v0O9tehp024813 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Jan 2017 16:55:40 +0700 (KRAT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.15.2/8.15.2/Submit) id v0O9td4n024811; Tue, 24 Jan 2017 16:55:39 +0700 (KRAT) (envelope-from eugen) Date: Tue, 24 Jan 2017 16:55:39 +0700 From: Eugene Grosbein To: Don Lewis Cc: freebsd-net@FreeBSD.org Subject: Re: inheriting fib from an interface Message-ID: <20170124095539.GA18648@rdtc.ru> References: <201701240131.v0O1VMcu005208@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201701240131.v0O1VMcu005208@gw.catspoiler.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,LOCAL_FROM,RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain * 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail * domains are different * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 10:13:38 -0000 On Mon, Jan 23, 2017 at 05:31:22PM -0800, Don Lewis wrote: > Let's say that I have an application running on a server that is > connected to the Internet via two different ISPs and is using IP > addresses (ISP A:10.0.0.10 and ISP B:192.168.1.10) delegated by those > two ISPs on it's two interfaces. Responses to requests sent to > 10.0.0.10 should be sent via ISP A, and responses to requests sent to > 192.168.1.10 should be ISB B. > > There are a couple of different ways that I can think of to do this: > > 1) Put the server behind another FreeBSD box that uses policy-based > routing to forward the outbound packets to the desired ISP. My > understanding is that this only works for packet forwarding and not > for locally generated packets. Single command "ipfw add 2000 fwd $ispgw2 ip from $ip2 to any out xmit $isp1_iface" works for locally generated packets too. It "fixes" outgoing routing path for packets from IP belonging to "non-default" ISP2 when default route points to ISP1. From owner-freebsd-net@freebsd.org Tue Jan 24 10:22:45 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF483CBFBCC for ; Tue, 24 Jan 2017 10:22:45 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (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 5E00135B for ; Tue, 24 Jan 2017 10:22:45 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (unknown [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPA id DEF589DC9D1; Tue, 24 Jan 2017 11:14:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: RFC: ethctl From: Borja Marcos In-Reply-To: <201701201836.v0KIailL014327@hergotha.csail.mit.edu> Date: Tue, 24 Jan 2017 11:14:45 +0100 Cc: gallatin@netflix.com, freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201701201836.v0KIailL014327@hergotha.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 10:22:46 -0000 > On 20 Jan 2017, at 19:36, Garrett Wollman = wrote: >=20 > In article you = write: >> Eg, I don't see why we need another tool for some of this missing >> "ethtool" functionality; it seems like most of it would naturally fit >> into ifconfig. >=20 > =46rom the end-user perspective, I agree with Drew. Most of this = stuff > should just be part of ifconfig. Actually I have a concern regarding the ethtool inspiration. I am sure = it=E2=80=99s not the only factor at play, but I think that the decision to include options such as autonegotiation = or forced speed/duplex modes in ifconfig helped FreeBSD drivers to be more consistent. In the old days = when Fast Ethernet ruled and so many devices got negotiation wrong my few interactions with Linux systems = were really frustrating. Either the ethtool package wasn=E2=80=99t installed, or it was the wrong version, or the = driver just didn=E2=80=99t support ethtool. More recently I faced a bug in an Intel driver: media detection didn=E2=80= =99t work properly for 10 GbE DA cables.=20 The interface worked, but the it didn=E2=80=99t get marked as full = duplex, which meant that lagg rightfully refused to use it in LACP mode (LACP mandates full duplex interfaces). Debugging it on FreeBSD was a somewhat straightforward task. It was easy = to determine why lagg refused to use it, ifconfig indeed reflected the =E2=80=9Cunknown duplexness=E2=80=9D and = it gave me a good pointer to the issue (driver problem). My coworkers told me that they were facing a similar problem on some = Linux systems and I tried to have a look at it. But looking at the whole ifconfig/ethtool stuff I believe (note, _I = believe_, I didn=E2=80=99t have time to pay more attention to it and it wasn=E2=80=99t critical for us anyway) that ethtool didn=E2=80=99t = report the actual interface status from the operating system point of = view, but it rather polled the network interface itself and represented its = own picture. So, while the same issue was probably causing LACP not to work, which = would mean that the interface wasn=E2=80=99t considered full-duplex, the system=E2=80=99s ifconfig did not show anything about = it, and ethtool probably deducted by itself that the interface was actually full duplex, after all half-duplex 10 GbE doesn=E2=80=99t = exist. The moral of the story is: ifconfig being tightly coupled to the OS is = more likely to be made to present the proper information. What about an ethtool-class command? I guess there is a risk that, being = more close to hardware, in the future it might be subject to a similar problem to that one I believe ethtool to have.=20 I understand that it wouldn=E2=80=99t be a Linux-style optional package, = but part of the system, which should remove the concerns about driver support. But, anyway, given that ifconfig is already = supporting plenty of media/driver options, wouldn=E2=80=99t it be better to refine it a bit and leave the handful of esoteric operations to a = driver specific tool? At least it=E2=80=99s cleaner I think. Just my opinion, based in part on = beliefs and, I admit it, on having been burned by linuxisms. Borja. From owner-freebsd-net@freebsd.org Tue Jan 24 10:46:54 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62FCECBF235 for ; Tue, 24 Jan 2017 10:46:54 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C0CE11BB for ; Tue, 24 Jan 2017 10:46:53 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-it0-f53.google.com with SMTP id c7so82854109itd.1 for ; Tue, 24 Jan 2017 02:46:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fh8wPts6vK/BT6KQgVfhBt0GC2OXG8AlirCBbG2O7C0=; b=R6bSPGNcg3A883ZbIMRBBRjg/5NPGFK/b7EtZNPpAITUbFj4pe3CqI60HKrcJqBM+P lE5rh+D+85X7Rq3pBG+2pKp+IMp/dNlHbajhRV1MaTMcQEBpNSJdTBOIl7yXCkMrb+B7 fqfk0t2LbJa+KnlWh+vYNNKjerIwea3Q+6imd+u+X0EAzXyB4epGNDX4B6HyNNliTwi7 uWZarvLWzWQO9VXs3s+PVOwXm5j1VcLjkRAzBoVWBXHmB2Ig9VevzjcykO2zmiwPD3fv IgkVPqZoGiVH1EvCydYfXrTEIcX95Hw2W+i9Ff7A6CfPCYe0slqEVFGAfQDRLebYgb3I fsew== X-Gm-Message-State: AIkVDXL81HwtatpuZYvl9SmUgO1RuQhcPOkU7TIjHL6HJy6OTbjOJAziarnBzmYzmvPB8YKDQp6dJ0NpqzL18A== X-Received: by 10.36.254.66 with SMTP id w63mr18730668ith.28.1485241216638; Mon, 23 Jan 2017 23:00:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Xiaoye Sun Date: Tue, 24 Jan 2017 07:00:06 +0000 Message-ID: Subject: Re: High priority for the tx queue in netmap To: Sepherosa Ziehau Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 10:46:54 -0000 I'm using the typical intel 10 Gbps nic. Does ethtool have related configuration command? On Tue, Jan 24, 2017 at 12:57 AM Sepherosa Ziehau wrote: > On Tue, Jan 24, 2017 at 4:09 AM, Xiaoye Sun wrote: > > > Hi, > > > > > > In my application, there are multiple tx queues in the OS, and the netmap > > > program uses one tx queue. I wondering if I can give the netmap tx queue > > > higher priority so that the NIC always sends the packets from this queue > if > > > netmap put any packet to it. > > > > You need to check your NIC chip vendor for this. > > > > Thanks, > > sephe > > > > From owner-freebsd-net@freebsd.org Tue Jan 24 14:17:35 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC63ACC0FAA; Tue, 24 Jan 2017 14:17:35 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A2B71A2C; Tue, 24 Jan 2017 14:17:35 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-248-244.albq.qwest.net [67.0.248.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 316211928BA; Tue, 24 Jan 2017 14:17:33 +0000 (UTC) Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending To: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> Cc: Matthew Macy , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" From: Sean Bruno Message-ID: Date: Tue, 24 Jan 2017 07:17:29 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EH3LBRDFiKXXA7NS0eMuW7tD6XgogV43s" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 14:17:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EH3LBRDFiKXXA7NS0eMuW7tD6XgogV43s Content-Type: multipart/mixed; boundary="2cFxsCj1f2BEwgvWWut6wxc47a2SP511u"; protected-headers="v1" From: Sean Bruno To: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= Cc: Matthew Macy , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Message-ID: Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> In-Reply-To: --2cFxsCj1f2BEwgvWWut6wxc47a2SP511u Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/23/17 23:31, Olivier Cochard-Labb=C3=A9 wrote: > On Tue, Jan 24, 2017 at 2:40 AM, Sean Bruno > wrote: >=20 >=20 >=20 > Which set of configs from your test suite are you using for this? > Specifically, what packet size are you slamming across? >=20 > https://github.com/ocochard/netbenches/tree/master/pktgen.configs > = >=20 >=20 > =E2=80=8BBecause I'm in the point of view of a Telco, I'm measuring the= =C2=ABworst=C2=BB > case, this mean with the smallest frame size. > Here is the exact pkt-gen command line I'm using: > - 60 byte Ethernet frame size (excluding the 4 CRC bytes) > - 2000 UDP flows (20 IP sources * 100 IP destinations) >=20 > pkt-gen -U -i igb2 -f tx -n 80000000 -l 60 -d 198.19.10.1:2000-198.19.1= 0.20 -D 00:0d:b9:41:ca:3d -s 198.18.10.1:2000-198.18.10.100 -w 4 >=20 > =E2=80=8BOption -U is available on a patched netmap version [1]: It fix= the > checksum calculation when using source/destination IP range on NIC that= > didn't enable HW CHKSUM in netmap mode and IPv6 support. >=20 > [1] > https://github.com/ocochard/BSDRP/blob/master/BSDRPcur/patches/freebsd.= pkt-gen.ae-ipv6.patch >=20 Did you increase the number of rx/tx rings to 8 and the number of descriptors to 4k in your tests or just the defaults? sean --2cFxsCj1f2BEwgvWWut6wxc47a2SP511u-- --EH3LBRDFiKXXA7NS0eMuW7tD6XgogV43s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAliHYflfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y fmSPMQgAqXlMPwL5pSNAJopoSHmZdKqVVqg+FFU8712U3aIfW2ZA04oign5ejspr n4YfDcl/Y/T2GMPsspKxBdRj00Muj0Vi55xpfyXbFeGNjaTA5q7XcNZ6zz29IZii J/5+KPIadFjdSEFILyfmGC+ZdyYTGcou1FufhxZsFFijTtaooz0T1OIL/83qQwNY trjI52fMWMpwyOugQ06oKIIZVn6MiL9ep5jNBo4y3/UMw7yHLMhFLNM9j7Do2uO2 pdE3vLNq6tM6Fpwp4vzJ+W6TT3PgB10bVz9D4VVHyCaXQTO67m6X78uLweWAqgRS D6QGY1fdrYUgjvb0i3tCJQkileLKmg== =D+Is -----END PGP SIGNATURE----- --EH3LBRDFiKXXA7NS0eMuW7tD6XgogV43s-- From owner-freebsd-net@freebsd.org Tue Jan 24 14:25:21 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1277CBE3D2 for ; Tue, 24 Jan 2017 14:25:21 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout08.t-online.de (mailout08.t-online.de [194.25.134.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77A241FD7 for ; Tue, 24 Jan 2017 14:25:21 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd11.aul.t-online.de (fwd11.aul.t-online.de [172.20.27.152]) by mailout08.t-online.de (Postfix) with SMTP id 9F0A541DABB2; Tue, 24 Jan 2017 15:25:11 +0100 (CET) Received: from [192.168.10.43] (E60sVyZBrhRDM4gs7Mork8AWYJsGAA7VibxZJqgz94F0OLmr+VDySeRhlAj0O+xwxs@[86.56.56.128]) by fwd11.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cW223-1sQYro0; Tue, 24 Jan 2017 15:25:11 +0100 Subject: Re: RTL8153 Gigabit Ethernet USB Adapter To: Hans Petter Selasky , freebsd-net@freebsd.org References: <59a929e6-5d6d-5f15-6ff6-4c61bf4a14c0@t-online.de> From: diffusae Message-ID: <48723e92-371b-39d2-d16d-845600b01b5c@t-online.de> Date: Tue, 24 Jan 2017 15:25:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: E60sVyZBrhRDM4gs7Mork8AWYJsGAA7VibxZJqgz94F0OLmr+VDySeRhlAj0O+xwxs X-TOI-MSGID: 5b49c2ac-7bbb-43f0-b776-f970836f3b22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 14:25:21 -0000 Hi! Thanks for your fast reply. On 23.01.2017 21:24, Hans Petter Selasky wrote: > On 01/23/17 21:06, diffusae wrote: >> Hi! >> >> Maybe a noobs question but I am mostly familiar with Linux. >> >> Currently there is no driver for the RTL8153 Gigabit Ethernet Adapter. >> >> Bus 001 Device 004: ID 0bda:8153 Realtek Semiconductor Corp. >> >> https://www.freebsd.org/relnotes/CURRENT/hardware/support.html >> >> RealTek has a Unix (Linux) driver here: >> >> http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=56&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false#RTL8153 >> >> >> How can I compile a custome kernel with this driver? >> >> I am using FreeBSD 11.0-STABLE (RPI-B) #0 r308738 >> > > Hi, > > Have a look in sys/dev/usb/net and see if you find any similar devices. > I think your driver is already supported. You need to: > > 1) kldload usb_quirk > 2) kldload if_ure > 3) replug your device and it should attach (FreeBSD-12 at least) > > grep -r 8153 /usr/src/sys/dev/usb > > --HPS That was the key. Yes, you're right. It's supported and uses the if_cdce driver, but there is no mediaopt extention with ifconfig. Nevertheless it is connected with one 1 Gbit/s. So, that's fine. It was due to a "faulty" USB OTG cable of the RPI. If I plug the device connector until the end, it isn't detected, because it has no power. If I slighly move it back for some mm, that the power is connected and the device will be detected: usbconfig -d 0.2 dump_device_desc ugen0.2: at usbus0, cfg=1 md=HOST spd=HIGH (480Mbps) pwr=ON (180mA) Strange chinese adaptors ... :-) So, thanks again Best regards, From owner-freebsd-net@freebsd.org Tue Jan 24 15:28:31 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7585CBFCF2 for ; Tue, 24 Jan 2017 15:28:31 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 07712C7B for ; Tue, 24 Jan 2017 15:28:30 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-yw0-f179.google.com ([209.85.161.179]) by mwinf5d02 with ME id cFUJ1u00Y3sYHUp03FUKdP; Tue, 24 Jan 2017 16:28:22 +0100 X-ME-Helo: mail-yw0-f179.google.com X-ME-Auth: Y29jaGFyZC1sYWJiZS5vbGl2aWVyQG9yYW5nZS5mcg== X-ME-Date: Tue, 24 Jan 2017 16:28:22 +0100 X-ME-IP: 209.85.161.179 Received: by mail-yw0-f179.google.com with SMTP id l19so163690682ywc.2; Tue, 24 Jan 2017 07:28:19 -0800 (PST) X-Gm-Message-State: AIkVDXJR9cdwykkWvz1NDgR6aQWjYTiV1swNTSmqJ141qCYh0CBTY1l/uGqMlrbTtdPY/MylC6eCzzXAdgR+gg== X-Received: by 10.55.151.199 with SMTP id z190mr31704288qkd.166.1485271697930; Tue, 24 Jan 2017 07:28:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.49.99 with HTTP; Tue, 24 Jan 2017 07:27:57 -0800 (PST) In-Reply-To: References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Tue, 24 Jan 2017 16:27:57 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending To: Sean Bruno Cc: Matthew Macy , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 15:28:31 -0000 On Tue, Jan 24, 2017 at 3:17 PM, Sean Bruno wrote: > > > Did you increase the number of rx/tx rings to 8 and the number of > descriptors to 4k in your tests or just the defaults? > Tuning are same as described in my previous email (rxd|txd=2048, rx|tx process_limit=-1, max_interrupt_rate=16000). [root@apu2]~# sysctl hw.igb. hw.igb.tx_process_limit: -1 hw.igb.rx_process_limit: -1 hw.igb.num_queues: 0 hw.igb.header_split: 0 hw.igb.max_interrupt_rate: 16000 hw.igb.enable_msix: 1 hw.igb.enable_aim: 1 hw.igb.txd: 2048 hw.igb.rxd: 2048 But I've did a new benchs with default setting, and the performance drop is now about -25% : x head r311848 packets-per-second (default settings) + head r311849 packets-per-second (default settings) +--------------------------------------------------------------------------+ |+ | |+ x | |+ xx| |++ xx| | A|| |A| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 618711 621135 619930.5 619840.8 951.83787 + 5 467389 468740 467778 467864.8 550.40322 Difference at 95.0% confidence -151976 +/- 1133.9 -24.5186% +/- 0.150581% (Student's t, pooled s = 777.476) From owner-freebsd-net@freebsd.org Tue Jan 24 15:31:19 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A15D6CC0043; Tue, 24 Jan 2017 15:31:19 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66157F6F; Tue, 24 Jan 2017 15:31:18 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-248-244.albq.qwest.net [67.0.248.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 025E31928BA; Tue, 24 Jan 2017 15:31:17 +0000 (UTC) Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending To: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> Cc: Matthew Macy , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" From: Sean Bruno Message-ID: Date: Tue, 24 Jan 2017 08:31:13 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Gjupok5Xwh92XDQejKlekdOSOrwjfXdic" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 15:31:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Gjupok5Xwh92XDQejKlekdOSOrwjfXdic Content-Type: multipart/mixed; boundary="xDI9f4ipfWJNETqafQe9wabhuoRSaXFIG"; protected-headers="v1" From: Sean Bruno To: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= Cc: Matthew Macy , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Message-ID: Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> In-Reply-To: --xDI9f4ipfWJNETqafQe9wabhuoRSaXFIG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/24/17 08:27, Olivier Cochard-Labb=C3=A9 wrote: > On Tue, Jan 24, 2017 at 3:17 PM, Sean Bruno > wrote: >=20 >=20 >=20 > Did you increase the number of rx/tx rings to 8 and the number of > descriptors to 4k in your tests or just the defaults? >=20 >=20 > Tuning are same as described in my previous email (rxd|txd=3D2048, rx|t= x > process_limit=3D-1, max_interrupt_rate=3D16000). > [root@apu2]~# sysctl hw.igb. > hw.igb.tx_process_limit: -1 > hw.igb.rx_process_limit: -1 > hw.igb.num_queues: 0 > hw.igb.header_split: 0 > hw.igb.max_interrupt_rate: 16000 > hw.igb.enable_msix: 1 > hw.igb.enable_aim: 1 > hw.igb.txd: 2048 > hw.igb.rxd: 2048 >=20 >=20 Oh, I think you missed my note on these. In order to adjust txd/rxd you need to tweak the iflib version of these numbers. nrxds/ntxds should be adjust upwards to your value of 2048. nrxqs/ntxqs should be adjust upwards to 8, I think, so you can test equivalent settings to the legacy driver. Specifically, you may want to adjust these: dev.em.0.iflib.override_nrxds: 0 dev.em.0.iflib.override_ntxds: 0 dev.em.0.iflib.override_nrxqs: 0 dev.em.0.iflib.override_ntxqs: 0 sean > But I've did a new benchs with default setting, and the performance dro= p > is now about -25% : >=20 > x head r311848 packets-per-second (default settings) > + head r311849 packets-per-second (default settings) > +----------------------------------------------------------------------= ----+ > |+ = | > |+ = x | > |+ = xx| > |++ = xx| > | = A|| > |A| = | > +----------------------------------------------------------------------= ----+ > N Min Max Median Avg St= ddev > x 5 618711 621135 619930.5 619840.8 951.8= 3787 > + 5 467389 468740 467778 467864.8 550.4= 0322 > Difference at 95.0% confidence > -151976 +/- 1133.9 > -24.5186% +/- 0.150581% > (Student's t, pooled s =3D 777.476) >=20 --xDI9f4ipfWJNETqafQe9wabhuoRSaXFIG-- --Gjupok5Xwh92XDQejKlekdOSOrwjfXdic Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAliHc0FfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y fmRKDAgAlleMvp13X8F/56RMAHj+zK2gnL3R1BRAzjeG3fGgPTiz/SnqaR9ngadl d3kYkAxMUyFz5zSmWW3d9BB49No+syppWdBIyH1Pv4wqNsSQOUP5pXl1ot143H84 Y9jEDgN4/QluuQXUaj1YvG7s6n1Bw8wE7SSCcjqvDg0O1L5xTOSQF+atwDd3+o6r zUOzhdYwKuc0f98vsGTspCu5JQ/FfS/p9Y5F3xvTo9Gj6HtbbBXHuJ3k5eBeHJ0f aKUhBSpxVrDBLUBpaj7ClO0/166PnBBUU1bRaty5iDJbMmYgnWDtQtvaoCOS2/U7 XM9vSI6D6kuZAY6k7MidzZjFCLP3sQ== =GH+B -----END PGP SIGNATURE----- --Gjupok5Xwh92XDQejKlekdOSOrwjfXdic-- From owner-freebsd-net@freebsd.org Tue Jan 24 16:35:23 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A323CC0703; Tue, 24 Jan 2017 16:35:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id C0E73289; Tue, 24 Jan 2017 16:35:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 87D9C3C440E; Wed, 25 Jan 2017 03:09:54 +1100 (AEDT) Date: Wed, 25 Jan 2017 03:09:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Sean Bruno cc: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , Matthew Macy Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending In-Reply-To: Message-ID: <20170125023853.Q1809@besplex.bde.org> References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> <1598f3f8588.d20017893749.339651164872952258@nextbsd.org> <1598f42ad77.eeec05be4113.9201780237587761460@nextbsd.org> <159902b73ed.10775291e21533.7488368455500235608@nextbsd.org> <18abdd64-08a6-50ca-fb6b-9c01a3d7b60c@freebsd.org> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=c+HbeV1l c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=nlC_4_pT8q9DhB4Ho9EA:9 a=6I5d2MoRAAAA:8 a=72mLzN8eAAAA:8 a=9PCMMyJtWz_l6bDDFeUA:9 a=F10vGVGQh35Fc93u:21 a=IRbHUhQxDI19dvun:21 a=45ClL6m2LaAA:10 a=IjZwj45LgO3ly-622nXo:22 a=-7La2cLJWLV_9KNFy1_x:22 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 16:35:23 -0000 On Tue, 24 Jan 2017, Sean Bruno wrote: > On 01/24/17 08:27, Olivier Cochard-Labb=C3=A9 wrote: >> On Tue, Jan 24, 2017 at 3:17 PM, Sean Bruno > > wrote: >> >> Did you increase the number of rx/tx rings to 8 and the number of >> descriptors to 4k in your tests or just the defaults? >> >> Tuning are same as described in my previous email (rxd|txd=3D2048, rx|tx >> process_limit=3D-1, max_interrupt_rate=3D16000). >> [root@apu2]~# sysctl hw.igb. >> hw.igb.tx_process_limit: -1 >> hw.igb.rx_process_limit: -1 >> hw.igb.num_queues: 0 >> hw.igb.header_split: 0 >> hw.igb.max_interrupt_rate: 16000 >> hw.igb.enable_msix: 1 >> hw.igb.enable_aim: 1 >> hw.igb.txd: 2048 >> hw.igb.rxd: 2048 > > Oh, I think you missed my note on these. In order to adjust txd/rxd you > need to tweak the iflib version of these numbers. nrxds/ntxds should be > adjust upwards to your value of 2048. nrxqs/ntxqs should be adjust > upwards to 8, I think, so you can test equivalent settings to the legacy > driver. > > Specifically, you may want to adjust these: > > dev.em.0.iflib.override_nrxds: 0 > dev.em.0.iflib.override_ntxds: 0 > > dev.em.0.iflib.override_nrxqs: 0 > dev.em.0.iflib.override_ntxqs: 0 That is painful. My hack to increase the ifq length also no longer works: X Index: if_em.c X =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 X --- if_em.c=09(revision 312696) X +++ if_em.c=09(working copy) X @@ -1,3 +1,5 @@ X +int em_qlenadj =3D -1; X + -1 gives a null adjustment; 0 gives a default (very large ifq), and other values give a non-null adustment. X /*- X * Copyright (c) 2016 Matt Macy X * All rights reserved. X @@ -2488,7 +2490,10 @@ X=20 X =09/* Single Queue */ X if (adapter->tx_num_queues =3D=3D 1) { X -=09 if_setsendqlen(ifp, scctx->isc_ntxd[0] - 1); X +=09 if (em_qlenadj =3D=3D 0) X +=09 em_qlenadj =3D imax(2 * tick, 0) * 15 / 10; X +=09 // lem_qlenadj =3D imax(2 * tick, 0) * 42 / 100; X +=09 if_setsendqlen(ifp, scctx->isc_ntxd[0] + em_qlenadj); X =09 if_setsendqready(ifp); X =09} X I don't want larger hardware queues, but sometimes want larger software queues. ifq's used to give them. The if_setsenqlen() call is still there. but no longer gives them. The large queues are needed for backet blasting benchmarks since select() doesn't work for udp sockets, so if the queues fill up then the benchmarks must busy-wait or sleep waiting for them to drain, and timeout granularity tends to prevent short sleeps from working so the queues run dry while sleeping unless the queues are very large. Bruce From owner-freebsd-net@freebsd.org Tue Jan 24 16:41:32 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60E1FCC0A90 for ; Tue, 24 Jan 2017 16:41:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAF18AAF; Tue, 24 Jan 2017 16:41:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id r126so35884785wmr.3; Tue, 24 Jan 2017 08:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/1r/ydDMi3ilS0B0ilPXaFftn08qd89LgHAUzIvya6M=; b=RupbhwC+h+cnEuyPZYo5Le53wEoF8kp6MzHub0YI/wgnw3GMnXpKXmUXL+Ztmrg+6h bx98SKKUKUVD1XN/WXYC5GxBGqembGI2FEGTBRef+rjNMSFicSODlsvaljHDjuGgb8lo vzgSgsRDpm8rw7MdASrEnUReJ1+ck6EO5mBB4hOLcEji85lcvP3nflbrTF6NnzT+BU5I X3XsO5Zkv8wP6VSwq/hg62WDPE0X45Ng1wQbpB3Xlm1AQMKJDfkeMTAgDVgdChCN5O7Y 1BGnGhxt2nKmXcBkeIW9Cw5cW+hgWbCnOVRb4yfgLCanI1obYMynIV2P8oSVwAV8Py9v OICQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/1r/ydDMi3ilS0B0ilPXaFftn08qd89LgHAUzIvya6M=; b=CZila5neOFdR5rDKKkRPZoi7mllqcW33cP+FlI5U432FGi4U5l6U/AWRSVmQtDFnQr niY5tro2zRn9yZBX3r9KAhR3VbCYgA2C2QNMg/HEDmtm6Mgg/0DHON6ZEN9nqix0Dthk VNs1K7i3d+bjMMWhNCp4XUknFS8SsaQoIHX4+3EXU3gW1IXpPT5ZPfnk8jf0glRFXyJG /f/xt1jIaRMEZWqEhokFdhdAwahPgYg3BfKzHj4jR0dKHDl19tJjMPH92E0k1jCjLFYT GST3eov/X1/5JSWUkwkYQ8S0S1ncCbs9kbQbpxBkH/JmcrAMqUECXvPwGy85jF5vNE49 irzw== X-Gm-Message-State: AIkVDXJedjB6WRYuyhfZurcYLKEEaVeGlGUByxi0qcphmMPvx8h9RRRTekoK0pCHGLlYitJrKNzbyOMMZyEf8w== X-Received: by 10.223.173.80 with SMTP id p74mr28009136wrc.168.1485276086774; Tue, 24 Jan 2017 08:41:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.82.162 with HTTP; Tue, 24 Jan 2017 08:41:25 -0800 (PST) In-Reply-To: References: From: Adrian Chadd Date: Tue, 24 Jan 2017 08:41:25 -0800 Message-ID: Subject: Re: RFC: ethctl To: Kevin Bowling Cc: FreeBSD Net , Scott Long , "Joyner, Eric" , Drew Gallatin , Oded Shanoon , Matthew Macy , hps@freebsd.org, "Cramer, Jeb J" , George Neville-Neil , arybchik@freebsd.org, shurd@freebsd.org, Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 24 Jan 2017 17:17:39 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 16:41:32 -0000 On 19 January 2017 at 19:58, Kevin Bowling wrote: > Greetings, > > I'm casting a wide net in cc, try to keep the noise minimal but we need > some input from a variety of HW vendors. > > I have heard from several vendors the need for a NIC configuration tool. > Chelsio ships a cxgb/cxgbetool in FreeBSD as one example. There is > precedence for some nod toward a basic unified tool in Linux ethtool. > > From your perspective, > 1) What are the common requirements? > 2) What are specialized requirements? For instance as a full TCP offload > card Chelsio needs things others wont > 3) What should it _not_ do? Several of you have experience doing Ethernet > driver dev on many platforms so we should attempt to avoid repeating past > design mistakes. > > I expect we can achieve some level of inversion so the device specific code > can live close to the driver and plug into the ethctl framework. It should > be general enough to add completely new top level commands, so vendors can > implement HW specific features. On the other hand, we should attempt to > hook into common core for features every NIC provides, with a focus on > iflib. > > I will fund Matt Macy to do the overall design and implementation. > > Regards, > Kevin Bowling, on behalf of Limelight Networks for this effort Hi, ethtool isn't exactly complicated. It's just vaguely standardized. When I was hoping (hah!) to do it, partly for wifi but partly for ethernet, my goals were: * generic interface for counter statistics, versus sysctl; * "default" mib space for known counter statistics, versus the small set we have now and then the very large vendor space that ethtool (linux) and sysctl (freebsd) exposes; * generic interface for configuring things like RSS mapping, L2/L3 rules for a NIC based on the NIC capability and what queue(s) they map to, versus vendor tools; * vendor specific extensions, which hopefully (!) are implemented as generic-ish plugins where required, or just strings that can be passed through to the driver and registered via a command hook; * and importantly - some kind of optional debug control, because every driver does something different for debugging / tracing, and boy it'd be nice if it all was like wifi (wlandebug -i +/-(feature)) A lot of what's in linux ethtool is in freebsd's ifconfig, albeit not in a reusable/runtime-extensible fashion. It'd be nice to include say, many more vendor counters in a somewhat generic fashion, versus how we currently do things. I think it'd be a good starting point to have an ethtool control iflib drivers, so any driver using iflib can benefit from what's implemented. 2c, -adrian From owner-freebsd-net@freebsd.org Tue Jan 24 20:25:43 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89D74CC0407 for ; Tue, 24 Jan 2017 20:25:43 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A5B281D for ; Tue, 24 Jan 2017 20:25:43 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v0OKPX0L008680; Tue, 24 Jan 2017 12:25:39 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201701242025.v0OKPX0L008680@gw.catspoiler.org> Date: Tue, 24 Jan 2017 12:25:33 -0800 (PST) From: Don Lewis Subject: Re: inheriting fib from an interface To: eugen@grosbein.net cc: freebsd-net@FreeBSD.org In-Reply-To: <20170124095539.GA18648@rdtc.ru> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Jan 2017 20:25:43 -0000 On 24 Jan, Eugene Grosbein wrote: > On Mon, Jan 23, 2017 at 05:31:22PM -0800, Don Lewis wrote: > >> Let's say that I have an application running on a server that is >> connected to the Internet via two different ISPs and is using IP >> addresses (ISP A:10.0.0.10 and ISP B:192.168.1.10) delegated by those >> two ISPs on it's two interfaces. Responses to requests sent to >> 10.0.0.10 should be sent via ISP A, and responses to requests sent to >> 192.168.1.10 should be ISB B. >> >> There are a couple of different ways that I can think of to do this: >> >> 1) Put the server behind another FreeBSD box that uses policy-based >> routing to forward the outbound packets to the desired ISP. My >> understanding is that this only works for packet forwarding and not >> for locally generated packets. > > Single command "ipfw add 2000 fwd $ispgw2 ip from $ip2 to any out xmit $isp1_iface" > works for locally generated packets too. > > It "fixes" outgoing routing path for packets > from IP belonging to "non-default" ISP2 when default route points to ISP1. Thanks, that looks very promising! From owner-freebsd-net@freebsd.org Wed Jan 25 11:41:29 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11338CC0EF6 for ; Wed, 25 Jan 2017 11:41:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 01806BF6 for ; Wed, 25 Jan 2017 11:41:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0PBfSTq014767 for ; Wed, 25 Jan 2017 11:41:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216456] iflib error checking for MSIX Date: Wed, 25 Jan 2017 11:41:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Jan 2017 11:41:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216456 Bug ID: 216456 Summary: iflib error checking for MSIX Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-net@FreeBSD.org Reporter: bz@FreeBSD.org CC: sbruno@FreeBSD.org Structurally this seems entirely backwards that drivers do supply a isc_msix_bar value without checking if MSIX is available. Writing code bas= ed on assumptions is not stable but iflib should guard against this. Add error checking to the pci_find_cap(, PCIY_MSIX,) call that is returns success and a good value. Only then try to use it and set the MSIX_ENABLE = bit. With the current em(4) driver we have observed failures in this case in a specific environment when pci_find_cap() would not return the assumed value, which meant we ended up writing to PCI register 2 (PCI_DEVICE_ID) which is read-only. It seems that a lot more safeguarding and perhaps better structuring between drivers and iflib is needed to avoid these kinds of errors. This patch just adds the safeguard in a single place in iflib, em(4) should ideally be improved to not signal an msix bar value anymore if MSIX is not avail. Index: head-r312664.svn/sys/net/iflib.c =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 --- head-r312664.svn/sys/net/iflib.c (revision 312664) +++ head-r312664.svn/sys/net/iflib.c (working copy) @@ -3710,6 +3710,10 @@ iflib_device_register(device_t dev, void *sc, if_s if (sctx->isc_flags & IFLIB_SKIP_MSIX) { msix =3D scctx->isc_vectors; } else if (scctx->isc_msix_bar !=3D 0) + /* + * The simple fact that isc_msix_bar is not 0 does not mean= we + * we have a good value there that is known to work. + */ msix =3D iflib_msix_init(ctx); else { scctx->isc_vectors =3D 1; @@ -4754,15 +4758,21 @@ iflib_msix_init(if_ctx_t ctx) uint16_t pci_cmd_word; int msix_ctrl, rid; - rid =3D 0; pci_cmd_word =3D pci_read_config(dev, PCIR_COMMAND, 2); pci_cmd_word |=3D PCIM_CMD_BUSMASTEREN; pci_write_config(dev, PCIR_COMMAND, pci_cmd_word, 2); - pci_find_cap(dev, PCIY_MSIX, &rid); - rid +=3D PCIR_MSIX_CTRL; - msix_ctrl =3D pci_read_config(dev, rid, 2); - msix_ctrl |=3D PCIM_MSIXCTRL_MSIX_ENABLE; - pci_write_config(dev, rid, msix_ctrl, 2); + + rid =3D 0; + if (pci_find_cap(dev, PCIY_MSIX, &rid) =3D=3D 0 && rid !=3D= 0) { + rid +=3D PCIR_MSIX_CTRL; + msix_ctrl =3D pci_read_config(dev, rid, 2); + msix_ctrl |=3D PCIM_MSIXCTRL_MSIX_ENABLE; + pci_write_config(dev, rid, msix_ctrl, 2); + } else { + device_printf(dev, "PCIY_MSIX capability not found;= " + "or rid %d =3D=3D 0.\n", rid); + goto msi; + } } /* --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 25 14:16:12 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25BE1CC0931 for ; Wed, 25 Jan 2017 14:16:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 1598335B for ; Wed, 25 Jan 2017 14:16:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0PEGBE5097432 for ; Wed, 25 Jan 2017 14:16:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216456] iflib error checking for MSIX Date: Wed, 25 Jan 2017 14:16:12 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: sbruno@FreeBSD.org 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: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Jan 2017 14:16:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216456 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |sbruno@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 25 21:26:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9170DCC1BC4 for ; Wed, 25 Jan 2017 21:26:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 814641F16 for ; Wed, 25 Jan 2017 21:26:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0PLQQaV086551 for ; Wed, 25 Jan 2017 21:26:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216304] Adding xn0 to bridge0 causes kernel panic Date: Wed, 25 Jan 2017 21:26:27 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Jan 2017 21:26:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216304 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Wed Jan 25 21:25:26 UTC 2017 New revision: 312782 URL: https://svnweb.freebsd.org/changeset/base/312782 Log: bridge: Release the bridge lock when calling bridge_set_ifcap() This calls ioctl() handlers for the different interfaces in the bridge. These handlers expect to get called in an ioctl context where it's safe for them to sleep. We may not sleep with the bridge lock held. However, we still need to protect the interface list, to ensure it doesn't get changed while we iterate over it. Use BRIDGE_XLOCK(), which prevents bridge members from being removed. Adding bridge members is safe, because it uses LIST_INSERT_HEAD(). This caused panics when adding xen interfaces to a bridge. PR: 216304 Reviewed by: ae MFC after: 1 week Sponsored by: RootBSD Differential Revision: https://reviews.freebsd.org/D9290 Changes: head/sys/net/if_bridge.c head/sys/net/if_bridgevar.h --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 26 05:22:21 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9C6BCC2D80 for ; Thu, 26 Jan 2017 05:22:21 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 895EAAA3 for ; Thu, 26 Jan 2017 05:22:21 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id B1E7F36F49; Thu, 26 Jan 2017 05:22:20 +0000 (UTC) Date: Thu, 26 Jan 2017 05:22:20 +0000 To: freebsd-net@freebsd.org From: "decui_microsoft.com (Dexuan Cui)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_218321ead0b022438f00c8a9a4693dde" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 05:22:21 -0000 --b1_218321ead0b022438f00c8a9a4693dde Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 ZGVjdWlfbWljcm9zb2Z0LmNvbSBjcmVhdGVkIHRoaXMgcmV2aXNpb24uCmRlY3VpX21pY3Jvc29m dC5jb20gYWRkZWQgcmV2aWV3ZXJzOiBoc2VsYXNreSwgc2VwaGVyb3NhX2dtYWlsLmNvbSwgY2Vt LCBucCwga21hY3ksIGtpYiwgaG9uemhhbl9taWNyb3NvZnQuY29tLCBob3dhcmQwc3VfZ21haWwu Y29tLCBqaGIsIGFlLCBkZWxwaGlqLCByb3lnZXIsIGdsZWJpdXMsIGdubiwgcndhdHNvbi4KZGVj dWlfbWljcm9zb2Z0LmNvbSBhZGRlZCBhIHN1YnNjcmliZXI6IGZyZWVic2QtbmV0LWxpc3QuCgpS RVZJU0lPTiBTVU1NQVJZCiAgVGhpcyBpcyB0byBmaXggCiAgc3ZuIGNvbW1pdDogcjMxMjY4NyAo aWZuZXQ6IGludHJvZHVjZSBldmVudCBoYW5kbGVycyBmb3IgaWZ1cC9pZmRvd24gZXZlbnRzKQog IAogIFRoYW5rIGdsZWJpdXMgZm9yIHBvaW50aW5nIHRoaXMgb3V0OgogICJUaGUgbmV0d29yayBz dHVmZiBzaGFsbCBub3QgYmUgYWRkZWQgdG8gc3lzL2V2ZW50aGFuZGxlci5oIgoKUkVWSVNJT04g REVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q5MzQ1CgpBRkZFQ1RFRCBGSUxF UwogIHN5cy9uZXQvaWYuYwogIHN5cy9uZXQvaWZfdmFyLmgKICBzeXMvc3lzL2V2ZW50aGFuZGxl ci5oCgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9zZXR0 aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IGRlY3VpX21pY3Jvc29mdC5jb20sIGhz ZWxhc2t5LCBzZXBoZXJvc2FfZ21haWwuY29tLCBjZW0sIG5wLCBrbWFjeSwga2liLCBob256aGFu X21pY3Jvc29mdC5jb20sIGhvd2FyZDBzdV9nbWFpbC5jb20sIGpoYiwgYWUsIGRlbHBoaWosIHJv eWdlciwgZ2xlYml1cywgZ25uLCByd2F0c29uCkNjOiBmcmVlYnNkLW5ldC1saXN0Cg== --b1_218321ead0b022438f00c8a9a4693dde Content-Type: text/x-patch; charset=utf-8; name="D9345.24465.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D9345.24465.patch" ZGlmZiAtLWdpdCBhL3N5cy9zeXMvZXZlbnRoYW5kbGVyLmggYi9zeXMvc3lzL2V2ZW50aGFuZGxl ci5oCi0tLSBhL3N5cy9zeXMvZXZlbnRoYW5kbGVyLmgKKysrIGIvc3lzL3N5cy9ldmVudGhhbmRs ZXIuaApAQCAtMjg0LDExICsyODQsNCBAQAogRVZFTlRIQU5ETEVSX0RFQ0xBUkUoc3dhcG9uLCBz d2Fwb25fZm4pOwogRVZFTlRIQU5ETEVSX0RFQ0xBUkUoc3dhcG9mZiwgc3dhcG9mZl9mbik7CiAK LS8qIGlmdXAvaWZkb3duIGV2ZW50cyAqLwotI2RlZmluZSBJRk5FVF9FVkVOVF9VUAkJMAotI2Rl ZmluZSBJRk5FVF9FVkVOVF9ET1dOCTEKLXN0cnVjdCBpZm5ldDsKLXR5cGVkZWYgdm9pZCAoKmlm bmV0X2V2ZW50X2ZuKSh2b2lkICosIHN0cnVjdCBpZm5ldCAqaWZwLCBpbnQgZXZlbnQpOwotRVZF TlRIQU5ETEVSX0RFQ0xBUkUoaWZuZXRfZXZlbnQsIGlmbmV0X2V2ZW50X2ZuKTsKLQogI2VuZGlm IC8qIF9TWVNfRVZFTlRIQU5ETEVSX0hfICovCmRpZmYgLS1naXQgYS9zeXMvbmV0L2lmX3Zhci5o IGIvc3lzL25ldC9pZl92YXIuaAotLS0gYS9zeXMvbmV0L2lmX3Zhci5oCisrKyBiL3N5cy9uZXQv aWZfdmFyLmgKQEAgLTQwNCw2ICs0MDQsMTEgQEAKIC8qIEludGVyZmFjZSBsaW5rIHN0YXRlIGNo YW5nZSBldmVudCAqLwogdHlwZWRlZiB2b2lkICgqaWZuZXRfbGlua19ldmVudF9oYW5kbGVyX3Qp KHZvaWQgKiwgc3RydWN0IGlmbmV0ICosIGludCk7CiBFVkVOVEhBTkRMRVJfREVDTEFSRShpZm5l dF9saW5rX2V2ZW50LCBpZm5ldF9saW5rX2V2ZW50X2hhbmRsZXJfdCk7CisvKiBJbnRlcmZhY2Ug dXAvaWZkb3duIGV2ZW50ICovCisjZGVmaW5lIElGTkVUX0VWRU5UX1VQCQkwCisjZGVmaW5lIElG TkVUX0VWRU5UX0RPV04JMQordHlwZWRlZiB2b2lkICgqaWZuZXRfZXZlbnRfZm4pKHZvaWQgKiwg c3RydWN0IGlmbmV0ICppZnAsIGludCBldmVudCk7CitFVkVOVEhBTkRMRVJfREVDTEFSRShpZm5l dF9ldmVudCwgaWZuZXRfZXZlbnRfZm4pOwogI2VuZGlmIC8qIF9TWVNfRVZFTlRIQU5ETEVSX0hf ICovCiAKIC8qCmRpZmYgLS1naXQgYS9zeXMvbmV0L2lmLmMgYi9zeXMvbmV0L2lmLmMKLS0tIGEv c3lzL25ldC9pZi5jCisrKyBiL3N5cy9uZXQvaWYuYwpAQCAtNTksNyArNTksNiBAQAogI2luY2x1 ZGUgPHN5cy9kb21haW4uaD4KICNpbmNsdWRlIDxzeXMvamFpbC5oPgogI2luY2x1ZGUgPHN5cy9w cml2Lmg+Ci0jaW5jbHVkZSA8c3lzL2V2ZW50aGFuZGxlci5oPgogCiAjaW5jbHVkZSA8bWFjaGlu ZS9zdGRhcmcuaD4KICNpbmNsdWRlIDx2bS91bWEuaD4KCg== --b1_218321ead0b022438f00c8a9a4693dde-- From owner-freebsd-net@freebsd.org Thu Jan 26 05:23:42 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B21B6CC2F34 for ; Thu, 26 Jan 2017 05:23:42 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 74239CAD for ; Thu, 26 Jan 2017 05:23:42 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id B275E3601B; Thu, 26 Jan 2017 05:23:41 +0000 (UTC) Date: Thu, 26 Jan 2017 05:23:41 +0000 To: freebsd-net@freebsd.org From: "decui_microsoft.com (Dexuan Cui)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: <45785c8c0781ef26c1ab868c507b53bb@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiJh90= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 05:23:42 -0000 ZGVjdWlfbWljcm9zb2Z0LmNvbSByZXRpdGxlZCB0aGlzIHJldmlzaW9uIGZyb20gImlmbmV0OiBt b3ZlIHRoZSBuZXcgaWZuZXRfZXZlbnQgRVZFTlRIQU5ETEVSX0RFQ0xBUkVzIHRvIG5ldC9pZl92 YXIuaCIgdG8gImlmbmV0OiBtb3ZlIHRoZSBuZXcgaWZuZXRfZXZlbnQgRVZFTlRIQU5ETEVSX0RF Q0xBUkUgdG8gbmV0L2lmX3Zhci5oIi4KClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3 cy5mcmVlYnNkLm9yZy9EOTM0NQoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmlld3Mu ZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBkZWN1aV9t aWNyb3NvZnQuY29tLCBoc2VsYXNreSwgc2VwaGVyb3NhX2dtYWlsLmNvbSwgY2VtLCBucCwga21h Y3ksIGtpYiwgaG9uemhhbl9taWNyb3NvZnQuY29tLCBob3dhcmQwc3VfZ21haWwuY29tLCBqaGIs IGFlLCBkZWxwaGlqLCByb3lnZXIsIGdsZWJpdXMsIGdubiwgcndhdHNvbgpDYzogZnJlZWJzZC1u ZXQtbGlzdAo= From owner-freebsd-net@freebsd.org Thu Jan 26 09:48:18 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46737CBFD71 for ; Thu, 26 Jan 2017 09:48:18 +0000 (UTC) (envelope-from arquicros@ciudad.com.ar) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2C561923 for ; Thu, 26 Jan 2017 09:48:18 +0000 (UTC) (envelope-from arquicros@ciudad.com.ar) Received: by mailman.ysv.freebsd.org (Postfix) id 2BB9ACBFD70; Thu, 26 Jan 2017 09:48:18 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B339CBFD6F for ; Thu, 26 Jan 2017 09:48:18 +0000 (UTC) (envelope-from arquicros@ciudad.com.ar) Received: from relay21.ciudad.com.ar (relay21.ciudad.com.ar [200.42.97.3]) by mx1.freebsd.org (Postfix) with ESMTP id ABDB391E for ; Thu, 26 Jan 2017 09:48:17 +0000 (UTC) (envelope-from arquicros@ciudad.com.ar) Received: from localhost (v1175uprod.int.cmd.com.ar [10.5.2.122]) by relay21.ciudad.com.ar (Postfix) with ESMTP id 2B608226760A; Thu, 26 Jan 2017 06:40:12 -0300 (ART) Received: from zrm6.int.cmd.com.ar ([127.0.0.1]) by localhost (zrm6.int.cmd.com.ar [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id L5JHCYAyQfog; Thu, 26 Jan 2017 06:40:05 -0300 (ART) Received: from zrm6.int.cmd.com.ar (localhost [127.0.0.1]) by zrm6.int.cmd.com.ar (Postfix) with ESMTP id 1C113174149C; Thu, 26 Jan 2017 06:40:05 -0300 (ART) DKIM-Filter: OpenDKIM Filter v2.9.2 zrm6.int.cmd.com.ar 1C113174149C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciudad.com.ar; s=5D1E4AA2-A04B-11E6-AD0D-58B86751EC7D; t=1485423605; bh=BtfH/QxchofDn12AXb7zz0K6XUJOKyPjkKxTqz6eGPI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=QECLdVO9g8Pb+jkP3D+BX7eTb+ZbKJGui1vOjYrFwnvqluBA1vsqjUd708yHiVFKY O+Rz/vE5omnR/jpsfyA0Sq5aMSONUicBVL1wD/tNtP/E5Ehr6/FwuHuA/wcemGgqGI G9uxOgndQEFv5e4IcfwjVOrJfGgXVqIS2xmouFy0= Received: from rezjxv-PC (unknown [187.67.47.104]) by zrm6.int.cmd.com.ar (Postfix) with ESMTPSA id 00AB91742852; Thu, 26 Jan 2017 06:39:52 -0300 (ART) From: "devesas.campos" To: "mn401" , "mydeposits.co.uk" , "neotyk" , "net" Subject: =?utf-8?B?d293IHNvbWU=?= Date: Thu, 26 Jan 2017 11:39:50 +0200 Message-ID: <1859905548.20170126123950@ciudad.com.ar> Content-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jan 2017 09:48:18 -0000 SGV5IGZyaWVuZCwgDQoNCkhhdmUgeW91IGhlYXJkIGFib3V0IHRoYXQgcmVhbGx5IHdvdyBzb21l ICBzdHVmZj8gWW91IHdvbid0IHJlZ3JldCwgYmVsaWV2ZSBtZSwgIHJlYWQgIG1vcmUgaGVyZSBo dHRwOi8vbWFyaWEuZHJlYW1iaXRjaGVzLm9yZy8yYTJiDQoNClNlbnQgZnJvbSBteSBpUGhvbmUs IGRldmVzYXMuY2FtcG9zDQoNCg== From owner-freebsd-net@freebsd.org Thu Jan 26 13:48:52 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 684B9CC1536 for ; Thu, 26 Jan 2017 13:48:52 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 3C993B1F for ; Thu, 26 Jan 2017 13:48:52 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 537B036E5D; Thu, 26 Jan 2017 13:48:51 +0000 (UTC) Date: Thu, 26 Jan 2017 13:48:51 +0000 To: freebsd-net@freebsd.org From: "David_A_Bright_DELL.com (David A. Bright)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: <33f6dd8d5147a416bbd41d93158a5243@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiJ/kM= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 13:48:52 -0000 RGF2aWRfQV9CcmlnaHRfREVMTC5jb20gYWRkZWQgYSBjb21tZW50LgoKCiAgSnVzdCBhIGNvdXBs ZSBzdHlsZSBuaXRzLgoKSU5MSU5FIENPTU1FTlRTCgo+IGlmX3Zhci5oOjQwNwo+ICBFVkVOVEhB TkRMRVJfREVDTEFSRShpZm5ldF9saW5rX2V2ZW50LCBpZm5ldF9saW5rX2V2ZW50X2hhbmRsZXJf dCk7Cj4gKy8qIEludGVyZmFjZSB1cC9pZmRvd24gZXZlbnQgKi8KPiArI2RlZmluZSBJRk5FVF9F VkVOVF9VUAkJMAoKSSB3b3VsZCBzdGljayB3aXRoIHRoZSBwcmV2aW91cyAiaWZ1cC9pZmRvd24i IG9yIGdvIHdpdGggIkludGVyZmFjZSB1cC9kb3duIi4gSSB0aGluayAiSW50ZXJmYWNlIHVwL2lm ZG93biIgcmVhZHMgcG9vcmx5LgoKPiBpZl92YXIuaDo0MDgKPiArLyogSW50ZXJmYWNlIHVwL2lm ZG93biBldmVudCAqLwo+ICsjZGVmaW5lIElGTkVUX0VWRU5UX1VQCQkwCj4gKyNkZWZpbmUgSUZO RVRfRVZFTlRfRE9XTgkxCgpJdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgdGhlIDAvMSB2YWx1ZXMg Zm9yIHRoZXNlIHR3byBkZWZpbmVzIGxpbmUgdXAuIEluIGFueSBjYXNlLCBpdCBkZWZpbml0ZWx5 IHNlZW1zIGxpa2UgdGhlcmUgaXMgZXh0cmFuZW91cyB3aGl0ZXNwYWNlIGJldHdlZW4gIklGTkVU X0VWRU5UX1VQIiBhbmQgIjAiLgoKUkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZy ZWVic2Qub3JnL0Q5MzQ1CgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVl YnNkLm9yZy9zZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IGRlY3VpX21pY3Jv c29mdC5jb20sIGhzZWxhc2t5LCBzZXBoZXJvc2FfZ21haWwuY29tLCBjZW0sIG5wLCBrbWFjeSwg a2liLCBob256aGFuX21pY3Jvc29mdC5jb20sIGhvd2FyZDBzdV9nbWFpbC5jb20sIGpoYiwgYWUs IGRlbHBoaWosIHJveWdlciwgZ2xlYml1cywgZ25uLCByd2F0c29uCkNjOiBEYXZpZF9BX0JyaWdo dF9ERUxMLmNvbSwgZnJlZWJzZC1uZXQtbGlzdAo= From owner-freebsd-net@freebsd.org Thu Jan 26 14:14:21 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF4B5CC1FCE for ; Thu, 26 Jan 2017 14:14:21 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id B7B5710C9 for ; Thu, 26 Jan 2017 14:14:21 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 171F236C08; Thu, 26 Jan 2017 14:14:21 +0000 (UTC) Date: Thu, 26 Jan 2017 14:14:21 +0000 To: freebsd-net@freebsd.org From: "decui_microsoft.com (Dexuan Cui)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: <56ca18038a0b2bc9cb92a0352a59abf4@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiKBD0= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 14:14:22 -0000 ZGVjdWlfbWljcm9zb2Z0LmNvbSBhZGRlZCBpbmxpbmUgY29tbWVudHMuCgpJTkxJTkUgQ09NTUVO VFMKCj4gRGF2aWRfQV9CcmlnaHRfREVMTC5jb20gd3JvdGUgaW4gaWZfdmFyLmg6NDA3Cj4gSSB3 b3VsZCBzdGljayB3aXRoIHRoZSBwcmV2aW91cyAiaWZ1cC9pZmRvd24iIG9yIGdvIHdpdGggIklu dGVyZmFjZSB1cC9kb3duIi4gSSB0aGluayAiSW50ZXJmYWNlIHVwL2lmZG93biIgcmVhZHMgcG9v cmx5LgoKSSB3YXMgdHJ5aW5nIHRvIGtlZXAgdGhlIGNvbnNpc3RlbmN5IHdpdGggTGluZSAzOTIs IDM5NSwgNDAxIGFuZCA0MDQuCkkgd291bGQgdGVuZCB0byBsZWF2ZSB0aGUgcGF0Y2ggYXMgaXQg aXMsIGlmIHlvdSB3b24ndCBzdHJvbmdseSBvYmplY3QgdG8gaXQuIDotKQoKPiBEYXZpZF9BX0Jy aWdodF9ERUxMLmNvbSB3cm90ZSBpbiBpZl92YXIuaDo0MDgKPiBJdCB3b3VsZCBiZSBuaWNlIHRv IGhhdmUgdGhlIDAvMSB2YWx1ZXMgZm9yIHRoZXNlIHR3byBkZWZpbmVzIGxpbmUgdXAuIEluIGFu eSBjYXNlLCBpdCBkZWZpbml0ZWx5IHNlZW1zIGxpa2UgdGhlcmUgaXMgZXh0cmFuZW91cyB3aGl0 ZXNwYWNlIGJldHdlZW4gIklGTkVUX0VWRU5UX1VQIiBhbmQgIjAiLgoKQWN0dWFsbHkgdGhlIDIg bGluZXMgZG8gbGluZSB1cC4KVGhlIHZpc3VhbCBjb25mdXNpb24gaXMgZHVlIHRvIHRoZSBuYXN0 eSBUYWIgaXNzdWUgaW4gdGhlIGNhc2Ugb2YgYSBwYXRjaC4gOi0pCgpXaXRoICJzZXQgbGlzdCIg aW4gbXkgVmltLCB0aGUgbGluZXMgb2YgdGhlIGZpbGUgbmV0L2lmX3Zhci5oIChyYXRoZXIgdGhh biB0aGUgcGF0Y2ggd2l0aCBhIGxlYWRpbmcgKyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBsaW5l cykgIHNob3dzCgojZGVmaW5lIElGTkVUX0VWRU5UX1VQXkleSTAkCiNkZWZpbmUgSUZORVRfRVZF TlRfRE9XTl5JMSQKCl5JIG1lYW5zIGEgVGFiLgokIG1lYW5zIGEgQ1ItTEYuCgpSRVZJU0lPTiBE RVRBSUwKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDkzNDUKCkVNQUlMIFBSRUZFUkVO Q0VTCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3NldHRpbmdzL3BhbmVsL2VtYWlscHJl ZmVyZW5jZXMvCgpUbzogZGVjdWlfbWljcm9zb2Z0LmNvbSwgaHNlbGFza3ksIHNlcGhlcm9zYV9n bWFpbC5jb20sIGNlbSwgbnAsIGttYWN5LCBraWIsIGhvbnpoYW5fbWljcm9zb2Z0LmNvbSwgaG93 YXJkMHN1X2dtYWlsLmNvbSwgamhiLCBhZSwgZGVscGhpaiwgcm95Z2VyLCBnbGViaXVzLCBnbm4s IHJ3YXRzb24KQ2M6IERhdmlkX0FfQnJpZ2h0X0RFTEwuY29tLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Thu Jan 26 14:31:22 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E74D8CC264D for ; Thu, 26 Jan 2017 14:31:22 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id A9C501DF9 for ; Thu, 26 Jan 2017 14:31:22 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id F0D873638C; Thu, 26 Jan 2017 14:31:21 +0000 (UTC) Date: Thu, 26 Jan 2017 14:31:21 +0000 To: freebsd-net@freebsd.org From: "David_A_Bright_DELL.com (David A. Bright)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: <67b43720aa445cb7b82db14eb43dd6e5@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiKCDk= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 14:31:23 -0000 RGF2aWRfQV9CcmlnaHRfREVMTC5jb20gYWNjZXB0ZWQgdGhpcyByZXZpc2lvbi4KRGF2aWRfQV9C cmlnaHRfREVMTC5jb20gYWRkZWQgYSByZXZpZXdlcjogRGF2aWRfQV9CcmlnaHRfREVMTC5jb20u CkRhdmlkX0FfQnJpZ2h0X0RFTEwuY29tIGFkZGVkIGlubGluZSBjb21tZW50cy4KVGhpcyByZXZp c2lvbiBoYXMgYSBwb3NpdGl2ZSByZXZpZXcuCgpJTkxJTkUgQ09NTUVOVFMKCj4gZGVjdWlfbWlj cm9zb2Z0LmNvbSB3cm90ZSBpbiBpZl92YXIuaDo0MDcKPiBJIHdhcyB0cnlpbmcgdG8ga2VlcCB0 aGUgY29uc2lzdGVuY3kgd2l0aCBMaW5lIDM5MiwgMzk1LCA0MDEgYW5kIDQwNC4KPiBJIHdvdWxk IHRlbmQgdG8gbGVhdmUgdGhlIHBhdGNoIGFzIGl0IGlzLCBpZiB5b3Ugd29uJ3Qgc3Ryb25nbHkg b2JqZWN0IHRvIGl0LiA6LSkKCk5vIG9iamVjdGlvbiB0byAiSW50ZXJmYWNlIC4uLiIgYnV0IHRo ZW4gSSdkIHVzZSAiSW50ZXJmYWNlIHVwL2Rvd24gZXZlbnQiICh0aGUgImlmIiBpbiAiaWZkb3du IiBtZWFuaW5nICJpbnRlcmZhY2UiIGlzIHJlZHVuZGFudCkuCgpCdXQsIHRoZW4sIHRoaXMgaXMg YSBuaXQuIEkgZG9uJ3Qgc3Ryb25nbHkgb2JqZWN0IHRvIHRoZSBwYXRjaCBhcy1pcy4KCj4gZGVj dWlfbWljcm9zb2Z0LmNvbSB3cm90ZSBpbiBpZl92YXIuaDo0MDgKPiBBY3R1YWxseSB0aGUgMiBs aW5lcyBkbyBsaW5lIHVwLgo+IFRoZSB2aXN1YWwgY29uZnVzaW9uIGlzIGR1ZSB0byB0aGUgbmFz dHkgVGFiIGlzc3VlIGluIHRoZSBjYXNlIG9mIGEgcGF0Y2guIDotKQo+IAo+IFdpdGggInNldCBs aXN0IiBpbiBteSBWaW0sIHRoZSBsaW5lcyBvZiB0aGUgZmlsZSBuZXQvaWZfdmFyLmggKHJhdGhl ciB0aGFuIHRoZSBwYXRjaCB3aXRoIGEgbGVhZGluZyArIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhl IGxpbmVzKSAgc2hvd3MKPiAKPiAjZGVmaW5lIElGTkVUX0VWRU5UX1VQXkleSTAkCj4gI2RlZmlu ZSBJRk5FVF9FVkVOVF9ET1dOXkkxJAo+IAo+IF5JIG1lYW5zIGEgVGFiLgo+ICQgbWVhbnMgYSBD Ui1MRi4KCkhtbW0sIHlvdSBhcmUgcmlnaHQ7IFBoYWJyaWNhdG9yIGlzIGRlY2VpdmluZyBtZS4g VGhleSBkb24ndCBsaW5lIHVwIGF0IGFsbCBpbiB0aGUgZGlmZiBkaXNwbGF5IGl0IHNob3dzIG1l LCBidXQgeW91IGFyZSByaWdodCB0aGF0IHRoZXkgZG8gaW4gY29kZS4gU29ycnkgYWJvdXQgdGhh dC4KCihKdXN0IGEgbm90ZSB0aGF0IHN0eWxlKDkpIHNheXMgdG8gdXNlIGp1c3QgYSBzaW5nbGUg dGFiIGJldHdlZW4gbmFtZSBhbmQgdmFsdWUsIHdoaWNoIHdvdWxkIG1lYW4gdGhleSB3b3VsZG4n dCBsaW5lIHVwLiBTZWUgc2ltaWxhciBzaXR1YXRpb24gYXQgbGluZXMgMTg1LTE4Ni4pCgpSRVZJ U0lPTiBERVRBSUwKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDkzNDUKCkVNQUlMIFBS RUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3NldHRpbmdzL3BhbmVsL2Vt YWlscHJlZmVyZW5jZXMvCgpUbzogZGVjdWlfbWljcm9zb2Z0LmNvbSwgaHNlbGFza3ksIHNlcGhl cm9zYV9nbWFpbC5jb20sIGNlbSwgbnAsIGttYWN5LCBraWIsIGhvbnpoYW5fbWljcm9zb2Z0LmNv bSwgaG93YXJkMHN1X2dtYWlsLmNvbSwgamhiLCBhZSwgZGVscGhpaiwgcm95Z2VyLCBnbGViaXVz LCBnbm4sIHJ3YXRzb24sIERhdmlkX0FfQnJpZ2h0X0RFTEwuY29tCkNjOiBEYXZpZF9BX0JyaWdo dF9ERUxMLmNvbSwgZnJlZWJzZC1uZXQtbGlzdAo= From owner-freebsd-net@freebsd.org Thu Jan 26 15:59:36 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31D0FCC2795 for ; Thu, 26 Jan 2017 15:59:36 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 09A008FD for ; Thu, 26 Jan 2017 15:59:36 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 4B95836FE5; Thu, 26 Jan 2017 15:59:35 +0000 (UTC) Date: Thu, 26 Jan 2017 15:59:35 +0000 To: freebsd-net@freebsd.org From: "decui_microsoft.com (Dexuan Cui)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: <6f051b4d23dc60c55c963dcffd4cc4b8@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiKHOc= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 15:59:36 -0000 ZGVjdWlfbWljcm9zb2Z0LmNvbSBhZGRlZCBpbmxpbmUgY29tbWVudHMuCgpJTkxJTkUgQ09NTUVO VFMKCj4gRGF2aWRfQV9CcmlnaHRfREVMTC5jb20gd3JvdGUgaW4gaWZfdmFyLmg6NDA3Cj4gTm8g b2JqZWN0aW9uIHRvICJJbnRlcmZhY2UgLi4uIiBidXQgdGhlbiBJJ2QgdXNlICJJbnRlcmZhY2Ug dXAvZG93biBldmVudCIgKHRoZSAiaWYiIGluICJpZmRvd24iIG1lYW5pbmcgImludGVyZmFjZSIg aXMgcmVkdW5kYW50KS4KPiAKPiBCdXQsIHRoZW4sIHRoaXMgaXMgYSBuaXQuIEkgZG9uJ3Qgc3Ry b25nbHkgb2JqZWN0IHRvIHRoZSBwYXRjaCBhcy1pcy4KCk9oLi4uIFNvcnJ5LCBteSBiYWQhIEkg ZmFpbGVkIHRvIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbnQgLS0gaXQncyBsYXRlIGF0IG5pZ2h0 IGhlcmUgYW5kIG9idmlvdXNseSBteSBleWVzIG9yIGJyYWluIGRpZG4ndCB3b3JrIHZlcnkgZ29v ZCA6LSkKClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EOTM0 NQoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvc2V0dGlu Z3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBkZWN1aV9taWNyb3NvZnQuY29tLCBoc2Vs YXNreSwgc2VwaGVyb3NhX2dtYWlsLmNvbSwgY2VtLCBucCwga21hY3ksIGtpYiwgaG9uemhhbl9t aWNyb3NvZnQuY29tLCBob3dhcmQwc3VfZ21haWwuY29tLCBqaGIsIGFlLCBkZWxwaGlqLCByb3ln ZXIsIGdsZWJpdXMsIGdubiwgcndhdHNvbiwgRGF2aWRfQV9CcmlnaHRfREVMTC5jb20KQ2M6IERh dmlkX0FfQnJpZ2h0X0RFTEwuY29tLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Thu Jan 26 16:04:40 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80D67CC29B5 for ; Thu, 26 Jan 2017 16:04:40 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 4370DCDF for ; Thu, 26 Jan 2017 16:04:40 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 7AABE36306; Thu, 26 Jan 2017 16:04:39 +0000 (UTC) Date: Thu, 26 Jan 2017 16:04:39 +0000 To: freebsd-net@freebsd.org From: "decui_microsoft.com (Dexuan Cui)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiKHhc= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_e133e2f9cd01f535aa2a4ad47476bdd3" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 16:04:40 -0000 --b1_e133e2f9cd01f535aa2a4ad47476bdd3 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 ZGVjdWlfbWljcm9zb2Z0LmNvbSB1cGRhdGVkIHRoaXMgcmV2aXNpb24gdG8gRGlmZiAyNDQ3OS4K ZGVjdWlfbWljcm9zb2Z0LmNvbSBhZGRlZCBhIGNvbW1lbnQuClRoaXMgcmV2aXNpb24gbm93IHJl cXVpcmVzIHJldmlldyB0byBwcm9jZWVkLgoKCiAgZml4ZWQgdGhlIGNvbW1lbnQgdHlwbyBwb2lu dGVkIG91dCBieSBEYXZpZC4KCkNIQU5HRVMgU0lOQ0UgTEFTVCBVUERBVEUKICBodHRwczovL3Jl dmlld3MuZnJlZWJzZC5vcmcvRDkzNDU/dnM9MjQ0NjUmaWQ9MjQ0NzkKClJFVklTSU9OIERFVEFJ TAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EOTM0NQoKQUZGRUNURUQgRklMRVMKICBz eXMvbmV0L2lmLmMKICBzeXMvbmV0L2lmX3Zhci5oCiAgc3lzL3N5cy9ldmVudGhhbmRsZXIuaAoK RU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvc2V0dGluZ3Mv cGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBkZWN1aV9taWNyb3NvZnQuY29tLCBoc2VsYXNr eSwgc2VwaGVyb3NhX2dtYWlsLmNvbSwgY2VtLCBucCwga21hY3ksIGtpYiwgaG9uemhhbl9taWNy b3NvZnQuY29tLCBob3dhcmQwc3VfZ21haWwuY29tLCBqaGIsIGFlLCBkZWxwaGlqLCByb3lnZXIs IGdsZWJpdXMsIGdubiwgcndhdHNvbiwgRGF2aWRfQV9CcmlnaHRfREVMTC5jb20KQ2M6IERhdmlk X0FfQnJpZ2h0X0RFTEwuY29tLCBmcmVlYnNkLW5ldC1saXN0Cg== --b1_e133e2f9cd01f535aa2a4ad47476bdd3 Content-Type: text/x-patch; charset=utf-8; name="D9345.24479.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D9345.24479.patch" ZGlmZiAtLWdpdCBhL3N5cy9zeXMvZXZlbnRoYW5kbGVyLmggYi9zeXMvc3lzL2V2ZW50aGFuZGxl ci5oCi0tLSBhL3N5cy9zeXMvZXZlbnRoYW5kbGVyLmgKKysrIGIvc3lzL3N5cy9ldmVudGhhbmRs ZXIuaApAQCAtMjg0LDExICsyODQsNCBAQAogRVZFTlRIQU5ETEVSX0RFQ0xBUkUoc3dhcG9uLCBz d2Fwb25fZm4pOwogRVZFTlRIQU5ETEVSX0RFQ0xBUkUoc3dhcG9mZiwgc3dhcG9mZl9mbik7CiAK LS8qIGlmdXAvaWZkb3duIGV2ZW50cyAqLwotI2RlZmluZSBJRk5FVF9FVkVOVF9VUAkJMAotI2Rl ZmluZSBJRk5FVF9FVkVOVF9ET1dOCTEKLXN0cnVjdCBpZm5ldDsKLXR5cGVkZWYgdm9pZCAoKmlm bmV0X2V2ZW50X2ZuKSh2b2lkICosIHN0cnVjdCBpZm5ldCAqaWZwLCBpbnQgZXZlbnQpOwotRVZF TlRIQU5ETEVSX0RFQ0xBUkUoaWZuZXRfZXZlbnQsIGlmbmV0X2V2ZW50X2ZuKTsKLQogI2VuZGlm IC8qIF9TWVNfRVZFTlRIQU5ETEVSX0hfICovCmRpZmYgLS1naXQgYS9zeXMvbmV0L2lmX3Zhci5o IGIvc3lzL25ldC9pZl92YXIuaAotLS0gYS9zeXMvbmV0L2lmX3Zhci5oCisrKyBiL3N5cy9uZXQv aWZfdmFyLmgKQEAgLTQwNCw2ICs0MDQsMTEgQEAKIC8qIEludGVyZmFjZSBsaW5rIHN0YXRlIGNo YW5nZSBldmVudCAqLwogdHlwZWRlZiB2b2lkICgqaWZuZXRfbGlua19ldmVudF9oYW5kbGVyX3Qp KHZvaWQgKiwgc3RydWN0IGlmbmV0ICosIGludCk7CiBFVkVOVEhBTkRMRVJfREVDTEFSRShpZm5l dF9saW5rX2V2ZW50LCBpZm5ldF9saW5rX2V2ZW50X2hhbmRsZXJfdCk7CisvKiBJbnRlcmZhY2Ug dXAvZG93biBldmVudCAqLworI2RlZmluZSBJRk5FVF9FVkVOVF9VUAkJMAorI2RlZmluZSBJRk5F VF9FVkVOVF9ET1dOCTEKK3R5cGVkZWYgdm9pZCAoKmlmbmV0X2V2ZW50X2ZuKSh2b2lkICosIHN0 cnVjdCBpZm5ldCAqaWZwLCBpbnQgZXZlbnQpOworRVZFTlRIQU5ETEVSX0RFQ0xBUkUoaWZuZXRf ZXZlbnQsIGlmbmV0X2V2ZW50X2ZuKTsKICNlbmRpZiAvKiBfU1lTX0VWRU5USEFORExFUl9IXyAq LwogCiAvKgpkaWZmIC0tZ2l0IGEvc3lzL25ldC9pZi5jIGIvc3lzL25ldC9pZi5jCi0tLSBhL3N5 cy9uZXQvaWYuYworKysgYi9zeXMvbmV0L2lmLmMKQEAgLTU5LDcgKzU5LDYgQEAKICNpbmNsdWRl IDxzeXMvZG9tYWluLmg+CiAjaW5jbHVkZSA8c3lzL2phaWwuaD4KICNpbmNsdWRlIDxzeXMvcHJp di5oPgotI2luY2x1ZGUgPHN5cy9ldmVudGhhbmRsZXIuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUv c3RkYXJnLmg+CiAjaW5jbHVkZSA8dm0vdW1hLmg+Cgo= --b1_e133e2f9cd01f535aa2a4ad47476bdd3-- From owner-freebsd-net@freebsd.org Thu Jan 26 17:28:11 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06D7DCC3E6C for ; Thu, 26 Jan 2017 17:28:11 +0000 (UTC) (envelope-from arybchik@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E7B286A7 for ; Thu, 26 Jan 2017 17:28:10 +0000 (UTC) (envelope-from arybchik@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E4067CC3E6B; Thu, 26 Jan 2017 17:28:10 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3AA8CC3E6A for ; Thu, 26 Jan 2017 17:28:10 +0000 (UTC) (envelope-from arybchik@freebsd.org) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [84.52.89.53]) (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 A651D6A6 for ; Thu, 26 Jan 2017 17:28:10 +0000 (UTC) (envelope-from arybchik@freebsd.org) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id D6F9C7F617 for ; Thu, 26 Jan 2017 20:19:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.9.2 shelob.oktetlabs.ru D6F9C7F617 Authentication-Results: shelob.oktetlabs.ru/D6F9C7F617; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral To: net@FreeBSD.org From: Andrew Rybchenko Subject: ifmedia status callback is non-sleepable Message-ID: <5278f854-4f6f-2ff3-b6d3-f95e23b26ded@freebsd.org> Date: Thu, 26 Jan 2017 20:19:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jan 2017 17:28:11 -0000 Hello, I'd like to double-check that it is intended/known limitation on ifmedia status callback to be non-sleepable. The limitation is imposed by usage of the ifmedia ioctl to get status from lacp/lagg code on port creation (it holds non-sleepable rm_wlock). Backtrace of the corresponding panic: Sleeping thread (tid 100578, pid 10653) owns a non-sleepable lock KDB: stack backtrace of thread 100578: #0 0xffffffff80ae46e2 at mi_switch+0xd2 #1 0xffffffff80b31e6a at sleepq_wait+0x3a #2 0xffffffff80ae34e2 at _sx_xlock_hard+0x592 #3 0xffffffff8222fd7e at sfxge_media_status+0x2e #4 0xffffffff80be7b90 at ifmedia_ioctl+0x170 #5 0xffffffff8222c3d0 at sfxge_if_ioctl+0x1f0 #6 0xffffffff82277fbe at lagg_port_ioctl+0xde #7 0xffffffff82278f9b at lacp_linkstate+0x4b #8 0xffffffff822794c2 at lacp_port_create+0x1e2 #9 0xffffffff82276a73 at lagg_ioctl+0x1243 #10 0xffffffff80bdcbec at ifioctl+0xfbc #11 0xffffffff80b41ab4 at kern_ioctl+0x2d4 #12 0xffffffff80b41771 at sys_ioctl+0x171 #13 0xffffffff80fa16ae at amd64_syscall+0x4ce #14 0xffffffff80f8442b at Xfast_syscall+0xfb panic: sleeping thread cpuid = 23 KDB: stack backtrace: #0 0xffffffff80b24077 at kdb_backtrace+0x67 #1 0xffffffff80ad93e2 at vpanic+0x182 #2 0xffffffff80ad9253 at panic+0x43 #3 0xffffffff80b39a99 at propagate_priority+0x299 #4 0xffffffff80b3a59f at turnstile_wait+0x3ef #5 0xffffffff80ab493d at __mtx_lock_sleep+0x13d #6 0xffffffff80ad39f2 at _rm_wlock+0xb2 #7 0xffffffff82275479 at lagg_port_setlladdr+0x29 #8 0xffffffff80b363ca at taskqueue_run_locked+0x14a #9 0xffffffff80b361bf at taskqueue_run+0xbf #10 0xffffffff80a9340f at intr_event_execute_handlers+0x20f #11 0xffffffff80a93676 at ithread_loop+0xc6 #12 0xffffffff80a90055 at fork_exit+0x85 #13 0xffffffff80f8467e at fork_trampoline+0xe I think vnic driver has the problem as well since it grabs sx_lock from ifmedia status callback. Andrew. From owner-freebsd-net@freebsd.org Thu Jan 26 21:06:17 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 051C6CC1A74 for ; Thu, 26 Jan 2017 21:06:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 D0ED41D0 for ; Thu, 26 Jan 2017 21:06:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0QL6GjN077919 for ; Thu, 26 Jan 2017 21:06:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216304] Adding xn0 to bridge0 causes kernel panic Date: Thu, 26 Jan 2017 21:06:16 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: nvass@gmx.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jan 2017 21:06:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216304 nvass@gmx.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nvass@gmx.com --- Comment #5 from nvass@gmx.com --- Hi, I am getting something similar and I am not sure whether it's related. > panic: _mtx_lock_sleep: recursed on non-recursive mutex if_bridge @ /usr/= src/sys/modules/if_bridge/../../net/if_bridge.c:2117 >=20 > cpuid =3D 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00954= a3260 > vpanic() at vpanic+0x186/frame 0xfffffe00954a32e0 > kassert_panic() at kassert_panic+0x126/frame 0xfffffe00954a3350 > __mtx_lock_sleep() at __mtx_lock_sleep+0x3e2/frame 0xfffffe00954a33d0 > __mtx_lock_flags() at __mtx_lock_flags+0x116/frame 0xfffffe00954a3430 > bridge_transmit() at bridge_transmit+0x61/frame 0xfffffe00954a3470 > ether_output() at ether_output+0x703/frame 0xfffffe00954a3510 > arprequest() at arprequest+0x413/frame 0xfffffe00954a3620 > arp_ifinit() at arp_ifinit+0x56/frame 0xfffffe00954a3660 > arp_handle_ifllchange() at arp_handle_ifllchange+0x3d/frame 0xfffffe00954= a3680 > bridge_ioctl_add() at bridge_ioctl_add+0x3b4/frame 0xfffffe00954a36d0 > bridge_ioctl() at bridge_ioctl+0x29f/frame 0xfffffe00954a3770 > ifioctl() at ifioctl+0xbc8/frame 0xfffffe00954a37f0 > kern_ioctl() at kern_ioctl+0x2b0/frame 0xfffffe00954a3850 > sys_ioctl() at sys_ioctl+0x13f/frame 0xfffffe00954a3930 > amd64_syscall() at amd64_syscall+0x2f9/frame 0xfffffe00954a3ab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00954a3ab0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800fd5aaa, rsp =3D = 0x7fffffffe1f8, rbp =3D 0x7fffffffe2a0 --- > KDB: enter: panic > [ thread pid 770 tid 100560 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 26 21:10:52 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F2E8CC1E01 for ; Thu, 26 Jan 2017 21:10:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 6F204C52 for ; Thu, 26 Jan 2017 21:10:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0QLAqDU053279 for ; Thu, 26 Jan 2017 21:10:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216304] Adding xn0 to bridge0 causes kernel panic Date: Thu, 26 Jan 2017 21:10:52 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jan 2017 21:10:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216304 --- Comment #6 from Kristof Provost --- (In reply to nvass from comment #5) That looks like a different problem. Can you file a new bug with the backtr= ace and a description of how you reproduce this? Please cc me on it. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 26 21:21:52 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E277FCC233C for ; Thu, 26 Jan 2017 21:21:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 D277F26C for ; Thu, 26 Jan 2017 21:21:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0QLLqja000137 for ; Thu, 26 Jan 2017 21:21:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216304] Adding xn0 to bridge0 causes kernel panic Date: Thu, 26 Jan 2017 21:21:52 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: nvass@gmx.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jan 2017 21:21:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216304 --- Comment #7 from nvass@gmx.com --- Thanks for the quick reply! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216510 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 26 21:57:46 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB4DECC30B3 for ; Thu, 26 Jan 2017 21:57:46 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 81E08CBD for ; Thu, 26 Jan 2017 21:57:46 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id CBB2C36A1F; Thu, 26 Jan 2017 21:57:45 +0000 (UTC) Date: Thu, 26 Jan 2017 21:57:45 +0000 To: freebsd-net@freebsd.org From: "glebius (Gleb Smirnoff)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: <660cfc2a980dea57105279e3c84a8ec3@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiKcNk= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 21:57:46 -0000 Z2xlYml1cyBhY2NlcHRlZCB0aGlzIHJldmlzaW9uLgpUaGlzIHJldmlzaW9uIGhhcyBhIHBvc2l0 aXZlIHJldmlldy4KClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9y Zy9EOTM0NQoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcv c2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBkZWN1aV9taWNyb3NvZnQuY29t LCBoc2VsYXNreSwgc2VwaGVyb3NhX2dtYWlsLmNvbSwgY2VtLCBucCwga21hY3ksIGtpYiwgaG9u emhhbl9taWNyb3NvZnQuY29tLCBob3dhcmQwc3VfZ21haWwuY29tLCBqaGIsIGFlLCBkZWxwaGlq LCByb3lnZXIsIGdubiwgcndhdHNvbiwgRGF2aWRfQV9CcmlnaHRfREVMTC5jb20sIGdsZWJpdXMK Q2M6IERhdmlkX0FfQnJpZ2h0X0RFTEwuY29tLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Thu Jan 26 23:54:57 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91A81CC2282 for ; Thu, 26 Jan 2017 23:54:57 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 734F818E9 for ; Thu, 26 Jan 2017 23:54:57 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6FA88CC2280; Thu, 26 Jan 2017 23:54:57 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DA53CC227F for ; Thu, 26 Jan 2017 23:54:57 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2963018E8; Thu, 26 Jan 2017 23:54:57 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-yb0-x22f.google.com with SMTP id 123so61003337ybe.3; Thu, 26 Jan 2017 15:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FFgjSsBnm9qVBGtCZtn0kyVfZkhbvZwruUlN4nP6yzQ=; b=kOX1EWdlXFaITrBj6TzncOZ7U1K6IqDhbSwzOSm3Omp9XTHFo9+4Ovonz9irdLyE4T t0LIHe34Y46pNJ3wLxtohyavjRL3vlhdoAyGmM86yitwHasoai4sTpgRARnJIhbXd+9r KUyDVS5bkOdvO5Z2SGqDX29/rcKyAkBcLTM8guCLzq3QaoPlyc3B2MzjQrMRf0KQ+pE8 xsEMp3dCeSsd/QnZpff6qcRsiHekBF2NxMRDx46HkIrP7uhDN5F8hWF712J9NsH6kp/y JGCGjQ3cp0CDH+eMqdUQjdBPYhDjC70S1PPvRVIvRwBMg+iVYdoSlc/oTHGhm/31HCVW WiRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FFgjSsBnm9qVBGtCZtn0kyVfZkhbvZwruUlN4nP6yzQ=; b=iLE3QF0hV3X4OjcJ1w5i7lFGQlL2LxE3FQARm1x/Rh4d4ZmfH76Qhh/Wqim8XcBMto OpMlQgYMhYixMq6Q0qKpmj5lCtWKPaKgk5nlYFna9zAA6u9IzGEKJcdtsQneRKcVhCoA 1Dg+U2LntFwirXFwV2STzuyzDg5UhE6jRQBQfU0EdMOzsF5CHtBdRR3cRKybIaK9hmAL QyPy3AMOkQKilvc7lY/8Gq0sYDrMbxzciguQFGAm6uzBYNnnWdsV+AWaSvHCy/55e4ma +0hxYqE2WVaKifSzFKEOvvzE0FVX3w05tdeL9DlyN9V/jJO/wa3wbGmOhAHuriFbN2oq 4msw== X-Gm-Message-State: AIkVDXKQWJFD3pPQf4VJdo+f5djASoAcf1LhRgxnfXkQX2RGx8H6O+uPbIQSI/RJiYceinQapME5RePRP3X0pg== X-Received: by 10.129.96.137 with SMTP id u131mr4282687ywb.302.1485474896234; Thu, 26 Jan 2017 15:54:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.20.23 with HTTP; Thu, 26 Jan 2017 15:54:55 -0800 (PST) In-Reply-To: <5278f854-4f6f-2ff3-b6d3-f95e23b26ded@freebsd.org> References: <5278f854-4f6f-2ff3-b6d3-f95e23b26ded@freebsd.org> From: Navdeep Parhar Date: Thu, 26 Jan 2017 15:54:55 -0800 Message-ID: Subject: Re: ifmedia status callback is non-sleepable To: Andrew Rybchenko Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jan 2017 23:54:57 -0000 I think it's a bad idea in general for the kernel to be holding non-sleepable locks around driver ioctls. Regards, Navdeep On Thu, Jan 26, 2017 at 9:19 AM, Andrew Rybchenko wrote: > Hello, > > I'd like to double-check that it is intended/known limitation on ifmedia > status callback to be non-sleepable. > The limitation is imposed by usage of the ifmedia ioctl to get status from > lacp/lagg code on port creation (it holds non-sleepable rm_wlock). > > Backtrace of the corresponding panic: > > Sleeping thread (tid 100578, pid 10653) owns a non-sleepable lock > KDB: stack backtrace of thread 100578: > #0 0xffffffff80ae46e2 at mi_switch+0xd2 > #1 0xffffffff80b31e6a at sleepq_wait+0x3a > #2 0xffffffff80ae34e2 at _sx_xlock_hard+0x592 > #3 0xffffffff8222fd7e at sfxge_media_status+0x2e > #4 0xffffffff80be7b90 at ifmedia_ioctl+0x170 > #5 0xffffffff8222c3d0 at sfxge_if_ioctl+0x1f0 > #6 0xffffffff82277fbe at lagg_port_ioctl+0xde > #7 0xffffffff82278f9b at lacp_linkstate+0x4b > #8 0xffffffff822794c2 at lacp_port_create+0x1e2 > #9 0xffffffff82276a73 at lagg_ioctl+0x1243 > #10 0xffffffff80bdcbec at ifioctl+0xfbc > #11 0xffffffff80b41ab4 at kern_ioctl+0x2d4 > #12 0xffffffff80b41771 at sys_ioctl+0x171 > #13 0xffffffff80fa16ae at amd64_syscall+0x4ce > #14 0xffffffff80f8442b at Xfast_syscall+0xfb > panic: sleeping thread > cpuid = 23 > KDB: stack backtrace: > #0 0xffffffff80b24077 at kdb_backtrace+0x67 > #1 0xffffffff80ad93e2 at vpanic+0x182 > #2 0xffffffff80ad9253 at panic+0x43 > #3 0xffffffff80b39a99 at propagate_priority+0x299 > #4 0xffffffff80b3a59f at turnstile_wait+0x3ef > #5 0xffffffff80ab493d at __mtx_lock_sleep+0x13d > #6 0xffffffff80ad39f2 at _rm_wlock+0xb2 > #7 0xffffffff82275479 at lagg_port_setlladdr+0x29 > #8 0xffffffff80b363ca at taskqueue_run_locked+0x14a > #9 0xffffffff80b361bf at taskqueue_run+0xbf > #10 0xffffffff80a9340f at intr_event_execute_handlers+0x20f > #11 0xffffffff80a93676 at ithread_loop+0xc6 > #12 0xffffffff80a90055 at fork_exit+0x85 > #13 0xffffffff80f8467e at fork_trampoline+0xe > > I think vnic driver has the problem as well since it grabs sx_lock from > ifmedia status callback. > > Andrew. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://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 Jan 27 00:52:53 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E940CC3949 for ; Fri, 27 Jan 2017 00:52:53 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 08DF91D10 for ; Fri, 27 Jan 2017 00:52:53 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 07A6ECC3948; Fri, 27 Jan 2017 00:52:53 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06DE0CC3947 for ; Fri, 27 Jan 2017 00:52:53 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 573691D0F; Fri, 27 Jan 2017 00:52:52 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v0R0qp2U031442 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Jan 2017 16:52:51 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v0R0qpEn031441; Thu, 26 Jan 2017 16:52:51 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 26 Jan 2017 16:52:51 -0800 From: Gleb Smirnoff To: jch@FreeBSD.org, hiren@FreeBSD.org, Jason Eggleston Cc: jtl@FreeBSD.org, rrs@FreeBSD.org, net@FreeBSD.org Subject: listening sockets as non sockets Message-ID: <20170127005251.GM2611@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/QKKmeG/X/bPShih" Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 00:52:53 -0000 --/QKKmeG/X/bPShih Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi guys, as some of you already heard, I'm trying to separate listening sockets into a new file descriptor type. If we look into current struct socket, we see that some functional fields belong to normal data flow sockets, and other belong to listening socket. They are never used simultaneously. Now, if we look at socket API, we see that once a socket underwent transformation to a listening socket, only 3 regular syscalls now may be called: listen(2), accept(2) and close(2) and a subset of ioctl() and setsockopt() parameters is accepted. A listening socket cannot be closed from the protocol side, only from user side. So, listening socket is so different from a dataflow socket, that separating them looks architecturally right thing to do. The benefits are: 1) Nicer code (I hope). 2) Smaller 'struct socket'. 3) Having two different locks for socket and solisten, we can try to get rid of ACCEPT_LOCK global lock. The patch is in a very pre-alpha state. It has been run only in my bhyve VM. It passes regression tests from tools/regression/sockets and tests/sys, including the race tests, and including accept filter ones. For TCP it passes basic functionality testing, but likely there are still races remaining after ACCEPT_LOCK removal. For SCTP the patch is unfinished yet. The tricky thing with SCTP is that it can un-listen a listening socket back to normal socket, doing listen(fd, 0) on it. My patch has API for that I started working on SCTP, but temporarily put this problem aside. It looks solvable, but I don't know yet how to test it. Better first see results with TCP. I've put current snapshot to Phab, so that you can view it there. The snap patch is also attached to this email. https://reviews.freebsd.org/D9356 At this moment I'd like to start doing some testing (and doing polishing in parallel), and here I seek for your help. Those, who run FreeBSD at very high connection rates and observe contention on the accept global mutex, anybody willing to collaborate with me on this? -- Totus tuus, Glebius. --/QKKmeG/X/bPShih Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="solisten.diff" Index: sys/kern/kern_sendfile.c =================================================================== --- sys/kern/kern_sendfile.c (revision 312784) +++ sys/kern/kern_sendfile.c (working copy) @@ -510,7 +510,7 @@ sendfile_getsock(struct thread *td, int s, struct * The socket must be a stream socket and connected. */ error = getsock_cap(td, s, cap_rights_init(&rights, CAP_SEND), - sock_fp, NULL, NULL); + sock_fp, NULL, NULL, DTYPE_SOCKET); if (error != 0) return (error); *so = (*sock_fp)->f_data; Index: sys/kern/sys_socket.c =================================================================== --- sys/kern/sys_socket.c (revision 312784) +++ sys/kern/sys_socket.c (working copy) @@ -115,6 +115,28 @@ struct fileops socketops = { .fo_flags = DFLAG_PASSABLE }; +static fo_rdwr_t notconn_readwrite; +static fo_ioctl_t sol_ioctl; +static fo_poll_t sol_poll; +extern fo_kqfilter_t sol_kqfilter; +static fo_stat_t sol_stat; +static fo_close_t sol_close; + +struct fileops solistenops = { + .fo_read = notconn_readwrite, + .fo_write = notconn_readwrite, + .fo_truncate = invfo_truncate, + .fo_ioctl = sol_ioctl, + .fo_poll = sol_poll, + .fo_kqfilter = sol_kqfilter, + .fo_stat = sol_stat, /* XXXGL: to do? */ + .fo_close = sol_close, + .fo_chmod = invfo_chmod, + .fo_chown = invfo_chown, + .fo_sendfile = invfo_sendfile, + .fo_flags = DFLAG_PASSABLE +}; + static int soo_read(struct file *fp, struct uio *uio, struct ucred *active_cred, int flags, struct thread *td) @@ -153,6 +175,14 @@ soo_write(struct file *fp, struct uio *uio, struct } static int +notconn_readwrite(struct file *fp, struct uio *uio, struct ucred *active_cred, + int flags, struct thread *td) +{ + + return (ENOTCONN); +} + +static int soo_ioctl(struct file *fp, u_long cmd, void *data, struct ucred *active_cred, struct thread *td) { @@ -262,6 +292,61 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, } static int +sol_ioctl(struct file *fp, u_long cmd, void *data, struct ucred *active_cred, + struct thread *td) +{ + struct solisten *sol = fp->f_data; + int error = 0; + + switch (cmd) { + case FIONBIO: + SOLISTEN_LOCK(sol); + if (*(int *)data) + sol->sol_state |= SS_NBIO; + else + sol->sol_state &= ~SS_NBIO; + SOLISTEN_UNLOCK(sol); + break; + + case FIOASYNC: + SOLISTEN_LOCK(sol); + /* To be copied to child sockets. */ + if (*(int *)data) + sol->sol_state |= SS_ASYNC; + else + sol->sol_state &= ~SS_ASYNC; + SOLISTEN_UNLOCK(sol); + break; + + case FIOSETOWN: + error = fsetown(*(int *)data, &sol->sol_sigio); + break; + + case FIOGETOWN: + *(int *)data = fgetown(&sol->sol_sigio); + break; + + case SIOCSPGRP: + error = fsetown(-(*(int *)data), &sol->sol_sigio); + break; + + case SIOCGPGRP: + *(int *)data = -fgetown(&sol->sol_sigio); + break; + + case FIONREAD: + case FIONWRITE: + case FIONSPACE: + case SIOCATMARK: + /* XXXGL: find a better error code for these. ENOBUFS? */ + default: + error = EINVAL; + } + + return (error); +} + +static int soo_poll(struct file *fp, int events, struct ucred *active_cred, struct thread *td) { @@ -277,6 +362,22 @@ soo_poll(struct file *fp, int events, struct ucred } static int +sol_poll(struct file *fp, int events, struct ucred *active_cred, + struct thread *td) +{ + struct solisten *sol = fp->f_data; +#ifdef MAC + int error; + + /* XXXGL */ + error = mac_socket_check_poll(active_cred, (struct socket *)sol); + if (error) + return (error); +#endif + return (solistenpoll(sol, events, fp->f_cred, td)); +} + +static int soo_stat(struct file *fp, struct stat *ub, struct ucred *active_cred, struct thread *td) { @@ -314,6 +415,14 @@ soo_stat(struct file *fp, struct stat *ub, struct return (*so->so_proto->pr_usrreqs->pru_sense)(so, ub); } +static int +sol_stat(struct file *fp, struct stat *ub, struct ucred *active_cred, + struct thread *td) +{ + + return (EINVAL); +} + /* * API socket close on file pointer. We call soclose() to close the socket * (including initiating closing protocols). soclose() will sorele() the @@ -336,6 +445,17 @@ soo_close(struct file *fp, struct thread *td) } static int +sol_close(struct file *fp, struct thread *td) +{ + struct solisten *sol = fp->f_data; + + fp->f_ops = &badfileops; + fp->f_data = NULL; + + return (solistenclose(sol)); +} + +static int soo_fill_kinfo(struct file *fp, struct kinfo_file *kif, struct filedesc *fdp) { struct sockaddr *sa; @@ -695,7 +815,6 @@ soaio_process_sb(struct socket *so, struct sockbuf sb->sb_flags &= ~SB_AIO_RUNNING; SOCKBUF_UNLOCK(sb); - ACCEPT_LOCK(); SOCK_LOCK(so); sorele(so); } Index: sys/kern/uipc_accf.c =================================================================== --- sys/kern/uipc_accf.c (revision 312784) +++ sys/kern/uipc_accf.c (working copy) @@ -162,28 +162,23 @@ accept_filt_generic_mod_event(module_t mod, int ev } int -do_getopt_accept_filter(struct socket *so, struct sockopt *sopt) +accept_filt_getopt(struct solisten *sol, struct sockopt *sopt) { struct accept_filter_arg *afap; int error; error = 0; - afap = malloc(sizeof(*afap), M_TEMP, - M_WAITOK | M_ZERO); - SOCK_LOCK(so); - if ((so->so_options & SO_ACCEPTCONN) == 0) { + afap = malloc(sizeof(*afap), M_TEMP, M_WAITOK | M_ZERO); + SOLISTEN_LOCK(sol); + if (sol->sol_accept_filter == NULL) { error = EINVAL; goto out; } - if ((so->so_options & SO_ACCEPTFILTER) == 0) { - error = EINVAL; - goto out; - } - strcpy(afap->af_name, so->so_accf->so_accept_filter->accf_name); - if (so->so_accf->so_accept_filter_str != NULL) - strcpy(afap->af_arg, so->so_accf->so_accept_filter_str); + strcpy(afap->af_name, sol->sol_accept_filter->accf_name); + if (sol->sol_accept_filter_str != NULL) + strcpy(afap->af_arg, sol->sol_accept_filter_str); out: - SOCK_UNLOCK(so); + SOLISTEN_UNLOCK(sol); if (error == 0) error = sooptcopyout(sopt, afap, sizeof(*afap)); free(afap, M_TEMP); @@ -191,35 +186,29 @@ out: } int -do_setopt_accept_filter(struct socket *so, struct sockopt *sopt) +accept_filt_setopt(struct solisten *sol, struct sockopt *sopt) { struct accept_filter_arg *afap; struct accept_filter *afp; - struct so_accf *newaf; - int error = 0; + char *accept_filter_str = NULL; + void *accept_filter_arg = NULL; + int error; /* * Handle the simple delete case first. */ if (sopt == NULL || sopt->sopt_val == NULL) { - SOCK_LOCK(so); - if ((so->so_options & SO_ACCEPTCONN) == 0) { - SOCK_UNLOCK(so); - return (EINVAL); + SOLISTEN_LOCK(sol); + if (sol->sol_accept_filter != NULL) { + if (sol->sol_accept_filter->accf_destroy != NULL) + sol->sol_accept_filter->accf_destroy(sol); + if (sol->sol_accept_filter_str != NULL) + free(sol->sol_accept_filter_str, M_ACCF); + sol->sol_accept_filter = NULL; + sol->sol_accept_filter_arg = NULL; + sol->sol_accept_filter_str = NULL; } - if (so->so_accf != NULL) { - struct so_accf *af = so->so_accf; - if (af->so_accept_filter != NULL && - af->so_accept_filter->accf_destroy != NULL) { - af->so_accept_filter->accf_destroy(so); - } - if (af->so_accept_filter_str != NULL) - free(af->so_accept_filter_str, M_ACCF); - free(af, M_ACCF); - so->so_accf = NULL; - } - so->so_options &= ~SO_ACCEPTFILTER; - SOCK_UNLOCK(so); + SOLISTEN_UNLOCK(sol); return (0); } @@ -227,8 +216,7 @@ int * Pre-allocate any memory we may need later to avoid blocking at * untimely moments. This does not optimize for invalid arguments. */ - afap = malloc(sizeof(*afap), M_TEMP, - M_WAITOK); + afap = malloc(sizeof(*afap), M_TEMP, M_WAITOK); error = sooptcopyin(sopt, afap, sizeof *afap, sizeof *afap); afap->af_name[sizeof(afap->af_name)-1] = '\0'; afap->af_arg[sizeof(afap->af_arg)-1] = '\0'; @@ -241,28 +229,18 @@ int free(afap, M_TEMP); return (ENOENT); } - /* - * Allocate the new accept filter instance storage. We may - * have to free it again later if we fail to attach it. If - * attached properly, 'newaf' is NULLed to avoid a free() - * while in use. - */ - newaf = malloc(sizeof(*newaf), M_ACCF, M_WAITOK | - M_ZERO); + if (afp->accf_create != NULL && afap->af_name[0] != '\0') { size_t len = strlen(afap->af_name) + 1; - newaf->so_accept_filter_str = malloc(len, M_ACCF, - M_WAITOK); - strcpy(newaf->so_accept_filter_str, afap->af_name); + accept_filter_str = malloc(len, M_ACCF, M_WAITOK); + strcpy(accept_filter_str, afap->af_name); } /* - * Require a listen socket; don't try to replace an existing filter - * without first removing it. + * Don't try to replace an existing filter without first removing it. */ - SOCK_LOCK(so); - if (((so->so_options & SO_ACCEPTCONN) == 0) || - (so->so_accf != NULL)) { + SOLISTEN_LOCK(sol); + if (sol->sol_accept_filter != NULL) { error = EINVAL; goto out; } @@ -273,25 +251,19 @@ int * can't block. */ if (afp->accf_create != NULL) { - newaf->so_accept_filter_arg = - afp->accf_create(so, afap->af_arg); - if (newaf->so_accept_filter_arg == NULL) { + accept_filter_arg = afp->accf_create(sol, afap->af_arg); + if (accept_filter_arg == NULL) { error = EINVAL; goto out; } } - newaf->so_accept_filter = afp; - so->so_accf = newaf; - so->so_options |= SO_ACCEPTFILTER; - newaf = NULL; + sol->sol_accept_filter = afp; + sol->sol_accept_filter_arg = accept_filter_arg; + sol->sol_accept_filter_str = accept_filter_str; out: - SOCK_UNLOCK(so); - if (newaf != NULL) { - if (newaf->so_accept_filter_str != NULL) - free(newaf->so_accept_filter_str, M_ACCF); - free(newaf, M_ACCF); - } - if (afap != NULL) - free(afap, M_TEMP); + SOLISTEN_UNLOCK(sol); + if (accept_filter_str != NULL) + free(accept_filter_str, M_ACCF); + free(afap, M_TEMP); return (error); } Index: sys/kern/uipc_debug.c =================================================================== --- sys/kern/uipc_debug.c (revision 312784) +++ sys/kern/uipc_debug.c (working copy) @@ -84,10 +84,6 @@ db_print_sooptions(short so_options) db_printf("%sSO_DEBUG", comma ? ", " : ""); comma = 1; } - if (so_options & SO_ACCEPTCONN) { - db_printf("%sSO_ACCEPTCONN", comma ? ", " : ""); - comma = 1; - } if (so_options & SO_REUSEADDR) { db_printf("%sSO_REUSEADDR", comma ? ", " : ""); comma = 1; @@ -458,15 +454,8 @@ db_print_socket(struct socket *so, const char *soc db_print_protosw(so->so_proto, "so_proto", indent); db_print_indent(indent); - db_printf("so_head: %p ", so->so_head); - db_printf("so_incomp first: %p ", TAILQ_FIRST(&so->so_incomp)); - db_printf("so_comp first: %p\n", TAILQ_FIRST(&so->so_comp)); - - db_print_indent(indent); + db_printf("so_listen: %p ", so->so_listen); /* so_list skipped */ - db_printf("so_qlen: %u ", so->so_qlen); - db_printf("so_incqlen: %u ", so->so_incqlen); - db_printf("so_qlimit: %u ", so->so_qlimit); db_printf("so_timeo: %d ", so->so_timeo); db_printf("so_error: %d\n", so->so_error); @@ -478,6 +467,29 @@ db_print_socket(struct socket *so, const char *soc db_print_sockbuf(&so->so_snd, "so_snd", indent); } +static void +db_print_solisten(struct solisten *sol, const char *socketname, int indent) +{ + + db_print_indent(indent); + db_printf("%s at %p\n", socketname, sol); + + indent += 2; + + db_print_indent(indent); + db_printf("sol_incomp first: %p ", TAILQ_FIRST(&sol->sol_incomp)); + db_printf("sol_comp first: %p\n", TAILQ_FIRST(&sol->sol_comp)); + db_printf("sol_qlen: %d ", sol->sol_qlen); + db_printf("sol_incqlen: %d ", sol->sol_incqlen); + db_printf("sol_qlimit: %d ", sol->sol_qlimit); + db_printf(")\n"); + + db_print_indent(indent); + db_printf("sol_options: 0x%x (", sol->sol_options); + db_print_sooptions(sol->sol_options); + db_printf(")\n"); +} + DB_SHOW_COMMAND(socket, db_show_socket) { struct socket *so; @@ -491,6 +503,19 @@ DB_SHOW_COMMAND(socket, db_show_socket) db_print_socket(so, "socket", 0); } +DB_SHOW_COMMAND(solisten, db_show_solisten) +{ + struct solisten *sol; + + if (!have_addr) { + db_printf("usage: show solisten \n"); + return; + } + sol = (struct solisten *)addr; + + db_print_solisten(sol, "solisten", 0); +} + DB_SHOW_COMMAND(sockbuf, db_show_sockbuf) { struct sockbuf *sb; Index: sys/kern/uipc_socket.c =================================================================== --- sys/kern/uipc_socket.c (revision 312784) +++ sys/kern/uipc_socket.c (working copy) @@ -106,6 +106,7 @@ __FBSDID("$FreeBSD$"); #include "opt_inet.h" #include "opt_inet6.h" #include "opt_compat.h" +#include "opt_sctp.h" #include #include @@ -159,14 +160,17 @@ static void filt_sordetach(struct knote *kn); static int filt_soread(struct knote *kn, long hint); static void filt_sowdetach(struct knote *kn); static int filt_sowrite(struct knote *kn, long hint); +static int filt_soempty(struct knote *kn, long hint); static int filt_solisten(struct knote *kn, long hint); +static void filt_soldetach(struct knote *kn); static int inline hhook_run_socket(struct socket *so, void *hctx, int32_t h_id); -static int filt_soempty(struct knote *kn, long hint); + fo_kqfilter_t soo_kqfilter; +fo_kqfilter_t sol_kqfilter; static struct filterops solisten_filtops = { .f_isfd = 1, - .f_detach = filt_sordetach, + .f_detach = filt_soldetach, .f_event = filt_solisten, }; static struct filterops soread_filtops = { @@ -187,6 +191,7 @@ static struct filterops soempty_filtops = { so_gen_t so_gencnt; /* generation count for sockets */ +MALLOC_DEFINE(M_SOLISTEN, "solisten", "listening sockets"); MALLOC_DEFINE(M_SONAME, "soname", "socket name"); MALLOC_DEFINE(M_PCB, "pcb", "protocol control block"); @@ -439,7 +444,6 @@ sodealloc(struct socket *so) { KASSERT(so->so_count == 0, ("sodealloc(): so_count %d", so->so_count)); - KASSERT(so->so_pcb == NULL, ("sodealloc(): so_pcb != NULL")); mtx_lock(&so_global_mtx); so->so_gencnt = ++so_gencnt; @@ -456,9 +460,6 @@ sodealloc(struct socket *so) if (so->so_snd.sb_hiwat) (void)chgsbsize(so->so_cred->cr_uidinfo, &so->so_snd.sb_hiwat, 0, RLIM_INFINITY); - /* remove accept filter if one is present. */ - if (so->so_accf != NULL) - do_setopt_accept_filter(so, NULL); #ifdef MAC mac_socket_destroy(so); #endif @@ -512,8 +513,6 @@ socreate(int dom, struct socket **aso, int type, i if (so == NULL) return (ENOBUFS); - TAILQ_INIT(&so->so_incomp); - TAILQ_INIT(&so->so_comp); so->so_type = type; so->so_cred = crhold(cred); if ((prp->pr_domain->dom_family == PF_INET) || @@ -563,7 +562,7 @@ SYSCTL_INT(_regression, OID_AUTO, sonewconn_earlyt * Note: the ref count on the socket is 0 on return. */ struct socket * -sonewconn(struct socket *head, int connstatus) +sonewconn(struct solisten *sol, int connstatus) { static struct timeval lastover; static struct timeval overinterval = { 60, 0 }; @@ -570,11 +569,11 @@ struct socket * static int overcount; struct socket *so; - int over; + u_int over; - ACCEPT_LOCK(); - over = (head->so_qlen > 3 * head->so_qlimit / 2); - ACCEPT_UNLOCK(); + SOLISTEN_LOCK(sol); + over = (sol->sol_qlen > 3 * sol->sol_qlimit / 2); + SOLISTEN_UNLOCK(sol); #ifdef REGRESSION if (regression_sonewconn_earlytest && over) { #else @@ -586,7 +585,7 @@ struct socket * log(LOG_DEBUG, "%s: pcb %p: Listen queue overflow: " "%i already in queue awaiting acceptance " "(%d occurrences)\n", - __func__, head->so_pcb, head->so_qlen, overcount); + __func__, sol->sol_pcb, sol->sol_qlen, overcount); overcount = 0; } @@ -593,69 +592,57 @@ struct socket * return (NULL); } - VNET_ASSERT(head->so_vnet != NULL, ("%s:%d so_vnet is NULL, head=%p", - __func__, __LINE__, head)); - so = soalloc(head->so_vnet); + VNET_ASSERT(sol->sol_vnet != NULL, ("%s: sol %p vnet is NULL", + __func__, sol)); + so = soalloc(sol->sol_vnet); if (so == NULL) { log(LOG_DEBUG, "%s: pcb %p: New socket allocation failure: " "limit reached or out of memory\n", - __func__, head->so_pcb); + __func__, sol->sol_pcb); return (NULL); } - if ((head->so_options & SO_ACCEPTFILTER) != 0) + if (sol->sol_accept_filter != NULL) connstatus = 0; - so->so_head = head; - so->so_type = head->so_type; - so->so_options = head->so_options &~ SO_ACCEPTCONN; - so->so_linger = head->so_linger; - so->so_state = head->so_state | SS_NOFDREF; - so->so_fibnum = head->so_fibnum; - so->so_proto = head->so_proto; - so->so_cred = crhold(head->so_cred); + so->so_listen = sol; + so->so_type = sol->sol_type; + so->so_options = sol->sol_options; + so->so_linger = sol->sol_linger; + so->so_state = sol->sol_state | SS_NOFDREF; + so->so_fibnum = sol->sol_fibnum; + so->so_proto = sol->sol_proto; + so->so_cred = crhold(sol->sol_cred); #ifdef MAC - mac_socket_newconn(head, so); + QQQ + mac_socket_newconn(sol, so); #endif knlist_init_mtx(&so->so_rcv.sb_sel.si_note, SOCKBUF_MTX(&so->so_rcv)); knlist_init_mtx(&so->so_snd.sb_sel.si_note, SOCKBUF_MTX(&so->so_snd)); - VNET_SO_ASSERT(head); - if (soreserve(so, head->so_snd.sb_hiwat, head->so_rcv.sb_hiwat)) { + VNET_SO_ASSERT(sol); + if (soreserve(so, sol->sol_sbsnd_hiwat, sol->sol_sbrcv_hiwat)) { sodealloc(so); log(LOG_DEBUG, "%s: pcb %p: soreserve() failed\n", - __func__, head->so_pcb); + __func__, sol->sol_pcb); return (NULL); } if ((*so->so_proto->pr_usrreqs->pru_attach)(so, 0, NULL)) { sodealloc(so); log(LOG_DEBUG, "%s: pcb %p: pru_attach() failed\n", - __func__, head->so_pcb); + __func__, sol->sol_pcb); return (NULL); } - so->so_rcv.sb_lowat = head->so_rcv.sb_lowat; - so->so_snd.sb_lowat = head->so_snd.sb_lowat; - so->so_rcv.sb_timeo = head->so_rcv.sb_timeo; - so->so_snd.sb_timeo = head->so_snd.sb_timeo; - so->so_rcv.sb_flags |= head->so_rcv.sb_flags & SB_AUTOSIZE; - so->so_snd.sb_flags |= head->so_snd.sb_flags & SB_AUTOSIZE; + so->so_rcv.sb_lowat = sol->sol_sbrcv_lowat; + so->so_snd.sb_lowat = sol->sol_sbsnd_lowat; + so->so_rcv.sb_timeo = sol->sol_sbrcv_timeo; + so->so_snd.sb_timeo = sol->sol_sbsnd_timeo; + so->so_rcv.sb_flags |= sol->sol_sbrcv_flags & SB_AUTOSIZE; + so->so_snd.sb_flags |= sol->sol_sbsnd_flags & SB_AUTOSIZE; so->so_state |= connstatus; - ACCEPT_LOCK(); - /* - * The accept socket may be tearing down but we just - * won a race on the ACCEPT_LOCK. - * However, if sctp_peeloff() is called on a 1-to-many - * style socket, the SO_ACCEPTCONN doesn't need to be set. - */ - if (!(head->so_options & SO_ACCEPTCONN) && - ((head->so_proto->pr_protocol != IPPROTO_SCTP) || - (head->so_type != SOCK_SEQPACKET))) { - SOCK_LOCK(so); - so->so_head = NULL; - sofree(so); /* NB: returns ACCEPT_UNLOCK'ed. */ - return (NULL); - } + + SOLISTEN_LOCK(sol); if (connstatus) { - TAILQ_INSERT_TAIL(&head->so_comp, so, so_list); + TAILQ_INSERT_TAIL(&sol->sol_comp, so, so_list); so->so_qstate |= SQ_COMP; - head->so_qlen++; + sol->sol_qlen++; } else { /* * Keep removing sockets from the head until there's room for @@ -664,29 +651,90 @@ struct socket * * threads and soabort() requires dropping locks, we must * loop waiting for the condition to be true. */ - while (head->so_incqlen > head->so_qlimit) { + while (sol->sol_incqlen > sol->sol_qlimit) { struct socket *sp; - sp = TAILQ_FIRST(&head->so_incomp); - TAILQ_REMOVE(&head->so_incomp, sp, so_list); - head->so_incqlen--; + sp = TAILQ_FIRST(&sol->sol_incomp); + TAILQ_REMOVE(&sol->sol_incomp, sp, so_list); + sol->sol_incqlen--; sp->so_qstate &= ~SQ_INCOMP; - sp->so_head = NULL; - ACCEPT_UNLOCK(); + sp->so_listen = NULL; + SOLISTEN_UNLOCK(sol); soabort(sp); - ACCEPT_LOCK(); + SOLISTEN_LOCK(sol); } - TAILQ_INSERT_TAIL(&head->so_incomp, so, so_list); + TAILQ_INSERT_TAIL(&sol->sol_incomp, so, so_list); so->so_qstate |= SQ_INCOMP; - head->so_incqlen++; + sol->sol_incqlen++; } - ACCEPT_UNLOCK(); + SOLISTEN_UNLOCK(sol); if (connstatus) { - sorwakeup(head); - wakeup_one(&head->so_timeo); + /* QQQ sorwakeup(head); */ + selwakeuppri(&sol->sol_selinfo, PSOCK); + KNOTE_LOCKED(&sol->sol_selinfo.si_note, 0); + wakeup_one(&sol->sol_comp); } return (so); } +#ifdef SCTP +/* + * Socket part of sctp_peeloff(). Detach a new socket from an + * association. The new socket is returned with a reference. + */ +struct socket * +sopeeloff(struct socket *head) +{ + struct socket *so; + + VNET_ASSERT(head->so_vnet != NULL, ("%s:%d so_vnet is NULL, head=%p", + __func__, __LINE__, head)); + so = soalloc(head->so_vnet); + if (so == NULL) { + log(LOG_DEBUG, "%s: pcb %p: New socket allocation failure: " + "limit reached or out of memory\n", + __func__, head->so_pcb); + return (NULL); + } + so->so_type = head->so_type; + so->so_options = head->so_options; + so->so_linger = head->so_linger; + so->so_state = (head->so_state & SS_NBIO) | SS_ISCONNECTED; + so->so_fibnum = head->so_fibnum; + so->so_proto = head->so_proto; + so->so_cred = crhold(head->so_cred); +#ifdef MAC + mac_socket_newconn(head, so); +#endif + knlist_init_mtx(&so->so_rcv.sb_sel.si_note, SOCKBUF_MTX(&so->so_rcv)); + knlist_init_mtx(&so->so_snd.sb_sel.si_note, SOCKBUF_MTX(&so->so_snd)); + VNET_SO_ASSERT(head); + if (soreserve(so, head->so_snd.sb_hiwat, head->so_rcv.sb_hiwat)) { + sodealloc(so); + log(LOG_DEBUG, "%s: pcb %p: soreserve() failed\n", + __func__, head->so_pcb); + return (NULL); + } + if ((*so->so_proto->pr_usrreqs->pru_attach)(so, 0, NULL)) { + sodealloc(so); + log(LOG_DEBUG, "%s: pcb %p: pru_attach() failed\n", + __func__, head->so_pcb); + return (NULL); + } + so->so_rcv.sb_lowat = head->so_rcv.sb_lowat; + so->so_snd.sb_lowat = head->so_snd.sb_lowat; + so->so_rcv.sb_timeo = head->so_rcv.sb_timeo; + so->so_snd.sb_timeo = head->so_snd.sb_timeo; + so->so_rcv.sb_flags |= head->so_rcv.sb_flags & SB_AUTOSIZE; + so->so_snd.sb_flags |= head->so_snd.sb_flags & SB_AUTOSIZE; + + SOCK_LOCK(so); + soref(so); + SOCK_UNLOCK(so); + + return (so); +} +#endif /* SCTP */ + int sobind(struct socket *so, struct sockaddr *nam, struct thread *td) { @@ -711,49 +759,128 @@ sobindat(int fd, struct socket *so, struct sockadd /* * solisten() transitions a socket from a non-listening state to a listening - * state, but can also be used to update the listen queue depth on an - * existing listen socket. The protocol will call back into the sockets - * layer using solisten_proto_check() and solisten_proto() to check and set - * socket-layer listen state. Call backs are used so that the protocol can - * acquire both protocol and socket layer locks in whatever order is required - * by the protocol. - * - * Protocol implementors are advised to hold the socket lock across the - * socket-layer test and set to avoid races at the socket layer. + * state. */ int -solisten(struct socket *so, int backlog, struct thread *td) +solisten(struct socket *so, int backlog, struct thread *td, struct file *fp) { + struct solisten *sol; int error; CURVNET_SET(so->so_vnet); - error = (*so->so_proto->pr_usrreqs->pru_listen)(so, backlog, td); - CURVNET_RESTORE(); - return (error); -} -int -solisten_proto_check(struct socket *so) -{ + sol = malloc(sizeof(struct solisten), M_SOLISTEN, M_WAITOK | M_ZERO); - SOCK_LOCK_ASSERT(so); - + SOCK_LOCK(so); if (so->so_state & (SS_ISCONNECTED | SS_ISCONNECTING | - SS_ISDISCONNECTING)) + SS_ISDISCONNECTING)) { + SOCK_UNLOCK(so); + free(sol, M_SOLISTEN); return (EINVAL); + } + /* + * XXXGL: we are going to drop socket lock, to avoid LOR + * against protocol locks, thus to block any other syscalls + * on the socket we mark it SS_ISDISCONNECTING. + * If that doesn't work well, we would need a separate flag + * to mark the fact that socket is now under listen(2) + * transmutation. + */ + so->so_state |= SS_ISDISCONNECTING; + SOCK_UNLOCK(so); + + sol->sol_type = so->so_type; + sol->sol_options = so->so_options; + sol->sol_linger = so->so_linger; + sol->sol_state = so->so_state & ~SS_ISDISCONNECTING; + sol->sol_fibnum = so->so_fibnum; + sol->sol_sbrcv_lowat = so->so_rcv.sb_lowat; + sol->sol_sbsnd_lowat = so->so_snd.sb_lowat; + sol->sol_sbrcv_hiwat = so->so_rcv.sb_hiwat; + sol->sol_sbsnd_hiwat = so->so_snd.sb_hiwat; + sol->sol_sbrcv_flags = so->so_rcv.sb_flags; + sol->sol_sbsnd_flags = so->so_snd.sb_flags; + sol->sol_sbrcv_timeo = so->so_rcv.sb_timeo; + sol->sol_sbsnd_timeo = so->so_snd.sb_timeo; + sol->sol_proto = so->so_proto; + sol->sol_vnet = so->so_vnet; + sol->sol_cred = so->so_cred; + if (so->so_sigio != NULL) + fsetown(fgetown(&so->so_sigio), &sol->sol_sigio); + else + sol->sol_sigio = NULL; + sol->sol_pcb = so->so_pcb; + sol->sol_accept_filter = NULL; + sol->sol_accept_filter_arg = NULL; + sol->sol_accept_filter_str = NULL; + sol->sol_error = 0; + + mtx_init(&sol->sol_mutex, "solisten", NULL, MTX_DEF); + knlist_init_mtx(&sol->sol_selinfo.si_note, &sol->sol_mutex); + sol->sol_qlen = sol->sol_incqlen = 0; + if (backlog < 0 || backlog > somaxconn) + backlog = somaxconn; + sol->sol_qlimit = backlog; + TAILQ_INIT(&sol->sol_incomp); + TAILQ_INIT(&sol->sol_comp); + + error = (*so->so_proto->pr_usrreqs->pru_listen)(so, sol, backlog, td); + if (error) { + SOCK_LOCK(so); + so->so_state &= ~SS_ISDISCONNECTING; + SOCK_UNLOCK(so); + funsetown(&sol->sol_sigio); + knlist_destroy(&sol->sol_selinfo.si_note); + mtx_destroy(&sol->sol_mutex); + free(sol, M_SOLISTEN); + return (error); + } + + finit(fp, fp->f_flag, DTYPE_SOLISTEN, sol, &solistenops); + + SOCK_LOCK(so); + KASSERT((so->so_state & SS_NOFDREF) == 0, ("%s: NOFDREF", __func__)); + funsetown(&so->so_sigio); + so->so_state |= SS_NOFDREF; + so->so_pcb = NULL; + sorele(so); + + CURVNET_RESTORE(); + return (0); } -void -solisten_proto(struct socket *so, int backlog) +/* + * sollisten() implements listen(2) on already listening socket. For most + * protocols it just updates backlog length, but for SCTP it unlistens the + * socket. + */ +int +sollisten(struct solisten *sol, int backlog, struct thread *td, struct file *fp) { + int error; - SOCK_LOCK_ASSERT(so); + error = (*sol->sol_proto->pr_usrreqs->pru_listen)(NULL, + sol, backlog, td); + /* + * If the protocol decides to do something more complex than backlog + * update, it does all the work itself and returns ENOTSOCK. For now + * this is case only for SCTP. + */ + if (error == ENOTSOCK) + return (0); + + if (error) + return (error); + if (backlog < 0 || backlog > somaxconn) backlog = somaxconn; - so->so_qlimit = backlog; - so->so_options |= SO_ACCEPTCONN; + SOLISTEN_LOCK(sol); + sol->sol_qlimit = backlog; + SOLISTEN_UNLOCK(sol); + + return (0); } /* @@ -780,52 +907,54 @@ void sofree(struct socket *so) { struct protosw *pr = so->so_proto; - struct socket *head; + struct solisten *sol; - ACCEPT_LOCK_ASSERT(); SOCK_LOCK_ASSERT(so); if ((so->so_state & SS_NOFDREF) == 0 || so->so_count != 0 || (so->so_state & SS_PROTOREF) || (so->so_qstate & SQ_COMP)) { SOCK_UNLOCK(so); - ACCEPT_UNLOCK(); return; } - head = so->so_head; - if (head != NULL) { + sol = so->so_listen; + if (sol != NULL) { KASSERT((so->so_qstate & SQ_COMP) != 0 || (so->so_qstate & SQ_INCOMP) != 0, - ("sofree: so_head != NULL, but neither SQ_COMP nor " + ("sofree: so_listen != NULL, but neither SQ_COMP nor " "SQ_INCOMP")); KASSERT((so->so_qstate & SQ_COMP) == 0 || (so->so_qstate & SQ_INCOMP) == 0, ("sofree: so->so_qstate is SQ_COMP and also SQ_INCOMP")); - TAILQ_REMOVE(&head->so_incomp, so, so_list); - head->so_incqlen--; + SOLISTEN_LOCK(sol); + TAILQ_REMOVE(&sol->sol_incomp, so, so_list); + sol->sol_incqlen--; + SOLISTEN_UNLOCK(sol); so->so_qstate &= ~SQ_INCOMP; - so->so_head = NULL; + so->so_listen = NULL; } KASSERT((so->so_qstate & SQ_COMP) == 0 && (so->so_qstate & SQ_INCOMP) == 0, - ("sofree: so_head == NULL, but still SQ_COMP(%d) or SQ_INCOMP(%d)", - so->so_qstate & SQ_COMP, so->so_qstate & SQ_INCOMP)); - if (so->so_options & SO_ACCEPTCONN) { - KASSERT((TAILQ_EMPTY(&so->so_comp)), - ("sofree: so_comp populated")); - KASSERT((TAILQ_EMPTY(&so->so_incomp)), - ("sofree: so_incomp populated")); - } + ("%s: so_listen == NULL, but still SQ_COMP(%d) or SQ_INCOMP(%d)", + __func__, so->so_qstate & SQ_COMP, so->so_qstate & SQ_INCOMP)); SOCK_UNLOCK(so); - ACCEPT_UNLOCK(); VNET_SO_ASSERT(so); - if (pr->pr_flags & PR_RIGHTS && pr->pr_domain->dom_dispose != NULL) - (*pr->pr_domain->dom_dispose)(so); - if (pr->pr_usrreqs->pru_detach != NULL) - (*pr->pr_usrreqs->pru_detach)(so); /* + * If socket has pcb pointer cleared, this means we are + * called from solisten() and pcb shall not be disposed + * and detached. + */ + if (so->so_pcb != NULL) { + if (pr->pr_flags & PR_RIGHTS && + pr->pr_domain->dom_dispose != NULL) + (*pr->pr_domain->dom_dispose)(so); + if (pr->pr_usrreqs->pru_detach != NULL) + (*pr->pr_usrreqs->pru_detach)(so); + } + + /* * From this point on, we assume that no other references to this * socket exist anywhere else in the stack. Therefore, no locks need * to be acquired or held. @@ -891,45 +1020,60 @@ soclose(struct socket *so) drop: if (so->so_proto->pr_usrreqs->pru_close != NULL) (*so->so_proto->pr_usrreqs->pru_close)(so); - ACCEPT_LOCK(); - if (so->so_options & SO_ACCEPTCONN) { - struct socket *sp; - /* - * Prevent new additions to the accept queues due - * to ACCEPT_LOCK races while we are draining them. - */ - so->so_options &= ~SO_ACCEPTCONN; - while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL) { - TAILQ_REMOVE(&so->so_incomp, sp, so_list); - so->so_incqlen--; - sp->so_qstate &= ~SQ_INCOMP; - sp->so_head = NULL; - ACCEPT_UNLOCK(); - soabort(sp); - ACCEPT_LOCK(); - } - while ((sp = TAILQ_FIRST(&so->so_comp)) != NULL) { - TAILQ_REMOVE(&so->so_comp, sp, so_list); - so->so_qlen--; - sp->so_qstate &= ~SQ_COMP; - sp->so_head = NULL; - ACCEPT_UNLOCK(); - soabort(sp); - ACCEPT_LOCK(); - } - KASSERT((TAILQ_EMPTY(&so->so_comp)), - ("%s: so_comp populated", __func__)); - KASSERT((TAILQ_EMPTY(&so->so_incomp)), - ("%s: so_incomp populated", __func__)); - } SOCK_LOCK(so); KASSERT((so->so_state & SS_NOFDREF) == 0, ("soclose: NOFDREF")); so->so_state |= SS_NOFDREF; - sorele(so); /* NB: Returns with ACCEPT_UNLOCK(). */ + sorele(so); CURVNET_RESTORE(); return (error); } +int +solistenclose(struct solisten *sol) +{ + struct accept_queue comp, incomp; + struct socket *so; + + KASSERT((sol->sol_state & SS_NOFDREF) == 0, ("%s: NOFDREF", __func__)); + + CURVNET_SET(sol->sol_vnet); + funsetown(&sol->sol_sigio); + + if (sol->sol_accept_filter != NULL) + accept_filt_setopt(sol, NULL); + + (*sol->sol_proto->pr_usrreqs->pru_listenclose)(sol); + + TAILQ_INIT(&comp); + TAILQ_INIT(&incomp); + SOLISTEN_LOCK(sol); + TAILQ_SWAP(&comp, &sol->sol_comp, socket, so_list); + TAILQ_SWAP(&incomp, &sol->sol_incomp, socket, so_list); + sol->sol_incqlen = 0; + sol->sol_qlen = 0; + SOLISTEN_UNLOCK(sol); + while ((so = TAILQ_FIRST(&incomp)) != NULL) { + TAILQ_REMOVE(&incomp, so, so_list); + so->so_qstate &= ~SQ_INCOMP; + so->so_listen = NULL; + soabort(so); + } + while ((so = TAILQ_FIRST(&comp)) != NULL) { + TAILQ_REMOVE(&comp, so, so_list); + so->so_qstate &= ~SQ_COMP; + so->so_listen = NULL; + soabort(so); + } + seldrain(&sol->sol_selinfo); + knlist_destroy(&sol->sol_selinfo.si_note); + sol->sol_state |= SS_NOFDREF; + mtx_destroy(&sol->sol_mutex); + free(sol, M_SOLISTEN); + CURVNET_RESTORE(); + + return (0); +} + /* * soabort() is used to abruptly tear down a connection, such as when a * resource limit is reached (listen queue depth exceeded), or if a listen @@ -963,7 +1107,6 @@ soabort(struct socket *so) if (so->so_proto->pr_usrreqs->pru_abort != NULL) (*so->so_proto->pr_usrreqs->pru_abort)(so); - ACCEPT_LOCK(); SOCK_LOCK(so); sofree(so); } @@ -996,9 +1139,6 @@ soconnectat(int fd, struct socket *so, struct sock { int error; - if (so->so_options & SO_ACCEPTCONN) - return (EOPNOTSUPP); - CURVNET_SET(so->so_vnet); /* * If protocol is connection-based, can only connect once. @@ -2509,7 +2649,7 @@ sosetopt(struct socket *so, struct sockopt *sopt) error = 0; if (sopt->sopt_level != SOL_SOCKET) { if (so->so_proto->pr_ctloutput != NULL) { - error = (*so->so_proto->pr_ctloutput)(so, sopt); + error = (*so->so_proto->pr_ctloutput)(so->so_pcb, sopt); CURVNET_RESTORE(); return (error); } @@ -2516,12 +2656,6 @@ sosetopt(struct socket *so, struct sockopt *sopt) error = ENOPROTOOPT; } else { switch (sopt->sopt_name) { - case SO_ACCEPTFILTER: - error = do_setopt_accept_filter(so, sopt); - if (error) - goto bad; - break; - case SO_LINGER: error = sooptcopyin(sopt, &l, sizeof l, sizeof l); if (error) @@ -2716,7 +2850,7 @@ sosetopt(struct socket *so, struct sockopt *sopt) break; } if (error == 0 && so->so_proto->pr_ctloutput != NULL) - (void)(*so->so_proto->pr_ctloutput)(so, sopt); + (void)(*so->so_proto->pr_ctloutput)(so->so_pcb, sopt); } bad: CURVNET_RESTORE(); @@ -2767,7 +2901,7 @@ sogetopt(struct socket *so, struct sockopt *sopt) error = 0; if (sopt->sopt_level != SOL_SOCKET) { if (so->so_proto->pr_ctloutput != NULL) - error = (*so->so_proto->pr_ctloutput)(so, sopt); + error = (*so->so_proto->pr_ctloutput)(so->so_pcb, sopt); else error = ENOPROTOOPT; CURVNET_RESTORE(); @@ -2775,7 +2909,7 @@ sogetopt(struct socket *so, struct sockopt *sopt) } else { switch (sopt->sopt_name) { case SO_ACCEPTFILTER: - error = do_getopt_accept_filter(so, sopt); + error = EINVAL; break; case SO_LINGER: @@ -2794,7 +2928,6 @@ sogetopt(struct socket *so, struct sockopt *sopt) case SO_REUSEPORT: case SO_BROADCAST: case SO_OOBINLINE: - case SO_ACCEPTCONN: case SO_TIMESTAMP: case SO_BINTIME: case SO_NOSIGPIPE: @@ -2855,11 +2988,11 @@ integer: error = sooptcopyin(sopt, &extmac, sizeof(extmac), sizeof(extmac)); if (error) - goto bad; + break; error = mac_getsockopt_label(sopt->sopt_td->td_ucred, so, &extmac); if (error) - goto bad; + break; error = sooptcopyout(sopt, &extmac, sizeof extmac); #else error = EOPNOTSUPP; @@ -2875,7 +3008,7 @@ integer: error = mac_getsockopt_peerlabel( sopt->sopt_td->td_ucred, so, &extmac); if (error) - goto bad; + break; error = sooptcopyout(sopt, &extmac, sizeof extmac); #else error = EOPNOTSUPP; @@ -2882,16 +3015,13 @@ integer: #endif break; +#if 0 +QQQ case SO_ACCEPTCONN: +#endif case SO_LISTENQLIMIT: - optval = so->so_qlimit; - goto integer; - case SO_LISTENQLEN: - optval = so->so_qlen; - goto integer; - case SO_LISTENINCQLEN: - optval = so->so_incqlen; + optval = 0; goto integer; case SO_TS_CLOCK: @@ -2911,14 +3041,81 @@ integer: break; } } -#ifdef MAC -bad: -#endif CURVNET_RESTORE(); return (error); } int +solgetopt(struct solisten *sol, struct sockopt *sopt) +{ + int optval, error; + + CURVNET_SET(sol->sol_vnet); + if (sopt->sopt_level != SOL_SOCKET) { + if (sol->sol_proto->pr_ctloutput != NULL) + error = (*sol->sol_proto->pr_ctloutput)(sol->sol_pcb, + sopt); + else + error = ENOPROTOOPT; + CURVNET_RESTORE(); + return (error); + } + + switch (sopt->sopt_name) { + case SO_ACCEPTFILTER: + error = accept_filt_getopt(sol, sopt); + break; + + case SO_LISTENQLIMIT: + optval = sol->sol_qlimit; + goto integer; + + case SO_LISTENQLEN: + optval = sol->sol_qlen; + goto integer; + + case SO_LISTENINCQLEN: + optval = sol->sol_incqlen; +integer: + error = sooptcopyout(sopt, &optval, sizeof optval); + break; + + default: + error = ENOPROTOOPT; + } + CURVNET_RESTORE(); + return (error); +} + +int +solsetopt(struct solisten *sol, struct sockopt *sopt) +{ + int error; + + CURVNET_SET(sol->sol_vnet); + if (sopt->sopt_level != SOL_SOCKET) { + if (sol->sol_proto->pr_ctloutput != NULL) + error = (*sol->sol_proto->pr_ctloutput)(sol->sol_pcb, + sopt); + else + error = ENOPROTOOPT; + CURVNET_RESTORE(); + return (error); + } + + switch (sopt->sopt_name) { + case SO_ACCEPTFILTER: + error = accept_filt_setopt(sol, sopt); + break; + + default: + error = ENOPROTOOPT; + } + CURVNET_RESTORE(); + return (error); +} + +int soopt_getm(struct sockopt *sopt, struct mbuf **mp) { struct mbuf *m, *m_prev; @@ -3100,6 +3297,25 @@ sopoll_generic(struct socket *so, int events, stru } int +solistenpoll(struct solisten *sol, int events, struct ucred *active_cred, + struct thread *td) +{ + + if (!(events & (POLLIN | POLLRDNORM))) + return (0); + + SOLISTEN_LOCK(sol); + if (!TAILQ_EMPTY(&sol->sol_comp)) { + SOLISTEN_UNLOCK(sol); + return (events & (POLLIN | POLLRDNORM)); + } else { + selrecord(td, &sol->sol_selinfo); + SOLISTEN_UNLOCK(sol); + return (0); + } +} + +int soo_kqfilter(struct file *fp, struct knote *kn) { struct socket *so = kn->kn_fp->f_data; @@ -3107,10 +3323,7 @@ soo_kqfilter(struct file *fp, struct knote *kn) switch (kn->kn_filter) { case EVFILT_READ: - if (so->so_options & SO_ACCEPTCONN) - kn->kn_fop = &solisten_filtops; - else - kn->kn_fop = &soread_filtops; + kn->kn_fop = &soread_filtops; sb = &so->so_rcv; break; case EVFILT_WRITE: @@ -3132,6 +3345,22 @@ soo_kqfilter(struct file *fp, struct knote *kn) return (0); } +int +sol_kqfilter(struct file *fp, struct knote *kn) +{ + struct solisten *sol = kn->kn_fp->f_data; + + if (kn->kn_filter != EVFILT_READ) + return (EINVAL); + + kn->kn_fop = &solisten_filtops; + SOLISTEN_LOCK(sol); + knlist_add(&sol->sol_selinfo.si_note, kn, 1); + SOLISTEN_UNLOCK(sol); + + return (0); +} + /* * Some routines that return EOPNOTSUPP for entry points that are not * supported by a protocol. Fill in as needed. @@ -3210,7 +3439,8 @@ pru_disconnect_notsupp(struct socket *so) } int -pru_listen_notsupp(struct socket *so, int backlog, struct thread *td) +pru_listen_notsupp(struct socket *so, struct solisten *sol, int backlog, + struct thread *td) { return EOPNOTSUPP; @@ -3314,6 +3544,16 @@ filt_sordetach(struct knote *kn) SOCKBUF_UNLOCK(&so->so_rcv); } +static void +filt_soldetach(struct knote *kn) +{ + struct solisten *sol = kn->kn_fp->f_data; + + SOLISTEN_LOCK(sol); + knlist_remove(&sol->sol_selinfo.si_note, kn, 1); + SOLISTEN_UNLOCK(sol); +} + /*ARGSUSED*/ static int filt_soread(struct knote *kn, long hint) @@ -3401,10 +3641,10 @@ filt_soempty(struct knote *kn, long hint) static int filt_solisten(struct knote *kn, long hint) { - struct socket *so = kn->kn_fp->f_data; + struct solisten *sol = kn->kn_fp->f_data; - kn->kn_data = so->so_qlen; - return (!TAILQ_EMPTY(&so->so_comp)); + kn->kn_data = sol->sol_qlen; + return (!TAILQ_EMPTY(&sol->sol_comp)); } int @@ -3463,35 +3703,37 @@ soisconnecting(struct socket *so) void soisconnected(struct socket *so) { - struct socket *head; + struct solisten *sol; int ret; restart: - ACCEPT_LOCK(); + if ((sol = so->so_listen) != NULL) + SOLISTEN_LOCK(sol); SOCK_LOCK(so); so->so_state &= ~(SS_ISCONNECTING|SS_ISDISCONNECTING|SS_ISCONFIRMING); so->so_state |= SS_ISCONNECTED; - head = so->so_head; - if (head != NULL && (so->so_qstate & SQ_INCOMP)) { + if (sol != NULL && (so->so_qstate & SQ_INCOMP)) { if ((so->so_options & SO_ACCEPTFILTER) == 0) { SOCK_UNLOCK(so); - TAILQ_REMOVE(&head->so_incomp, so, so_list); - head->so_incqlen--; + TAILQ_REMOVE(&sol->sol_incomp, so, so_list); + sol->sol_incqlen--; so->so_qstate &= ~SQ_INCOMP; - TAILQ_INSERT_TAIL(&head->so_comp, so, so_list); - head->so_qlen++; + TAILQ_INSERT_TAIL(&sol->sol_comp, so, so_list); + sol->sol_qlen++; so->so_qstate |= SQ_COMP; - ACCEPT_UNLOCK(); - sorwakeup(head); - wakeup_one(&head->so_timeo); + /* QQQ sorwakeup(sol); */ + selwakeuppri(&sol->sol_selinfo, PSOCK); + KNOTE_LOCKED(&sol->sol_selinfo.si_note, 0); + SOLISTEN_UNLOCK(sol); + wakeup_one(&sol->sol_comp); } else { - ACCEPT_UNLOCK(); + SOLISTEN_UNLOCK(sol); soupcall_set(so, SO_RCV, - head->so_accf->so_accept_filter->accf_callback, - head->so_accf->so_accept_filter_arg); + sol->sol_accept_filter->accf_callback, + sol->sol_accept_filter_arg); so->so_options &= ~SO_ACCEPTFILTER; - ret = head->so_accf->so_accept_filter->accf_callback(so, - head->so_accf->so_accept_filter_arg, M_NOWAIT); + ret = sol->sol_accept_filter->accf_callback(so, + sol->sol_accept_filter_arg, M_NOWAIT); if (ret == SU_ISCONNECTED) soupcall_clear(so, SO_RCV); SOCK_UNLOCK(so); @@ -3500,8 +3742,9 @@ restart: } return; } + if (sol != NULL) + SOLISTEN_UNLOCK(sol); SOCK_UNLOCK(so); - ACCEPT_UNLOCK(); wakeup(&so->so_timeo); sorwakeup(so); sowwakeup(so); @@ -3628,9 +3871,7 @@ sotoxsocket(struct socket *so, struct xsocket *xso xso->so_pcb = so->so_pcb; xso->xso_protocol = so->so_proto->pr_protocol; xso->xso_family = so->so_proto->pr_domain->dom_family; - xso->so_qlen = so->so_qlen; - xso->so_incqlen = so->so_incqlen; - xso->so_qlimit = so->so_qlimit; + xso->so_qlen = xso->so_incqlen = xso->so_qlimit = 0; xso->so_timeo = so->so_timeo; xso->so_error = so->so_error; xso->so_pgid = so->so_sigio ? so->so_sigio->sio_pgid : 0; @@ -3640,20 +3881,33 @@ sotoxsocket(struct socket *so, struct xsocket *xso xso->so_uid = so->so_cred->cr_uid; } - /* - * Socket accessor functions to provide external consumers with - * a safe interface to socket state - * + * Create an external-format (``xsocket'') structure using the information in + * the listening socket structure pointed to by sol. */ - void -so_listeners_apply_all(struct socket *so, void (*func)(struct socket *, void *), - void *arg) +soltoxsocket(struct solisten *sol, struct xsocket *xso) { - TAILQ_FOREACH(so, &so->so_comp, so_list) - func(so, arg); + xso->xso_len = sizeof *xso; + xso->xso_so = (struct socket *)sol; + xso->so_type = sol->sol_type; + xso->so_options = sol->sol_options /* QQQ | SO_ACCEPTCON */ ; + xso->so_linger = sol->sol_linger; + xso->so_state = sol->sol_state; + xso->so_pcb = sol->sol_pcb; + xso->xso_protocol = sol->sol_proto->pr_protocol; + xso->xso_family = sol->sol_proto->pr_domain->dom_family; + xso->so_qlen = sol->sol_qlen; + xso->so_incqlen = sol->sol_incqlen; + xso->so_qlimit = sol->sol_qlimit; + xso->so_timeo = 0; + xso->so_error = sol->sol_error; + xso->so_pgid = sol->sol_sigio ? sol->sol_sigio->sio_pgid : 0; + xso->so_oobmark = 0; + bzero(&xso->so_snd, sizeof(xso->so_snd)); + bzero(&xso->so_rcv, sizeof(xso->so_rcv)); + xso->so_uid = sol->sol_cred->cr_uid; } struct sockbuf * Index: sys/kern/uipc_syscalls.c =================================================================== --- sys/kern/uipc_syscalls.c (revision 312784) +++ sys/kern/uipc_syscalls.c (working copy) @@ -94,7 +94,7 @@ static int sockargs(struct mbuf **, char *, sockle */ int getsock_cap(struct thread *td, int fd, cap_rights_t *rightsp, - struct file **fpp, u_int *fflagp, struct filecaps *havecapsp) + struct file **fpp, u_int *fflagp, struct filecaps *havecapsp, short type) { struct file *fp; int error; @@ -102,7 +102,7 @@ getsock_cap(struct thread *td, int fd, cap_rights_ error = fget_cap(td, fd, rightsp, &fp, havecapsp); if (error != 0) return (error); - if (fp->f_type != DTYPE_SOCKET) { + if (fp->f_type != type && type != 0) { fdrop(fp, td); if (havecapsp != NULL) filecaps_free(havecapsp); @@ -191,7 +191,7 @@ kern_bindat(struct thread *td, int dirfd, int fd, AUDIT_ARG_FD(fd); AUDIT_ARG_SOCKADDR(td, dirfd, sa); error = getsock_cap(td, fd, cap_rights_init(&rights, CAP_BIND), - &fp, NULL, NULL); + &fp, NULL, NULL, DTYPE_SOCKET); if (error != 0) return (error); so = fp->f_data; @@ -232,6 +232,7 @@ int sys_listen(struct thread *td, struct listen_args *uap) { struct socket *so; + struct solisten *sol; struct file *fp; cap_rights_t rights; int error; @@ -238,17 +239,33 @@ sys_listen(struct thread *td, struct listen_args * AUDIT_ARG_FD(uap->s); error = getsock_cap(td, uap->s, cap_rights_init(&rights, CAP_LISTEN), - &fp, NULL, NULL); - if (error == 0) { + &fp, NULL, NULL, 0); + if (error) + return (error); + + switch (fp->f_type) { + case DTYPE_SOCKET: so = fp->f_data; #ifdef MAC error = mac_socket_check_listen(td->td_ucred, so); if (error == 0) #endif - error = solisten(so, uap->backlog, td); - fdrop(fp, td); + error = solisten(so, uap->backlog, td, fp); + break; + case DTYPE_SOLISTEN: + sol = fp->f_data; +#ifdef MAC + QQQ + if (error == 0) +#endif + error = sollisten(sol, uap->backlog, td, fp); + break; + default: + error = ENOTSOCK; } - return(error); + fdrop(fp, td); + + return (error); } /* @@ -308,9 +325,10 @@ int kern_accept4(struct thread *td, int s, struct sockaddr **name, socklen_t *namelen, int flags, struct file **fp) { - struct file *headfp, *nfp = NULL; + struct file *solfp, *nfp = NULL; struct sockaddr *sa = NULL; - struct socket *head, *so; + struct solisten *sol; + struct socket *so; struct filecaps fcaps; cap_rights_t rights; u_int fflag; @@ -322,16 +340,17 @@ kern_accept4(struct thread *td, int s, struct sock AUDIT_ARG_FD(s); error = getsock_cap(td, s, cap_rights_init(&rights, CAP_ACCEPT), - &headfp, &fflag, &fcaps); + &solfp, &fflag, &fcaps, 0); if (error != 0) return (error); - head = headfp->f_data; - if ((head->so_options & SO_ACCEPTCONN) == 0) { - error = EINVAL; + if (solfp->f_type != DTYPE_SOLISTEN) { + error = solfp->f_type == DTYPE_SOCKET ? EINVAL : ENOTSOCK; goto done; } + sol = solfp->f_data; #ifdef MAC - error = mac_socket_check_accept(td->td_ucred, head); + QQQ + error = mac_socket_check_accept(td->td_ucred, sol); if (error != 0) goto done; #endif @@ -339,31 +358,27 @@ kern_accept4(struct thread *td, int s, struct sock (flags & SOCK_CLOEXEC) ? O_CLOEXEC : 0, &fcaps); if (error != 0) goto done; - ACCEPT_LOCK(); - if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) { - ACCEPT_UNLOCK(); + SOLISTEN_LOCK(sol); + if ((sol->sol_state & SS_NBIO) && TAILQ_EMPTY(&sol->sol_comp)) { + SOLISTEN_UNLOCK(sol); error = EWOULDBLOCK; goto noconnection; } - while (TAILQ_EMPTY(&head->so_comp) && head->so_error == 0) { - if (head->so_rcv.sb_state & SBS_CANTRCVMORE) { - head->so_error = ECONNABORTED; - break; - } - error = msleep(&head->so_timeo, &accept_mtx, PSOCK | PCATCH, + while (TAILQ_EMPTY(&sol->sol_comp) && sol->sol_error == 0) { + error = msleep(&sol->sol_comp, &sol->sol_mutex, PSOCK | PCATCH, "accept", 0); if (error != 0) { - ACCEPT_UNLOCK(); + SOLISTEN_UNLOCK(sol); goto noconnection; } } - if (head->so_error) { - error = head->so_error; - head->so_error = 0; - ACCEPT_UNLOCK(); + if (sol->sol_error) { + error = sol->sol_error; + sol->sol_error = 0; + SOLISTEN_UNLOCK(sol); goto noconnection; } - so = TAILQ_FIRST(&head->so_comp); + so = TAILQ_FIRST(&sol->sol_comp); KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP")); KASSERT(so->so_qstate & SQ_COMP, ("accept1: so not SQ_COMP")); @@ -375,26 +390,26 @@ kern_accept4(struct thread *td, int s, struct sock SOCK_LOCK(so); /* soref() and so_state update */ soref(so); /* file descriptor reference */ - TAILQ_REMOVE(&head->so_comp, so, so_list); - head->so_qlen--; + TAILQ_REMOVE(&sol->sol_comp, so, so_list); + sol->sol_qlen--; if (flags & ACCEPT4_INHERIT) - so->so_state |= (head->so_state & SS_NBIO); + so->so_state |= (sol->sol_state & SS_NBIO); else so->so_state |= (flags & SOCK_NONBLOCK) ? SS_NBIO : 0; so->so_qstate &= ~SQ_COMP; - so->so_head = NULL; + so->so_listen = NULL; SOCK_UNLOCK(so); - ACCEPT_UNLOCK(); + SOLISTEN_UNLOCK(sol); /* An extra reference on `nfp' has been held for us by falloc(). */ td->td_retval[0] = fd; - /* connection has been removed from the listen queue */ - KNOTE_UNLOCKED(&head->so_rcv.sb_sel.si_note, 0); + /* Connection has been removed from the listen queue. */ + KNOTE_UNLOCKED(&sol->sol_selinfo.si_note, 0); if (flags & ACCEPT4_INHERIT) { - pgid = fgetown(&head->so_sigio); + pgid = fgetown(&sol->sol_sigio); if (pgid != 0) fsetown(pgid, &so->so_sigio); } else { @@ -456,7 +471,7 @@ done: } if (nfp != NULL) fdrop(nfp, td); - fdrop(headfp, td); + fdrop(solfp, td); return (error); } @@ -518,7 +533,7 @@ kern_connectat(struct thread *td, int dirfd, int f AUDIT_ARG_FD(fd); AUDIT_ARG_SOCKADDR(td, dirfd, sa); error = getsock_cap(td, fd, cap_rights_init(&rights, CAP_CONNECT), - &fp, NULL, NULL); + &fp, NULL, NULL, DTYPE_SOCKET); if (error != 0) return (error); so = fp->f_data; @@ -761,7 +776,7 @@ kern_sendit(struct thread *td, int s, struct msghd AUDIT_ARG_SOCKADDR(td, AT_FDCWD, mp->msg_name); cap_rights_set(&rights, CAP_CONNECT); } - error = getsock_cap(td, s, &rights, &fp, NULL, NULL); + error = getsock_cap(td, s, &rights, &fp, NULL, NULL, DTYPE_SOCKET); if (error != 0) { m_freem(control); return (error); @@ -937,7 +952,7 @@ kern_recvit(struct thread *td, int s, struct msghd AUDIT_ARG_FD(s); error = getsock_cap(td, s, cap_rights_init(&rights, CAP_RECV), - &fp, NULL, NULL); + &fp, NULL, NULL, DTYPE_SOCKET); if (error != 0) return (error); so = fp->f_data; @@ -1205,7 +1220,6 @@ sys_recvmsg(struct thread *td, struct recvmsg_args int sys_shutdown(struct thread *td, struct shutdown_args *uap) { - struct socket *so; struct file *fp; cap_rights_t rights; int error; @@ -1212,21 +1226,27 @@ sys_shutdown(struct thread *td, struct shutdown_ar AUDIT_ARG_FD(uap->s); error = getsock_cap(td, uap->s, cap_rights_init(&rights, CAP_SHUTDOWN), - &fp, NULL, NULL); - if (error == 0) { - so = fp->f_data; - error = soshutdown(so, uap->how); - /* - * Previous versions did not return ENOTCONN, but 0 in - * case the socket was not connected. Some important - * programs like syslogd up to r279016, 2015-02-19, - * still depend on this behavior. - */ - if (error == ENOTCONN && - td->td_proc->p_osrel < P_OSREL_SHUTDOWN_ENOTCONN) - error = 0; - fdrop(fp, td); + &fp, NULL, NULL, 0); + if (error) + return (error); + switch (fp->f_type) { + case DTYPE_SOCKET: + error = soshutdown((struct socket *)fp->f_data, uap->how); + break; + case DTYPE_SOLISTEN: + error = ENOTCONN; + break; } + /* + * Previous versions did not return ENOTCONN, but 0 in + * case the socket was not connected. Some important + * programs like syslogd up to r279016, 2015-02-19, + * still depend on this behavior. + */ + if (error == ENOTCONN && + td->td_proc->p_osrel < P_OSREL_SHUTDOWN_ENOTCONN) + error = 0; + fdrop(fp, td); return (error); } @@ -1242,7 +1262,6 @@ int kern_setsockopt(struct thread *td, int s, int level, int name, void *val, enum uio_seg valseg, socklen_t valsize) { - struct socket *so; struct file *fp; struct sockopt sopt; cap_rights_t rights; @@ -1271,13 +1290,21 @@ kern_setsockopt(struct thread *td, int s, int leve AUDIT_ARG_FD(s); error = getsock_cap(td, s, cap_rights_init(&rights, CAP_SETSOCKOPT), - &fp, NULL, NULL); - if (error == 0) { - so = fp->f_data; - error = sosetopt(so, &sopt); - fdrop(fp, td); + &fp, NULL, NULL, 0); + if (error) + return (error); + switch (fp->f_type) { + case DTYPE_SOCKET: + error = sosetopt((struct socket *)fp->f_data, &sopt); + break; + case DTYPE_SOLISTEN: + error = solsetopt((struct solisten *)fp->f_data, &sopt); + break; + default: + error = ENOTSOCK; } - return(error); + fdrop(fp, td); + return (error); } int @@ -1308,7 +1335,6 @@ int kern_getsockopt(struct thread *td, int s, int level, int name, void *val, enum uio_seg valseg, socklen_t *valsize) { - struct socket *so; struct file *fp; struct sockopt sopt; cap_rights_t rights; @@ -1337,13 +1363,23 @@ kern_getsockopt(struct thread *td, int s, int leve AUDIT_ARG_FD(s); error = getsock_cap(td, s, cap_rights_init(&rights, CAP_GETSOCKOPT), - &fp, NULL, NULL); - if (error == 0) { - so = fp->f_data; - error = sogetopt(so, &sopt); + &fp, NULL, NULL, 0); + if (error) + return (error); + switch (fp->f_type) { + case DTYPE_SOCKET: + error = sogetopt((struct socket *)fp->f_data, &sopt); *valsize = sopt.sopt_valsize; - fdrop(fp, td); + break; + case DTYPE_SOLISTEN: + error = solgetopt((struct solisten *)fp->f_data, &sopt); + *valsize = sopt.sopt_valsize; + break; + break; + default: + error = ENOTSOCK; } + fdrop(fp, td); return (error); } @@ -1390,7 +1426,7 @@ kern_getsockname(struct thread *td, int fd, struct AUDIT_ARG_FD(fd); error = getsock_cap(td, fd, cap_rights_init(&rights, CAP_GETSOCKNAME), - &fp, NULL, NULL); + &fp, NULL, NULL, DTYPE_SOCKET); if (error != 0) return (error); so = fp->f_data; @@ -1477,7 +1513,7 @@ kern_getpeername(struct thread *td, int fd, struct AUDIT_ARG_FD(fd); error = getsock_cap(td, fd, cap_rights_init(&rights, CAP_GETPEERNAME), - &fp, NULL, NULL); + &fp, NULL, NULL, DTYPE_SOCKET); if (error != 0) return (error); so = fp->f_data; Index: sys/kern/uipc_usrreq.c =================================================================== --- sys/kern/uipc_usrreq.c (revision 312784) +++ sys/kern/uipc_usrreq.c (working copy) @@ -270,7 +270,7 @@ static struct mtx unp_defers_lock; #define UNP_PCB_LOCK_ASSERT(unp) mtx_assert(&(unp)->unp_mtx, MA_OWNED) static int uipc_connect2(struct socket *, struct socket *); -static int uipc_ctloutput(struct socket *, struct sockopt *); +static int uipc_ctloutput(void *, struct sockopt *); static int unp_connect(struct socket *, struct sockaddr *, struct thread *); static int unp_connectat(int, struct socket *, struct sockaddr *, @@ -284,6 +284,7 @@ static void unp_drop(struct unpcb *); static void unp_gc(__unused void *, int); static void unp_scan(struct mbuf *, void (*)(struct filedescent **, int)); static void unp_discard(struct file *); +static void unp_free(struct unpcb *); static void unp_freerights(struct filedescent **, int); static void unp_init(void); static int unp_internalize(struct mbuf **, struct thread *); @@ -430,7 +431,7 @@ uipc_attach(struct socket *so, int proto, struct t unp->unp_socket = so; so->so_pcb = unp; unp->unp_refcount = 1; - if (so->so_head != NULL) + if (so->so_listen != NULL) unp->unp_flags |= UNP_NASCENT; UNP_LIST_LOCK(); @@ -552,7 +553,7 @@ restart: UNP_LINK_WLOCK(); UNP_PCB_LOCK(unp); - VOP_UNP_BIND(vp, unp->unp_socket); + VOP_UNP_BIND(vp, unp); unp->unp_vnode = vp; unp->unp_addr = soun; unp->unp_flags &= ~UNP_BINDING; @@ -646,14 +647,35 @@ uipc_connect2(struct socket *so1, struct socket *s static void uipc_detach(struct socket *so) { - struct unpcb *unp, *unp2; + struct unpcb *unp; + + unp = sotounpcb(so); + KASSERT(unp != NULL, ("%s: unp == NULL", __func__)); + + unp_free(unp); +} + +static void +uipc_listenclose(struct solisten *sol) +{ + struct unpcb *unp; + + unp = soltounpcb(sol); + KASSERT(unp != NULL, ("%s: unp == NULL", __func__)); + KASSERT(unp->unp_conn == NULL && unp->unp_flags & UNP_LISTENING, + ("%s: bad unp %p", __func__, unp)); + + unp_free(unp); +} + +static void +unp_free(struct unpcb *unp) +{ + struct unpcb *unp2; struct sockaddr_un *saved_unp_addr; struct vnode *vp; int freeunp, local_unp_rights; - unp = sotounpcb(so); - KASSERT(unp != NULL, ("uipc_detach: unp == NULL")); - vp = NULL; local_unp_rights = 0; @@ -698,7 +720,10 @@ uipc_detach(struct socket *so) local_unp_rights = unp_rights; UNP_LINK_WUNLOCK(); teardown: - unp->unp_socket->so_pcb = NULL; + if (unp->unp_flags & UNP_LISTENING) + unp->unp_listen->sol_pcb = NULL; + else + unp->unp_socket->so_pcb = NULL; saved_unp_addr = unp->unp_addr; unp->unp_addr = NULL; unp->unp_refcount--; @@ -738,11 +763,15 @@ uipc_disconnect(struct socket *so) } static int -uipc_listen(struct socket *so, int backlog, struct thread *td) +uipc_listen(struct socket *so, struct solisten *sol, int backlog, + struct thread *td) { struct unpcb *unp; int error; + if (so == NULL) + return (0); + if (so->so_type != SOCK_STREAM && so->so_type != SOCK_SEQPACKET) return (EOPNOTSUPP); @@ -757,16 +786,12 @@ static int return (error); } - SOCK_LOCK(so); - error = solisten_proto_check(so); - if (error == 0) { - cru2x(td->td_ucred, &unp->unp_peercred); - unp->unp_flags |= UNP_HAVEPCCACHED; - solisten_proto(so, backlog); - } - SOCK_UNLOCK(so); + cru2x(td->td_ucred, &unp->unp_peercred); + unp->unp_flags |= UNP_LISTENING; + unp->unp_listen = sol; + VOP_UNP_BIND(unp->unp_vnode, unp); UNP_PCB_UNLOCK(unp); - return (error); + return (0); } static int @@ -1157,6 +1182,7 @@ static struct pr_usrreqs uipc_usrreqs_dgram = { .pru_detach = uipc_detach, .pru_disconnect = uipc_disconnect, .pru_listen = uipc_listen, + .pru_listenclose = uipc_listenclose, .pru_peeraddr = uipc_peeraddr, .pru_rcvd = uipc_rcvd, .pru_send = uipc_send, @@ -1179,6 +1205,7 @@ static struct pr_usrreqs uipc_usrreqs_seqpacket = .pru_detach = uipc_detach, .pru_disconnect = uipc_disconnect, .pru_listen = uipc_listen, + .pru_listenclose = uipc_listenclose, .pru_peeraddr = uipc_peeraddr, .pru_rcvd = uipc_rcvd, .pru_send = uipc_send, @@ -1201,6 +1228,7 @@ static struct pr_usrreqs uipc_usrreqs_stream = { .pru_detach = uipc_detach, .pru_disconnect = uipc_disconnect, .pru_listen = uipc_listen, + .pru_listenclose = uipc_listenclose, .pru_peeraddr = uipc_peeraddr, .pru_rcvd = uipc_rcvd, .pru_send = uipc_send, @@ -1213,17 +1241,20 @@ static struct pr_usrreqs uipc_usrreqs_stream = { }; static int -uipc_ctloutput(struct socket *so, struct sockopt *sopt) +uipc_ctloutput(void *xpcb, struct sockopt *sopt) { - struct unpcb *unp; + struct unpcb *unp = (struct unpcb *)xpcb; struct xucred xu; int error, optval; + short type; if (sopt->sopt_level != 0) return (EINVAL); - unp = sotounpcb(so); - KASSERT(unp != NULL, ("uipc_ctloutput: unp == NULL")); + if (unp->unp_flags & UNP_LISTENING) + type = unp->unp_listen->sol_type; + else + type = unp->unp_socket->so_type; error = 0; switch (sopt->sopt_dir) { case SOPT_GET: @@ -1233,7 +1264,7 @@ static int if (unp->unp_flags & UNP_HAVEPC) xu = unp->unp_peercred; else { - if (so->so_type == SOCK_STREAM) + if (type == SOCK_STREAM) error = ENOTCONN; else error = EINVAL; @@ -1319,7 +1350,7 @@ unp_connectat(int fd, struct socket *so, struct so { struct sockaddr_un *soun = (struct sockaddr_un *)nam; struct vnode *vp; - struct socket *so2, *so3; + struct socket *so2; struct unpcb *unp, *unp2, *unp3; struct nameidata nd; char buf[SOCK_MAXADDRLEN]; @@ -1386,31 +1417,32 @@ unp_connectat(int fd, struct socket *so, struct so * and to protect simultaneous locking of multiple pcbs. */ UNP_LINK_WLOCK(); - VOP_UNP_CONNECT(vp, &so2); - if (so2 == NULL) { + VOP_UNP_CONNECT(vp, &unp2); + if (unp2 == NULL) { error = ECONNREFUSED; goto bad2; } - if (so->so_type != so2->so_type) { - error = EPROTOTYPE; - goto bad2; - } + UNP_PCB_LOCK(unp); + UNP_PCB_LOCK(unp2); if (so->so_proto->pr_flags & PR_CONNREQUIRED) { - if (so2->so_options & SO_ACCEPTCONN) { - CURVNET_SET(so2->so_vnet); - so3 = sonewconn(so2, 0); + if (unp2->unp_flags & UNP_LISTENING) { + struct solisten *sol; + + sol = unp2->unp_listen; + if (so->so_type != sol->sol_type) { + error = EPROTOTYPE; + goto bad3; + } + CURVNET_SET(sol->sol_vnet); + so2 = sonewconn(sol, 0); CURVNET_RESTORE(); } else - so3 = NULL; - if (so3 == NULL) { + so2 = NULL; + if (so2 == NULL) { error = ECONNREFUSED; - goto bad2; + goto bad3; } - unp = sotounpcb(so); - unp2 = sotounpcb(so2); - unp3 = sotounpcb(so3); - UNP_PCB_LOCK(unp); - UNP_PCB_LOCK(unp2); + unp3 = sotounpcb(so2); UNP_PCB_LOCK(unp3); if (unp2->unp_addr != NULL) { bcopy(unp2->unp_addr, sa, unp2->unp_addr->sun_len); @@ -1431,30 +1463,34 @@ unp_connectat(int fd, struct socket *so, struct so * listen(); uipc_listen() cached that process's credentials * at that time so we can use them now. */ - KASSERT(unp2->unp_flags & UNP_HAVEPCCACHED, - ("unp_connect: listener without cached peercred")); memcpy(&unp->unp_peercred, &unp2->unp_peercred, sizeof(unp->unp_peercred)); unp->unp_flags |= UNP_HAVEPC; if (unp2->unp_flags & UNP_WANTCRED) unp3->unp_flags |= UNP_WANTCRED; - UNP_PCB_UNLOCK(unp3); UNP_PCB_UNLOCK(unp2); - UNP_PCB_UNLOCK(unp); + unp2 = unp3; #ifdef MAC - mac_socketpeer_set_from_socket(so, so3); - mac_socketpeer_set_from_socket(so3, so); + mac_socketpeer_set_from_socket(so, so2); + mac_socketpeer_set_from_socket(so2, so); #endif + } else { /* !UNP_LISTENING */ + so2 = unp2->unp_socket; + if (so2->so_type != so->so_type) { + error = EPROTOTYPE; + goto bad3; + } + if (so2->so_proto->pr_flags & PR_CONNREQUIRED) { + error = ECONNREFUSED; + goto bad3; + } + } - so2 = so3; - } - unp = sotounpcb(so); - KASSERT(unp != NULL, ("unp_connect: unp == NULL")); - unp2 = sotounpcb(so2); - KASSERT(unp2 != NULL, ("unp_connect: unp2 == NULL")); - UNP_PCB_LOCK(unp); - UNP_PCB_LOCK(unp2); + KASSERT(unp2 != NULL && so2 != NULL && unp2->unp_socket == so2 && + sotounpcb(so2) == unp2, + ("%s: unp2 %p so2 %p", __func__, unp2, so2)); error = unp_connect2(so, so2, PRU_CONNECT); +bad3: UNP_PCB_UNLOCK(unp2); UNP_PCB_UNLOCK(unp); bad2: @@ -1618,8 +1654,13 @@ unp_pcblist(SYSCTL_HANDLER_ARGS) unp = LIST_NEXT(unp, unp_link)) { UNP_PCB_LOCK(unp); if (unp->unp_gencnt <= gencnt) { - if (cr_cansee(req->td->td_ucred, - unp->unp_socket->so_cred)) { + struct ucred *cr; + + if (unp->unp_flags & UNP_LISTENING) + cr = unp->unp_listen->sol_cred; + else + cr = unp->unp_socket->so_cred; + if (cr_cansee(req->td->td_ucred, cr)) { UNP_PCB_UNLOCK(unp); continue; } @@ -1653,7 +1694,10 @@ unp_pcblist(SYSCTL_HANDLER_ARGS) &xu->xu_caddr, unp->unp_conn->unp_addr->sun_len); bcopy(unp, &xu->xu_unp, sizeof *unp); - sotoxsocket(unp->unp_socket, &xu->xu_socket); + if (unp->unp_flags & UNP_LISTENING) + soltoxsocket(unp->unp_listen, &xu->xu_socket); + else + sotoxsocket(unp->unp_socket, &xu->xu_socket); UNP_PCB_UNLOCK(unp); error = SYSCTL_OUT(req, xu, sizeof *xu); } else { @@ -2237,8 +2281,8 @@ unp_accessable(struct filedescent **fdep, int fdco static void unp_gc_process(struct unpcb *unp) { - struct socket *soa; struct socket *so; + struct solisten *sol; struct file *fp; /* Already processed. */ @@ -2258,28 +2302,31 @@ unp_gc_process(struct unpcb *unp) return; } - /* - * Mark all sockets we reference with RIGHTS. - */ - so = unp->unp_socket; - if ((unp->unp_gcflag & UNPGC_IGNORE_RIGHTS) == 0) { - SOCKBUF_LOCK(&so->so_rcv); - unp_scan(so->so_rcv.sb_mb, unp_accessable); - SOCKBUF_UNLOCK(&so->so_rcv); + if ((unp->unp_flags & UNP_LISTENING) == 0) { + /* + * Mark all sockets we reference with RIGHTS. + */ + so = unp->unp_socket; + if ((unp->unp_gcflag & UNPGC_IGNORE_RIGHTS) == 0) { + SOCKBUF_LOCK(&so->so_rcv); + unp_scan(so->so_rcv.sb_mb, unp_accessable); + SOCKBUF_UNLOCK(&so->so_rcv); + } + } else { + /* + * Mark all sockets in our accept queue. + */ + sol = unp->unp_listen; + SOLISTEN_LOCK(sol); + TAILQ_FOREACH(so, &sol->sol_comp, so_list) { + if (sotounpcb(so)->unp_gcflag & UNPGC_IGNORE_RIGHTS) + continue; + SOCKBUF_LOCK(&so->so_rcv); + unp_scan(so->so_rcv.sb_mb, unp_accessable); + SOCKBUF_UNLOCK(&so->so_rcv); + } + SOLISTEN_UNLOCK(sol); } - - /* - * Mark all sockets in our accept queue. - */ - ACCEPT_LOCK(); - TAILQ_FOREACH(soa, &so->so_comp, so_list) { - if ((sotounpcb(soa)->unp_gcflag & UNPGC_IGNORE_RIGHTS) != 0) - continue; - SOCKBUF_LOCK(&soa->so_rcv); - unp_scan(soa->so_rcv.sb_mb, unp_accessable); - SOCKBUF_UNLOCK(&soa->so_rcv); - } - ACCEPT_UNLOCK(); unp->unp_gcflag |= UNPGC_SCANNED; } @@ -2454,7 +2501,6 @@ unp_scan(struct mbuf *m0, void (*op)(struct filede void vfs_unp_reclaim(struct vnode *vp) { - struct socket *so; struct unpcb *unp; int active; @@ -2464,10 +2510,7 @@ vfs_unp_reclaim(struct vnode *vp) active = 0; UNP_LINK_WLOCK(); - VOP_UNP_CONNECT(vp, &so); - if (so == NULL) - goto done; - unp = sotounpcb(so); + VOP_UNP_CONNECT(vp, &unp); if (unp == NULL) goto done; UNP_PCB_LOCK(unp); @@ -2503,8 +2546,8 @@ db_print_unpflags(int unp_flags) db_printf("%sUNP_HAVEPC", comma ? ", " : ""); comma = 1; } - if (unp_flags & UNP_HAVEPCCACHED) { - db_printf("%sUNP_HAVEPCCACHED", comma ? ", " : ""); + if (unp_flags & UNP_LISTENING) { + db_printf("%sUNP_LISTENING", comma ? ", " : ""); comma = 1; } if (unp_flags & UNP_WANTCRED) { Index: sys/kern/vfs_default.c =================================================================== --- sys/kern/vfs_default.c (revision 312784) +++ sys/kern/vfs_default.c (working copy) @@ -1124,7 +1124,7 @@ int vop_stdunp_bind(struct vop_unp_bind_args *ap) { - ap->a_vp->v_socket = ap->a_socket; + ap->a_vp->v_unpcb = ap->a_unpcb; return (0); } @@ -1132,7 +1132,7 @@ int vop_stdunp_connect(struct vop_unp_connect_args *ap) { - *ap->a_socket = ap->a_vp->v_socket; + *ap->a_unpcb = ap->a_vp->v_unpcb; return (0); } @@ -1140,7 +1140,7 @@ int vop_stdunp_detach(struct vop_unp_detach_args *ap) { - ap->a_vp->v_socket = NULL; + ap->a_vp->v_unpcb = NULL; return (0); } Index: sys/kern/vfs_subr.c =================================================================== --- sys/kern/vfs_subr.c (revision 312784) +++ sys/kern/vfs_subr.c (working copy) @@ -2992,7 +2992,10 @@ _vdrop(struct vnode *vp, bool locked) /* XXX Elsewhere we detect an already freed vnode via NULL v_op. */ vp->v_op = NULL; #endif - bzero(&vp->v_un, sizeof(vp->v_un)); + vp->v_mountedhere = NULL; + vp->v_unpcb = NULL; + vp->v_rdev = NULL; + vp->v_fifoinfo = NULL; vp->v_lasta = vp->v_clen = vp->v_cstart = vp->v_lastw = 0; vp->v_iflag = 0; vp->v_vflag = 0; Index: sys/kern/vnode_if.src =================================================================== --- sys/kern/vnode_if.src (revision 312784) +++ sys/kern/vnode_if.src (working copy) @@ -662,7 +662,7 @@ vop_advise { vop_unp_bind { IN struct vnode *vp; - IN struct socket *socket; + IN struct unpcb *unpcb; }; @@ -670,7 +670,7 @@ vop_unp_bind { vop_unp_connect { IN struct vnode *vp; - OUT struct socket **socket; + OUT struct unpcb **unpcb; }; Index: sys/netinet/in_pcb.h =================================================================== --- sys/netinet/in_pcb.h (revision 312784) +++ sys/netinet/in_pcb.h (working copy) @@ -192,7 +192,10 @@ struct inpcb { struct inpcbinfo *inp_pcbinfo; /* (c) PCB list info */ struct inpcbgroup *inp_pcbgroup; /* (g/i) PCB group list */ LIST_ENTRY(inpcb) inp_pcbgroup_wild; /* (g/i/h) group wildcard entry */ - struct socket *inp_socket; /* (i) back pointer to socket */ + union { + struct socket *inp_socket; /* (i) back pointer to socket */ + struct solisten *inp_solisten; /* or solisten */ + }; struct ucred *inp_cred; /* (c) cache of socket cred */ u_int32_t inp_flow; /* (i) IPv6 flow information */ int inp_flags; /* (i) generic IP/datagram flags */ @@ -618,6 +621,7 @@ short inp_so_options(const struct inpcb *inp); #define INP_RECVFLOWID 0x00000100 /* populate recv datagram with flow info */ #define INP_RECVRSSBUCKETID 0x00000200 /* populate recv datagram with bucket id */ #define INP_RATE_LIMIT_CHANGED 0x00000400 /* rate limit needs attention */ +#define INP_LISTENING 0x00000800 /* this is a listening socket */ /* * Flags passed to in_pcblookup*() functions. @@ -631,6 +635,7 @@ short inp_so_options(const struct inpcb *inp); #define sotoinpcb(so) ((struct inpcb *)(so)->so_pcb) #define sotoin6pcb(so) sotoinpcb(so) /* for KAME src sync over BSD*'s */ +#define soltoinpcb(sol) ((struct inpcb *)(sol)->sol_pcb) #define INP_SOCKAF(so) so->so_proto->pr_domain->dom_family Index: sys/netinet/ip_output.c =================================================================== --- sys/netinet/ip_output.c (revision 312784) +++ sys/netinet/ip_output.c (working copy) @@ -965,9 +965,10 @@ in_delayed_cksum(struct mbuf *m) * IP socket option processing. */ int -ip_ctloutput(struct socket *so, struct sockopt *sopt) +ip_ctloutput(void *xpcb, struct sockopt *sopt) { - struct inpcb *inp = sotoinpcb(so); + struct inpcb *inp = (struct inpcb *)xpcb; + struct socket *so = inp->inp_socket; int error, optval; #ifdef RSS uint32_t rss_bucket; Index: sys/netinet/ip_var.h =================================================================== --- sys/netinet/ip_var.h (revision 312784) +++ sys/netinet/ip_var.h (working copy) @@ -203,7 +203,7 @@ void inp_freemoptions(struct ip_moptions *); int inp_getmoptions(struct inpcb *, struct sockopt *); int inp_setmoptions(struct inpcb *, struct sockopt *); -int ip_ctloutput(struct socket *, struct sockopt *sopt); +int ip_ctloutput(void *, struct sockopt *sopt); void ip_drain(void); int ip_fragment(struct ip *ip, struct mbuf **m_frag, int mtu, u_long if_hwassist_flags); @@ -223,7 +223,7 @@ void ip_savecontrol(struct inpcb *, struct mbuf ** struct mbuf *); void ip_slowtimo(void); void ip_fillid(struct ip *); -int rip_ctloutput(struct socket *, struct sockopt *); +int rip_ctloutput(void *, struct sockopt *); void rip_ctlinput(int, struct sockaddr *, void *); void rip_init(void); int rip_input(struct mbuf **, int *, int); Index: sys/netinet/raw_ip.c =================================================================== --- sys/netinet/raw_ip.c (revision 312784) +++ sys/netinet/raw_ip.c (working copy) @@ -562,9 +562,10 @@ rip_output(struct mbuf *m, struct socket *so, ...) * XXX-BZ inp locking? */ int -rip_ctloutput(struct socket *so, struct sockopt *sopt) +rip_ctloutput(void *xpcb, struct sockopt *sopt) { - struct inpcb *inp = sotoinpcb(so); + struct inpcb *inp = (struct inpcb *)xpcb; + struct socket *so = inp->inp_socket; int error, optval; if (sopt->sopt_level != IPPROTO_IP) { @@ -626,7 +627,7 @@ int break; default: - error = ip_ctloutput(so, sopt); + error = ip_ctloutput(inp, sopt); break; } break; Index: sys/netinet/sctp_input.c =================================================================== --- sys/netinet/sctp_input.c (revision 312784) +++ sys/netinet/sctp_input.c (working copy) @@ -161,13 +161,13 @@ sctp_handle_init(struct mbuf *m, int iphlen, int o *abort_no_unlock = 1; goto outnow; } - /* We are only accepting if we have a socket with positive - * so_qlimit. */ + /* + * Check if the socket is accepting. + */ if ((stcb == NULL) && ((inp->sctp_flags & SCTP_PCB_FLAGS_SOCKET_GONE) || (inp->sctp_flags & SCTP_PCB_FLAGS_SOCKET_ALLGONE) || - (inp->sctp_socket == NULL) || - (inp->sctp_socket->so_qlimit == 0))) { + !(inp->sctp_flags & SCTP_PCB_FLAGS_ACCEPTING))) { /* * FIX ME ?? What about TCP model and we have a * match/restart case? Actually no fix is needed. the lookup @@ -1605,7 +1605,7 @@ sctp_process_cookie_existing(struct mbuf *m, int i sctp_stop_all_cookie_timers(stcb); if (((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_TCPTYPE) || (stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_IN_TCPPOOL)) && - (inp->sctp_socket->so_qlimit == 0) + !(stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_ACCEPTING) ) { #if defined(__APPLE__) || defined(SCTP_SO_LOCK_TESTING) struct socket *so; @@ -1806,7 +1806,7 @@ sctp_process_cookie_existing(struct mbuf *m, int i if (((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_TCPTYPE) || (stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_IN_TCPPOOL)) && - (inp->sctp_socket->so_qlimit == 0)) { + !(stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_ACCEPTING)) { #if defined(__APPLE__) || defined(SCTP_SO_LOCK_TESTING) struct socket *so; #endif @@ -2317,7 +2317,7 @@ sctp_process_cookie_new(struct mbuf *m, int iphlen *notification = SCTP_NOTIFY_ASSOC_UP; if (((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_TCPTYPE) || (stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_IN_TCPPOOL)) && - (inp->sctp_socket->so_qlimit == 0)) { + !(stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_ACCEPTING)) { /* * This is an endpoint that called connect() how it got a * cookie that is NEW is a bit of a mystery. It must be that @@ -2343,7 +2343,7 @@ sctp_process_cookie_new(struct mbuf *m, int iphlen SCTP_SOCKET_UNLOCK(so, 1); #endif } else if ((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_TCPTYPE) && - (inp->sctp_socket->so_qlimit)) { + (stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_ACCEPTING)) { /* * We don't want to do anything with this one. Since it is * the listening guy. The timer will get started for @@ -2720,13 +2720,14 @@ sctp_handle_cookie_echo(struct mbuf *m, int iphlen sctp_start_net_timers(*stcb); if ((*inp_p)->sctp_flags & SCTP_PCB_FLAGS_TCPTYPE) { if (!had_a_existing_tcb || - (((*inp_p)->sctp_flags & SCTP_PCB_FLAGS_CONNECTED) == 0)) { + ((*inp_p)->sctp_flags & SCTP_PCB_FLAGS_ACCEPTING)) { /* * If we have a NEW cookie or the connect never * reached the connected state during collision we * must do the TCP accept thing. */ - struct socket *so, *oso; + struct solisten *sol; + struct socket *so; struct sctp_inpcb *inp; if (notification == SCTP_NOTIFY_ASSOC_RESTART) { @@ -2741,12 +2742,11 @@ sctp_handle_cookie_echo(struct mbuf *m, int iphlen } return (m); } - oso = (*inp_p)->sctp_socket; + sol = (*inp_p)->sctp_solisten; atomic_add_int(&(*stcb)->asoc.refcnt, 1); SCTP_TCB_UNLOCK((*stcb)); CURVNET_SET(oso->so_vnet); - so = sonewconn(oso, 0 - ); + so = sonewconn(sol, 0); CURVNET_RESTORE(); SCTP_TCB_LOCK((*stcb)); atomic_subtract_int(&(*stcb)->asoc.refcnt, 1); Index: sys/netinet/sctp_pcb.h =================================================================== --- sys/netinet/sctp_pcb.h (revision 312784) +++ sys/netinet/sctp_pcb.h (working copy) @@ -385,8 +385,11 @@ struct sctp_inpcb { */ struct sctp_laddr *next_addr_touse; - /* back pointer to our socket */ - struct socket *sctp_socket; + /* back pointer to our socket / listening socket */ + union { + struct socket *sctp_socket; + struct solisten *sctp_solisten; + }; uint64_t sctp_features; /* Feature flags */ uint32_t sctp_flags; /* INP state flag set */ uint32_t sctp_mobility_features; /* Mobility Feature flags */ Index: sys/netinet/sctp_syscalls.c =================================================================== --- sys/netinet/sctp_syscalls.c (revision 312784) +++ sys/netinet/sctp_syscalls.c (working copy) @@ -152,29 +152,11 @@ sys_sctp_peeloff(td, uap) td->td_retval[0] = fd; CURVNET_SET(head->so_vnet); - so = sonewconn(head, SS_ISCONNECTED); + so = sopeeloff(head); if (so == NULL) { error = ENOMEM; goto noconnection; } - /* - * Before changing the flags on the socket, we have to bump the - * reference count. Otherwise, if the protocol calls sofree(), - * the socket will be released due to a zero refcount. - */ - SOCK_LOCK(so); - soref(so); /* file descriptor reference */ - SOCK_UNLOCK(so); - - ACCEPT_LOCK(); - - TAILQ_REMOVE(&head->so_comp, so, so_list); - head->so_qlen--; - so->so_state |= (head->so_state & SS_NBIO); - so->so_state &= ~SS_NOFDREF; - so->so_qstate &= ~SQ_COMP; - so->so_head = NULL; - ACCEPT_UNLOCK(); finit(nfp, fflag, DTYPE_SOCKET, so, &socketops); error = sctp_do_peeloff(head, so, (sctp_assoc_t)uap->name); if (error != 0) Index: sys/netinet/sctp_usrreq.c =================================================================== --- sys/netinet/sctp_usrreq.c (revision 312784) +++ sys/netinet/sctp_usrreq.c (working copy) @@ -6985,19 +6985,11 @@ out_now: #endif int -sctp_listen(struct socket *so, int backlog, struct thread *p) +sctp_listen(struct socket *so, struct solisten *sol, int backlog, + struct thread *p) { - /* - * Note this module depends on the protocol processing being called - * AFTER any socket level flags and backlog are applied to the - * socket. The traditional way that the socket flags are applied is - * AFTER protocol processing. We have made a change to the - * sys/kern/uipc_socket.c module to reverse this but this MUST be in - * place if the socket API for SCTP is to work properly. - */ - - int error = 0; struct sctp_inpcb *inp; + int error; inp = (struct sctp_inpcb *)so->so_pcb; if (inp == NULL) { @@ -7096,13 +7088,6 @@ int sctp_log_lock(inp, (struct sctp_tcb *)NULL, SCTP_LOG_LOCK_SOCK); } #endif - SOCK_LOCK(so); - error = solisten_proto_check(so); - SOCK_UNLOCK(so); - if (error) { - SCTP_INP_RUNLOCK(inp); - return (error); - } if ((sctp_is_feature_on(inp, SCTP_PCB_FLAGS_PORTREUSE)) && (inp->sctp_flags & SCTP_PCB_FLAGS_IN_TCPPOOL)) { /* @@ -7132,19 +7117,17 @@ int return (error); } } - SOCK_LOCK(so); - /* It appears for 7.0 and on, we must always call this. */ - solisten_proto(so, backlog); - if (inp->sctp_flags & SCTP_PCB_FLAGS_UDPTYPE) { - /* remove the ACCEPTCONN flag for one-to-many sockets */ - so->so_options &= ~SO_ACCEPTCONN; - } - if (backlog == 0) { - /* turning off listen */ - so->so_options &= ~SO_ACCEPTCONN; - } - SOCK_UNLOCK(so); - return (error); + + /* + * If it is a one-to-many socket, or backlog is 0, we refuse + * transfer to solisten. + */ + if ((inp->sctp_flags & SCTP_PCB_FLAGS_UDPTYPE) || backlog == 0) + return (ENOTSOCK); + + inp->sctp_flags |= SCTP_PCB_FLAGS_ACCEPTING; + inp->sctp_solisten = sol; + return (0); } static int sctp_defered_wakeup_cnt = 0; Index: sys/netinet/tcp_input.c =================================================================== --- sys/netinet/tcp_input.c (revision 312784) +++ sys/netinet/tcp_input.c (working copy) @@ -601,6 +601,7 @@ tcp_input(struct mbuf **mp, int *offp, int proto) struct inpcb *inp = NULL; struct tcpcb *tp = NULL; struct socket *so = NULL; + struct solisten *sol = NULL; u_char *optp = NULL; int off0; int optlen = 0; @@ -633,6 +634,7 @@ tcp_input(struct mbuf **mp, int *offp, int proto) u_char tcp_saveipgen[IP6_HDR_LEN]; struct tcphdr tcp_savetcp; short ostate = 0; + bool debug = false; #endif #ifdef INET6 @@ -940,7 +942,7 @@ findpcb: if ((inp->inp_flowtype == M_HASHTYPE_NONE) && (M_HASHTYPE_GET(m) != M_HASHTYPE_NONE) && ((inp->inp_socket == NULL) || - (inp->inp_socket->so_options & SO_ACCEPTCONN) == 0)) { + (inp->inp_flags2 & INP_LISTENING) == 0)) { inp->inp_flowid = m->m_pkthdr.flowid; inp->inp_flowtype = M_HASHTYPE_GET(m); } @@ -1077,10 +1079,21 @@ relocked: if (mac_inpcb_check_deliver(inp, m)) goto dropunlock; #endif - so = inp->inp_socket; - KASSERT(so != NULL, ("%s: so == NULL", __func__)); + if (inp->inp_flags2 & INP_LISTENING) { + sol = inp->inp_solisten; #ifdef TCPDEBUG - if (so->so_options & SO_DEBUG) { + debug = sol->sol_options & SO_DEBUG; +#endif + } else { + so = inp->inp_socket; +#ifdef TCPDEBUG + debug = so->so_options & SO_DEBUG; +#endif + } + KASSERT(so != NULL || sol != NULL, + ("%s: inp %p has not socket", __func__, inp)); +#ifdef TCPDEBUG + if (debug) { ostate = tp->t_state; #ifdef INET6 if (isipv6) { @@ -1096,9 +1109,10 @@ relocked: * state) we look into the SYN cache if this is a new connection * attempt or the completion of a previous one. */ - KASSERT(tp->t_state == TCPS_LISTEN || !(so->so_options & SO_ACCEPTCONN), - ("%s: so accepting but tp %p not listening", __func__, tp)); - if (tp->t_state == TCPS_LISTEN && (so->so_options & SO_ACCEPTCONN)) { + KASSERT(tp->t_state == TCPS_LISTEN || + !(inp->inp_flags2 & INP_LISTENING), + ("%s: pcb listening but tp %p not listening", __func__, tp)); + if (tp->t_state == TCPS_LISTEN && (inp->inp_flags2 & INP_LISTENING)) { struct in_conninfo inc; bzero(&inc, sizeof(inc)); @@ -1115,7 +1129,7 @@ relocked: } inc.inc_fport = th->th_sport; inc.inc_lport = th->th_dport; - inc.inc_fibnum = so->so_fibnum; + inc.inc_fibnum = sol->sol_fibnum; /* * Check for an existing connection attempt in syncache if @@ -1135,7 +1149,7 @@ relocked: * NB: syncache_expand() doesn't unlock * inp and tcpinfo locks. */ - if (!syncache_expand(&inc, &to, th, &so, m)) { + if (!syncache_expand(&inc, &to, th, sol, &so, m)) { /* * No syncache entry or ACK was not * for our SYN/ACK. Send a RST. @@ -1404,7 +1418,7 @@ tfo_socket_result: * for syncache. */ #ifdef TCPDEBUG - if (so->so_options & SO_DEBUG) + if (debug) tcp_trace(TA_INPUT, ostate, tp, (void *)tcp_saveipgen, &tcp_savetcp, 0); #endif @@ -1411,10 +1425,10 @@ tfo_socket_result: TCP_PROBE3(debug__input, tp, th, m); tcp_dooptions(&to, optp, optlen, TO_SYN); #ifdef TCP_RFC7413 - if (syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL)) + if (syncache_add(&inc, &to, th, inp, sol, m, NULL, NULL)) goto tfo_socket_result; #else - syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL); + syncache_add(&inc, &to, th, inp, sol, m, NULL, NULL); #endif /* * Entry added to syncache and mbuf consumed. @@ -1428,6 +1442,7 @@ tfo_socket_result: return (IPPROTO_DONE); } else if (tp->t_state == TCPS_LISTEN) { /* + * QQQ * When a listen socket is torn down the SO_ACCEPTCONN * flag is removed first while connections are drained * from the accept queue in a unlock/lock cycle of the Index: sys/netinet/tcp_subr.c =================================================================== --- sys/netinet/tcp_subr.c (revision 312784) +++ sys/netinet/tcp_subr.c (working copy) @@ -1557,12 +1557,13 @@ tcp_close(struct tcpcb *tp) { struct inpcb *inp = tp->t_inpcb; struct socket *so; + bool listening = (tp->t_state == TCPS_LISTEN); INP_INFO_LOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); #ifdef TCP_OFFLOAD - if (tp->t_state == TCPS_LISTEN) + if (listening) tcp_offload_listen_stop(tp); #endif #ifdef TCP_RFC7413 @@ -1580,6 +1581,12 @@ tcp_close(struct tcpcb *tp) TCPSTAT_INC(tcps_closed); if (tp->t_state != TCPS_CLOSED) tcp_state_change(tp, TCPS_CLOSED); + if (listening) { + tcp_discardcb(tp); + in_pcbdetach(inp); + in_pcbfree(inp); + return (NULL); + } KASSERT(inp->inp_socket != NULL, ("tcp_close: inp_socket NULL")); so = inp->inp_socket; soisdisconnected(so); @@ -1588,7 +1595,6 @@ tcp_close(struct tcpcb *tp) ("tcp_close: !SS_PROTOREF")); inp->inp_flags &= ~INP_SOCKREF; INP_WUNLOCK(inp); - ACCEPT_LOCK(); SOCK_LOCK(so); so->so_state &= ~SS_PROTOREF; sofree(so); @@ -1802,9 +1808,14 @@ tcp_pcblist(SYSCTL_HANDLER_ARGS) if (xt.xt_tp.t_timers) tcp_timer_to_xtimer(&xt.xt_tp, xt.xt_tp.t_timers, &xt.xt_timer); } - if (inp->inp_socket != NULL) - sotoxsocket(inp->inp_socket, &xt.xt_socket); - else { + if (inp->inp_socket != NULL) { + if (inp->inp_flags2 & INP_LISTENING) + soltoxsocket(inp->inp_solisten, + &xt.xt_socket); + else + sotoxsocket(inp->inp_socket, + &xt.xt_socket); + } else { bzero(&xt.xt_socket, sizeof xt.xt_socket); xt.xt_socket.xso_protocol = IPPROTO_TCP; } @@ -2964,7 +2975,7 @@ sysctl_drop(SYSCTL_HANDLER_ARGS) else INP_WUNLOCK(inp); } else if (!(inp->inp_flags & INP_DROPPED) && - !(inp->inp_socket->so_options & SO_ACCEPTCONN)) { + !(inp->inp_flags2 & INP_LISTENING)) { tp = intotcpcb(inp); tp = tcp_drop(tp, ECONNABORTED); if (tp != NULL) Index: sys/netinet/tcp_syncache.c =================================================================== --- sys/netinet/tcp_syncache.c (revision 312784) +++ sys/netinet/tcp_syncache.c (working copy) @@ -129,7 +129,7 @@ static void syncache_free(struct syncache *); static void syncache_insert(struct syncache *, struct syncache_head *); static int syncache_respond(struct syncache *, struct syncache_head *, int, const struct mbuf *); -static struct socket *syncache_socket(struct syncache *, struct socket *, +static struct socket *syncache_socket(struct syncache *, struct solisten *, struct mbuf *m); static void syncache_timeout(struct syncache *sc, struct syncache_head *sch, int docallout); @@ -141,12 +141,12 @@ static tcp_seq syncookie_generate(struct syncache static struct syncache *syncookie_lookup(struct in_conninfo *, struct syncache_head *, struct syncache *, struct tcphdr *, struct tcpopt *, - struct socket *); + struct solisten *); static void syncookie_reseed(void *); #ifdef INVARIANTS -static int syncookie_cmp(struct in_conninfo *inc, struct syncache_head *sch, - struct syncache *sc, struct tcphdr *th, struct tcpopt *to, - struct socket *lso); +static int syncookie_cmp(struct in_conninfo *, struct syncache_head *, + struct syncache *, struct tcphdr *, struct tcpopt *, + struct solisten *); #endif /* @@ -635,7 +635,7 @@ done: * On success return the newly created socket with its underlying inp locked. */ static struct socket * -syncache_socket(struct syncache *sc, struct socket *lso, struct mbuf *m) +syncache_socket(struct syncache *sc, struct solisten *sol, struct mbuf *m) { struct tcp_function_block *blk; struct inpcb *inp = NULL; @@ -652,7 +652,7 @@ static struct socket * * connection when the SYN arrived. If we can't create * the connection, abort it. */ - so = sonewconn(lso, 0); + so = sonewconn(sol, 0); if (so == NULL) { /* * Drop the connection; we will either send a RST or @@ -738,12 +738,12 @@ static struct socket * } #ifdef IPSEC /* Copy old policy into new socket's. */ - if (ipsec_copy_policy(sotoinpcb(lso)->inp_sp, inp->inp_sp)) + if (ipsec_copy_policy(soltoinpcb(sol)->inp_sp, inp->inp_sp)) printf("syncache_socket: could not copy policy\n"); #endif #ifdef INET6 if (sc->sc_inc.inc_flags & INC_ISIPV6) { - struct inpcb *oinp = sotoinpcb(lso); + struct inpcb *oinp = soltoinpcb(sol); struct in6_addr laddr6; struct sockaddr_in6 sin6; /* @@ -829,7 +829,7 @@ static struct socket * tp->irs = sc->sc_irs; tcp_rcvseqinit(tp); tcp_sendseqinit(tp); - blk = sototcpcb(lso)->t_fb; + blk = soltotcpcb(sol)->t_fb; if (blk != tp->t_fb) { /* * Our parents t_fb was not the default, @@ -857,7 +857,7 @@ static struct socket * tp->rcv_adv += tp->rcv_wnd; tp->last_ack_sent = tp->rcv_nxt; - tp->t_flags = sototcpcb(lso)->t_flags & (TF_NOPUSH|TF_NODELAY); + tp->t_flags = soltotcpcb(sol)->t_flags & (TF_NOPUSH|TF_NODELAY); if (sc->sc_flags & SCF_NOOPT) tp->t_flags |= TF_NOOPT; else { @@ -912,10 +912,10 @@ static struct socket * /* * Copy and activate timers. */ - tp->t_keepinit = sototcpcb(lso)->t_keepinit; - tp->t_keepidle = sototcpcb(lso)->t_keepidle; - tp->t_keepintvl = sototcpcb(lso)->t_keepintvl; - tp->t_keepcnt = sototcpcb(lso)->t_keepcnt; + tp->t_keepinit = soltotcpcb(sol)->t_keepinit; + tp->t_keepidle = soltotcpcb(sol)->t_keepidle; + tp->t_keepintvl = soltotcpcb(sol)->t_keepintvl; + tp->t_keepcnt = soltotcpcb(sol)->t_keepcnt; tcp_timer_activate(tp, TT_KEEP, TP_KEEPINIT(tp)); TCPSTAT_INC(tcps_accepts); @@ -941,7 +941,7 @@ abort2: */ int syncache_expand(struct in_conninfo *inc, struct tcpopt *to, struct tcphdr *th, - struct socket **lsop, struct mbuf *m) + struct solisten *sol, struct socket **so, struct mbuf *m) { struct syncache *sc; struct syncache_head *sch; @@ -965,7 +965,7 @@ syncache_expand(struct in_conninfo *inc, struct tc * values with the reconstructed values from the cookie. */ if (sc != NULL) - syncookie_cmp(inc, sch, sc, th, to, *lsop); + syncookie_cmp(inc, sch, sc, th, to, sol); #endif if (sc == NULL) { @@ -987,7 +987,7 @@ syncache_expand(struct in_conninfo *inc, struct tc goto failed; } bzero(&scs, sizeof(scs)); - sc = syncookie_lookup(inc, sch, &scs, th, to, *lsop); + sc = syncookie_lookup(inc, sch, &scs, th, to, sol); SCH_UNLOCK(sch); if (sc == NULL) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) @@ -1087,9 +1087,9 @@ syncache_expand(struct in_conninfo *inc, struct tc goto failed; } - *lsop = syncache_socket(sc, *lsop, m); + *so = syncache_socket(sc, sol, m); - if (*lsop == NULL) + if (*so == NULL) TCPSTAT_INC(tcps_sc_aborted); else TCPSTAT_INC(tcps_sc_completed); @@ -1103,7 +1103,7 @@ failed: syncache_free(sc); if (s != NULL) free(s, M_TCPLOG); - *lsop = NULL; + *so = NULL; return (0); } @@ -1161,7 +1161,7 @@ syncache_tfo_expand(struct syncache *sc, struct so */ int syncache_add(struct in_conninfo *inc, struct tcpopt *to, struct tcphdr *th, - struct inpcb *inp, struct socket **lsop, struct mbuf *m, void *tod, + struct inpcb *inp, struct solisten *sol, struct mbuf *m, void *tod, void *todctx) { struct tcpcb *tp; @@ -1193,12 +1193,11 @@ syncache_add(struct in_conninfo *inc, struct tcpop ("%s: unexpected tcp flags", __func__)); /* - * Combine all so/tp operations very early to drop the INP lock as - * soon as possible. + * Combine all solisten/tp operations very early to drop the INP + * lock as soon as possible. */ - so = *lsop; - tp = sototcpcb(so); - cred = crhold(so->so_cred); + tp = soltotcpcb(sol); + cred = crhold(sol->sol_cred); #ifdef INET6 if ((inc->inc_flags & INC_ISIPV6) && @@ -1207,7 +1206,7 @@ syncache_add(struct in_conninfo *inc, struct tcpop #endif ip_ttl = inp->inp_ip_ttl; ip_tos = inp->inp_ip_tos; - win = sbspace(&so->so_rcv); + win = sol->sol_sbrcv_hiwat; ltflags = (tp->t_flags & (TF_NOOPT | TF_SIGNATURE)); #ifdef TCP_RFC7413 @@ -1220,7 +1219,7 @@ syncache_add(struct in_conninfo *inc, struct tcpop * listen queue with bogus TFO connections. */ if (atomic_fetchadd_int(tp->t_tfo_pending, 1) <= - (so->so_qlimit / 2)) { + (sol->sol_qlimit / 2)) { int result; result = tcp_fastopen_check_cookie(inc, @@ -1498,10 +1497,7 @@ skip_alloc: } done: - if (m) { - *lsop = NULL; - m_freem(m); - } + m_freem(m); #ifdef TCP_RFC7413 /* * If tfo_pending is not NULL here, then a TFO SYN that did not @@ -1981,7 +1977,7 @@ syncookie_generate(struct syncache_head *sch, stru static struct syncache * syncookie_lookup(struct in_conninfo *inc, struct syncache_head *sch, struct syncache *sc, struct tcphdr *th, struct tcpopt *to, - struct socket *lso) + struct solisten *sol) { uint32_t hash; uint8_t *secbits; @@ -2024,13 +2020,13 @@ syncookie_lookup(struct in_conninfo *inc, struct s switch (inc->inc_flags & INC_ISIPV6) { #ifdef INET case 0: - sc->sc_ip_ttl = sotoinpcb(lso)->inp_ip_ttl; - sc->sc_ip_tos = sotoinpcb(lso)->inp_ip_tos; + sc->sc_ip_ttl = soltoinpcb(sol)->inp_ip_ttl; + sc->sc_ip_tos = soltoinpcb(sol)->inp_ip_tos; break; #endif #ifdef INET6 case INC_ISIPV6: - if (sotoinpcb(lso)->inp_flags & IN6P_AUTOFLOWLABEL) + if (soltoinpcb(sol)->inp_flags & IN6P_AUTOFLOWLABEL) sc->sc_flowlabel = sc->sc_iss & IPV6_FLOWLABEL_MASK; break; #endif @@ -2049,7 +2045,7 @@ syncookie_lookup(struct in_conninfo *inc, struct s sc->sc_flags |= SCF_WINSCALE; } - wnd = sbspace(&lso->so_rcv); + wnd = sol->sol_sbrcv_hiwat; wnd = imax(wnd, 0); wnd = imin(wnd, TCP_MAXWIN); sc->sc_wnd = wnd; @@ -2077,13 +2073,13 @@ syncookie_lookup(struct in_conninfo *inc, struct s static int syncookie_cmp(struct in_conninfo *inc, struct syncache_head *sch, struct syncache *sc, struct tcphdr *th, struct tcpopt *to, - struct socket *lso) + struct solisten *sol) { struct syncache scs, *scx; char *s; bzero(&scs, sizeof(scs)); - scx = syncookie_lookup(inc, sch, &scs, th, to, lso); + scx = syncookie_lookup(inc, sch, &scs, th, to, sol); if ((s = tcp_log_addrs(inc, th, NULL, NULL)) == NULL) return (0); Index: sys/netinet/tcp_syncache.h =================================================================== --- sys/netinet/tcp_syncache.h (revision 312784) +++ sys/netinet/tcp_syncache.h (working copy) @@ -40,9 +40,10 @@ void syncache_destroy(void); #endif void syncache_unreach(struct in_conninfo *, struct tcphdr *); int syncache_expand(struct in_conninfo *, struct tcpopt *, - struct tcphdr *, struct socket **, struct mbuf *); + struct tcphdr *, struct solisten *, struct socket **, + struct mbuf *); int syncache_add(struct in_conninfo *, struct tcpopt *, - struct tcphdr *, struct inpcb *, struct socket **, struct mbuf *, + struct tcphdr *, struct inpcb *, struct solisten *, struct mbuf *, void *, void *); void syncache_chkrst(struct in_conninfo *, struct tcphdr *); void syncache_badack(struct in_conninfo *); Index: sys/netinet/tcp_timewait.c =================================================================== --- sys/netinet/tcp_timewait.c (revision 312784) +++ sys/netinet/tcp_timewait.c (working copy) @@ -352,7 +352,6 @@ tcp_twstart(struct tcpcb *tp) ("tcp_twstart: !SS_PROTOREF")); inp->inp_flags &= ~INP_SOCKREF; INP_WUNLOCK(inp); - ACCEPT_LOCK(); SOCK_LOCK(so); so->so_state &= ~SS_PROTOREF; sofree(so); @@ -491,7 +490,6 @@ tcp_twclose(struct tcptw *tw, int reuse) if (inp->inp_flags & INP_SOCKREF) { inp->inp_flags &= ~INP_SOCKREF; INP_WUNLOCK(inp); - ACCEPT_LOCK(); SOCK_LOCK(so); KASSERT(so->so_state & SS_PROTOREF, ("tcp_twclose: INP_SOCKREF && !SS_PROTOREF")); Index: sys/netinet/tcp_usrreq.c =================================================================== --- sys/netinet/tcp_usrreq.c (revision 312784) +++ sys/netinet/tcp_usrreq.c (working copy) @@ -394,97 +394,129 @@ out: * Prepare to accept connections. */ static int -tcp_usr_listen(struct socket *so, int backlog, struct thread *td) +tcp_usr_listen(struct socket *so, struct solisten *sol, int backlog, + struct thread *td) { - int error = 0; struct inpcb *inp; - struct tcpcb *tp = NULL; + struct tcpcb *tp; TCPDEBUG0; + if (so == NULL) + return (0); inp = sotoinpcb(so); KASSERT(inp != NULL, ("tcp_usr_listen: inp == NULL")); INP_WLOCK(inp); if (inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) { - error = EINVAL; - goto out; + INP_WUNLOCK(inp); + return (EINVAL); } tp = intotcpcb(inp); TCPDEBUG1(); SOCK_LOCK(so); - error = solisten_proto_check(so); - INP_HASH_WLOCK(&V_tcbinfo); - if (error == 0 && inp->inp_lport == 0) + if (inp->inp_lport == 0) { + int error; + + INP_HASH_WLOCK(&V_tcbinfo); error = in_pcbbind(inp, (struct sockaddr *)0, td->td_ucred); - INP_HASH_WUNLOCK(&V_tcbinfo); - if (error == 0) { - tcp_state_change(tp, TCPS_LISTEN); - solisten_proto(so, backlog); + INP_HASH_WUNLOCK(&V_tcbinfo); + if (error) { + SOCK_UNLOCK(so); + INP_WUNLOCK(inp); + return (error); + } + } + tcp_state_change(tp, TCPS_LISTEN); + inp->inp_flags2 |= INP_LISTENING; + inp->inp_solisten = sol; #ifdef TCP_OFFLOAD - if ((so->so_options & SO_NO_OFFLOAD) == 0) - tcp_offload_listen_start(tp); + if ((so->so_options & SO_NO_OFFLOAD) == 0) + tcp_offload_listen_start(tp); #endif - } SOCK_UNLOCK(so); - #ifdef TCP_RFC7413 if (IS_FASTOPEN(tp->t_flags)) tp->t_tfo_pending = tcp_fastopen_alloc_counter(); #endif -out: TCPDEBUG2(PRU_LISTEN); TCP_PROBE2(debug__user, tp, PRU_LISTEN); INP_WUNLOCK(inp); - return (error); + return (0); } + +static void +tcp_usr_listenclose(struct solisten *sol) +{ + struct inpcb *inp; + struct tcpcb *tp; + + inp = soltoinpcb(sol); + INP_INFO_RLOCK(&V_tcbinfo); + INP_WLOCK(inp); + KASSERT(inp->inp_flags2 & INP_LISTENING, + ("%s: inp %p not listening", __func__, inp)); + KASSERT(!(inp->inp_flags & INP_DROPPED), + ("%s: listening inp %p dropped", __func__, inp)); + tp = intotcpcb(inp); + TCPDEBUG2(PRU_CLOSE); + TCP_PROBE2(debug__user, tp, PRU_CLOSE); + tcp_disconnect(tp); + /* inp gone */ + INP_INFO_RUNLOCK(&V_tcbinfo); +} #endif /* INET */ #ifdef INET6 static int -tcp6_usr_listen(struct socket *so, int backlog, struct thread *td) +tcp6_usr_listen(struct socket *so, struct solisten *sol, int backlog, + struct thread *td) { - int error = 0; struct inpcb *inp; - struct tcpcb *tp = NULL; + struct tcpcb *tp; TCPDEBUG0; + if (so == NULL) + return (0); inp = sotoinpcb(so); KASSERT(inp != NULL, ("tcp6_usr_listen: inp == NULL")); INP_WLOCK(inp); if (inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) { - error = EINVAL; - goto out; + INP_WUNLOCK(inp); + return (EINVAL); } tp = intotcpcb(inp); TCPDEBUG1(); SOCK_LOCK(so); - error = solisten_proto_check(so); - INP_HASH_WLOCK(&V_tcbinfo); - if (error == 0 && inp->inp_lport == 0) { + if (inp->inp_lport == 0) { + int error; + inp->inp_vflag &= ~INP_IPV4; if ((inp->inp_flags & IN6P_IPV6_V6ONLY) == 0) inp->inp_vflag |= INP_IPV4; + INP_HASH_WLOCK(&V_tcbinfo); error = in6_pcbbind(inp, (struct sockaddr *)0, td->td_ucred); + INP_HASH_WUNLOCK(&V_tcbinfo); + if (error) { + SOCK_UNLOCK(so); + INP_WUNLOCK(inp); + return (error); + } } - INP_HASH_WUNLOCK(&V_tcbinfo); - if (error == 0) { - tcp_state_change(tp, TCPS_LISTEN); - solisten_proto(so, backlog); + tcp_state_change(tp, TCPS_LISTEN); + inp->inp_flags2 |= INP_LISTENING; + inp->inp_solisten = sol; #ifdef TCP_OFFLOAD - if ((so->so_options & SO_NO_OFFLOAD) == 0) - tcp_offload_listen_start(tp); + if ((so->so_options & SO_NO_OFFLOAD) == 0) + tcp_offload_listen_start(tp); #endif - } SOCK_UNLOCK(so); - #ifdef TCP_RFC7413 if (IS_FASTOPEN(tp->t_flags)) tp->t_tfo_pending = tcp_fastopen_alloc_counter(); #endif -out: TCPDEBUG2(PRU_LISTEN); TCP_PROBE2(debug__user, tp, PRU_LISTEN); INP_WUNLOCK(inp); - return (error); + return (0); } #endif /* INET6 */ @@ -1177,6 +1209,7 @@ struct pr_usrreqs tcp_usrreqs = { .pru_detach = tcp_usr_detach, .pru_disconnect = tcp_usr_disconnect, .pru_listen = tcp_usr_listen, + .pru_listenclose = tcp_usr_listenclose, .pru_peeraddr = in_getpeeraddr, .pru_rcvd = tcp_usr_rcvd, .pru_rcvoob = tcp_usr_rcvoob, @@ -1200,6 +1233,7 @@ struct pr_usrreqs tcp6_usrreqs = { .pru_detach = tcp_usr_detach, .pru_disconnect = tcp_usr_disconnect, .pru_listen = tcp6_usr_listen, + .pru_listenclose = tcp_usr_listenclose, .pru_peeraddr = in6_mapped_peeraddr, .pru_rcvd = tcp_usr_rcvd, .pru_rcvoob = tcp_usr_rcvoob, @@ -1392,23 +1426,21 @@ tcp_fill_info(struct tcpcb *tp, struct tcp_info *t #define INP_WLOCK_RECHECK(inp) INP_WLOCK_RECHECK_CLEANUP((inp), /* noop */) int -tcp_ctloutput(struct socket *so, struct sockopt *sopt) +tcp_ctloutput(void *xpcb, struct sockopt *sopt) { - int error; - struct inpcb *inp; - struct tcpcb *tp; + struct inpcb *inp = (struct inpcb *)xpcb; + struct tcpcb *tp; struct tcp_function_block *blk; struct tcp_function_set fsn; + int error; error = 0; - inp = sotoinpcb(so); - KASSERT(inp != NULL, ("tcp_ctloutput: inp == NULL")); INP_WLOCK(inp); if (sopt->sopt_level != IPPROTO_TCP) { #ifdef INET6 if (inp->inp_vflag & INP_IPV6PROTO) { INP_WUNLOCK(inp); - error = ip6_ctloutput(so, sopt); + error = ip6_ctloutput(inp, sopt); } #endif /* INET6 */ #if defined(INET6) && defined(INET) @@ -1417,7 +1449,7 @@ int #ifdef INET { INP_WUNLOCK(inp); - error = ip_ctloutput(so, sopt); + error = ip_ctloutput(inp, sopt); } #endif return (error); @@ -1510,18 +1542,19 @@ int return (error); } /* Pass in the INP locked, called must unlock it */ - return (tp->t_fb->tfb_tcp_ctloutput(so, sopt, inp, tp)); + return (tp->t_fb->tfb_tcp_ctloutput(inp, sopt)); } int -tcp_default_ctloutput(struct socket *so, struct sockopt *sopt, struct inpcb *inp, struct tcpcb *tp) +tcp_default_ctloutput(struct inpcb *inp, struct sockopt *sopt) { - int error, opt, optval; - u_int ui; - struct tcp_info ti; + struct tcp_info ti; struct cc_algo *algo; + struct tcpcb *tp = intotcpcb(inp); char *pbuf, buf[TCP_CA_NAME_MAX]; size_t len; + int error, opt, optval; + u_int ui; /* * For TCP_CCALGOOPT forward the control to CC module, for both @@ -1946,11 +1979,13 @@ tcp_disconnect(struct tcpcb *tp) INP_WLOCK_ASSERT(inp); /* - * Neither tcp_close() nor tcp_drop() should return NULL, as the - * socket is still open. + * For a regular socket neither tcp_close() nor tcp_drop() should + * return NULL, as the socket is still open. */ - if (tp->t_state < TCPS_ESTABLISHED) { + if (tp->t_state == TCPS_LISTEN) tp = tcp_close(tp); + else if (tp->t_state < TCPS_ESTABLISHED) { + tp = tcp_close(tp); KASSERT(tp != NULL, ("tcp_disconnect: tcp_close() returned NULL")); } else if ((so->so_options & SO_LINGER) && so->so_linger == 0) { Index: sys/netinet/tcp_var.h =================================================================== --- sys/netinet/tcp_var.h (revision 312784) +++ sys/netinet/tcp_var.h (working copy) @@ -136,8 +136,7 @@ struct tcp_function_block { struct socket *, struct tcpcb *, int, int, uint8_t, int); - int (*tfb_tcp_ctloutput)(struct socket *so, struct sockopt *sopt, - struct inpcb *inp, struct tcpcb *tp); + int (*tfb_tcp_ctloutput)(struct inpcb *inp, struct sockopt *sopt); /* Optional memory allocation/free routine */ void (*tfb_tcp_fb_init)(struct tcpcb *); void (*tfb_tcp_fb_fini)(struct tcpcb *, int); @@ -466,6 +465,7 @@ struct tcptw { #define intotcpcb(ip) ((struct tcpcb *)(ip)->inp_ppcb) #define intotw(ip) ((struct tcptw *)(ip)->inp_ppcb) #define sototcpcb(so) (intotcpcb(sotoinpcb(so))) +#define soltotcpcb(sol) (intotcpcb(soltoinpcb(sol))) /* * The smoothed round-trip time and estimated variance @@ -771,7 +771,7 @@ void tcp_discardcb(struct tcpcb *); void tcp_twstart(struct tcpcb *); void tcp_twclose(struct tcptw *, int); void tcp_ctlinput(int, struct sockaddr *, void *); -int tcp_ctloutput(struct socket *, struct sockopt *); +int tcp_ctloutput(void *, struct sockopt *); struct tcpcb * tcp_drop(struct tcpcb *, int); void tcp_drain(void); @@ -810,7 +810,7 @@ int register_tcp_functions(struct tcp_function_blo int deregister_tcp_functions(struct tcp_function_block *blk); struct tcp_function_block *find_and_ref_tcp_functions(struct tcp_function_set *fs); struct tcp_function_block *find_and_ref_tcp_fb(struct tcp_function_block *blk); -int tcp_default_ctloutput(struct socket *so, struct sockopt *sopt, struct inpcb *inp, struct tcpcb *tp); +int tcp_default_ctloutput(struct inpcb *inp, struct sockopt *sopt); uint32_t tcp_maxmtu(struct in_conninfo *, struct tcp_ifcap *); uint32_t tcp_maxmtu6(struct in_conninfo *, struct tcp_ifcap *); Index: sys/netinet/udp_usrreq.c =================================================================== --- sys/netinet/udp_usrreq.c (revision 312784) +++ sys/netinet/udp_usrreq.c (working copy) @@ -988,16 +988,15 @@ SYSCTL_PROC(_net_inet_udp, OID_AUTO, getcred, #endif /* INET */ int -udp_ctloutput(struct socket *so, struct sockopt *sopt) +udp_ctloutput(void *xpcb, struct sockopt *sopt) { - struct inpcb *inp; + struct inpcb *inp = (struct inpcb *)xpcb; + struct socket *so = inp->inp_socket; struct udpcb *up; int isudplite, error, optval; error = 0; isudplite = (so->so_proto->pr_protocol == IPPROTO_UDPLITE) ? 1 : 0; - inp = sotoinpcb(so); - KASSERT(inp != NULL, ("%s: inp == NULL", __func__)); INP_WLOCK(inp); if (sopt->sopt_level != so->so_proto->pr_protocol) { #ifdef INET6 @@ -1012,7 +1011,7 @@ int #ifdef INET { INP_WUNLOCK(inp); - error = ip_ctloutput(so, sopt); + error = ip_ctloutput(inp, sopt); } #endif return (error); @@ -1027,8 +1026,6 @@ int sizeof optval); if (error) break; - inp = sotoinpcb(so); - KASSERT(inp != NULL, ("%s: inp == NULL", __func__)); INP_WLOCK(inp); #ifdef IPSEC_NAT_T up = intoudpcb(inp); Index: sys/netinet/udp_var.h =================================================================== --- sys/netinet/udp_var.h (revision 312784) +++ sys/netinet/udp_var.h (working copy) @@ -168,7 +168,7 @@ void udp_discardcb(struct udpcb *); void udp_ctlinput(int, struct sockaddr *, void *); void udplite_ctlinput(int, struct sockaddr *, void *); -int udp_ctloutput(struct socket *, struct sockopt *); +int udp_ctloutput(void *, struct sockopt *); void udp_init(void); void udplite_init(void); int udp_input(struct mbuf **, int *, int); Index: sys/netinet6/ip6_output.c =================================================================== --- sys/netinet6/ip6_output.c (revision 312784) +++ sys/netinet6/ip6_output.c (working copy) @@ -1410,11 +1410,12 @@ ip6_calcmtu(struct ifnet *ifp, const struct in6_ad * IP6 socket option processing. */ int -ip6_ctloutput(struct socket *so, struct sockopt *sopt) +ip6_ctloutput(void *xpcb, struct sockopt *sopt) { + struct inpcb *in6p = (struct inpcb *)xpcb; + struct socket *so = in6p->inp_socket; int optdatalen, uproto; void *optdata; - struct inpcb *in6p = sotoinpcb(so); int error, optval; int level, op, optname; int optlen; Index: sys/netinet6/ip6_var.h =================================================================== --- sys/netinet6/ip6_var.h (revision 312784) +++ sys/netinet6/ip6_var.h (working copy) @@ -385,7 +385,7 @@ int ip6_output(struct mbuf *, struct ip6_pktopts * int, struct ip6_moptions *, struct ifnet **, struct inpcb *); -int ip6_ctloutput(struct socket *, struct sockopt *); +int ip6_ctloutput(void *, struct sockopt *); int ip6_raw_ctloutput(struct socket *, struct sockopt *); void ip6_initpktopts(struct ip6_pktopts *); int ip6_setpktopts(struct mbuf *, struct ip6_pktopts *, @@ -407,7 +407,7 @@ void frag6_drain(void); void rip6_init(void); int rip6_input(struct mbuf **, int *, int); void rip6_ctlinput(int, struct sockaddr *, void *); -int rip6_ctloutput(struct socket *, struct sockopt *); +int rip6_ctloutput(void *, struct sockopt *); int rip6_output(struct mbuf *, struct socket *, ...); int rip6_usrreq(struct socket *, int, struct mbuf *, struct mbuf *, struct mbuf *, struct thread *); Index: sys/netinet6/raw_ip6.c =================================================================== --- sys/netinet6/raw_ip6.c (revision 312784) +++ sys/netinet6/raw_ip6.c (working copy) @@ -560,9 +560,10 @@ rip6_output(struct mbuf *m, struct socket *so, ... * Raw IPv6 socket option processing. */ int -rip6_ctloutput(struct socket *so, struct sockopt *sopt) +rip6_ctloutput(void *xpcb, struct sockopt *sopt) { - struct inpcb *inp; + struct inpcb *inp = (struct inpcb *)xpcb; + struct socket *so = inp->inp_socket; int error; if (sopt->sopt_level == IPPROTO_ICMPV6) @@ -574,7 +575,6 @@ int else if (sopt->sopt_level != IPPROTO_IPV6) { if (sopt->sopt_level == SOL_SOCKET && sopt->sopt_name == SO_SETFIB) { - inp = sotoinpcb(so); INP_WLOCK(inp); inp->inp_inc.inc_fibnum = so->so_fibnum; INP_WUNLOCK(inp); @@ -623,7 +623,7 @@ int error = ip6_raw_ctloutput(so, sopt); break; default: - error = ip6_ctloutput(so, sopt); + error = ip6_ctloutput(inp, sopt); break; } break; Index: sys/sys/file.h =================================================================== --- sys/sys/file.h (revision 312784) +++ sys/sys/file.h (working copy) @@ -54,7 +54,7 @@ struct vnode; #endif /* _KERNEL */ #define DTYPE_VNODE 1 /* file */ -#define DTYPE_SOCKET 2 /* communications endpoint */ +#define DTYPE_SOCKET 2 /* regular (data flow) socket */ #define DTYPE_PIPE 3 /* pipe */ #define DTYPE_FIFO 4 /* fifo (named pipe) */ #define DTYPE_KQUEUE 5 /* event queue */ @@ -66,6 +66,7 @@ struct vnode; #define DTYPE_DEV 11 /* Device specific fd type */ #define DTYPE_PROCDESC 12 /* process descriptor */ #define DTYPE_LINUXEFD 13 /* emulation eventfd type */ +#define DTYPE_SOLISTEN 14 /* listen(2)ing socket */ #ifdef _KERNEL @@ -224,6 +225,7 @@ struct xfile { extern struct fileops vnops; extern struct fileops badfileops; extern struct fileops socketops; +extern struct fileops solistenops; extern int maxfiles; /* kernel limit on number of open files */ extern int maxfilesperproc; /* per process limit on number of open files */ extern volatile int openfiles; /* actual number of open files */ Index: sys/sys/protosw.h =================================================================== --- sys/sys/protosw.h (revision 312784) +++ sys/sys/protosw.h (working copy) @@ -39,6 +39,7 @@ struct mbuf; struct thread; struct sockaddr; struct socket; +struct solisten; struct sockopt; /*#ifdef _KERNEL*/ @@ -68,7 +69,7 @@ struct sockopt; typedef int pr_input_t (struct mbuf **, int*, int); typedef int pr_output_t (struct mbuf *, struct socket *, ...); typedef void pr_ctlinput_t (int, struct sockaddr *, void *); -typedef int pr_ctloutput_t (struct socket *, struct sockopt *); +typedef int pr_ctloutput_t (void *, struct sockopt *); typedef void pr_init_t (void); typedef void pr_fasttimo_t (void); typedef void pr_slowtimo_t (void); @@ -196,8 +197,8 @@ struct pr_usrreqs { struct ifnet *ifp, struct thread *td); void (*pru_detach)(struct socket *so); int (*pru_disconnect)(struct socket *so); - int (*pru_listen)(struct socket *so, int backlog, - struct thread *td); + int (*pru_listen)(struct socket *so, struct solisten *sol, + int backlog, struct thread *td); int (*pru_peeraddr)(struct socket *so, struct sockaddr **nam); int (*pru_rcvd)(struct socket *so, int flags); int (*pru_rcvoob)(struct socket *so, struct mbuf *m, int flags); @@ -223,6 +224,7 @@ struct pr_usrreqs { struct ucred *cred, struct thread *td); void (*pru_sosetlabel)(struct socket *so); void (*pru_close)(struct socket *so); + void (*pru_listenclose)(struct solisten *sol); int (*pru_bindat)(int fd, struct socket *so, struct sockaddr *nam, struct thread *td); int (*pru_connectat)(int fd, struct socket *so, @@ -248,7 +250,8 @@ int pru_connect2_notsupp(struct socket *so1, struc int pru_control_notsupp(struct socket *so, u_long cmd, caddr_t data, struct ifnet *ifp, struct thread *td); int pru_disconnect_notsupp(struct socket *so); -int pru_listen_notsupp(struct socket *so, int backlog, struct thread *td); +int pru_listen_notsupp(struct socket *so, struct solisten *sol, + int backlog, struct thread *td); int pru_peeraddr_notsupp(struct socket *so, struct sockaddr **nam); int pru_rcvd_notsupp(struct socket *so, int flags); int pru_rcvoob_notsupp(struct socket *so, struct mbuf *m, int flags); Index: sys/sys/socket.h =================================================================== --- sys/sys/socket.h (revision 312784) +++ sys/sys/socket.h (working copy) @@ -117,7 +117,9 @@ typedef __uintptr_t uintptr_t; * Option flags per-socket. */ #define SO_DEBUG 0x0001 /* turn on debugging info recording */ +#if 0 #define SO_ACCEPTCONN 0x0002 /* socket has had listen() */ +#endif #define SO_REUSEADDR 0x0004 /* allow local address reuse */ #define SO_KEEPALIVE 0x0008 /* keep connections alive */ #define SO_DONTROUTE 0x0010 /* just use interface addresses */ @@ -704,9 +706,5 @@ void so_sowwakeup(struct socket *so); void so_lock(struct socket *so); void so_unlock(struct socket *so); -void so_listeners_apply_all(struct socket *so, void (*func)(struct socket *, void *), void *arg); - -#endif - - +#endif /* _KERNEL */ #endif /* !_SYS_SOCKET_H_ */ Index: sys/sys/socketvar.h =================================================================== --- sys/sys/socketvar.h (revision 312784) +++ sys/sys/socketvar.h (working copy) @@ -58,6 +58,7 @@ struct vnet; typedef u_quad_t so_gen_t; struct socket; +struct solisten; /*- * Locking key to struct socket: @@ -64,7 +65,7 @@ struct socket; * (a) constant after allocation, no locking required. * (b) locked by SOCK_LOCK(so). * (c) locked by SOCKBUF_LOCK(&so->so_rcv). - * (e) locked by ACCEPT_LOCK(). + * (e) locked by SOLISTEN_LOCK() of corresponding listening socket. * (f) not locked since integer reads/writes are atomic. * (g) used only as a sleep/wakeup address, no value. * (h) locked by global mutex so_global_mtx. @@ -79,25 +80,8 @@ struct socket { void *so_pcb; /* protocol control block */ struct vnet *so_vnet; /* (a) network stack instance */ struct protosw *so_proto; /* (a) protocol handle */ -/* - * Variables for connection queuing. - * Socket where accepts occur is so_head in all subsidiary sockets. - * If so_head is 0, socket is not related to an accept. - * For head socket so_incomp queues partially completed connections, - * while so_comp is a queue of connections ready to be accepted. - * If a connection is aborted and it has so_head set, then - * it has to be pulled out of either so_incomp or so_comp. - * We allow connections to queue up based on current queue lengths - * and limit on number of queued connections for this socket. - */ - struct socket *so_head; /* (e) back pointer to listen socket */ - TAILQ_HEAD(, socket) so_incomp; /* (e) queue of partial unaccepted connections */ - TAILQ_HEAD(, socket) so_comp; /* (e) queue of complete unaccepted connections */ + struct solisten *so_listen; /* (e) back pointer to listen socket */ TAILQ_ENTRY(socket) so_list; /* (e) list of unaccepted connections */ - u_int so_qlen; /* (e) number of unaccepted connections */ - u_int so_incqlen; /* (e) number of unaccepted incomplete - connections */ - u_int so_qlimit; /* (e) max number queued connections */ short so_timeo; /* (g) connection timeout */ u_short so_error; /* (f) error affecting connection */ struct sigio *so_sigio; /* [sg] information for async I/O or @@ -112,11 +96,6 @@ struct socket { /* NB: generation count must not be first. */ so_gen_t so_gencnt; /* (h) generation count */ void *so_emuldata; /* (b) private data for emulators */ - struct so_accf { - struct accept_filter *so_accept_filter; - void *so_accept_filter_arg; /* saved filter args */ - char *so_accept_filter_str; /* saved user args */ - } *so_accf; struct osd osd; /* Object Specific extensions */ /* * so_fibnum, so_user_cookie and friends can be used to attach @@ -135,17 +114,64 @@ struct socket { }; /* - * Global accept mutex to serialize access to accept queues and - * fields associated with multiple sockets. This allows us to - * avoid defining a lock order between listen and accept sockets - * until such time as it proves to be a good idea. + * Structure for listening socket. + * Socket where accepts occur is so_listen in all subsidiary sockets. + * If so_listen is NULL, socket is not related to an accept. + * For head socket so_incomp queues partially completed connections, + * while so_comp is a queue of connections ready to be accepted. + * If a connection is aborted and it has so_listen set, then + * it has to be pulled out of either so_incomp or so_comp. + * We allow connections to queue up based on current queue lengths + * and limit on number of queued connections for this socket. */ -extern struct mtx accept_mtx; -#define ACCEPT_LOCK_ASSERT() mtx_assert(&accept_mtx, MA_OWNED) -#define ACCEPT_UNLOCK_ASSERT() mtx_assert(&accept_mtx, MA_NOTOWNED) -#define ACCEPT_LOCK() mtx_lock(&accept_mtx) -#define ACCEPT_UNLOCK() mtx_unlock(&accept_mtx) +TAILQ_HEAD(accept_queue, socket); +struct solisten { + /* + * Data inherited from 'struct socket' before listen(2) + * mutation, to be copied to our children sockets. + */ + short sol_type; + short sol_options; + short sol_linger; + short sol_state; + int sol_fibnum; + int sol_sbrcv_lowat; + int sol_sbsnd_lowat; + u_int sol_sbrcv_hiwat; + u_int sol_sbsnd_hiwat; + short sol_sbrcv_flags; + short sol_sbsnd_flags; + sbintime_t sol_sbrcv_timeo; + sbintime_t sol_sbsnd_timeo; + struct protosw *sol_proto; + struct vnet *sol_vnet; + struct ucred *sol_cred; + struct label *sol_label; + struct sigio *sol_sigio; + void *sol_pcb; + /* accept_filter(9) optional data */ + struct accept_filter *sol_accept_filter; + void *sol_accept_filter_arg; /* saved filter args */ + char *sol_accept_filter_str; /* saved user args */ + + /* Actual queue management. */ + struct mtx sol_mutex; + struct selinfo sol_selinfo; + u_int sol_qlen; /* (e) number of unaccepted connections */ + u_int sol_incqlen; /* (e) number of unaccepted incomplete + connections */ + u_int sol_qlimit; /* (e) max number queued connections */ + u_int sol_error; + /* (e) queue of partial unaccepted connections */ + struct accept_queue sol_incomp; + /* (e) queue of complete unaccepted connections */ + struct accept_queue sol_comp; +}; + +#define SOLISTEN_LOCK(sol) mtx_lock(&(sol)->sol_mutex) +#define SOLISTEN_UNLOCK(sol) mtx_unlock(&(sol)->sol_mutex) + /* * Per-socket mutex: we reuse the receive socket buffer mutex for space * efficiency. This decision should probably be revisited as we optimize @@ -212,8 +238,7 @@ struct xsocket { /* can we read something from so? */ #define soreadabledata(so) \ - (sbavail(&(so)->so_rcv) >= (so)->so_rcv.sb_lowat || \ - !TAILQ_EMPTY(&(so)->so_comp) || (so)->so_error) + (sbavail(&(so)->so_rcv) >= (so)->so_rcv.sb_lowat || (so)->so_error) #define soreadable(so) \ (soreadabledata(so) || ((so)->so_rcv.sb_state & SBS_CANTRCVMORE)) @@ -236,16 +261,13 @@ struct xsocket { } while (0) #define sorele(so) do { \ - ACCEPT_LOCK_ASSERT(); \ SOCK_LOCK_ASSERT(so); \ if ((so)->so_count <= 0) \ panic("sorele"); \ if (--(so)->so_count == 0) \ sofree(so); \ - else { \ + else \ SOCK_UNLOCK(so); \ - ACCEPT_UNLOCK(); \ - } \ } while (0) /* @@ -285,11 +307,11 @@ struct xsocket { struct accept_filter { char accf_name[16]; int (*accf_callback) - (struct socket *so, void *arg, int waitflag); + (struct socket *, void *, int); void * (*accf_create) - (struct socket *so, char *arg); + (struct solisten *, char *); void (*accf_destroy) - (struct socket *so); + (struct solisten *); SLIST_ENTRY(accept_filter) accf_next; }; @@ -296,6 +318,7 @@ struct accept_filter { #ifdef MALLOC_DECLARE MALLOC_DECLARE(M_ACCF); MALLOC_DECLARE(M_PCB); +MALLOC_DECLARE(M_SOLISTEN); MALLOC_DECLARE(M_SONAME); #endif @@ -344,7 +367,8 @@ struct uio; */ int getsockaddr(struct sockaddr **namp, caddr_t uaddr, size_t len); int getsock_cap(struct thread *td, int fd, cap_rights_t *rightsp, - struct file **fpp, u_int *fflagp, struct filecaps *havecaps); + struct file **fpp, u_int *fflagp, struct filecaps *havecaps, + short type); void soabort(struct socket *so); int soaccept(struct socket *so, struct sockaddr **nam); void soaio_enqueue(struct task *task); @@ -365,13 +389,8 @@ int sodisconnect(struct socket *so); struct sockaddr *sodupsockaddr(const struct sockaddr *sa, int mflags); void sofree(struct socket *so); void sohasoutofband(struct socket *so); -int solisten(struct socket *so, int backlog, struct thread *td); -void solisten_proto(struct socket *so, int backlog); -int solisten_proto_check(struct socket *so); -struct socket * - sonewconn(struct socket *head, int connstatus); - - +struct socket * sonewconn(struct solisten *, int); +struct socket * sopeeloff(struct socket *); int sopoll(struct socket *so, int events, struct ucred *active_cred, struct thread *td); int sopoll_generic(struct socket *so, int events, @@ -409,6 +428,17 @@ int selsocket(struct socket *so, int events, struc struct thread *td); /* + * Listening sockets. + */ +int solisten(struct socket *so, int backlog, struct thread *td, + struct file *fp); +int sollisten(struct solisten *so, int backlog, struct thread *td, + struct file *fp); +int solistenpoll(struct solisten *, int, struct ucred *a, struct thread *); +int solistenclose(struct solisten *); +void soltoxsocket(struct solisten *so, struct xsocket *xso); + +/* * Accept filter functions (duh). */ int accept_filt_add(struct accept_filter *filt); Index: sys/sys/sockopt.h =================================================================== --- sys/sys/sockopt.h (revision 312784) +++ sys/sys/sockopt.h (working copy) @@ -40,6 +40,7 @@ struct thread; struct socket; +struct solisten; /* * Argument structure for sosetopt et seq. This is in the KERNEL @@ -58,6 +59,8 @@ struct sockopt { int sosetopt(struct socket *so, struct sockopt *sopt); int sogetopt(struct socket *so, struct sockopt *sopt); +int solsetopt(struct solisten *so, struct sockopt *sopt); +int solgetopt(struct solisten *so, struct sockopt *sopt); int sooptcopyin(struct sockopt *sopt, void *buf, size_t len, size_t minlen); int sooptcopyout(struct sockopt *sopt, const void *buf, size_t len); /* XXX; prepare mbuf for (__FreeBSD__ < 3) routines. */ @@ -64,8 +67,8 @@ int sooptcopyout(struct sockopt *sopt, const void int soopt_getm(struct sockopt *sopt, struct mbuf **mp); int soopt_mcopyin(struct sockopt *sopt, struct mbuf *m); int soopt_mcopyout(struct sockopt *sopt, struct mbuf *m); -int do_getopt_accept_filter(struct socket *so, struct sockopt *sopt); -int do_setopt_accept_filter(struct socket *so, struct sockopt *sopt); +int accept_filt_getopt(struct solisten *, struct sockopt *); +int accept_filt_setopt(struct solisten *, struct sockopt *); int so_setsockopt(struct socket *so, int level, int optname, void *optval, size_t optlen); Index: sys/sys/unpcb.h =================================================================== --- sys/sys/unpcb.h (revision 312784) +++ sys/sys/unpcb.h (working copy) @@ -66,7 +66,10 @@ LIST_HEAD(unp_head, unpcb); struct unpcb { LIST_ENTRY(unpcb) unp_link; /* glue on list of all PCBs */ - struct socket *unp_socket; /* pointer back to socket */ + union { + struct socket *unp_socket; /* pointer back to socket */ + struct solisten *unp_listen; /* to listening socket */ + }; struct file *unp_file; /* back-pointer to file for gc. */ struct vnode *unp_vnode; /* if associated with file */ ino_t unp_ino; /* fake inode number */ @@ -93,13 +96,14 @@ struct unpcb { * to determine whether the contents should be sent to the user or * not. * - * UNP_HAVEPCCACHED - indicates that the unp_peercred member is filled - * in, but does *not* contain the credentials of the connected peer + * UNP_LISTENING - indicates that unp is listening, and unp_listen should + * be dereferenced instead of unp_socket. The unp_peercred member is + * filled in, but does *not* contain the credentials of the connected peer * (there may not even be a peer). This is set in unp_listen() when * it fills in unp_peercred for later consumption by unp_connect(). */ #define UNP_HAVEPC 0x001 -#define UNP_HAVEPCCACHED 0x002 +#define UNP_LISTENING 0x002 #define UNP_WANTCRED 0x004 /* credentials wanted */ #define UNP_CONNWAIT 0x008 /* connect blocks until accepted */ @@ -121,6 +125,7 @@ struct unpcb { #define UNPGC_IGNORE_RIGHTS 0x8 /* Attached rights are freed */ #define sotounpcb(so) ((struct unpcb *)((so)->so_pcb)) +#define soltounpcb(sol) ((struct unpcb *)((sol)->sol_pcb)) /* Hack alert -- this structure depends on . */ #ifdef _SYS_SOCKETVAR_H_ Index: sys/sys/vnode.h =================================================================== --- sys/sys/vnode.h (revision 312784) +++ sys/sys/vnode.h (working copy) @@ -112,14 +112,13 @@ struct vnode { /* * Type specific fields, only one applies to any given vnode. - * See #defines below for renaming to v_* namespace. */ union { - struct mount *vu_mount; /* v ptr to mountpoint (VDIR) */ - struct socket *vu_socket; /* v unix domain net (VSOCK) */ - struct cdev *vu_cdev; /* v device (VCHR, VBLK) */ - struct fifoinfo *vu_fifoinfo; /* v fifo (VFIFO) */ - } v_un; + struct mount *v_mountedhere; /* v ptr to mountpoint (VDIR) */ + struct unpcb *v_unpcb; /* v unix domain net (VSOCK) */ + struct cdev *v_rdev; /* v device (VCHR, VBLK) */ + struct fifoinfo *v_fifoinfo; /* v fifo (VFIFO) */ + }; /* * vfs_hash: (mount + inode) -> vnode hash. The hash value @@ -175,11 +174,6 @@ struct vnode { #endif /* defined(_KERNEL) || defined(_KVM_VNODE) */ -#define v_mountedhere v_un.vu_mount -#define v_socket v_un.vu_socket -#define v_rdev v_un.vu_cdev -#define v_fifoinfo v_un.vu_fifoinfo - #define bo2vnode(bo) __containerof((bo), struct vnode, v_bufobj) /* XXX: These are temporary to avoid a source sweep at this time */ @@ -200,7 +194,7 @@ struct xvnode { long xv_numoutput; /* num of writes in progress */ enum vtype xv_type; /* vnode type */ union { - void *xvu_socket; /* socket, if VSOCK */ + void *xvu_socket; /* unpcb, if VSOCK */ void *xvu_fifo; /* fifo, if VFIFO */ dev_t xvu_rdev; /* maj/min, if VBLK/VCHR */ struct { --/QKKmeG/X/bPShih-- From owner-freebsd-net@freebsd.org Fri Jan 27 01:41:25 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E10B7CC375D for ; Fri, 27 Jan 2017 01:41:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BF48E853 for ; Fri, 27 Jan 2017 01:41:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BE9ACCC375C; Fri, 27 Jan 2017 01:41:25 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE3C4CC3759 for ; Fri, 27 Jan 2017 01:41:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EF2E852; Fri, 27 Jan 2017 01:41:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x244.google.com with SMTP id f144so17492452pfa.2; Thu, 26 Jan 2017 17:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MMW0danuRY04yQzAfkO7vY/dZLErN7DGuEQJFGVCLTI=; b=G50230Z6Le/HlunfIon2+jOgkBBXFSnIFcJREJnXq1wl8JUWyhZAS5G5Ld4eB5CFOL O9Qqt67OXjv+UjLr6TaWM4TavhtU+6idsICuOPyr4DEp57vGIxtgVYOb0ylWxTI6BTiD KwI3LLGB3Tb25jQGzuRlWMErxS2s7BhBlUE8URYaCis8pK+LBTWbx2cHuJ/uPXNhYjf6 whm9Jhq2zIJ4BQ52/SLlB1GuA4EQqyHK2VDhPaHAgEeWiF6RYXYWTvfX8KCgHKGv6hU/ kNzFeKK0qf/VCBxnmfblBw9k/WTMaH7dEZuMZojRHDwzB9clzpU7lFPTtVZm+qCQLSDH l+ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=MMW0danuRY04yQzAfkO7vY/dZLErN7DGuEQJFGVCLTI=; b=TYhdoEclhNSfcyD6jMCOrP41mvA7v99yAVJRFtQydV/heUu9jH8S6dF99v6gBLWe7L 586ROeiHd2TvJLOIIzUWpgDrElWuzYgk+U6/vQvcvXm5zguv7wpPCPoEvOYLINdXgl2L cSchjRjl+EjB8MbYcZi7ts3C6XiUacyLBQyUOygBc3jdR/iBFmCmT0Q8mRWInrvv4FKk 6p0zvlmhehomjvwgsr7I8u2tL7/Nrhmkn3IkMuCo0OlAmrgOOqqTKPd3uCFrI6kXPaCI 5DWugwKvTHg/vXd0/6FjkkvP5VgS6oyho4UiKa+JrGs4xfPoKwLZ1ZvEGKFspG6gfaH8 Zq5A== X-Gm-Message-State: AIkVDXLQYJ6K5j5i28mlJrzfdnUi61jcuO8PMIjKTtL2dZs4ZGAxqRd8smnkJkRv+OtV6g== X-Received: by 10.84.216.24 with SMTP id m24mr8618575pli.22.1485481285026; Thu, 26 Jan 2017 17:41:25 -0800 (PST) Received: from raichu ([2604:4080:1102:0:ca60:ff:fe9d:3963]) by smtp.gmail.com with ESMTPSA id j185sm6132098pgd.35.2017.01.26.17.41.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 17:41:24 -0800 (PST) Sender: Mark Johnston Date: Thu, 26 Jan 2017 17:41:17 -0800 From: Mark Johnston To: Gleb Smirnoff Cc: jch@FreeBSD.org, hiren@FreeBSD.org, Jason Eggleston , rrs@FreeBSD.org, jtl@FreeBSD.org, net@FreeBSD.org Subject: Re: listening sockets as non sockets Message-ID: <20170127014117.GA90480@raichu> References: <20170127005251.GM2611@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170127005251.GM2611@FreeBSD.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 01:41:26 -0000 On Thu, Jan 26, 2017 at 04:52:51PM -0800, Gleb Smirnoff wrote: > Hi guys, > > as some of you already heard, I'm trying to separate listening sockets > into a new file descriptor type. If we look into current struct socket, > we see that some functional fields belong to normal data flow sockets, > and other belong to listening socket. They are never used simultaneously. > Now, if we look at socket API, we see that once a socket underwent transformation > to a listening socket, only 3 regular syscalls now may be called: listen(2), > accept(2) and close(2) and a subset of ioctl() and setsockopt() parameters is > accepted. A listening socket cannot be closed from the protocol side, only from > user side. So, listening socket is so different from a dataflow socket, that > separating them looks architecturally right thing to do. > > The benefits are: > > 1) Nicer code (I hope). > 2) Smaller 'struct socket'. > 3) Having two different locks for socket and solisten, we can try to get rid > of ACCEPT_LOCK global lock. > > The patch is in a very pre-alpha state. It has been run only in my bhyve VM. > > It passes regression tests from tools/regression/sockets and tests/sys, > including the race tests, and including accept filter ones. I haven't yet looked much at the diff, so sorry in advance if this question is inappropriate. One problem I've fought a couple of times (with Infiniband SDP and unix sockets) is a race between accept(2) and a concurrent close of the listening socket. Right now, this problem has to be handled in the domain-specific code (see r303855 for instance), and it's generally awkward to do so. Does your work address this intrinsic race in any way? FWIW, I have a basic test case for unix sockets here, though I believe it's been incorporated into stress2: https://people.freebsd.org/~markj/unix_socket_detach.c > > For TCP it passes basic functionality testing, but likely there are still races > remaining after ACCEPT_LOCK removal. > > For SCTP the patch is unfinished yet. The tricky thing with SCTP is that it > can un-listen a listening socket back to normal socket, doing listen(fd, 0) > on it. My patch has API for that I started working on SCTP, but temporarily > put this problem aside. It looks solvable, but I don't know yet how to test > it. Better first see results with TCP. > > I've put current snapshot to Phab, so that you can view it there. The snap > patch is also attached to this email. > > https://reviews.freebsd.org/D9356 > > At this moment I'd like to start doing some testing (and doing polishing > in parallel), and here I seek for your help. Those, who run FreeBSD at > very high connection rates and observe contention on the accept global > mutex, anybody willing to collaborate with me on this? From owner-freebsd-net@freebsd.org Fri Jan 27 02:43:40 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36064CC3680 for ; Fri, 27 Jan 2017 02:43:40 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 0C680182B for ; Fri, 27 Jan 2017 02:43:40 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 5637336A65; Fri, 27 Jan 2017 02:43:39 +0000 (UTC) Date: Fri, 27 Jan 2017 02:43:39 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiKs9s= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 02:43:40 -0000 c2VwaGVyb3NhX2dtYWlsLmNvbSBhY2NlcHRlZCB0aGlzIHJldmlzaW9uLgoKUkVWSVNJT04gREVU QUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q5MzQ1CgpFTUFJTCBQUkVGRVJFTkNF UwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9zZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZl cmVuY2VzLwoKVG86IGRlY3VpX21pY3Jvc29mdC5jb20sIGhzZWxhc2t5LCBjZW0sIG5wLCBrbWFj eSwga2liLCBob256aGFuX21pY3Jvc29mdC5jb20sIGhvd2FyZDBzdV9nbWFpbC5jb20sIGpoYiwg YWUsIGRlbHBoaWosIHJveWdlciwgZ25uLCByd2F0c29uLCBEYXZpZF9BX0JyaWdodF9ERUxMLmNv bSwgZ2xlYml1cywgc2VwaGVyb3NhX2dtYWlsLmNvbQpDYzogRGF2aWRfQV9CcmlnaHRfREVMTC5j b20sIGZyZWVic2QtbmV0LWxpc3QK From owner-freebsd-net@freebsd.org Fri Jan 27 04:16:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01482CC3F95 for ; Fri, 27 Jan 2017 04:16:00 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E0C541EFC for ; Fri, 27 Jan 2017 04:15:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E0296CC3F94; Fri, 27 Jan 2017 04:15:59 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFD01CC3F93 for ; Fri, 27 Jan 2017 04:15:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E3DA1EFB; Fri, 27 Jan 2017 04:15:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v0R4FvQ4032515 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Jan 2017 20:15:58 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v0R4FvYl032514; Thu, 26 Jan 2017 20:15:57 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 26 Jan 2017 20:15:57 -0800 From: Gleb Smirnoff To: Mark Johnston Cc: jch@FreeBSD.org, hiren@FreeBSD.org, Jason Eggleston , rrs@FreeBSD.org, jtl@FreeBSD.org, net@FreeBSD.org Subject: Re: listening sockets as non sockets Message-ID: <20170127041557.GN2611@FreeBSD.org> References: <20170127005251.GM2611@FreeBSD.org> <20170127014117.GA90480@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170127014117.GA90480@raichu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 04:16:00 -0000 On Thu, Jan 26, 2017 at 05:41:17PM -0800, Mark Johnston wrote: M> > It passes regression tests from tools/regression/sockets and tests/sys, M> > including the race tests, and including accept filter ones. M> M> I haven't yet looked much at the diff, so sorry in advance if this M> question is inappropriate. M> M> One problem I've fought a couple of times (with Infiniband SDP and unix M> sockets) is a race between accept(2) and a concurrent close of the M> listening socket. Right now, this problem has to be handled in the M> domain-specific code (see r303855 for instance), and it's generally M> awkward to do so. Does your work address this intrinsic race in any way? M> M> FWIW, I have a basic test case for unix sockets here, though I believe M> it's been incorporated into stress2: M> https://people.freebsd.org/~markj/unix_socket_detach.c This is strees2/misc/unix_socket_detach.sh, isn't it? My patch survived running it during night. I have also looked at r303855 and its code isn't touched by my patch. I will look further if the problem can be solved in general at socket layer. Thanks for point. -- Totus tuus, Glebius. From owner-freebsd-net@freebsd.org Fri Jan 27 06:10:38 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53D2CCC39E7 for ; Fri, 27 Jan 2017 06:10:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 305711D4 for ; Fri, 27 Jan 2017 06:10:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2CEA7CC39E6; Fri, 27 Jan 2017 06:10:38 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AD55CC39E5 for ; Fri, 27 Jan 2017 06:10:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCA451D3; Fri, 27 Jan 2017 06:10:37 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt0-x241.google.com with SMTP id h53so7425255qth.3; Thu, 26 Jan 2017 22:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Dz95wd4hbrU86nWPZIy1+sPyp5ZclYlMC76VNRZawjk=; b=HK9bT7lE+tJTQABwq8fcwM1doJVqGxW/9jk6c9UfvrwueaP57HcCT2HjvJzivVTWQi CkPBc2NqtUM0u2cEpTpt/NcThy/02uEEPRF54wSvx4f19luvJx8d5cl9BuRYFVqKNHnV sEY3nV58EODt6p3947TkBqsmj6wHx2wd+aK/gjLwClA9R8OFsCXI/wFwEAbplbvGReUE 3+jvFgXsj80CeeKwDWfHFlKPyHg9ZK9PIuaAs8r/h2cEt+iETzoKem2ab3+++U4hdrwR yFJkc1Jg54CmeVlVq8jpJVboIK8NP9T3rnJ+es+oPWhR3FU3TrjSMeumTUtlorPMaiaw WvYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Dz95wd4hbrU86nWPZIy1+sPyp5ZclYlMC76VNRZawjk=; b=i+F/gVugzjAe9PEmlFd39RvnKtLt0q8HaUdFPvKWkqXiMSgJevLhu1VumoiNIhGZXl RnDTHgX8EuFyYUHrfYHsDjfs0gTgRsdrzpx7fhfeC4xcg8cfTjJoqmfSMcXZn/ZoYQwd xRyTrFsbZNEO3WmBJ+vlRRkHXE2m3M7FPg0sfFv2AgCcAfKNV2TKhd0us0Ox/oVcatUO bqP+dhWGsj9nIZGkI5fGSmu6NcLMN6pZyez8RgKP/lOKv3wlA6B1SwFSs1p2rDsfYYfq ld7b/DU3ZO2eMuwsR5f1QQ8MB1Z8lEK0YtXlUVo2ePXBxyTNa5y04Hz7gA4/55kZ5QVM 6JwQ== X-Gm-Message-State: AIkVDXJh/MFP2uQNWc6VOsvDWT2I/kwQNufmbouIa/I0KQAxVgZDRHlE1++VK+P46DpErQ== X-Received: by 10.55.148.133 with SMTP id w127mr7114326qkd.217.1485497436434; Thu, 26 Jan 2017 22:10:36 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id h33sm3301156qtc.42.2017.01.26.22.10.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 22:10:35 -0800 (PST) Sender: Mark Johnston Date: Thu, 26 Jan 2017 22:16:13 -0800 From: Mark Johnston To: Gleb Smirnoff Cc: jch@FreeBSD.org, hiren@FreeBSD.org, Jason Eggleston , rrs@FreeBSD.org, jtl@FreeBSD.org, net@FreeBSD.org Subject: Re: listening sockets as non sockets Message-ID: <20170127061613.GA61354@wkstn-mjohnston.west.isilon.com> References: <20170127005251.GM2611@FreeBSD.org> <20170127014117.GA90480@raichu> <20170127041557.GN2611@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170127041557.GN2611@FreeBSD.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 06:10:38 -0000 On Thu, Jan 26, 2017 at 08:15:57PM -0800, Gleb Smirnoff wrote: > On Thu, Jan 26, 2017 at 05:41:17PM -0800, Mark Johnston wrote: > M> > It passes regression tests from tools/regression/sockets and tests/sys, > M> > including the race tests, and including accept filter ones. > M> > M> I haven't yet looked much at the diff, so sorry in advance if this > M> question is inappropriate. > M> > M> One problem I've fought a couple of times (with Infiniband SDP and unix > M> sockets) is a race between accept(2) and a concurrent close of the > M> listening socket. Right now, this problem has to be handled in the > M> domain-specific code (see r303855 for instance), and it's generally > M> awkward to do so. Does your work address this intrinsic race in any way? > M> > M> FWIW, I have a basic test case for unix sockets here, though I believe > M> it's been incorporated into stress2: > M> https://people.freebsd.org/~markj/unix_socket_detach.c > > This is strees2/misc/unix_socket_detach.sh, isn't it? Yep. unix_socket_detach2.sh too. > My patch survived > running it during night. I have also looked at r303855 and its code isn't > touched by my patch. I will look further if the problem can be solved > in general at socket layer. Thanks for point. Thanks for looking! From owner-freebsd-net@freebsd.org Fri Jan 27 07:36:41 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3AE0CC3C67 for ; Fri, 27 Jan 2017 07:36:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 87F968FA for ; Fri, 27 Jan 2017 07:36:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0R7ae0v065005 for ; Fri, 27 Jan 2017 07:36:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 183148] [patch] add getaddrinfo(1) tool from NetBSD Date: Fri, 27 Jan 2017 07:36:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 1.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: lohithbsd@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 07:36:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D183148 --- Comment #4 from Lohith Bellad --- Adopted the patch to FreeBSD. Made little change to getaddrinfo Makefile ba= sed on new LIBADD framework. getaddrinfo utility is working as expected on Free= BSD Head. Thanks, Lohith --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 27 07:49:01 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6ABDECC32E5 for ; Fri, 27 Jan 2017 07:49:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 59F3E11B for ; Fri, 27 Jan 2017 07:49:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0R7n1Lw096364 for ; Fri, 27 Jan 2017 07:49:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216460] 82599ES 10-Gigabit SFI/SFP+ Network Connection link constantly flaps Date: Fri, 27 Jan 2017 07:49:01 +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-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc cc assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 07:49:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216460 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|82599ES 10-Gigabit SFI/SFP+ |82599ES 10-Gigabit SFI/SFP+ |Network Connection link |Network Connection link |constantly falps |constantly flaps CC|freebsd-amd64@FreeBSD.org | Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Keywords| |IntelNetworking --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 27 12:35:36 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01C43CC1C22 for ; Fri, 27 Jan 2017 12:35:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 E4C7DFE3 for ; Fri, 27 Jan 2017 12:35:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0RCZZOH028021 for ; Fri, 27 Jan 2017 12:35:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 157182] [lagg] lagg interface not working together with epair interface on bridge Date: Fri, 27 Jan 2017 12:35:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: samm@os2.kiev.ua X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 12:35:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D157182 samm@os2.kiev.ua changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |samm@os2.kiev.ua --- Comment #2 from samm@os2.kiev.ua --- I just tested - bug is still present on 11-RELEASE --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 27 13:06:01 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A118ACC32F1 for ; Fri, 27 Jan 2017 13:06:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 90FE61BD0 for ; Fri, 27 Jan 2017 13:06:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0RD5wJl065530 for ; Fri, 27 Jan 2017 13:06:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 208205] re0 watchdog timeout Date: Fri, 27 Jan 2017 13:05:59 +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.3-BETA2 X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marc@marc-mach.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 13:06:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208205 Marc Mach changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc@marc-mach.de --- Comment #13 from Marc Mach --- Greetings! This issue seems to be not only FBSD 10 specific: Some other use= rs (including me) had an discussion @ FBSD Forum about this annoying problem. Please see https://forums.freebsd.org/threads/55861/ for more details In short: it seems that the built-in Driver for re0 nics has a bug. The workaround is to compile and use the latest version from realtek by compili= ng the re0 driver as an external module. I hope this helps you further. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 27 13:56:15 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95E08CC30F7 for ; Fri, 27 Jan 2017 13:56:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 858F2277 for ; Fri, 27 Jan 2017 13:56:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0RDuFDX092510 for ; Fri, 27 Jan 2017 13:56:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 183148] [patch] add getaddrinfo(1) tool from NetBSD Date: Fri, 27 Jan 2017 13:56:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 1.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vangyzen@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: vangyzen@FreeBSD.org 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: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 13:56:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D183148 Eric van Gyzen changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |vangyzen@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 27 14:26:59 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CB11CC3854 for ; Fri, 27 Jan 2017 14:26:59 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 46E7413A9 for ; Fri, 27 Jan 2017 14:26:59 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id A377936B36; Fri, 27 Jan 2017 14:26:58 +0000 (UTC) Date: Fri, 27 Jan 2017 14:26:58 +0000 To: freebsd-net@freebsd.org From: "David_A_Bright_DELL.com (David A. Bright)" Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiLWLI= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 14:26:59 -0000 RGF2aWRfQV9CcmlnaHRfREVMTC5jb20gYWNjZXB0ZWQgdGhpcyByZXZpc2lvbi4KClJFVklTSU9O IERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EOTM0NQoKRU1BSUwgUFJFRkVS RU5DRVMKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxw cmVmZXJlbmNlcy8KClRvOiBkZWN1aV9taWNyb3NvZnQuY29tLCBoc2VsYXNreSwgY2VtLCBucCwg a21hY3ksIGtpYiwgaG9uemhhbl9taWNyb3NvZnQuY29tLCBob3dhcmQwc3VfZ21haWwuY29tLCBq aGIsIGFlLCBkZWxwaGlqLCByb3lnZXIsIGdubiwgcndhdHNvbiwgZ2xlYml1cywgc2VwaGVyb3Nh X2dtYWlsLmNvbSwgRGF2aWRfQV9CcmlnaHRfREVMTC5jb20KQ2M6IERhdmlkX0FfQnJpZ2h0X0RF TEwuY29tLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Fri Jan 27 14:38:16 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8770BCC3B00 for ; Fri, 27 Jan 2017 14:38:16 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 642BB18E2 for ; Fri, 27 Jan 2017 14:38:16 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6384CCC3AFC; Fri, 27 Jan 2017 14:38:16 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63298CC3AFA for ; Fri, 27 Jan 2017 14:38:16 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE6C718E1; Fri, 27 Jan 2017 14:38:15 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mail-wm0-f67.google.com with SMTP id r144so58739330wme.0; Fri, 27 Jan 2017 06:38:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=WAqoe6+TVwx8XqspomZZNHU1KLKGD4gft28CCFJ9m2o=; b=E8bI++dc1Of9LVR8xnArB8xlhQLuE2iWdEsnG2OwK7tTVQIO4Uk7aB3I7uesO95i9x yrxsHyHjyS+2iPi3eBeRFSSvLdncMkRt90Dvy2eB/xrNxgFfJh2kQINAoQuC/OhVxoKj y2DMcsMsnJwOpFoGFxs2cVb93ekg7wlcvsdxs4lqMeN7wpltbzKaeEVDyQmK1bW+gJ9t 4ubOFxsf6oHkTCitaI4y1/nDzcSUgrXXXzJq/5skSXWijczfGKOoI+EUksUAXXUUGy1K 1nPVuaVlDWXzgqQKxGiJtT5NnYew65ArsM08ocMg5NvtG5IQFsTm6K9wB+ZA5v/tglbs pWCg== X-Gm-Message-State: AIkVDXLmS/hzKIOLwI1nAF1Eg7zfddPHBm3EQ+S5AqG/R+JY4BqxMGXk5a1ScwxXmdNfIw== X-Received: by 10.28.173.74 with SMTP id w71mr3237319wme.14.1485527887944; Fri, 27 Jan 2017 06:38:07 -0800 (PST) Received: from [10.100.64.12] ([217.30.88.44]) by smtp.gmail.com with ESMTPSA id 61sm8191614wrs.29.2017.01.27.06.38.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 06:38:06 -0800 (PST) Subject: Re: listening sockets as non sockets To: Gleb Smirnoff , hiren@FreeBSD.org, Jason Eggleston References: <20170127005251.GM2611@FreeBSD.org> Cc: jtl@FreeBSD.org, rrs@FreeBSD.org, net@FreeBSD.org From: Julien Charbon Message-ID: <84f9c348-1e65-1b94-37a6-a4c67d195709@freebsd.org> Date: Fri, 27 Jan 2017 15:37:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170127005251.GM2611@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mc4llJNOAcSIKKqbI6nk76vuCmWPKUGma" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 14:38:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mc4llJNOAcSIKKqbI6nk76vuCmWPKUGma Content-Type: multipart/mixed; boundary="Bia7XafaO9k9cIeGEGeH9sxqELVnt3SLP"; protected-headers="v1" From: Julien Charbon To: Gleb Smirnoff , hiren@FreeBSD.org, Jason Eggleston Cc: jtl@FreeBSD.org, rrs@FreeBSD.org, net@FreeBSD.org Message-ID: <84f9c348-1e65-1b94-37a6-a4c67d195709@freebsd.org> Subject: Re: listening sockets as non sockets References: <20170127005251.GM2611@FreeBSD.org> In-Reply-To: <20170127005251.GM2611@FreeBSD.org> --Bia7XafaO9k9cIeGEGeH9sxqELVnt3SLP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Gleb, On 1/27/17 1:52 AM, Gleb Smirnoff wrote: > as some of you already heard, I'm trying to separate listening socket= s > into a new file descriptor type. If we look into current struct socket,= > we see that some functional fields belong to normal data flow sockets, > and other belong to listening socket. They are never used simultaneousl= y. > Now, if we look at socket API, we see that once a socket underwent tran= sformation > to a listening socket, only 3 regular syscalls now may be called: liste= n(2), > accept(2) and close(2) and a subset of ioctl() and setsockopt() paramet= ers is > accepted. A listening socket cannot be closed from the protocol side, o= nly from > user side. So, listening socket is so different from a dataflow socket,= that > separating them looks architecturally right thing to do. >=20 > The benefits are: >=20 > 1) Nicer code (I hope). > 2) Smaller 'struct socket'. > 3) Having two different locks for socket and solisten, we can try to ge= t rid > of ACCEPT_LOCK global lock. >=20 > The patch is in a very pre-alpha state. It has been run only in my bhyv= e VM. >=20 > It passes regression tests from tools/regression/sockets and tests/sys,= > including the race tests, and including accept filter ones. >=20 > For TCP it passes basic functionality testing, but likely there are sti= ll races > remaining after ACCEPT_LOCK removal. > > I've put current snapshot to Phab, so that you can view it there. The s= nap > patch is also attached to this email. >=20 > https://reviews.freebsd.org/D9356 >=20 > At this moment I'd like to start doing some testing (and doing polishin= g > in parallel), and here I seek for your help. Those, who run FreeBSD at > very high connection rates and observe contention on the accept global > mutex, anybody willing to collaborate with me on this? Good idea, we are (obviously) interested by point #3 (Get rid of ACCEPT global lock) and its connection rate scalability improvement. I might be able to look at potential race conditions related to ACCEPT_LOCK and SO_ACCEPTFILTER usage (even if I am more used to INP_INFO lock), but I can certainly provide performance numbers and lock contention metrics using our setup. Do you think it is the right time to start performance testing with your change? Or it is a bit premature? -- Julien --Bia7XafaO9k9cIeGEGeH9sxqELVnt3SLP-- --mc4llJNOAcSIKKqbI6nk76vuCmWPKUGma Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYi1tLAAoJEKVlQ5Je6dhxK6cH/2pOgTzT9i1b1nvBbZi82p3D ashJsxwEk/2gLcpDNlwrUL7K7Y/qea0Ah//isO47ZHc3qdZOZm7t9D1mr/hmoS6e BJteTgYvvjhOiCradH8lB1LG6kNg+6vQsjsJ/AovepAonRrKnQl2dj6XgFpKDcHi jCqcBW768lIl3FaW/geVwtACXqAeHMIXvg5ikeVM3MtG22H1mTmumMG8GsGu6QYs zWxXdfL3CFAvyFArfUD+Gv2ng5sItCL3gDvo7KeolpHI0nwL297f4BmYkeuks773 4aAogg9Y3e5GkrxF1l56YA3EGg4mwOvLwhjb3OB0m4lW4R2B0Fx1jTFa76np/Ag= =1tCk -----END PGP SIGNATURE----- --mc4llJNOAcSIKKqbI6nk76vuCmWPKUGma-- From owner-freebsd-net@freebsd.org Fri Jan 27 15:05:30 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DCC9CC3844 for ; Fri, 27 Jan 2017 15:05:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 4DDC3228 for ; Fri, 27 Jan 2017 15:05:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0RF5QhF090409 for ; Fri, 27 Jan 2017 15:05:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 208205] re0 watchdog timeout Date: Fri, 27 Jan 2017 15:05:26 +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.3-BETA2 X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 15:05:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208205 --- Comment #14 from Sean Bruno --- (In reply to Marc Mach from comment #13) If someone could identify what is in the Realtek driver that is not in the FreeBSD base driver, I'm willing to commit it. The diff's are kind of ridiculous and may take a lot of sleuthing to figure out. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 27 15:10:35 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75D5ACC3947 for ; Fri, 27 Jan 2017 15:10:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 4BA013F1 for ; Fri, 27 Jan 2017 15:10:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0RFAYLX016064 for ; Fri, 27 Jan 2017 15:10:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204340] [panic] nfsd, em, msix, fatal trap 9 Date: Fri, 27 Jan 2017 15:10:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: IntelNetworking, crash, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rmacklem@FreeBSD.org X-Bugzilla-Flags: mfc-stable9- mfc-stable10+ X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 15:10:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204340 Andriy Gapon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |avg@FreeBSD.org --- Comment #17 from Andriy Gapon --- Rick, we got what looks like a very similar crash in FreeBSD 10.3: db_trace_self_wrapper+0x2a kdb_backtrace+0x37 vpanic+0xf7 panic+0x67 trap_fatal+0x264 trap_pfault+0x216 trap+0x32b calltrap+0x8 __mtx_lock_sleep+0xa2 xprt_active+0xe7 svc_vc_soupcall+0x25 sowakeup+0x69 tcp_do_segment+0x319e tcp_input+0x701 ip_input+0x14c netisr_dispatch_src+0x228 ether_demux+0x1a5 ether_nh_input+0x1fc netisr_dispatch_src+0x228 tcp_lro_flush+0x2b ixgbe_rxeof+0x30d ixgbe_msix_que+0x88 intr_event_execute_handlers+0x102 ithread_loop+0x9a fork_exit+0x11f fork_trampoline+0xe It's this lock: void=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 xprt_active(SVCXPRT *xprt)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 {=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 SVCGROUP *grp =3D xprt->xp_group;=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 mtx_lock(&grp->sg_lock); Do you have any suggestions? Thank you! --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 27 16:10:05 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1DA5CC478E for ; Fri, 27 Jan 2017 16:10:05 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DCA9C7E7 for ; Fri, 27 Jan 2017 16:10:05 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id D909DCC478D; Fri, 27 Jan 2017 16:10:05 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8A7CCC478C for ; Fri, 27 Jan 2017 16:10:05 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A34B7E6; Fri, 27 Jan 2017 16:10:05 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v0RGA15M036892 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Jan 2017 08:10:02 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v0RGA1NL036890; Fri, 27 Jan 2017 08:10:01 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 27 Jan 2017 08:10:01 -0800 From: Gleb Smirnoff To: Julien Charbon Cc: hiren@FreeBSD.org, Jason Eggleston , jtl@FreeBSD.org, rrs@FreeBSD.org, net@FreeBSD.org Subject: Re: listening sockets as non sockets Message-ID: <20170127161001.GP2611@FreeBSD.org> References: <20170127005251.GM2611@FreeBSD.org> <84f9c348-1e65-1b94-37a6-a4c67d195709@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84f9c348-1e65-1b94-37a6-a4c67d195709@freebsd.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 16:10:06 -0000 Hi Julien, On Fri, Jan 27, 2017 at 03:37:57PM +0100, Julien Charbon wrote: J> I might be able to look at potential race conditions related to J> ACCEPT_LOCK and SO_ACCEPTFILTER usage (even if I am more used to J> INP_INFO lock), but I can certainly provide performance numbers and lock J> contention metrics using our setup. J> J> Do you think it is the right time to start performance testing with J> your change? Or it is a bit premature? I don't know of any race or bug in the patch right now, but of course I won't recommend start testing it in production. If you have performance testing environment that is safe (non production) I'd appreciate if you start testing. -- Totus tuus, Glebius. From owner-freebsd-net@freebsd.org Fri Jan 27 17:46:16 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 914CECBF6F4 for ; Fri, 27 Jan 2017 17:46:16 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 631276E4; Fri, 27 Jan 2017 17:46:15 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-248-244.albq.qwest.net [67.0.248.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id C4B5A1928BA; Fri, 27 Jan 2017 17:46:08 +0000 (UTC) Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending To: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> Cc: "freebsd-net@freebsd.org" From: Sean Bruno Message-ID: Date: Fri, 27 Jan 2017 10:46:04 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JBPSXTMuAN4S0GGIIEmRSb9jLKW4DWmwc" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 17:46:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JBPSXTMuAN4S0GGIIEmRSb9jLKW4DWmwc Content-Type: multipart/mixed; boundary="6vxjMBqwSAcAE2JVGJLvr6BfJpsGX205F"; protected-headers="v1" From: Sean Bruno To: =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= Cc: "freebsd-net@freebsd.org" Message-ID: Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <1598d97bf2a.c6bcb76838987.6501340920645175463@nextbsd.org> <574a7ac7-4842-9518-8286-a4d89a9f7a27@freebsd.org> <6c6cb534-73c7-464b-8af1-7445a9c0188c@freebsd.org> <1598f29d379.ea6360351471.8752933472741761813@nextbsd.org> In-Reply-To: --6vxjMBqwSAcAE2JVGJLvr6BfJpsGX205F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/11/17 13:34, Olivier Cochard-Labb=C3=A9 wrote: >=20 > On Wed, Jan 11, 2017 at 9:13 PM, Matthew Macy > wrote: >=20 >=20 > > Hmmm ... did your old tests do 4 or 8 queues on this hardware? > > > > Did the old tests run 1024 tx/rx slots or the max 4096? >=20 > That's a great point, only having one thread per core could easily > account for this. I'm hoping Sean can make txq !=3D rxq work so tha= t > you can have 8txqs and 4 rxqs. >=20 >=20 > =E2=80=8BThe netgate RCC-VE 4860 is a 4 cores atom C2558E, and I'm usin= g 2 of > the 4 Gigabit Intel i350 ports. > Lab detail: > https://bsdrp.net/documentation/examples/forwarding_performance_lab_of_= a_netgate_rcc-ve_4860 >=20 > My tunning are (same for both test): > hw.igb.rxd=3D"2048" (it should be useless now) > hw.igb.txd=3D"2048" (it should be useless now) > hw.em.rxd=3D"2048" > hw.em.txd=3D"2048" > hw.igb.rx_process_limit=3D"-1" (It should be useless now too) > hw.em.rx_process_limit=3D"-1" >=20 > dev.igb.2.fc=3D0 > dev.igb.3.fc=3D0 >=20 > I can generate profiling data for you: what kind of data do you want ? Olivier: Matt has come up with some changes that seem to resolve a number of degenerate cases that I saw in my testing after dissecting your test case. In your spare time, can you try applying and testing the linked patch here to see if your results match my results? https://people.freebsd.org/~sbruno/iflib/iflib_update.diff sean --6vxjMBqwSAcAE2JVGJLvr6BfJpsGX205F-- --JBPSXTMuAN4S0GGIIEmRSb9jLKW4DWmwc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAliLh11fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y fmQHeggAtJMUiL65vzSVJiVqrQwkYOOeiaMTte+B27cvpRDnL7B8SPHqFguPgDSF 3OswtaGztpYRjSQ7UbmPUPRIju5ASEl/otz4vkTJYgYlU4JJFxvuAjc8+UNjB43J Kn0t9lK3S9k+uNpgdDZsMi1lTsfEfXqrYi+UsS6KWgxHIKT/mAEz4e3zsR8bYYS8 y6v9MHyekWqM8FuVoqGxqvUkm4uFCA5L1eQKgWdFN/xlysDBiECTMtQXRhuLz2A5 R0j9QhYpqoY5QnpaDFEiMWOX3N7Bp7pDXaWbISPtCGtFkh//VGXQ9rMj+Y9byRmH //qYGTQKa9bSB7oYwW/h2ebqvSyHAA== =4NHv -----END PGP SIGNATURE----- --JBPSXTMuAN4S0GGIIEmRSb9jLKW4DWmwc-- From owner-freebsd-net@freebsd.org Fri Jan 27 20:53:26 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BDE7CC4BA6 for ; Fri, 27 Jan 2017 20:53:26 +0000 (UTC) (envelope-from aelwelkxzbns@t-online.de) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FF7B8AF for ; Fri, 27 Jan 2017 20:53:25 +0000 (UTC) (envelope-from aelwelkxzbns@t-online.de) Received: from fwd24.aul.t-online.de (fwd24.aul.t-online.de [172.20.26.129]) by mailout11.t-online.de (Postfix) with SMTP id DFE6E424FAAD for ; Fri, 27 Jan 2017 21:53:22 +0100 (CET) Received: from spica01.aul.t-online.de (bRVZ4+ZfYhYFEu+9-MKSpUXrzPAzlnxvwehB0xMAPOmghqzrf4xAILNzyfdXjxSZTv@[172.20.102.138]) by fwd24.aul.t-online.de with esmtp id 1cXDWL-0lDBcO0; Fri, 27 Jan 2017 21:53:21 +0100 Received: from 188.235.13.89:10140 by cmpweb21.aul.t-online.de with HTTP/1.1 (Lisa V4-6-6-0.13826 on API V5-3-1-0) Received: from 172.20.102.120:29886 by spica01.aul.t-online.de:8080; Fri, 27 Jan 2017 21:53:21 +0100 (MET) Date: Fri, 27 Jan 2017 21:53:21 +0100 (MET) From: "aelwelkxzbns@t-online.de" Sender: "aelwelkxzbns@t-online.de" Reply-To: "aelwelkxzbns@t-online.de" To: "freebsd-net@freebsd.org" Message-ID: <1485550401270.3884158.52888f446b39bc9529608f57fb16ab93618042e2@spica.telekom.de> Subject: Customer MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Importance: normal X-MSMail-Priority: normal X-Priority: 3 X-UMS: email X-ID: bRVZ4+ZfYhYFEu+9-MKSpUXrzPAzlnxvwehB0xMAPOmghqzrf4xAILNzyfdXjxSZTv@t-dialin.net X-TOI-MSGID: 35278ef4-5a25-4fbe-ada5-b8952f158976 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jan 2017 20:53:26 -0000 Hello Customer ,=20 http://tinyurl.com/ht9o38t&page=3D3a8d4c5981d1cbb&gp=3Dridxdrb=20 =20 You can order any prescription quickly and easily from the comfort of your = home or office. We provide shipping guarantee to give you peace of mind.=EF=BB=BF ---------------------------------------------------------------- Gesendet mit Telekom Mail - kostenlos= und sicher f=C3=BCr alle! From owner-freebsd-net@freebsd.org Sat Jan 28 07:27:07 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A1B0CC5652 for ; Sat, 28 Jan 2017 07:27:07 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 4B31013CE for ; Sat, 28 Jan 2017 07:27:07 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 535C236B7B; Sat, 28 Jan 2017 07:27:06 +0000 (UTC) Date: Sat, 28 Jan 2017 07:27:06 +0000 To: freebsd-net@freebsd.org From: Phabricator Reply-to: D9345+325+c9b812d4eb678e67@reviews.freebsd.org Subject: [Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLAREs to net/if_var.h X-Herald-Rules: <81> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZDA2ODRkMmQ5ZDYyNDI1YzBkOWU5MzVkMmE4IFiMR8o= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_a2de316f377ac2794f5058898131cc60" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 07:27:07 -0000 --b1_a2de316f377ac2794f5058898131cc60 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 VGhpcyByZXZpc2lvbiB3YXMgYXV0b21hdGljYWxseSB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIGNv bW1pdHRlZCBjaGFuZ2VzLgpDbG9zZWQgYnkgY29tbWl0IHJTMzEyOTE2OiBpZm5ldDogbW92ZSB0 aGUgbmV3IGlmbmV0X2V2ZW50IEVWRU5USEFORExFUl9ERUNMQVJFIHRvIG5ldC9pZl92YXIuaCAo YXV0aG9yZWQgYnkgZGV4dWFuKS4KCkNIQU5HRUQgUFJJT1IgVE8gQ09NTUlUCiAgaHR0cHM6Ly9y ZXZpZXdzLmZyZWVic2Qub3JnL0Q5MzQ1P3ZzPTI0NDc5JmlkPTI0NTIyI3RvYwoKUkVQT1NJVE9S WQogIHJTIEZyZWVCU0Qgc3JjIHJlcG9zaXRvcnkKCkNIQU5HRVMgU0lOQ0UgTEFTVCBVUERBVEUK ICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDkzNDU/dnM9MjQ0NzkmaWQ9MjQ1MjIKClJF VklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EOTM0NQoKQUZGRUNU RUQgRklMRVMKICBoZWFkL3N5cy9uZXQvaWYuYwogIGhlYWQvc3lzL25ldC9pZl92YXIuaAogIGhl YWQvc3lzL3N5cy9ldmVudGhhbmRsZXIuaAoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jl dmlld3MuZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBk ZWN1aV9taWNyb3NvZnQuY29tLCBoc2VsYXNreSwgY2VtLCBucCwga21hY3ksIGtpYiwgaG9uemhh bl9taWNyb3NvZnQuY29tLCBob3dhcmQwc3VfZ21haWwuY29tLCBqaGIsIGFlLCBkZWxwaGlqLCBy b3lnZXIsIGdubiwgcndhdHNvbiwgZ2xlYml1cywgc2VwaGVyb3NhX2dtYWlsLmNvbSwgRGF2aWRf QV9CcmlnaHRfREVMTC5jb20KQ2M6IERhdmlkX0FfQnJpZ2h0X0RFTEwuY29tLCBmcmVlYnNkLW5l dC1saXN0Cg== --b1_a2de316f377ac2794f5058898131cc60 Content-Type: text/x-patch; charset=utf-8; name="D9345.24522.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D9345.24522.patch" ZGlmZiAtLWdpdCBhL2hlYWQvc3lzL3N5cy9ldmVudGhhbmRsZXIuaCBiL2hlYWQvc3lzL3N5cy9l dmVudGhhbmRsZXIuaAotLS0gYS9oZWFkL3N5cy9zeXMvZXZlbnRoYW5kbGVyLmgKKysrIGIvaGVh ZC9zeXMvc3lzL2V2ZW50aGFuZGxlci5oCkBAIC0yODQsMTEgKzI4NCw0IEBACiBFVkVOVEhBTkRM RVJfREVDTEFSRShzd2Fwb24sIHN3YXBvbl9mbik7CiBFVkVOVEhBTkRMRVJfREVDTEFSRShzd2Fw b2ZmLCBzd2Fwb2ZmX2ZuKTsKIAotLyogaWZ1cC9pZmRvd24gZXZlbnRzICovCi0jZGVmaW5lIElG TkVUX0VWRU5UX1VQCQkwCi0jZGVmaW5lIElGTkVUX0VWRU5UX0RPV04JMQotc3RydWN0IGlmbmV0 OwotdHlwZWRlZiB2b2lkICgqaWZuZXRfZXZlbnRfZm4pKHZvaWQgKiwgc3RydWN0IGlmbmV0ICpp ZnAsIGludCBldmVudCk7Ci1FVkVOVEhBTkRMRVJfREVDTEFSRShpZm5ldF9ldmVudCwgaWZuZXRf ZXZlbnRfZm4pOwotCiAjZW5kaWYgLyogX1NZU19FVkVOVEhBTkRMRVJfSF8gKi8KZGlmZiAtLWdp dCBhL2hlYWQvc3lzL25ldC9pZl92YXIuaCBiL2hlYWQvc3lzL25ldC9pZl92YXIuaAotLS0gYS9o ZWFkL3N5cy9uZXQvaWZfdmFyLmgKKysrIGIvaGVhZC9zeXMvbmV0L2lmX3Zhci5oCkBAIC00MDQs NiArNDA0LDExIEBACiAvKiBJbnRlcmZhY2UgbGluayBzdGF0ZSBjaGFuZ2UgZXZlbnQgKi8KIHR5 cGVkZWYgdm9pZCAoKmlmbmV0X2xpbmtfZXZlbnRfaGFuZGxlcl90KSh2b2lkICosIHN0cnVjdCBp Zm5ldCAqLCBpbnQpOwogRVZFTlRIQU5ETEVSX0RFQ0xBUkUoaWZuZXRfbGlua19ldmVudCwgaWZu ZXRfbGlua19ldmVudF9oYW5kbGVyX3QpOworLyogSW50ZXJmYWNlIHVwL2Rvd24gZXZlbnQgKi8K KyNkZWZpbmUgSUZORVRfRVZFTlRfVVAJCTAKKyNkZWZpbmUgSUZORVRfRVZFTlRfRE9XTgkxCit0 eXBlZGVmIHZvaWQgKCppZm5ldF9ldmVudF9mbikodm9pZCAqLCBzdHJ1Y3QgaWZuZXQgKmlmcCwg aW50IGV2ZW50KTsKK0VWRU5USEFORExFUl9ERUNMQVJFKGlmbmV0X2V2ZW50LCBpZm5ldF9ldmVu dF9mbik7CiAjZW5kaWYgLyogX1NZU19FVkVOVEhBTkRMRVJfSF8gKi8KIAogLyoKZGlmZiAtLWdp dCBhL2hlYWQvc3lzL25ldC9pZi5jIGIvaGVhZC9zeXMvbmV0L2lmLmMKLS0tIGEvaGVhZC9zeXMv bmV0L2lmLmMKKysrIGIvaGVhZC9zeXMvbmV0L2lmLmMKQEAgLTU5LDcgKzU5LDYgQEAKICNpbmNs dWRlIDxzeXMvZG9tYWluLmg+CiAjaW5jbHVkZSA8c3lzL2phaWwuaD4KICNpbmNsdWRlIDxzeXMv cHJpdi5oPgotI2luY2x1ZGUgPHN5cy9ldmVudGhhbmRsZXIuaD4KIAogI2luY2x1ZGUgPG1hY2hp bmUvc3RkYXJnLmg+CiAjaW5jbHVkZSA8dm0vdW1hLmg+Cgo= --b1_a2de316f377ac2794f5058898131cc60-- From owner-freebsd-net@freebsd.org Sat Jan 28 18:21:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B8BACC5DE3; Sat, 28 Jan 2017 18:21:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 D3F808E5; Sat, 28 Jan 2017 18:21:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cXXck-0009YM-7f; Sat, 28 Jan 2017 21:21:18 +0300 Date: Sat, 28 Jan 2017 21:21:18 +0300 From: Slawa Olhovchenkov To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: LACP: Fatal trap 18: integer divide fault while in kernel mode Message-ID: <20170128182118.GH58505@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 28 Jan 2017 18:21:27 -0000 I am got panic on recent stable: Fatal trap 18: integer divide fault while in kernel mode cpuid = 3; apic id = 06 instruction pointer = 0x20:0xffffffff81453230 stack pointer = 0x28:0xfffffe3e56f46480 frame pointer = 0x28:0xfffffe3e56f464a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock (3)) trap number = 18 panic: integer divide fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff8032b3eb = db_trace_self_wrapper+0x2b/frame 0xfffffe3e56f460c0 vpanic() at 0xffffffff804e33a6 = vpanic+0x186/frame 0xfffffe3e56f46140 panic() at 0xffffffff804e3213 = panic+0x43/frame 0xfffffe3e56f461a0 trap_fatal() at 0xffffffff807b07c2 = trap_fatal+0x322/frame 0xfffffe3e56f461f0 trap() at 0xffffffff807b0475 = trap+0x6b5/frame 0xfffffe3e56f463b0 calltrap() at 0xffffffff807946b1 = calltrap+0x8/frame 0xfffffe3e56f463b0 --- trap 0x12, rip = 0xffffffff81453230, rsp = 0xfffffe3e56f46480, rbp = 0xfffffe3e56f464a0 --- lacp_select_tx_port() at 0xffffffff81453230 = lacp_select_tx_port+0x70/frame 0xfffffe3e56f464a0 lagg_lacp_start() at 0xffffffff814504ae = lagg_lacp_start+0xe/frame 0xfffffe3e56f464c0 lagg_transmit() at 0xffffffff8144e73f = lagg_transmit+0xbf/frame 0xfffffe3e56f46530 ether_output() at 0xffffffff805f30bc = ether_output+0x71c/frame 0xfffffe3e56f465d0 ip_output() at 0xffffffff80629935 = ip_output+0x1585/frame 0xfffffe3e56f46720 tcp_output() at 0xffffffff806b9e16 = tcp_output+0x1876/frame 0xfffffe3e56f468c0 tcp_timer_rexmt() at 0xffffffff806c572f = tcp_timer_rexmt+0x4df/frame 0xfffffe3e56f46900 softclock_call_cc() at 0xffffffff804fd1b6 = softclock_call_cc+0x156/frame 0xfffffe3e56f469b0 softclock() at 0xffffffff804fd754 = softclock+0x94/frame 0xfffffe3e56f469e0 intr_event_execute_handlers() at 0xffffffff8049d15f = intr_event_execute_handlers+0x20f/frame 0xfffffe3e56f46a20 ithread_loop() at 0xffffffff8049d766 = ithread_loop+0xc6/frame 0xfffffe3e56f46a70 fork_exit() at 0xffffffff80499e25 = fork_exit+0x85/frame 0xfffffe3e56f46ab0 fork_trampoline() at 0xffffffff80794bee = fork_trampoline+0xe/frame 0xfffffe3e56f46ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- (kgdb) info line *0xffffffff81453230 Line 848 of "/usr/src/sys/modules/if_lagg/../../net/ieee8023ad_lacp.c" starts at address 0xffffffff8145322e and ends at 0xffffffff81453233 . Do I need to create PR? From owner-freebsd-net@freebsd.org Sat Jan 28 19:20:52 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8EFDCC621A; Sat, 28 Jan 2017 19:20:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9A7BBB9; Sat, 28 Jan 2017 19:20:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x230.google.com with SMTP id v200so35720076ywc.3; Sat, 28 Jan 2017 11:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tDe24Zp1+IeZN0I+xnz+v2hQx/zOM+DGcNjVjWzl0uI=; b=sPQfP6oH3Nh/AU8fnenOfK5uU4yLN6bLSP3zRUPK+eRGyMegvvzh8JfgrXxDwOKGrv SO9+3g4uyVwiFlK6p5aDuOwno2js9GUVUMDkhhX2vX5AHvkkbAgLaPhT836YGA8WT4Pi 0KItNe6+RCKl5EVjxs9GZDKNNWt4eJWKgEsrVbUGFBXR31s3UF6tT97alThTZBanb6zN DpA7rWnX5+dmUv4xioMXY0nF6XNzmbnOByzIewYyrL9ayWKUAW2JL/2YgBo07DOaqqDL MydS9XYIoIrh2wShuP94lckBPfo8s1U3lC3juQBTrbo7PrheKJ60+wJZE/WC3oSdQx4m X8Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tDe24Zp1+IeZN0I+xnz+v2hQx/zOM+DGcNjVjWzl0uI=; b=aDAmaIGR1xQlpdw6EqrkhIznmBv9m0Yq6dJpPyxcxjhFUPdrHL+TOBUYxiuhJqaSIG 6Q8MJBzB5NqpmSk/3OC9x7roGVNAUeyIDCMBx7Yvvg7C7LrBCI7sCmCo2PEQBBLGdW+k fyGVZxKMRMr0bRqSZ28evPX83gk9Jg24c2JHchkl0ASRL/aG6Ks/fpukHsw7yvN4vmSF rPL8NVyvwyf/tJghRFugzZoqSPGL+Rb7XEs20IBYBhEKYNFIETSIdKRXE04L5ySyGODf i1RYMqKkGLmF54P+s4HdKM2xvAqU0rsqnrRvXCErqeSkpjlk7R0YKKKItpO6e43BuUP9 tWXw== X-Gm-Message-State: AIkVDXLnYw5IJKmjmu7Uy+Oux2RkSJGD8P5hV7ql60FWg4IUyF2itpV2DGHvpggx5DRGiEf3xP44T2Z1oejyoQ== X-Received: by 10.13.230.135 with SMTP id p129mr9790080ywe.253.1485631251709; Sat, 28 Jan 2017 11:20:51 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Sat, 28 Jan 2017 11:20:51 -0800 (PST) In-Reply-To: <20170128182118.GH58505@zxy.spb.ru> References: <20170128182118.GH58505@zxy.spb.ru> From: Alan Somers Date: Sat, 28 Jan 2017 12:20:51 -0700 X-Google-Sender-Auth: XNL9emNSC1BVN9eImOCfHut4YpA Message-ID: Subject: Re: LACP: Fatal trap 18: integer divide fault while in kernel mode To: Slawa Olhovchenkov Cc: FreeBSD , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 28 Jan 2017 19:20:53 -0000 Please do open a PR and CC me. As well as the stack trace, post your lagg configuration, and, if you can determine it, the ports' state at the time of the crash. -Alan On Sat, Jan 28, 2017 at 11:21 AM, Slawa Olhovchenkov wrote: > I am got panic on recent stable: > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 3; apic id = 06 > instruction pointer = 0x20:0xffffffff81453230 > stack pointer = 0x28:0xfffffe3e56f46480 > frame pointer = 0x28:0xfffffe3e56f464a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi4: clock (3)) > trap number = 18 > panic: integer divide fault > cpuid = 3 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff8032b3eb = db_trace_self_wrapper+0x2b/frame 0xfffffe3e56f460c0 > vpanic() at 0xffffffff804e33a6 = vpanic+0x186/frame 0xfffffe3e56f46140 > panic() at 0xffffffff804e3213 = panic+0x43/frame 0xfffffe3e56f461a0 > trap_fatal() at 0xffffffff807b07c2 = trap_fatal+0x322/frame 0xfffffe3e56f461f0 > trap() at 0xffffffff807b0475 = trap+0x6b5/frame 0xfffffe3e56f463b0 > calltrap() at 0xffffffff807946b1 = calltrap+0x8/frame 0xfffffe3e56f463b0 > --- trap 0x12, rip = 0xffffffff81453230, rsp = 0xfffffe3e56f46480, rbp = 0xfffffe3e56f464a0 --- > lacp_select_tx_port() at 0xffffffff81453230 = lacp_select_tx_port+0x70/frame 0xfffffe3e56f464a0 > lagg_lacp_start() at 0xffffffff814504ae = lagg_lacp_start+0xe/frame 0xfffffe3e56f464c0 > lagg_transmit() at 0xffffffff8144e73f = lagg_transmit+0xbf/frame 0xfffffe3e56f46530 > ether_output() at 0xffffffff805f30bc = ether_output+0x71c/frame 0xfffffe3e56f465d0 > ip_output() at 0xffffffff80629935 = ip_output+0x1585/frame 0xfffffe3e56f46720 > tcp_output() at 0xffffffff806b9e16 = tcp_output+0x1876/frame 0xfffffe3e56f468c0 > tcp_timer_rexmt() at 0xffffffff806c572f = tcp_timer_rexmt+0x4df/frame 0xfffffe3e56f46900 > softclock_call_cc() at 0xffffffff804fd1b6 = softclock_call_cc+0x156/frame 0xfffffe3e56f469b0 > softclock() at 0xffffffff804fd754 = softclock+0x94/frame 0xfffffe3e56f469e0 > intr_event_execute_handlers() at 0xffffffff8049d15f = intr_event_execute_handlers+0x20f/frame 0xfffffe3e56f46a20 > ithread_loop() at 0xffffffff8049d766 = ithread_loop+0xc6/frame 0xfffffe3e56f46a70 > fork_exit() at 0xffffffff80499e25 = fork_exit+0x85/frame 0xfffffe3e56f46ab0 > fork_trampoline() at 0xffffffff80794bee = fork_trampoline+0xe/frame 0xfffffe3e56f46ab0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > (kgdb) info line *0xffffffff81453230 > Line 848 of "/usr/src/sys/modules/if_lagg/../../net/ieee8023ad_lacp.c" starts at address 0xffffffff8145322e and ends at 0xffffffff81453233 . > > Do I need to create PR? > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"