From owner-freebsd-net@freebsd.org Sun Dec 25 01:20:03 2016 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 B499BC854BC for ; Sun, 25 Dec 2016 01:20:03 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 8D71F78D for ; Sun, 25 Dec 2016 01:20:03 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:e8bc:6ee6:e320:5c16]) by elvis.mu.org (Postfix) with ESMTPSA id EE27D346DDDC; Sat, 24 Dec 2016 17:19:56 -0800 (PST) Subject: Re: question about fopen fd limit To: =?UTF-8?B?55ub5oWn5Y2O?= , Hongjiang Zhang , freebsd-net References: <2016122223570929089978@corp.netease.com> <2016122311014089280414@corp.netease.com> <2016122316484066524625@corp.netease.com> From: Alfred Perlstein Organization: FreeBSD Message-ID: Date: Sat, 24 Dec 2016 17:19:56 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <2016122316484066524625@corp.netease.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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, 25 Dec 2016 01:20:03 -0000 Hello 盛慧华 Here's another trick that may work. Use funopen(3) and provide your own read/write/seek and close functions for the high fds. You can basically make "cookie" a struct that contains your "int sized" fds. FILE * funopen(const void *cookie, int (*readfn)(void *, char *, int), int (*writefn)(void *, const char *, int), fpos_t (*seekfn)(void *, fpos_t, int), int (*closefn)(void *)); If you need more help please make sure to email me directly so I can see your question. -Alfred On 12/23/16 12:48 AM, 盛慧华 wrote: > hi all, > > Thank you for your advice ~ > solution 2 definitly broaden my horizons ~~but may be not a good choice for my project ~~LoL > i will try to mail freebsd-current mail list, if libc is as your description , may be i should modify it by myself ~~ > Thank you so much~ > Are u KingSoft's Dr Zhang ? nice to meet you !!!!! > > winson sheng > > > > winson sheng > > From: Hongjiang Zhang > Date: 2016-12-23 11:44 > To: 盛慧华; freebsd-net > Subject: RE: RE: question about fopen fd limit > Ok. I know. > There are two possible solutions: > Quick solution for short term: modify short to int in libc by yourself, buildworld and installworld. Pushing to modify libc may take a long time, especially only few people encounter this issue. You’d better send email to freebsd-current to confirm whether they accept your suggestion. > Work around: You can first reserve a series of fd before opening TCP connections. For example, invoke open(“/dev/null”) for 10000 times to get 10000 fds. Those fd values are small enough to be held by “short”. After that, start TCP connections. Once you need to fopen a file, please call open(“xxx”) instead, and then use dup2(old_fd, new_fd) to exchange the two fd. The old_fd value is the one obtained by open(“xxx”), and new_fd is one in your reserved fd fields, and next please use fdopen(fd, mode). Here, you have to manage the reserved fds by yourself including open/close. > > In my eyes: > is the quick method, and there is no modifications in your logic. > Needs you to maintain the reserved consecutive fields for fd by yourself, which increased the complexity of your logic. > > Thanks > Hongjiang Zhang > > From: 盛慧华 [mailto:hhsheng@corp.netease.com] > Sent: Friday, December 23, 2016 11:02 AM > To: Hongjiang Zhang ; freebsd-net > Subject: Re: RE: question about fopen fd limit > > hi all, > > not map TCP to FILE, you misunderstanding my meaning~ > > for example, if my server tcp already holds 32000 connection > fopen only has 767 fd to use > > the problem has no bussiness with tcp fd, BUT fopen ... > > in some particular situlations , my server will open 1k+ FILE , that will exceed the fileno limit, and overflow occur > my server can't open any file more ,that's the problem ~ > > so i felt if bsd official could change FILE struct's fileno to a UNSIGNED SHORT that may be an effecient and convenient solution just for my case ? > UNSIGNED SHORT fileno is enough for me, and i don't wanna change a lot of FILE function that take FILE * as its argument ~ > > Thank you ~~~ > > winson sheng > > > > > winson sheng > > From: Hongjiang Zhang > Date: 2016-12-23 10:17 > To: 盛慧华; freebsd-net > Subject: RE: question about fopen fd limit > Why do you need to map TCP fd to FILE? > > It is difficult to modify FILE structure. If it is possible, let us figure out some new designs to meet your requirement. > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of ??? > Sent: Thursday, December 22, 2016 11:57 PM > To: freebsd-net > Subject: question about fopen fd limit > > hi all, > > hi~ > we are from Chinese Game Develop Corp, Netease. > and One of our product using FreeBsd as its OS platform. > This Game has Millions of players online , and Each Server may holds 25000+ tcp connection at the same time.Thanks to BSD and kqueue :) > > for example, it's one of our server , netstat cmd to list connections overall... > netstat -an | grep 13396 (it's our listening port) | wc -l > 23221 > > recently we do some performance optimize and promote this connect limit to 28000+ or 30000+. > But we find Freebsd has a limit that this huge online number will take 28000+ fd, and bsd FILE * struct's > fd only support to SHORT . such as .. > > struct __sFILE { > ... > short _file; /* (*) fileno, if Unix descriptor, else -1 */ ... > > so if our server want to fopen some file when we still hold this online number, the fd amount may easily exceed 32767, and fopen definitely return a err code. then the server will appear some fataly ERROR. > > we do a simple test and confirm this situation. > > then in fopen's code , we notice that we can use open to return a fd instread of fopen to avoid this overflow, > as below > > 68 /* > 1 * File descriptors are a full int, but _file is only a short. > 2 * If we get a valid file descriptor that is greater than > 3 * SHRT_MAX, then the fd will get sign-extended into an > 4 * invalid file descriptor. Handle this case by failing the > 5 * open. > 6 */ > > > BUT ... so many c lib FILE series function needs a FILE * pointer as input argument, we can't convert all of them to fd, or it will be a rather suffering things to us. > > and even in BSD 10 , it seems this short limit still there , but other OS as debian , FILE strucnt's fileno is a int . > > we found an unoffical patch easily change this fileno to unsigned , but we are a very stready project, we can't afford the risk to use an unoffical patch. > > so, do you have any plan to change this fopen fd limit to UNSIGNED SHORT or int in the future ? ushort is enough for us . > if you do , we are really glad and excited~~~~~~~if you don't ,it donen't matter, plz give us a reply so that we may need to > find some other plan to resolved this suffering thing. > LoL, thank you !!!!! > > yours sincerely > winson sheng > > > winson sheng > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freebsd.org%2Fmailman%2Flistinfo%2Ffreebsd-net&data=02%7C01%7Chonzhan%40microsoft.com%7C4a9dfccbccd446be2f4a08d42a833fb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636180190584478890&sdata=PAwJP5IXHy0WJwxbV7MB%2B8zvKheZUYjhHx3ohFRSPZM%3D&reserved=0 > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > 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 Sun Dec 25 08:30:19 2016 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 2BE47C90D8C for ; Sun, 25 Dec 2016 08:30:19 +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 1BEA81BBE for ; Sun, 25 Dec 2016 08:30:19 +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 uBP8UIZI038604 for ; Sun, 25 Dec 2016 08:30:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215513] panic: SACK scoreboard must not be empty Date: Sun, 25 Dec 2016 08:30:19 +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 Only Me X-Bugzilla-Who: pho@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, 25 Dec 2016 08:30:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215513 --- Comment #3 from Peter Holm --- (In reply to Hiren Panchasara from comment #1) Sure: OK set hw.physmem=3D6g : $ svnlite checkout -q svn://svn.freebsd.org/base/user/pho/stress2 $ cd stress2 $ make > /dev/null $ echo "testuser=3Dstress" > `hostname` $ cd misc $ ./all.sh full.sh Details @ https://people.freebsd.org/~pho/stress/log/full-2.txt --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 25 08:39:30 2016 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 834ECC8E055 for ; Sun, 25 Dec 2016 08:39: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 72ED9109 for ; Sun, 25 Dec 2016 08:39: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 uBP8dU37060249 for ; Sun, 25 Dec 2016 08:39:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215513] panic: SACK scoreboard must not be empty Date: Sun, 25 Dec 2016 08:39:30 +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 Only Me X-Bugzilla-Who: pho@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, 25 Dec 2016 08:39:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215513 --- Comment #4 from Peter Holm --- (In reply to Michael Tuexen from comment #2) Michael, the panic is very easy to reproduce on my hardware. What do I need= to do? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 25 09:31:49 2016 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 85A5DC8F6BC for ; Sun, 25 Dec 2016 09:31:49 +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 7576D1DC0 for ; Sun, 25 Dec 2016 09:31:49 +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 uBP9VnfK015027 for ; Sun, 25 Dec 2016 09:31:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215513] panic: SACK scoreboard must not be empty Date: Sun, 25 Dec 2016 09:31:49 +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 Only Me X-Bugzilla-Who: tuexen@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, 25 Dec 2016 09:31:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215513 --- Comment #5 from Michael Tuexen --- By looking at your Details, your system is low on memory when the problem occurs. Can you just remove the KASSERT http://fxr.watson.org/fxr/source/netinet/tcp_sack.c#L474 and retest? I think if tcp_sackhole_insert in http://fxr.watson.org/fxr/source/netinet/tcp_sack.c#L446 returns NULL due to memory shortage, you run into the KASSERT. Best regards Michael --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 25 10:50:08 2016 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 D94B2C90A1B for ; Sun, 25 Dec 2016 10:50:08 +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 C966AA9 for ; Sun, 25 Dec 2016 10:50:08 +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 uBPAo8jm088776 for ; Sun, 25 Dec 2016 10:50:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215513] panic: SACK scoreboard must not be empty Date: Sun, 25 Dec 2016 10:50:09 +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 Only Me X-Bugzilla-Who: pho@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, 25 Dec 2016 10:50:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215513 --- Comment #6 from Peter Holm --- (In reply to Michael Tuexen from comment #5) Looks promising. I'll let the test run a bit longer, just to be sure. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 25 14:05:09 2016 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 B739EC8F81F for ; Sun, 25 Dec 2016 14:05:09 +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 9FF8CDC7 for ; Sun, 25 Dec 2016 14:05:09 +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 uBPE59VX090232 for ; Sun, 25 Dec 2016 14:05:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215513] panic: SACK scoreboard must not be empty Date: Sun, 25 Dec 2016 14:05:09 +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 Only Me X-Bugzilla-Who: pho@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, 25 Dec 2016 14:05:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215513 --- Comment #7 from Peter Holm --- (In reply to Peter Holm from comment #6) No problems seen in four hours. LGTM. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 25 14:38:28 2016 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 E78ECC907A4 for ; Sun, 25 Dec 2016 14:38:28 +0000 (UTC) (envelope-from jdison16@yahoo.com) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F70F6A6 for ; Sun, 25 Dec 2016 14:38:28 +0000 (UTC) (envelope-from jdison16@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1482676706; bh=UhgRccKpLTa/jO01Ir/HKpLbOinyujOvL9OU2QvorkI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=SQV0Z5oeF7y4ycuW0acnea7WIq/Xg08ZWfQzJj5D0fqS0UtDfKYFjD7UFvEyv1EAFy9neGM6RuNLNl4S7XbaLG84EpHDClSt7ek29cvX/mKctWFBvUGpLiuqFDCOnAdbrX1exk55lpGm9n56XOcOGst7Lb57Pu8CpFxEuyK4Jzqw6Ny6akSsshJ96xxle+LJSHSYqrL6xAzICZstAYwgWcMiQNG3NvtvzywIdGiQo+s21F3TWO3L8EmMXVAGHuzs/pAWGYVKS4to/tEgwEb0QPu2Lxja2PIeMChiKuXZmc8+dQQljCGQLfQJHZAdfr7A4rSV2XrecfCKmVpGWLQR7A== Received: from [98.139.215.142] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2016 14:38:26 -0000 Received: from [98.139.212.199] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2016 14:38:26 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 25 Dec 2016 14:38:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 559944.66041.bm@omp1008.mail.bf1.yahoo.com X-YMail-OSG: 1rUoVQwVM1lvNDl_gps97wz7RSFs9iBuVGmMs3h8U28SzpXJgnzhmIcHHA805FW nBAjgt_ZUpd4NDpYJwcMSoIYI1xKyZBE53ugvDXkOOfB9T1LQG0cpcis77F0Jmje1lictR7BomIg SqYQtBjmyLOCTRgAZPHDFwKbFCluvLQ627ZxgmPOAgdnj50FUWLvXU7O17aLvOuct4l6cd_6m8x_ niSvbcDxzH4WCFvE6xl4aqe6xnZ40E0qqztBI2zA0c.3pK.E2QuV66XXrNwFmhryFOGemCjPkS_2 27LCJz4sZvI0NRw5eIX548_oPfketDOOqZ149.AKgp10Gls8FC8PlZ9QUJGszAazl2s60RB3wH9r t1RpEhzxFNyTxB6Y5KaO8TurX2fHMyYTT.piyCsgpmDsklVrIcUNCB23jGEMJE.8Os._0mJs4ynw V1JQ8GbrzbTgbsXFwr16aLALc4e_cXE2pFLFr6sjzn.K8XQO8fcUOXbDtmJYXSjMgBMe2EOKFU2I- Received: from jws400081.mail.bf2.yahoo.com by sendmailws140.mail.bf1.yahoo.com; Sun, 25 Dec 2016 14:38:26 +0000; 1482676706.136 Date: Sun, 25 Dec 2016 14:38:25 +0000 (UTC) From: John Dison Reply-To: John Dison To: "freebsd-net@freebsd.org" Cc: "hrs@FreeBSD.org" Message-ID: <788296467.1718144.1482676705910@mail.yahoo.com> In-Reply-To: <1821478968.1639587.1482657592713@mail.yahoo.com> References: <20161224.205457.537205546150309741.hrs@allbsd.org> <31938292.1421737.1482589536048@mail.yahoo.com> <252311393.1502179.1482604113540@mail.yahoo.com> <20161225.065934.1192800130496756773.hrs@allbsd.org> <1821478968.1639587.1482657592713@mail.yahoo.com> Subject: Fw: How to configure another loopback device? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 25 Dec 2016 14:38:29 -0000 jd> > Does adding ifconfig_lo0="inet 127.0.0.1/8" to /etc/rc.conf work? jd> jd> Yes, adding ifconfig_lo0="inet 127.0.0.1/8" helps indeed. jd> jd> Interesting is that if I also add ifconfig_lo0_ipv6="inet6 ::1/128" jd> then ::1/128 will be on lo1. If I do not add that line, it will be on lo0. jd> jd> Looks weird but that workaround work. Thanks. > Here are the reasons: > > - 127.0.0.1/8 will be configured on lo0 in rc.d scripts if > ifconfig_lo0 is missing after processing ifconfig_IF and before > doing ifconfig_IF_alias*. > > - You cannot manually configure ::1/128 because it is configured by > the kernel when a loopback interface becomes "up". If you have an > ifconfig_lo1 and no ifconfig_lo0, ifconfig_lo1 will be processed > and make lo1 "up" first. Okay, I see. Thanks for the explanation. Also one more thing which looks strange: if I use ifconfig_lo1_ipv6="inet6 auto_linklocal", then ipv6 aliases on lo1 are configured correctly, but there is no link-local address. If I exclude this line from rc.conf, then no ipv6 aliases are configured at all (only ipv4). From owner-freebsd-net@freebsd.org Sun Dec 25 17:24:38 2016 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 6ADE4C904CE for ; Sun, 25 Dec 2016 17:24:38 +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 5AC95878 for ; Sun, 25 Dec 2016 17:24:38 +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 uBPHOcXG082731 for ; Sun, 25 Dec 2016 17:24:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215513] panic: SACK scoreboard must not be empty Date: Sun, 25 Dec 2016 17:24:38 +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 Only Me X-Bugzilla-Who: tuexen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tuexen@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: Sun, 25 Dec 2016 17:24:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215513 Michael Tuexen changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |tuexen@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 25 17:51:42 2016 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 26B04C90DD4 for ; Sun, 25 Dec 2016 17:51:42 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2A641AFD for ; Sun, 25 Dec 2016 17:51:41 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org (p2027-ipbf1605funabasi.chiba.ocn.ne.jp [123.225.191.27]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id uBPHpIAk008033 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Mon, 26 Dec 2016 02:51:38 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org (alph.allbsd.org [192.168.0.10]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id uBPHo3XW020057 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Dec 2016 02:50:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id uBPHo3gs020054; Mon, 26 Dec 2016 02:50:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 26 Dec 2016 02:45:52 +0900 (JST) Message-Id: <20161226.024552.1280870399257773844.hrs@allbsd.org> To: jdison16@yahoo.com Cc: freebsd-net@freebsd.org Subject: Re: How to configure another loopback device? From: Hiroki Sato In-Reply-To: <788296467.1718144.1482676705910@mail.yahoo.com> References: <20161225.065934.1192800130496756773.hrs@allbsd.org> <1821478968.1639587.1482657592713@mail.yahoo.com> <788296467.1718144.1482676705910@mail.yahoo.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Dec_26_02_45_52_2016_750)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [133.31.130.32]); Mon, 26 Dec 2016 02:51:39 +0900 (JST) X-Spam-Status: No, score=-99.9 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org 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, 25 Dec 2016 17:51:42 -0000 ----Security_Multipart(Mon_Dec_26_02_45_52_2016_750)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Dison wrote in <788296467.1718144.1482676705910@mail.yahoo.com>: jd> Also one more thing which looks strange: if I use jd> ifconfig_lo1_ipv6="inet6 auto_linklocal", then ipv6 aliases on lo1 are jd> configured correctly, but there is no link-local address. If I jd> exclude this line from rc.conf, then no ipv6 aliases are configured at jd> all (only ipv4). auto_linklocal does not work on the second loopback interface because multiple loopback interface support for IPv6 is incomplete at this moment. You need to add fe80::1%lo1 (or similar) manually if you want an LLA. The ifconfig_IF_ipv6 line determines whether the interface uses IPv6 or not. So if you drop it, all of inet6 configuration such as ifconfig_IF_aliasN="inet6..." will be ignored. -- Hiroki ----Security_Multipart(Mon_Dec_26_02_45_52_2016_750)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlhgBdAACgkQTyzT2CeTzy1o4wCfRMumL3I2Mq42/e+Cxk8qgaJG xm0An3Y6RtcCgJMNSXE4Nl/Rx3Q99n9N =kLO9 -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Dec_26_02_45_52_2016_750)---- From owner-freebsd-net@freebsd.org Sun Dec 25 21:00:24 2016 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 7ED31C90C1F for ; Sun, 25 Dec 2016 21:00:24 +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 713F81F83 for ; Sun, 25 Dec 2016 21:00:24 +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 uBPL01ls000583 for ; Sun, 25 Dec 2016 21:00:24 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201612252100.uBPL01ls000583@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, 25 Dec 2016 21:00:24 +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, 25 Dec 2016 21:00:24 -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 | 206053 | kqueue support code of netmap causes panic New | 213410 | [carp] service netif restart causes hang only whe 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 | 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 16 problems total for which you should take action. From owner-freebsd-net@freebsd.org Mon Dec 26 03:28:47 2016 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 B004CC90C14 for ; Mon, 26 Dec 2016 03:28:47 +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 876A1C94 for ; Mon, 26 Dec 2016 03:28:47 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id E7C8716C83; Mon, 26 Dec 2016 03:28:46 +0000 (UTC) Date: Mon, 26 Dec 2016 03:28:46 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D8904+325+7336aa65c010aea9@reviews.freebsd.org Subject: [Differential] D8904: inet: Fix routing issue by calling if_up() 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: D8904: inet: Fix routing issue by calling if_up() 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-Cc: Precedence: bulk Thread-Index: ZjczN2EyNTY0YWQ0YjU5MTFiOTVmNTcwYjRk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_95b4e9613d858d57bb5877c475faaff0" 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, 26 Dec 2016 03:28:47 -0000 --b1_95b4e9613d858d57bb5877c475faaff0 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 c2VwaGVyb3NhX2dtYWlsLmNvbSBjcmVhdGVkIHRoaXMgcmV2aXNpb24uCnNlcGhlcm9zYV9nbWFp bC5jb20gYWRkZWQgcmV2aWV3ZXJzOiBkZWxwaGlqLCByb3lnZXIsIGRlY3VpX21pY3Jvc29mdC5j b20sIGhvbnpoYW5fbWljcm9zb2Z0LmNvbSwgaG93YXJkMHN1X2dtYWlsLmNvbSwgYWRyaWFuLCBi eiwgZ25uLCBoaXJlbiwgZ2xlYml1cywgcndhdHNvbiwga2FyZWxzLgpzZXBoZXJvc2FfZ21haWwu Y29tIGFkZGVkIGEgc3Vic2NyaWJlcjogZnJlZWJzZC1uZXQtbGlzdC4KClJFVklTSU9OIFNVTU1B UlkKICAgIFRoaXMgaXMgbWFpbmx5IGludGVuZGVkIHRvIGZpeCB0aGUgZm9sbG93aW5nIGNhc2Ug YXQgbGVhc3Q6CiAgICAKICAgIGlmY29uZmlnIGlmYWNlMCAxOTIuMTY4LjUuMQogICAgaWZjb25m aWcgaWZhY2UwIGRvd24KICAgIGlmY29uZmlnIGlmYWNlMCBhbGlhcyAxOTIuMTY4LjYuMQogICAg CiAgICBCZWZvcmUgdGhpcyBjb21taXQsIHRoZSByZWxhdGVkIHBhcnQgb2YgdGhlIHJvdXRpbmcg dGFibGUgaXM6CiAgICAxOTIuMTY4LjUuMSAgICAgICAgbGluayMzICAgICAgICAgICAgIFVIUyAg ICAgICAgIGxvMAogICAgMTkyLjE2OC42LjAvMjQgICAgIGxpbmsjMyAgICAgICAgICAgICBVICAg ICAgICAgICBobjEKICAgIDE5Mi4xNjguNi4xICAgICAgICBsaW5rIzMgICAgICAgICAgICAgVUhT ICAgICAgICAgbG8wCiAgICAKICAgIFRoZSAxOTIuMTY4LjUuMC8yNCBjYW4ndCBiZSByZWFjaGVk LgogICAgCiAgICBBZnRlciB0aGlzIGZpeCwgdGhlIHJlbGF0ZWQgcGFydCBvZiB0aGUgcm91dGlu ZyB0YWJsZSBpczoKICAgIDE5Mi4xNjguNS4wLzI0ICAgICBsaW5rIzMgICAgICAgICAgICAgVSAg ICAgICAgICAgaG4xCiAgICAxOTIuMTY4LjUuMSAgICAgICAgbGluayMzICAgICAgICAgICAgIFVI UyAgICAgICAgIGxvMAogICAgMTkyLjE2OC42LjAvMjQgICAgIGxpbmsjMyAgICAgICAgICAgICBV ICAgICAgICAgICBobjEKICAgIDE5Mi4xNjguNi4xICAgICAgICBsaW5rIzMgICAgICAgICAgICAg VUhTICAgICAgICAgbG8wCiAgICAKICAgIEV2ZXJ5dGhpbmcgd29ya3MgYXMgZXhwZWN0ZWQuCgpS RVZJU0lPTiBERVRBSUwKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDg5MDQKCkFGRkVD VEVEIEZJTEVTCiAgc3lzL25ldGluZXQvaW4uYwoKQ0hBTkdFIERFVEFJTFMKCmRpZmYgLS1naXQg YS9zeXMvbmV0aW5ldC9pbi5jIGIvc3lzL25ldGluZXQvaW4uYwotLS0gYS9zeXMvbmV0aW5ldC9p bi5jCisrKyBiL3N5cy9uZXRpbmV0L2luLmMKQEAgLTIyOCw3ICsyMjgsNyBAQAogCXN0cnVjdCBz b2NrYWRkcl9pbiAqYWRkciA9IChzdHJ1Y3Qgc29ja2FkZHJfaW4gKikmaWZyLT5pZnJfYWRkcjsK IAlzdHJ1Y3QgaWZhZGRyICppZmE7CiAJc3RydWN0IGluX2lmYWRkciAqaWE7Ci0JaW50IGVycm9y OworCWludCBlcnJvciwgd2FzX3VwID0gMDsKIAogCWlmIChpZnAgPT0gTlVMTCkKIAkJcmV0dXJu IChFQUREUk5PVEFWQUlMKTsKQEAgLTI1MCw5ICsyNTAsMTMgQEAKIAkJcmV0dXJuIChlcnJvcik7 CiAJY2FzZSBPU0lPQ0FJRkFERFI6CS8qIDkueCBjb21wYXQgKi8KIAljYXNlIFNJT0NBSUZBRERS OgorCQlpZiAoaWZwLT5pZl9mbGFncyAmIElGRl9VUCkKKwkJCXdhc191cCA9IDE7CiAJCXN4X3hs b2NrKCZpbl9jb250cm9sX3N4KTsKIAkJZXJyb3IgPSBpbl9haWZhZGRyX2lvY3RsKGNtZCwgZGF0 YSwgaWZwLCB0ZCk7CiAJCXN4X3h1bmxvY2soJmluX2NvbnRyb2xfc3gpOworCQlpZiAoIXdhc191 cCAmJiAoaWZwLT5pZl9mbGFncyAmIElGRl9VUCkpCisJCQlpZl91cChpZnApOwogCQlyZXR1cm4g KGVycm9yKTsKIAljYXNlIFNJT0NTSUZBRERSOgogCWNhc2UgU0lPQ1NJRkJSREFERFI6CgoKCkVN QUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3NldHRpbmdzL3Bh bmVsL2VtYWlscHJlZmVyZW5jZXMvCgpUbzogc2VwaGVyb3NhX2dtYWlsLmNvbSwgZGVscGhpaiwg cm95Z2VyLCBkZWN1aV9taWNyb3NvZnQuY29tLCBob256aGFuX21pY3Jvc29mdC5jb20sIGhvd2Fy ZDBzdV9nbWFpbC5jb20sIGFkcmlhbiwgYnosIGdubiwgaGlyZW4sIGdsZWJpdXMsIHJ3YXRzb24s IGthcmVscwpDYzogZnJlZWJzZC1uZXQtbGlzdAo= --b1_95b4e9613d858d57bb5877c475faaff0 Content-Type: text/x-patch; charset=utf-8; name="D8904.23257.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D8904.23257.patch" ZGlmZiAtLWdpdCBhL3N5cy9uZXRpbmV0L2luLmMgYi9zeXMvbmV0aW5ldC9pbi5jCi0tLSBhL3N5 cy9uZXRpbmV0L2luLmMKKysrIGIvc3lzL25ldGluZXQvaW4uYwpAQCAtMjI4LDcgKzIyOCw3IEBA CiAJc3RydWN0IHNvY2thZGRyX2luICphZGRyID0gKHN0cnVjdCBzb2NrYWRkcl9pbiAqKSZpZnIt Pmlmcl9hZGRyOwogCXN0cnVjdCBpZmFkZHIgKmlmYTsKIAlzdHJ1Y3QgaW5faWZhZGRyICppYTsK LQlpbnQgZXJyb3I7CisJaW50IGVycm9yLCB3YXNfdXAgPSAwOwogCiAJaWYgKGlmcCA9PSBOVUxM KQogCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOwpAQCAtMjUwLDkgKzI1MCwxMyBAQAogCQlyZXR1 cm4gKGVycm9yKTsKIAljYXNlIE9TSU9DQUlGQUREUjoJLyogOS54IGNvbXBhdCAqLwogCWNhc2Ug U0lPQ0FJRkFERFI6CisJCWlmIChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKQorCQkJd2FzX3VwID0g MTsKIAkJc3hfeGxvY2soJmluX2NvbnRyb2xfc3gpOwogCQllcnJvciA9IGluX2FpZmFkZHJfaW9j dGwoY21kLCBkYXRhLCBpZnAsIHRkKTsKIAkJc3hfeHVubG9jaygmaW5fY29udHJvbF9zeCk7CisJ CWlmICghd2FzX3VwICYmIChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKSkKKwkJCWlmX3VwKGlmcCk7 CiAJCXJldHVybiAoZXJyb3IpOwogCWNhc2UgU0lPQ1NJRkFERFI6CiAJY2FzZSBTSU9DU0lGQlJE QUREUjoKCg== --b1_95b4e9613d858d57bb5877c475faaff0-- From owner-freebsd-net@freebsd.org Mon Dec 26 05:14:06 2016 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 C0969C91862 for ; Mon, 26 Dec 2016 05:14: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 996D418CD for ; Mon, 26 Dec 2016 05:14:06 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 2033516E54; Mon, 26 Dec 2016 05:14:06 +0000 (UTC) Date: Mon, 26 Dec 2016 05:14:06 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D8905+325+e1c9b54ecf40ba1e@reviews.freebsd.org Subject: [Differential] D8905: if: Defer the if_up until the ifnet.if_ioctl is called. 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: D8905: if: Defer the if_up until the ifnet.if_ioctl is called. 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-Cc: Precedence: bulk Thread-Index: ZGM0ZmZhMDQxMTU2OTYwMzY1ZTRkNjhiMzkx MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_b312d5553dbc292943f7c18df58cdabb" 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, 26 Dec 2016 05:14:06 -0000 --b1_b312d5553dbc292943f7c18df58cdabb Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 c2VwaGVyb3NhX2dtYWlsLmNvbSBjcmVhdGVkIHRoaXMgcmV2aXNpb24uCnNlcGhlcm9zYV9nbWFp bC5jb20gYWRkZWQgcmV2aWV3ZXJzOiBkZWxwaGlqLCByb3lnZXIsIGRlY3VpX21pY3Jvc29mdC5j b20sIGhvbnpoYW5fbWljcm9zb2Z0LmNvbSwgaG93YXJkMHN1X2dtYWlsLmNvbSwgYWRyaWFuLCBo aXJlbiwgYnosIGdubiwgZ2xlYml1cywga2FyZWxzLgpzZXBoZXJvc2FfZ21haWwuY29tIGFkZGVk IGEgc3Vic2NyaWJlcjogZnJlZWJzZC1uZXQtbGlzdC4KClJFVklTSU9OIFNVTU1BUlkKICBTbyBp Zl97ZG93bix1cH0gcGFpcnMgYmV0dGVyIHdpdGggdGhlIGlmbmV0LmlmX2lvY3RsLgoKUkVWSVNJ T04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q4OTA1CgpBRkZFQ1RFRCBG SUxFUwogIHN5cy9uZXQvaWYuYwoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmlld3Mu ZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBzZXBoZXJv c2FfZ21haWwuY29tLCBkZWxwaGlqLCByb3lnZXIsIGRlY3VpX21pY3Jvc29mdC5jb20sIGhvbnpo YW5fbWljcm9zb2Z0LmNvbSwgaG93YXJkMHN1X2dtYWlsLmNvbSwgYWRyaWFuLCBoaXJlbiwgYnos IGdubiwgZ2xlYml1cywga2FyZWxzCkNjOiBmcmVlYnNkLW5ldC1saXN0Cg== --b1_b312d5553dbc292943f7c18df58cdabb Content-Type: text/x-patch; charset=utf-8; name="D8905.23258.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D8905.23258.patch" ZGlmZiAtLWdpdCBhL3N5cy9uZXQvaWYuYyBiL3N5cy9uZXQvaWYuYwotLS0gYS9zeXMvbmV0L2lm LmMKKysrIGIvc3lzL25ldC9pZi5jCkBAIC0yMzAwLDcgKzIzMDAsNyBAQAogaWZod2lvY3RsKHVf bG9uZyBjbWQsIHN0cnVjdCBpZm5ldCAqaWZwLCBjYWRkcl90IGRhdGEsIHN0cnVjdCB0aHJlYWQg KnRkKQogewogCXN0cnVjdCBpZnJlcSAqaWZyOwotCWludCBlcnJvciA9IDA7CisJaW50IGVycm9y ID0gMCwgZG9faWZ1cCA9IDA7CiAJaW50IG5ld19mbGFncywgdGVtcF9mbGFnczsKIAlzaXplX3Qg bmFtZWxlbiwgb25hbWVsZW47CiAJc2l6ZV90IGRlc2NybGVuOwpAQCAtMjQyNyw3ICsyNDI3LDcg QEAKIAkJCWlmX2Rvd24oaWZwKTsKIAkJfSBlbHNlIGlmIChuZXdfZmxhZ3MgJiBJRkZfVVAgJiYK IAkJICAgIChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKSA9PSAwKSB7Ci0JCQlpZl91cChpZnApOwor CQkJZG9faWZ1cCA9IDE7CiAJCX0KIAkJLyogU2VlIGlmIHBlcm1hbmVudGx5IHByb21pc2N1b3Vz IG1vZGUgYml0IGlzIGFib3V0IHRvIGZsaXAgKi8KIAkJaWYgKChpZnAtPmlmX2ZsYWdzIF4gbmV3 X2ZsYWdzKSAmIElGRl9QUFJPTUlTQykgewpAQCAtMjQ0Niw2ICsyNDQ2LDggQEAKIAkJaWYgKGlm cC0+aWZfaW9jdGwpIHsKIAkJCSh2b2lkKSAoKmlmcC0+aWZfaW9jdGwpKGlmcCwgY21kLCBkYXRh KTsKIAkJfQorCQlpZiAoZG9faWZ1cCkKKwkJCWlmX3VwKGlmcCk7CiAJCWdldG1pY3JvdGltZSgm aWZwLT5pZl9sYXN0Y2hhbmdlKTsKIAkJYnJlYWs7CiAKCg== --b1_b312d5553dbc292943f7c18df58cdabb-- From owner-freebsd-net@freebsd.org Mon Dec 26 07:43:37 2016 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 55440C91271 for ; Mon, 26 Dec 2016 07:43:37 +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 2C55AF8B for ; Mon, 26 Dec 2016 07:43:37 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 9BA6726A2A; Mon, 26 Dec 2016 07:43:36 +0000 (UTC) Date: Mon, 26 Dec 2016 07:43:36 +0000 To: freebsd-net@freebsd.org From: "hrs (Hiroki Sato)" Reply-to: D8904+325+7336aa65c010aea9@reviews.freebsd.org Subject: [Differential] D8904: inet: Fix routing issue by calling if_up() Message-ID: <63e1bfb6c571f8ec4e1f0d9856cfea1c@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: D8904: inet: Fix routing issue by calling if_up() 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-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZjczN2EyNTY0YWQ0YjU5MTFiOTVmNTcwYjRkIFhgyig= 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, 26 Dec 2016 07:43:37 -0000 aHJzIGFkZGVkIGEgY29tbWVudC4KCgogIFRoZSBjYXVzZSBpcyB0aGF0IHRoZSBwcmVmaXggcm91 dGUgd2FzIHJlbW92ZWQgYnkgaW5fc2NydWJwcmVmaXgoKSBpbiB0aGUgUFJDX0lGRE9XTiBoYW5k bGVyIGFuZCBuZXZlciByZWluc3RhbGxlZCB1cG9uIFBSQ19JRlVQIGJlY2F1c2UgdGhlIHJlaW5z dGFsbGF0aW9uICBpcyBkb25lIG9ubHkgZm9yIGlmYSBwYXNzZWQgdG8gU0lPQ0FJRkFERFIuICBK dXN0IGNhbGxpbmcgaWZfdXAoaWZwKSBsb29rcyB0b28gaGVhdnkgdG8gbWUgYmVjYXVzZSBpdCBj YXVzZXMgZXh0cmEgcHJfY3RsaW5wdXQoKSBjYWxscyBvZiBlYWNoIHByb3RvY29sLCBub3Qgb25s eSBpbmV0ZG9tYWluLCBpbiBvcmRlciB0byByZWNvdmVyIHRoZSByb3V0ZXMuICBXaGF0IGRvIHlv dSB0aGluayBhYm91dCBhZGRpbmcgcmVpbnN0YWxsdGlvbiBvZiB0aGUgcHJlZml4IHJvdXRlcyBp biB0aGUgcHJvdG9jb2wgc3BlY2lmaWMgUFJDX0lGVVAgaGFuZGxlciBpbnN0ZWFkPwoKUkVWSVNJ T04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q4OTA0CgpFTUFJTCBQUkVG RVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9zZXR0aW5ncy9wYW5lbC9lbWFp bHByZWZlcmVuY2VzLwoKVG86IHNlcGhlcm9zYV9nbWFpbC5jb20sIGRlbHBoaWosIHJveWdlciwg ZGVjdWlfbWljcm9zb2Z0LmNvbSwgaG9uemhhbl9taWNyb3NvZnQuY29tLCBob3dhcmQwc3VfZ21h aWwuY29tLCBhZHJpYW4sIGJ6LCBnbm4sIGhpcmVuLCBnbGViaXVzLCByd2F0c29uLCBrYXJlbHMK Q2M6IGhycywgZnJlZWJzZC1uZXQtbGlzdAo= From owner-freebsd-net@freebsd.org Mon Dec 26 07:52:59 2016 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 DD484C91516 for ; Mon, 26 Dec 2016 07:52: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 B77B013E3 for ; Mon, 26 Dec 2016 07:52:59 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 32F5225140; Mon, 26 Dec 2016 07:52:59 +0000 (UTC) Date: Mon, 26 Dec 2016 07:52:59 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D8904+325+7336aa65c010aea9@reviews.freebsd.org Subject: [Differential] D8904: inet: Fix routing issue by calling if_up() Message-ID: <6a3bfdbf8f9023f9daa9c5f821456039@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: D8904: inet: Fix routing issue by calling if_up() 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-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZjczN2EyNTY0YWQ0YjU5MTFiOTVmNTcwYjRkIFhgzFs= 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, 26 Dec 2016 07:53:00 -0000 c2VwaGVyb3NhX2dtYWlsLmNvbSBhZGRlZCBhIGNvbW1lbnQuCgoKICBJbiBodHRwczovL3Jldmll d3MuZnJlZWJzZC5vcmcvRDg5MDQjMTg0NDMwLCBAaHJzIHdyb3RlOgogIAogID4gVGhlIGNhdXNl IGlzIHRoYXQgdGhlIHByZWZpeCByb3V0ZSB3YXMgcmVtb3ZlZCBieSBpbl9zY3J1YnByZWZpeCgp IGluIHRoZSBQUkNfSUZET1dOIGhhbmRsZXIgYW5kIG5ldmVyIHJlaW5zdGFsbGVkIHVwb24gUFJD X0lGVVAgYmVjYXVzZSB0aGUgcmVpbnN0YWxsYXRpb24gIGlzIGRvbmUgb25seSBmb3IgaWZhIHBh c3NlZCB0byBTSU9DQUlGQUREUi4gIEp1c3QgY2FsbGluZyBpZl91cChpZnApIGxvb2tzIHRvbyBo ZWF2eSB0byBtZSBiZWNhdXNlIGl0IGNhdXNlcyBleHRyYSBwcl9jdGxpbnB1dCgpIGNhbGxzIG9m IGVhY2ggcHJvdG9jb2wsIG5vdCBvbmx5IGluZXRkb21haW4sIGluIG9yZGVyIHRvIHJlY292ZXIg dGhlIHJvdXRlcy4gIFdoYXQgZG8geW91IHRoaW5rIGFib3V0IGFkZGluZyByZWluc3RhbGx0aW9u IG9mIHRoZSBwcmVmaXggcm91dGVzIGluIHRoZSBwcm90b2NvbCBzcGVjaWZpYyBQUkNfSUZVUCBo YW5kbGVyIGluc3RlYWQ/CiAgCiAgCiAgV2VsbCwgSSBiZWxpZXZlIGl0IG1pcnJvcnMgdGhlIGJl aGF2aW9yIG9mICdpZmNvbmZpZyBpZmFjZTAgdXAnOyB3L28gdGhlIGlmX3VwKCksIHdlIGp1c3Qg YnJpbmcgdGhlIGludGVyZmFjZSB1cCB3L28gbm90aWZ5aW5nIGFueSBkb21haW5zLCB3aGljaCBw cm9iYWJseSBpcyBub3QgaW50ZW5kZWQuCgpSRVZJU0lPTiBERVRBSUwKICBodHRwczovL3Jldmll d3MuZnJlZWJzZC5vcmcvRDg5MDQKCkVNQUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdz LmZyZWVic2Qub3JnL3NldHRpbmdzL3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvCgpUbzogc2VwaGVy b3NhX2dtYWlsLmNvbSwgZGVscGhpaiwgcm95Z2VyLCBkZWN1aV9taWNyb3NvZnQuY29tLCBob256 aGFuX21pY3Jvc29mdC5jb20sIGhvd2FyZDBzdV9nbWFpbC5jb20sIGFkcmlhbiwgYnosIGdubiwg aGlyZW4sIGdsZWJpdXMsIHJ3YXRzb24sIGthcmVscwpDYzogaHJzLCBmcmVlYnNkLW5ldC1saXN0 Cg== From owner-freebsd-net@freebsd.org Mon Dec 26 10:44:29 2016 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 47648C0B402 for ; Mon, 26 Dec 2016 10:44: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 36F21A6D for ; Mon, 26 Dec 2016 10:44: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 uBQAiSPh017488 for ; Mon, 26 Dec 2016 10:44:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 168842] [tcp] FreeBSD hosts are sending TCP packets with FIN flag and no ACK set Date: Mon, 26 Dec 2016 10:44:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ndenev@gmail.com X-Bugzilla-Status: Open 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: Mon, 26 Dec 2016 10:44:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D168842 Nikolay Denev changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ndenev@gmail.com --- Comment #5 from Nikolay Denev --- Unfortunately I no longer have access to these systems. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Dec 26 22:53:02 2016 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 3D1F1C92362 for ; Mon, 26 Dec 2016 22:53:02 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [IPv6:2001:41d0:1008:bcb:1:1:0:1]) (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 CB0231CEE for ; Mon, 26 Dec 2016 22:53:01 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from [IPv6:2003:8c:2e02:5301:d0be:dcb:6e13:1bd3] (p2003008C2E025301D0BE0DCB6E131BD3.dip0.t-ipconnect.de [IPv6:2003:8c:2e02:5301:d0be:dcb:6e13:1bd3]) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 3tnZ5b51J7zSbp for ; Mon, 26 Dec 2016 23:52:51 +0100 (CET) From: Michael Grimm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: IPSec tunnel, VNET jail and routing issue Message-Id: Date: Mon, 26 Dec 2016 23:52:50 +0100 To: freebsd-net@freebsd.org X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean 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: Mon, 26 Dec 2016 22:53:02 -0000 Hi -- I am referring to the following (simplified) setup: [hostA /ix0 / 2001:dead::1 / 1.2.3.4] <=3D=3D=3D=3D=3D IPsec tunnel = =3D=3D=3D=3D=3D> [hostB / ix0 / 2001:beef::10 / 10.20.30.40] | | = =20 | | [jail1 / bridge0 / fd00:a::1 / 10.1.1.1] [jail1 = / bridge0 / fd00:b::2 / 10.2.2.2] All my jails are VNET jails, that use the bridge0 (epair) device. Thus, = all IPv4 and IPv6 addresses of my local networks an A and B are bound to = the bridge0 interface! But, the IPsec tunnel (via racoon) is anchored at = public IPv4 addresses on ix0 at both hosts. Task: route all local traffic from hostA to hostB via the tunnel. Working: IPv6 traffic is running fine, meaning, that I can reach every = jail from every host. That has been working for years. Issue: I recently wanted to extend my setup to local IPv4 addresses of = my jails, and failed miserably. Configuration (shown for hostA, only): setkey.conf # hostA hostB = hostA hostB=20 spdadd fd00:a::/64 fd00:b::/64 any -P out ipsec = esp/tunnel/1.2.3.4-10.20.30.40/require; spdadd fd00:a::/64 2001:beef::/56 any -P out ipsec = esp/tunnel/1.2.3.4-10.20.30.40/require; spdadd 2001:dead::/56 fd00:b::/64 any -P out ipsec = esp/tunnel/1.2.3.4-10.20.30.40/require; # hostB hostA = hostB hostA=20 spdadd fd00:b::/64 fd00:a::/64 any -P in ipsec = esp/tunnel/10.20.30.40-1.2.3.4/require; spdadd fd00:b::/64 2001:dead::/56 any -P in ipsec = esp/tunnel/10.20.30.40-1.2.3.4/require; spdadd 2001:beef::/56 fd00:a::/64 any -P in ipsec = esp/tunnel/10.20.30.40-1.2.3.4/require; # hostA hostB = hostA hostB=20 spdadd 10.1.1.0/24 10.2.2.0/24 any -P out ipsec = esp/tunnel/1.2.3.4-10.20.30.40/require; spdadd 10.1.1.0/24 10.20.30.40 any -P out ipsec = esp/tunnel/1.2.3.4-10.20.30.40/require; spdadd 1.2.3.4 10.2.2.0/24 any -P out ipsec = esp/tunnel/1.2.3.4-10.20.30.40/require; # hostB hostA = hostB hostA=20 spdadd 10.2.2.0/24 10.1.1.0/24 any -P in ipsec = esp/tunnel/10.20.30.40-1.2.3.4/require; spdadd 10.2.2.0/24 1.2.3.4 any -P in ipsec = esp/tunnel/10.20.30.40-1.2.3.4/require; spdadd 10.20.30.40 10.1.1.0/24 any -P in ipsec = esp/tunnel/10.20.30.40-1.2.3.4/require; There is no specific routing regarding the tunnel defined. All = should be done by this spdadd's. Achieved sofar: #) I can reach each jail at the other site from the host. #) Allowing arpproxy_all=3D"YES" will satisfy ARP (MACs from = opposite VNET jails will become assigned).=20 I do not know if that is needed, but now ping from jails to = the opposite jails will at least start to send ICMP packages. Unsolved issue: I cannot reach opposite jails from another host's jail; e.g.: = ping 10.20.30.40 in jail1@hostA will not work. Observations so far: #) tcpdump shows for "ping 10.2.2.2 in jail1@hostA" ICMP traffic = at the bridge0 at hostA: IP 10.1.1.1 > 10.2.2.2: ICMP echo request, id 20099, seq = 0, length 64=20 and at bridge0 at hostB: IP 10.1.1.1 > 10.2.2.2: ICMP echo request, id 15233, seq = 6, length 64=20 IP 10.2.2.2 > 10.1.1.1: ICMP echo reply, id 15233, seq = 6, length 64=20 =09 Hmm: hostA doesn't get an echo replay, although hostB did send = one.=20 #) tcpdump shows for "ping 10.2.2.2 at hostA" *no* ICMP traffic = at hostA@bridge0 or hostA@ix0 but ICMP traffic at hostB@bridge0: IP 1.2.3.4 > 10.2.2.2: ICMP echo request, id 60543, seq = 0, length 64=20 IP 10.2.2.2 > 1.2.3.4: ICMP echo reply, id 60543, seq 0, = length 64=20 =09 Hmm: it's working. #) It looks to me as if the tunnel does not recognise "spdadd = 10.1.1.0/24 10.2.2.0/24" and vice versa settings because those IPs are = bound to the bridge. #) Whenever an IP bound to ix0 is involved (host to jail) the = corresponding spdadd parts are recognised. #) adding static routes like "add route 10.2.2.0/24 1.2.3.4" and = alike do not solve my issue.=20 Questions: #) Is this an issue with IPsec/racoon? #) Is this a routing issue? #) Why does IPv6 address space work (identical configuration = regarding jails, firewalling, routing, et al.) #) Any other idea? Sorry for this lengthy post, and any feedback is highly welcome, Michael From owner-freebsd-net@freebsd.org Tue Dec 27 08:32:16 2016 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 9FA83C93FC9 for ; Tue, 27 Dec 2016 08:32:16 +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 8F80D1F05 for ; Tue, 27 Dec 2016 08:32: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 uBR8WFS7058677 for ; Tue, 27 Dec 2016 08:32:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206185] [netgraph][patch] refactoring ng_patch Date: Tue, 27 Dec 2016 08:32: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: 10.2-STABLE X-Bugzilla-Keywords: patch 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: Tue, 27 Dec 2016 08:32:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206185 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: julian Date: Tue Dec 27 08:31:41 UTC 2016 New revision: 310625 URL: https://svnweb.freebsd.org/changeset/base/310625 Log: MFH: r309408 Changes to allow the patching of packets with an offset (and other change= s.. see man page) PR: 206185 Submitted by: Dmitry Vagin MFC after: 1 week Relnotes: yes (also ng_checksum node) Changes: _U stable/11/ stable/11/share/man/man4/ng_patch.4 stable/11/sys/netgraph/ng_patch.c stable/11/sys/netgraph/ng_patch.h --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 27 10:19:25 2016 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 43AE4C8FF3E; Tue, 27 Dec 2016 10:19:25 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by mx1.freebsd.org (Postfix) with ESMTP id EB9271C6D; Tue, 27 Dec 2016 10:19:23 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: [RFC/RFT] projects/ipsec To: freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org References: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> From: "Andrey V. Elsukov" Cc: "Bjoern A. Zeeb" , George Neville-Neil Message-ID: Date: Tue, 27 Dec 2016 13:18:47 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 27 Dec 2016 10:19:25 -0000 On 11.12.2016 02:07, Andrey V. Elsukov wrote: > Hi All, > > I am pleased to announce that projects/ipsec, that I started several > months ago is ready for testing and review. > The main goals were: > * rework locking to make IPsec code more friendly for concurrent > processing; > * make lookup in SADB/SPDB faster; > * revise PFKEY implementation, remove stale code, make it closer > to RFC; > * implement IPsec VTI (virtual tunneling interface); > * make IPsec code loadable as kernel module. > > Currently all, except the last one is mostly done. So, I decided ask for > a help to test the what already done, while I will work on the last task. I finished the last task, now it is possible to load/unload IPsec and TCP-MD5 support as kernel modules. New kernel option IPSEC_SUPPORT should be used to build the kernel that is able to load IPsec module. So, if you have 'options IPSEC' in the kernel config, IPsec support will be build in the kernel without TCP-MD5 support. If you have 'options IPSEC' and 'options TCP_SIGNATURE', IPsec and TCP-MD5 support will be build in the kernel. If you have 'options IPSEC' and 'options IPSEC_SUPPORT', IPsec support will be build in the kernel and TCP-MD5 can be loaded. If you have 'options IPSEC_SUPPORT', IPsec and TCP-MD5 can be loaded. If you have 'options IPSEC_SUPPORT' and 'options TCP_SIGNATURE', TCP-MD5 support will be build in the kernel and IPsec can be loaded. If you have not IPSEC* options, it isn't possible to use IPsec as module. So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. -- WBR, Andrey V. Elsukov From owner-freebsd-net@freebsd.org Tue Dec 27 13:15:17 2016 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 6529BC93332 for ; Tue, 27 Dec 2016 13:15:17 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 3A0321041 for ; Tue, 27 Dec 2016 13:15:17 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-io0-x22e.google.com with SMTP id n85so79089829ioi.2 for ; Tue, 27 Dec 2016 05:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7sNiJQQmAHVAz5l3wOSF/XiGqaxuGZ/BxlwZ9Iwlg1M=; b=RkiOebxEPJiJHS9iHVigB8b/NAwRHchIVXTAAygt3a7HHr56mAt1IVhPW8tLHzvxc9 rhIBahExS3p2rrtG1wpxrl1rEtXSoUueMBc3X2oUrGpXn83vPhO4sBvIO9L6FvfVznYZ wazy2g44erieW46Bn+L30aFjDs4fRylOIZmFM= 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:content-transfer-encoding; bh=7sNiJQQmAHVAz5l3wOSF/XiGqaxuGZ/BxlwZ9Iwlg1M=; b=aH5P0IMXz2AjXyKV/ZwB+dW0Si4c1rVrCtKX6aZbojY0DuZ2Bh+yp04J+hOcTpzC/F PlGpiweFwjvq0UZlxlULpnQoQDO9uRXsMVNR0Q36wv/N5QIz31DianQHUUlRPaS1m0dR P/40XrYhcr73GZFjDRzFK4PkOFq9eJUYs5sRFtCgUJblYrTdVN+SvqwYPSZ6Qu+FmpZX aEqr52uE9p0mFGHYwKArRgJv4uFaUulQRyhRG0G+7zT/D9yjN4ASQpQVTx5o/UUsKxOn GyldJSWSv95IoKIKIf3qa03hHrB67wUY11cW4ahzM0bPI0AEqT+PxN+iOKIVjb6hKq9P rR1g== X-Gm-Message-State: AIkVDXJ2y8IlrTEMwmZrOzIhfiaStX72sjSvvdtOEtGfeQ81Lj1HcLSrAe0I1ASzNu2yv64ty/F69XK8ufMquoHU X-Received: by 10.107.28.12 with SMTP id c12mr18917335ioc.223.1482844516394; Tue, 27 Dec 2016 05:15:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.32.4 with HTTP; Tue, 27 Dec 2016 05:15:15 -0800 (PST) In-Reply-To: <5889f1f5-5585-95d4-beac-285dbc722b4e@norma.perm.ru> References: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> <5889f1f5-5585-95d4-beac-285dbc722b4e@norma.perm.ru> From: Jim Thompson Date: Tue, 27 Dec 2016 07:15:15 -0600 Message-ID: Subject: Re: [RFC/RFT] projects/ipsec To: "Eugene M. Zheganin" Cc: FreeBSD Current , freebsd-net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 27 Dec 2016 13:15:17 -0000 > In it's initial state if_ipsec allows to use only one set of encryption p= arameters (because only one sainfo anonyumous is possible), so at this time= it doesn't allow to create multiple tunnels with VPN hubs that use differe= nt cipers and/or transform sets, but as far as I understand this is subject= to change and Andrey is already working on a support of this feature from = ipsec-tools IKE daemon. pfSense (which you mention below) is using strongswan, so when Andrey is finished with ipsec-tools, we will need to review his changes and see what we can do for strongswan. I'm looking forward to the mutliple-tunnel support, which is required for pfSense. > But even in this state this feature is already useful and I'm excited to = see it commited to HEAD and then MFC'd to 11.x, to start using it in my pro= duction network (as you may know, buiding gre/ipsec tunnels on Juniper is v= ery hackish and tricky, bit I still have more than dozen of them). I've alr= eady saw a discussion on FreeBSD web forums, and people there are excited a= bout if_ipsec too. > Furthermore, I believe that guys using pfSense will be very happy about i= f_ipsec in their routers, because I saw several discussions mentioning miss= ing VTI support there. I'm not sure what discussions you saw. We're aware, and very interested in the VTI support. https://twitter.com/gonzopancho/status/809412164259893248 On Wed, Dec 14, 2016 at 10:52 AM, Eugene M. Zheganin wr= ote: > Hi, > > On 11.12.2016 4:07, Andrey V. Elsukov wrote: >> >> Hi All, >> >> I am pleased to announce that projects/ipsec, that I started several >> months ago is ready for testing and review. >> The main goals were: >> * rework locking to make IPsec code more friendly for concurrent >> processing; >> * make lookup in SADB/SPDB faster; >> * revise PFKEY implementation, remove stale code, make it closer >> to RFC; >> * implement IPsec VTI (virtual tunneling interface); >> * make IPsec code loadable as kernel module. >> >> Currently all, except the last one is mostly done. So, I decided ask for >> a help to test the what already done, while I will work on the last task= . >> > Well, at last FreeBSD got one of the most anticipated features in it's ip= sec > stack. When I wrote the message in the freebsd-net ML in the middle of 20= 12 > (https://lists.freebsd.org/pipermail/freebsd-net/2012-June/032556.html) I > had a very little hope that someone will actually implement this, and now > I'm very grateful that Andrey got the time to do this (and I'm really sor= ry > for being such a pain in the ass, I'm saying so because I was bothering > Andrey all this time in IRC). This isn't definitely a feature that every > FreeBSD enthusiast will use, and, sadly, even not the feature that every > network engineer that use ipsec in it's every day work will configure (ma= ny > people still use obsoleted legacy interfaceless ipsec approach, not to > mention weird and hybrid software routers like openvpn), but it's definit= ely > a feature that will be appreciated by every skilled L3 VPN engineer that = is > using FreeBSD in it's operating stack. I've ran some tests in my producti= on > network and I should say that even on it's initial release state if_ipsec= is > fully operational with Juniper st tunnel on the other side, so I'm alread= y > running one FreeBSD <--> Juniper tunnel at my work: > > # ifconfig ipsec0 > ipsec0: flags=3D8051 metric 0 mtu 1400 > tunnel inet 128.127.144.19 --> 128.127.146.1 > inet 172.16.3.104 --> 172.16.3.105 netmask 0xffffffff > inet6 fe80::204:23ff:fec7:194d%ipsec0 prefixlen 64 scopeid 0x9 > nd6 options=3D21 > reqid: 16385 > groups: ipsec > > racoon.conf: > path pre_shared_key "/usr/local/etc/racoon/psk.txt"; > > padding { > maximum_length 20; # maximum padding length. > randomize off; # enable randomize length. > strict_check off; # enable strict check. > exclusive_tail off; # extract last one octet. > } > > listen { > isakmp 128.127.144.19 [500]; > strict_address; # requires that all addresses must be bound. > } > > timer { > counter 5; > interval 20 sec; > persend 1; > > phase1 30 sec; > phase2 15 sec; > } > > # > # SPb, Test > # > > remote 128.127.146.1 { > exchange_mode main; > lifetime time 1 hour; > my_identifier address 128.127.144.19; > peers_identifier address 128.127.146.1; > passive off; > proposal_check obey; > dpd_delay 20; > proposal { > encryption_algorithm des; > hash_algorithm md5; > authentication_method pre_shared_key; > dh_group modp768; > } > } > > # > # SPb, Test > # > > sainfo address 0.0.0.0/0 [500] any address 0.0.0.0/0 [500] any { > pfs_group modp768; > lifetime time 60 min; > encryption_algorithm des; > authentication_algorithm non_auth; > compression_algorithm deflate; > } > > Juniper side: > >> show configuration interfaces st0.147 > description "Perm, FreeBSD Test Server"; > family inet { > mtu 1455; > address 172.16.3.105/32 { > destination 172.16.3.104; > } > } > >> show configuration security ike policy kosm65 > proposals norma-ike; > pre-shared-key ascii-text > "$9$-SV4ZUDkqPQUjBIclLXgoJUqf9CuESeAp-w2gGUjHqfQn"; ## SECRET-DATA > >> show configuration security ike gateway kosm65-freebsd-test > ike-policy perm-freebsd-test; > address 128.127.144.19; > local-identity inet 128.127.146.1; > remote-identity inet 128.127.144.19; > external-interface reth1.2; > >> show configuration security ipsec vpn kosm65-freebsd-test > bind-interface st0.147; > ike { > gateway kosm65-freebsd-test; > ipsec-policy norma-policy; > } > >> show configuration security ipsec policy norma-policy > perfect-forward-secrecy { > keys group1; > } > proposals norma-ipsec; > >> show configuration security ipsec proposal norma-ipsec > protocol esp; > encryption-algorithm des-cbc; > lifetime-seconds 600; > >> show configuration security ike proposal norma-ike > authentication-method pre-shared-keys; > dh-group group1; > authentication-algorithm md5; > encryption-algorithm des-cbc; > > In it's initial state if_ipsec allows to use only one set of encryption > parameters (because only one sainfo anonyumous is possible), so at this t= ime > it doesn't allow to create multiple tunnels with VPN hubs that use differ= ent > cipers and/or transform sets, but as far as I understand this is subject = to > change and Andrey is already working on a support of this feature from > ipsec-tools IKE daemon. But even in this state this feature is already > useful and I'm excited to see it commited to HEAD and then MFC'd to 11.x,= to > start using it in my production network (as you may know, buiding gre/ips= ec > tunnels on Juniper is very hackish and tricky, bit I still have more than > dozen of them). I've already saw a discussion on FreeBSD web forums, and > people there are excited about if_ipsec too. Furthermore, I believe that > guys using pfSense will be very happy about if_ipsec in their routers, > because I saw several discussions mentioning missing VTI support there. > > It's very easy to configure, because it uses ifconfig syntax and it creat= es > all the needed policies in the SADB automatically, so one less thing to > bother with. And when I say "fully opertational with Juniper" I mean it: = no > tricky or hackish configuration directives are required oin the Juniper > side, everything is like it's a Juniper or Cisco on the other side. So I'= m > pretty sure this will work with Cisco too (didn't run any test with Cisco > though). > > Once again, I thank Andrey for this. > > Eugene. > > _______________________________________________ > 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 Tue Dec 27 14:10:53 2016 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 242E2C8A725; Tue, 27 Dec 2016 14:10:53 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1p.cmail.yandex.net (forward1p.cmail.yandex.net [77.88.31.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2C061C5B; Tue, 27 Dec 2016 14:10:52 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2p.mail.yandex.net (smtp2p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b6:7]) by forward1p.cmail.yandex.net (Yandex) with ESMTP id 3C213206A2; Tue, 27 Dec 2016 17:10:43 +0300 (MSK) Received: from smtp2p.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2p.mail.yandex.net (Yandex) with ESMTP id 57E5C1A8005A; Tue, 27 Dec 2016 17:10:40 +0300 (MSK) Received: by smtp2p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id u0pS26SToL-AdQKnW9E; Tue, 27 Dec 2016 17:10:40 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1482847840; bh=D5EqgLa7fidsqvuF/bL8hpfr+BSutNcNsOi52eLaxq0=; h=Subject:To:References:Cc:From:Message-ID:Date:In-Reply-To; b=oI+alu6NpL1bVuQL4aJkqzp8iksqmYVgsErF0yYS2B3Bul91gxN1jPnM92OJ6dNJH /+G0P/usWMdYW4oyRHNa95HP0sO8mQU4dZQSJ/AaJA6PHSlsZ8JRfdg6EcsXgASvvf weEfreLVRqu9HRS3/ZbqiUuF0BwXAE5NiUEaWfbE= Authentication-Results: smtp2p.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0,1 0 Subject: Re: [RFC/RFT] projects/ipsec To: Jim Thompson , "Eugene M. Zheganin" References: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> <5889f1f5-5585-95d4-beac-285dbc722b4e@norma.perm.ru> Cc: FreeBSD Current , freebsd-net From: "Andrey V. Elsukov" Message-ID: Date: Tue, 27 Dec 2016 17:10:02 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: 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: Tue, 27 Dec 2016 14:10:53 -0000 On 27.12.2016 16:15, Jim Thompson wrote: >> In it's initial state if_ipsec allows to use only one set of >> encryption parameters (because only one sainfo anonyumous is >> possible), so at this time it doesn't allow to create multiple >> tunnels with VPN hubs that use different cipers and/or transform >> sets, but as far as I understand this is subject to change and >> Andrey is already working on a support of this feature from >> ipsec-tools IKE daemon. > > pfSense (which you mention below) is using strongswan, so when > Andrey is finished with ipsec-tools, we will need to review his > changes and see what we can do for strongswan. > > I'm looking forward to the mutliple-tunnel support, which is > required for pfSense. There are no such limits. You can create multiple VTI interfaces. The problem is in with racoon configuration restrictions. It looks like ipsec-tools project is dead, I didn't received any replies from ipsec-tools-devel mailing list. I'm not aware how to configure strongswan, so if someone will not try to do this, I don't know when I will do this. -- WBR, Andrey V. Elsukov From owner-freebsd-net@freebsd.org Tue Dec 27 15:31:36 2016 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 049B9C925A2 for ; Tue, 27 Dec 2016 15:31:36 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [IPv6:2001:41d0:d:3049:1:1:0:1]) (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 C7A4E1BFD for ; Tue, 27 Dec 2016 15:31:35 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from [IPv6:2003:8c:2e0c:ce01:846f:d63b:4897:ada6] (p2003008C2E0CCE01846FD63B4897ADA6.dip0.t-ipconnect.de [IPv6:2003:8c:2e0c:ce01:846f:d63b:4897:ada6]) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 3tp0Fx0D6RzRfX for ; Tue, 27 Dec 2016 16:31:32 +0100 (CET) From: Michael Grimm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: [SOLVED] IPSec tunnel, VNET jail and routing issue Date: Tue, 27 Dec 2016 16:31:31 +0100 References: To: freebsd-net@freebsd.org In-Reply-To: Message-Id: <7BDE3BD8-FC09-413C-801C-5985C1781754@ellael.org> X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean 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, 27 Dec 2016 15:31:36 -0000 Michael Grimm wrote: Nevermind, I solved my issue. I has been a minor typo with major = consequences. > Configuration (shown for hostA, only): >=20 > setkey.conf > # hostA hostB = hostA hostB=20 > spdadd 10.1.1.0/24 10.2.2.0/24 any -P out ipsec = esp/tunnel/1.2.3.4-10.20.30.40/require; Contrarily to this example line above, my real setkey.conf has had an = "in" instead of "out" :-(=20 > Achieved sofar: >=20 > #) Allowing arpproxy_all=3D"YES" will satisfy ARP (MACs from = opposite VNET jails will become assigned).=20 > I do not know if that is needed, but now ping from jails to = the opposite jails will at least start to send ICMP packages. Now I have to state: yes, ARP proxying is mandatory in my setup. Hmm, I need to learn more about ARP. Because now I do observe a lot of = lines like =E2=80=A6 | mike kernel: arp: proxy: ignoring request from = 10.1.1.1 via epair1a =E2=80=A6 and I do not know if I do have to be concerned about those. Do = I? Sorry for the noise! Regards, Michael From owner-freebsd-net@freebsd.org Tue Dec 27 16:55:49 2016 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 23B09C93F8B for ; Tue, 27 Dec 2016 16:55:49 +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 059DF160A for ; Tue, 27 Dec 2016 16:55:49 +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 uBRGtlEe002580 for ; Tue, 27 Dec 2016 16:55:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 212283] oversized IP datagrams on raw socket with IP_RAWOUTPUT hang network interface drivers Date: Tue, 27 Dec 2016 16:55:48 +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: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? 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: Tue, 27 Dec 2016 16:55:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212283 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |ae@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 27 19:17:40 2016 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 0B8F6C93495 for ; Tue, 27 Dec 2016 19:17:40 +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 EF2401AD8 for ; Tue, 27 Dec 2016 19:17:39 +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 uBRJHdXC054250 for ; Tue, 27 Dec 2016 19:17:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 24959] [patch] proper TCP_NOPUSH/TCP_CORK compatibility Date: Tue, 27 Dec 2016 19:17:39 +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: 4.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Feedback Timeout X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc resolution bug_status 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: Tue, 27 Dec 2016 19:17:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D24959 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hiren@FreeBSD.org Resolution|--- |Feedback Timeout Status|In Progress |Closed --- Comment #11 from Hiren Panchasara --- Please reopen if needed. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 27 19:23:13 2016 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 BB239C936CD for ; Tue, 27 Dec 2016 19:23:13 +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 AA47B1EBF for ; Tue, 27 Dec 2016 19:23:13 +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 uBRJNDam070820 for ; Tue, 27 Dec 2016 19:23:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 96268] [socket] TCP socket performance drops by 3000% if packets are split at the first byte Date: Tue, 27 Dec 2016 19:23:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution cc bug_status 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: Tue, 27 Dec 2016 19:23:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D96268 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events CC| |hiren@FreeBSD.org Status|In Progress |Closed --- Comment #5 from Hiren Panchasara --- Based on the last comment. Reopen/comment if that is not the case. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 27 19:26:47 2016 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 6477DC93769 for ; Tue, 27 Dec 2016 19:26:47 +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 53CB81FC5 for ; Tue, 27 Dec 2016 19:26:47 +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 uBRJQlen074907 for ; Tue, 27 Dec 2016 19:26:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 125845] [netinet] [patch] tcp_lro_rx() should make use of hardware IP cksum assistance when available Date: Tue, 27 Dec 2016 19:26:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org 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: Tue, 27 Dec 2016 19:26:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D125845 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hiren@FreeBSD.org, | |np@FreeBSD.org --- Comment #2 from Hiren Panchasara --- Navdeep, Is this something still valid and you care about? If not, can we close it? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 27 19:34:43 2016 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 C782FC93D53 for ; Tue, 27 Dec 2016 19:34:43 +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 B671F1601 for ; Tue, 27 Dec 2016 19:34:43 +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 uBRJYhS8092196 for ; Tue, 27 Dec 2016 19:34:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 151937] [patch] netstat(1) utility lack support of displaying rtt related counters of tcp sockets Date: Tue, 27 Dec 2016 19:34:43 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org 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: 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: Tue, 27 Dec 2016 19:34:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D151937 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #2 from Hiren Panchasara --- This can be a good addition to '-x' option. Does anyone want to pick it up and adapt it to -HEAD? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 27 19:37:40 2016 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 224CCC93E72 for ; Tue, 27 Dec 2016 19:37:40 +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 11870175A for ; Tue, 27 Dec 2016 19:37:40 +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 uBRJbdsm095986 for ; Tue, 27 Dec 2016 19:37:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193579] [axge] axge driver issue with tcp checksum offload with pf nat Date: Tue, 27 Dec 2016 19:37:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kp@freebsd.org X-Bugzilla-Flags: mfc-stable9+ mfc-stable10+ X-Bugzilla-Changed-Fields: bug_status cc resolution 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: Tue, 27 Dec 2016 19:37:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193579 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed CC| |hiren@FreeBSD.org Resolution|--- |FIXED --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Dec 28 04:08:50 2016 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 96BE0C90550; Wed, 28 Dec 2016 04:08:50 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 5DC981518; Wed, 28 Dec 2016 04:08:50 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by mail-it0-x244.google.com with SMTP id c20so35003698itb.0; Tue, 27 Dec 2016 20:08:50 -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=OqOHKwcBNHPDMJ3SbL7pevobQzcZ62gu+Aifdqgb1XA=; b=OQtkKxhpr+35E06CRbLPsdP4Az6wxJ6I5hl9IHcjexqwTGWFndhihL3fk496hap0Ze fJ5xlD06DbL9jxvm9KodN7y1mc/CcRO0KXN017p/8A9QF+R90shohxdP/kjIHYFWoUdE 9ZvId1uBmni82UtqbW7JcC9lEtP3OHT3T6i8Vt5C9cLpKIDkOScCHWHa5g+AEteqk1lY z0NV1DUx8uzcFZBDYH6K4Ocr86A8gztVMqUW6GKClaJLdmlhv8H3E3ACoa8CPVkJ+rjk 85qMe9rRdGOl9ai1gC7BxY3oeGehslHLsvTEAO6S4mnyxg3ixw5jlEs+FCOj9oun8LY3 XLyA== 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=OqOHKwcBNHPDMJ3SbL7pevobQzcZ62gu+Aifdqgb1XA=; b=ufWwVGM97+BpNprZz3D6WQCKXV9nqxauD/3qIewGi4NhUQ9OD7j1a6HA1n0ZPjaYO7 IXHIvfTZ22UxCy+gq1aV+Uks35RSCgZi/+iB2x40p3cMLoWzLJs5AIc2HDnjKnkR+vSZ XdixRbjzSxQrdNP2lzJ9zG31fK4e3SQc7JEXRJ+L2/2u2B4vORwuIHpQv0XydFL7MVbS L+0Dd9zI7++cgURfNEygT0dz2ilZhZUHlSakMMuMhLN21l3G3B0ookCr0gGrxGrStTtH KCcOZr+H9g2xiWA0c9F4+WJ4VCB9vwMn0b/nsGfn75PubbjkgpXtUUqP2NKhMLXx5OCz aqDQ== X-Gm-Message-State: AIkVDXLrSdngn39PFNUlo2P/cvV+g4WUQpMXqHeIxnrv/+YG0vodZ6B4eZNFIE1wMR3bzHRwTdZjMqrhjW2ucQ== X-Received: by 10.36.120.5 with SMTP id p5mr17859238itc.5.1482898129800; Tue, 27 Dec 2016 20:08:49 -0800 (PST) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.107.55.11 with HTTP; Tue, 27 Dec 2016 20:08:49 -0800 (PST) In-Reply-To: References: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> <5889f1f5-5585-95d4-beac-285dbc722b4e@norma.perm.ru> From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Date: Tue, 27 Dec 2016 20:08:49 -0800 X-Google-Sender-Auth: BtW4BRVxOuUKgkwmWWSIz5HL3Kc Message-ID: Subject: Re: [RFC/RFT] projects/ipsec To: "Andrey V. Elsukov" Cc: Jim Thompson , "Eugene M. Zheganin" , freebsd-net , FreeBSD Current 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: Wed, 28 Dec 2016 04:08:50 -0000 On Tue, Dec 27, 2016 at 6:10 AM, Andrey V. Elsukov wrote: > On 27.12.2016 16:15, Jim Thompson wrote: > >> In it's initial state if_ipsec allows to use only one set of >>> encryption parameters (because only one sainfo anonyumous is >>> possible), so at this time it doesn't allow to create multiple >>> tunnels with VPN hubs that use different cipers and/or transform >>> sets, but as far as I understand this is subject to change and >>> Andrey is already working on a support of this feature from >>> ipsec-tools IKE daemon. >>> >> >> pfSense (which you mention below) is using strongswan, so when >> Andrey is finished with ipsec-tools, we will need to review his >> changes and see what we can do for strongswan. >> >> I'm looking forward to the mutliple-tunnel support, which is >> required for pfSense. >> > > There are no such limits. You can create multiple VTI interfaces. > The problem is in with racoon configuration restrictions. It looks like > ipsec-tools project is dead, I didn't received any replies from > ipsec-tools-devel mailing list. > > I'm not aware how to configure strongswan, so if someone will not try to > do this, I don't know when I will do this. > > Strongswan already supports this. Just the FreeBSD code for it is not there due to the missing feature until now. > -- > WBR, Andrey V. Elsukov > _______________________________________________ > 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" > > -- > Ermal > From owner-freebsd-net@freebsd.org Wed Dec 28 12:22:44 2016 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 4B671C916AE for ; Wed, 28 Dec 2016 12:22:44 +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 3B19D192F for ; Wed, 28 Dec 2016 12:22:44 +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 uBSCMhGT083326 for ; Wed, 28 Dec 2016 12:22:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215613] [panic] if if_ixl due to NULL pointer dereference Date: Wed, 28 Dec 2016 12:22:44 +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: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@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: 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: Wed, 28 Dec 2016 12:22:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215613 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- 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 Wed Dec 28 18:06:45 2016 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 5690FC95A7B for ; Wed, 28 Dec 2016 18:06:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3040B17EA; Wed, 28 Dec 2016 18:06:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id D558610A761; Wed, 28 Dec 2016 13:06:43 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Cc: Luigi Rizzo , Adrian Chadd , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar , Vincenzo Maffione Subject: Re: cxgbe's native netmap support broken since r307394 Date: Wed, 28 Dec 2016 10:06:41 -0800 Message-ID: <2698793.0b4KyHrqck@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20161217222812.GA4979@ox> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 28 Dec 2016 13:06:43 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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, 28 Dec 2016 18:06:45 -0000 Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to be a smaller patch and probably more correct for FreeBSD. On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote: > sure go ahead and thank you! > > On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd wrote: > > ok, does anyone mind if I commit it as-is? > > > > > > -a > > > > > > On 21 December 2016 at 13:37, Vincenzo Maffione wrote: > >> Hi Luigi, > >> I attached a minimal change containing two fixes: > >> > >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related > >> to this thread > >> - use the proper locking functions for the "worker_lock", unrelated > >> but needed to avoid the O.S. to trap because of a mismatch between > >> MTX_SPIN and MTX_DEF. > >> > >> Cheers, > >> Vincenzo > >> > >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo : > >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione > >>> wrote: > >>>> Hi, > >>>> There is no commit related to that in the FreeBSD svn or git. > >>>> > >>>> The fix has been published to the github netmap repository here > >>>> (branch master): https://github.com/luigirizzo/netmap > >>>> > >>>> What we should do is to import all the recent updates from the github > >>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me > >>>> know. > >>> > >>> I just checked and the diff between FreeBSD head and netmap head > >>> in github is almost 3k lines due to a lot of recent refactoring. > >>> So, if there is an easy way to extract just the locking change that would > >>> be preferable as an interim solution. > >>> > >>> cheers > >>> luigi > >>> > >>>> > >>>> Cheers, > >>>> Vincenzo > >>>> > >>>> > >>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd : > >>>>> hi, > >>>>> > >>>>> What's the commit? We should get it into -HEAD asap. > >>>>> > >>>>> > >>>>> -adrian > >>>>> > >>>>> > >>>>> On 20 December 2016 at 01:25, Vincenzo Maffione wrote: > >>>>>> Ok, applied to the netmap github repo. > >>>>>> This fix will be published when Luigi does the next commit on FreeBSD. > >>>>>> > >>>>>> Cheers, > >>>>>> Vincenzo > >>>>>> > >>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar : > >>>>>>> IFNET_RLOCK will work, thanks. > >>>>>>> > >>>>>>> Navdeep > >>>>>>> > >>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: > >>>>>>>> Hi Navdeep, > >>>>>>>> > >>>>>>>> Indeed, we have reviewed the code, and we think it is ok to > >>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using > >>>>>>>> IFNET_WLOCK(). > >>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. > >>>>>>>> > >>>>>>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie(). > >>>>>>>> However, on Linux the same lock is also needed to protect the call to > >>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified" > >>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock. > >>>>>>>> > >>>>>>>> Does this make sense to you? Would it be easy for you to make a quick > >>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Vincenzo > >>>>>>>> > >>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar : > >>>>>>>>> Luigi, Vincenzo, > >>>>>>>>> > >>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's > >>>>>>>>> native netmap support. The problem is that netmap_hw_reg now holds an > >>>>>>>>> rw_lock around the driver's netmap_on/off routines. It has always been > >>>>>>>>> safe for the driver to sleep during these operations but now it panics > >>>>>>>>> instead. > >>>>>>>>> > >>>>>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to disallow > >>>>>>>>> sleep on the control path. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Navdeep > >>>>>>>>> > >>>>>>>>> begin_synchronized_op with the following non-sleepable locks held: > >>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff8271d680) locked @ > >>>>>>>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95 > >>>>>>>>> stack backtrace: > >>>>>>>>> #0 0xffffffff810837a5 at witness_debugger+0xe5 > >>>>>>>>> #1 0xffffffff81084d88 at witness_warn+0x3b8 > >>>>>>>>> #2 0xffffffff83ef2bcc at begin_synchronized_op+0x6c > >>>>>>>>> #3 0xffffffff83f14beb at cxgbe_netmap_reg+0x5b > >>>>>>>>> #4 0xffffffff809846f1 at netmap_hw_reg+0x81 > >>>>>>>>> #5 0xffffffff809806de at netmap_do_regif+0x19e > >>>>>>>>> #6 0xffffffff8098121d at netmap_ioctl+0x7ad > >>>>>>>>> #7 0xffffffff8098682f at freebsd_netmap_ioctl+0x5f > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Vincenzo Maffione > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>> _______________________________________________ > >>>>>> 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 > >>> > >>> > >>> > >>> -- > >>> -----------------------------------------+------------------------------- > >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > >>> TEL +39-050-2217533 . via Diotisalvi 2 > >>> Mobile +39-338-6809875 . 56122 PISA (Italy) > >>> -----------------------------------------+------------------------------- > >> > >> > >> > >> -- > >> Vincenzo Maffione > > > > -- John Baldwin From owner-freebsd-net@freebsd.org Wed Dec 28 18:09:34 2016 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 889FAC95BB5 for ; Wed, 28 Dec 2016 18:09:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 68AAE1B3E for ; Wed, 28 Dec 2016 18:09:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 96A0C10A76C for ; Wed, 28 Dec 2016 13:09:32 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: aio_write and PRUS_MORETOCOME Date: Wed, 28 Dec 2016 10:09:27 -0800 Message-ID: <4088181.HpKjA8cOgr@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 28 Dec 2016 13:09:32 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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, 28 Dec 2016 18:09:34 -0000 For folks who are interested, I have uploaded a patch to phabricator that will set PRUS_MORETOCOME when there are multiple writes queued up to a socket via aio_write(). This mostly matters for TCP. Silly arc wouldn't let me add 'network' to the review, but you can find the revision at https://reviews.freebsd.org/D8955 if you'd like to comment/review. -- John Baldwin From owner-freebsd-net@freebsd.org Wed Dec 28 18:25:25 2016 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 2D0F2C94125 for ; Wed, 28 Dec 2016 18:25:25 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::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 EEBBC15B1; Wed, 28 Dec 2016 18:25:24 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id 3so23397074oih.1; Wed, 28 Dec 2016 10:25:24 -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=i3ZIsUUBqcbzOgP/N6CDlWkY3z9wMfJnAgS70+1iXtY=; b=Za3glGU3Tio9HOCfSD48WZV4Y9XDq9VdkdIRaLfCJ9XjbKRPqTxDoX+jt1eguMmG8m 8QXKJFRKzD9FaXKtjzmjomwpgnVHXpwhBmqP/qOYFlObSqKvHUZj3UASv83B2A52iYom n2DhT7+oz7WBCKKnlODDI1aiSNR6cMmOMwLc1ANxD2iMzlebhaAL0Mfgj+Ta8Ier9kTn wMOgpI8U2a4wAEeaZ574WgKtj0PY+OC72UUVXgE/d16Y0CXzuSdNkQly5pOEnx7Yh7Aa T1WTaj0bwmMfVRfUbODOAaj97o66b02cd/kuHSPMJK9PvQqABROgxZ+tqcUYu5vhpQqN PNAQ== 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=i3ZIsUUBqcbzOgP/N6CDlWkY3z9wMfJnAgS70+1iXtY=; b=GPoqdzmb3Yf27RRGwu9/mdwyvvaugvrXMTiyi0e9DgkC51jDebRvzGP/z2OKJbxmJB b5SoEJ/igjsoGKMzYciNarZaC6Q64SqAhCveGn2ecz/Uyvq2T4ZO5wTBC1Amv9wCwIT1 CKpljNNNccW/CQFG3U1l00owNZD7fQEe83186MIla1mDut+bS5nAotpGadj4e0zFrpXD 0n95xQLCjlJGlfiIXFIQzOT/6Dd8W0wt/2jXvjKfWzm7xugy14R0OFHTmGGnIGhQJHst YDaHUtqtvAOf4Lk1juIj4JxcVLBaBsQACF0WBpafkUoCfo1kld6hN+qKsS/9BAYL/9hv Q/NA== X-Gm-Message-State: AIkVDXKGaeFOfE91EEhvMEa0Dri+HYfBMpWAEojn83AnW7+0oQSztaT+qCxPonfgphlIrTkuxjnK60hKm+jxlg== X-Received: by 10.157.12.172 with SMTP id b41mr20506757otb.105.1482949522882; Wed, 28 Dec 2016 10:25:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.200 with HTTP; Wed, 28 Dec 2016 10:25:22 -0800 (PST) In-Reply-To: <2698793.0b4KyHrqck@ralph.baldwin.cx> References: <20161217222812.GA4979@ox> <2698793.0b4KyHrqck@ralph.baldwin.cx> From: Vincenzo Maffione Date: Wed, 28 Dec 2016 19:25:22 +0100 Message-ID: Subject: Re: cxgbe's native netmap support broken since r307394 To: John Baldwin Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Adrian Chadd , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar 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: Wed, 28 Dec 2016 18:25:25 -0000 Hi, The "worker_lock" is taken by nm_os_kthread_wakeup_worker(), which in turn is called by nm_pt_host_notify(). The latter function is a callback that may be called by a driver interrupt service routine; more precisely this happens when the driver calls netmap_tx_irq() or netmap_rx_irq(). As far as I know in FreeBSD it is not possible to lock a MTX_DEF mtx inside an ISR. Am I wrong on this? Cheers, Vincenzo 2016-12-28 19:06 GMT+01:00 John Baldwin : > Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to > be a smaller patch and probably more correct for FreeBSD. > > On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote: >> sure go ahead and thank you! >> >> On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd wrote: >> > ok, does anyone mind if I commit it as-is? >> > >> > >> > -a >> > >> > >> > On 21 December 2016 at 13:37, Vincenzo Maffione wrote: >> >> Hi Luigi, >> >> I attached a minimal change containing two fixes: >> >> >> >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related >> >> to this thread >> >> - use the proper locking functions for the "worker_lock", unrelated >> >> but needed to avoid the O.S. to trap because of a mismatch between >> >> MTX_SPIN and MTX_DEF. >> >> >> >> Cheers, >> >> Vincenzo >> >> >> >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo : >> >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione >> >>> wrote: >> >>>> Hi, >> >>>> There is no commit related to that in the FreeBSD svn or git. >> >>>> >> >>>> The fix has been published to the github netmap repository here >> >>>> (branch master): https://github.com/luigirizzo/netmap >> >>>> >> >>>> What we should do is to import all the recent updates from the github >> >>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me >> >>>> know. >> >>> >> >>> I just checked and the diff between FreeBSD head and netmap head >> >>> in github is almost 3k lines due to a lot of recent refactoring. >> >>> So, if there is an easy way to extract just the locking change that would >> >>> be preferable as an interim solution. >> >>> >> >>> cheers >> >>> luigi >> >>> >> >>>> >> >>>> Cheers, >> >>>> Vincenzo >> >>>> >> >>>> >> >>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd : >> >>>>> hi, >> >>>>> >> >>>>> What's the commit? We should get it into -HEAD asap. >> >>>>> >> >>>>> >> >>>>> -adrian >> >>>>> >> >>>>> >> >>>>> On 20 December 2016 at 01:25, Vincenzo Maffione wrote: >> >>>>>> Ok, applied to the netmap github repo. >> >>>>>> This fix will be published when Luigi does the next commit on FreeBSD. >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Vincenzo >> >>>>>> >> >>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar : >> >>>>>>> IFNET_RLOCK will work, thanks. >> >>>>>>> >> >>>>>>> Navdeep >> >>>>>>> >> >>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: >> >>>>>>>> Hi Navdeep, >> >>>>>>>> >> >>>>>>>> Indeed, we have reviewed the code, and we think it is ok to >> >>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using >> >>>>>>>> IFNET_WLOCK(). >> >>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. >> >>>>>>>> >> >>>>>>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie(). >> >>>>>>>> However, on Linux the same lock is also needed to protect the call to >> >>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified" >> >>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock. >> >>>>>>>> >> >>>>>>>> Does this make sense to you? Would it be easy for you to make a quick >> >>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK? >> >>>>>>>> >> >>>>>>>> Thanks, >> >>>>>>>> Vincenzo >> >>>>>>>> >> >>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar : >> >>>>>>>>> Luigi, Vincenzo, >> >>>>>>>>> >> >>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's >> >>>>>>>>> native netmap support. The problem is that netmap_hw_reg now holds an >> >>>>>>>>> rw_lock around the driver's netmap_on/off routines. It has always been >> >>>>>>>>> safe for the driver to sleep during these operations but now it panics >> >>>>>>>>> instead. >> >>>>>>>>> >> >>>>>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to disallow >> >>>>>>>>> sleep on the control path. >> >>>>>>>>> >> >>>>>>>>> Regards, >> >>>>>>>>> Navdeep >> >>>>>>>>> >> >>>>>>>>> begin_synchronized_op with the following non-sleepable locks held: >> >>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff8271d680) locked @ >> >>>>>>>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95 >> >>>>>>>>> stack backtrace: >> >>>>>>>>> #0 0xffffffff810837a5 at witness_debugger+0xe5 >> >>>>>>>>> #1 0xffffffff81084d88 at witness_warn+0x3b8 >> >>>>>>>>> #2 0xffffffff83ef2bcc at begin_synchronized_op+0x6c >> >>>>>>>>> #3 0xffffffff83f14beb at cxgbe_netmap_reg+0x5b >> >>>>>>>>> #4 0xffffffff809846f1 at netmap_hw_reg+0x81 >> >>>>>>>>> #5 0xffffffff809806de at netmap_do_regif+0x19e >> >>>>>>>>> #6 0xffffffff8098121d at netmap_ioctl+0x7ad >> >>>>>>>>> #7 0xffffffff8098682f at freebsd_netmap_ioctl+0x5f >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Vincenzo Maffione >> >>>>>>>> _______________________________________________ >> >>>>>>>> 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 >> >>>>>> _______________________________________________ >> >>>>>> 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 >> >>> >> >>> >> >>> >> >>> -- >> >>> -----------------------------------------+------------------------------- >> >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> >>> TEL +39-050-2217533 . via Diotisalvi 2 >> >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >> >>> -----------------------------------------+------------------------------- >> >> >> >> >> >> >> >> -- >> >> Vincenzo Maffione >> >> >> >> > > > -- > John Baldwin -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Thu Dec 29 01:06:34 2016 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 00ABCC94EB8 for ; Thu, 29 Dec 2016 01:06:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF8411702; Thu, 29 Dec 2016 01:06:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 6A2B810AA56; Wed, 28 Dec 2016 20:06:32 -0500 (EST) From: John Baldwin To: Vincenzo Maffione Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Adrian Chadd , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar Subject: Re: cxgbe's native netmap support broken since r307394 Date: Wed, 28 Dec 2016 17:06:22 -0800 Message-ID: <9729046.di4hkLAXiP@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20161217222812.GA4979@ox> <2698793.0b4KyHrqck@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 28 Dec 2016 20:06:32 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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, 29 Dec 2016 01:06:34 -0000 On Wednesday, December 28, 2016 07:25:22 PM Vincenzo Maffione wrote: > Hi, > The "worker_lock" is taken by nm_os_kthread_wakeup_worker(), which > in turn is called by nm_pt_host_notify(). The latter function is a > callback that may be called by a driver interrupt service routine; > more precisely this happens when the driver calls netmap_tx_irq() or > netmap_rx_irq(). As far as I know in FreeBSD it is not possible to > lock a MTX_DEF mtx inside an ISR. Am I wrong on this? It depends. Most interrupt handlers run in ithreads and can use MTX_DEF. Only interrupt handlers that run from a filter are restricted to using MTX_SPIN. Looking at all the calls to netmap_[tr]x_irq() in the tree, they are all done from contexts that are safe to use MTX_DEF (and in general they have to be as the equivalent code for the non-netmap case is calling routines like if_input or m_freem that can't be invoked from a filter either). > > Cheers, > Vincenzo > > 2016-12-28 19:06 GMT+01:00 John Baldwin : > > Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to > > be a smaller patch and probably more correct for FreeBSD. > > > > On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote: > >> sure go ahead and thank you! > >> > >> On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd wrote: > >> > ok, does anyone mind if I commit it as-is? > >> > > >> > > >> > -a > >> > > >> > > >> > On 21 December 2016 at 13:37, Vincenzo Maffione wrote: > >> >> Hi Luigi, > >> >> I attached a minimal change containing two fixes: > >> >> > >> >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related > >> >> to this thread > >> >> - use the proper locking functions for the "worker_lock", unrelated > >> >> but needed to avoid the O.S. to trap because of a mismatch between > >> >> MTX_SPIN and MTX_DEF. > >> >> > >> >> Cheers, > >> >> Vincenzo > >> >> > >> >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo : > >> >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione > >> >>> wrote: > >> >>>> Hi, > >> >>>> There is no commit related to that in the FreeBSD svn or git. > >> >>>> > >> >>>> The fix has been published to the github netmap repository here > >> >>>> (branch master): https://github.com/luigirizzo/netmap > >> >>>> > >> >>>> What we should do is to import all the recent updates from the github > >> >>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me > >> >>>> know. > >> >>> > >> >>> I just checked and the diff between FreeBSD head and netmap head > >> >>> in github is almost 3k lines due to a lot of recent refactoring. > >> >>> So, if there is an easy way to extract just the locking change that would > >> >>> be preferable as an interim solution. > >> >>> > >> >>> cheers > >> >>> luigi > >> >>> > >> >>>> > >> >>>> Cheers, > >> >>>> Vincenzo > >> >>>> > >> >>>> > >> >>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd : > >> >>>>> hi, > >> >>>>> > >> >>>>> What's the commit? We should get it into -HEAD asap. > >> >>>>> > >> >>>>> > >> >>>>> -adrian > >> >>>>> > >> >>>>> > >> >>>>> On 20 December 2016 at 01:25, Vincenzo Maffione wrote: > >> >>>>>> Ok, applied to the netmap github repo. > >> >>>>>> This fix will be published when Luigi does the next commit on FreeBSD. > >> >>>>>> > >> >>>>>> Cheers, > >> >>>>>> Vincenzo > >> >>>>>> > >> >>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar : > >> >>>>>>> IFNET_RLOCK will work, thanks. > >> >>>>>>> > >> >>>>>>> Navdeep > >> >>>>>>> > >> >>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: > >> >>>>>>>> Hi Navdeep, > >> >>>>>>>> > >> >>>>>>>> Indeed, we have reviewed the code, and we think it is ok to > >> >>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using > >> >>>>>>>> IFNET_WLOCK(). > >> >>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. > >> >>>>>>>> > >> >>>>>>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie(). > >> >>>>>>>> However, on Linux the same lock is also needed to protect the call to > >> >>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified" > >> >>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock. > >> >>>>>>>> > >> >>>>>>>> Does this make sense to you? Would it be easy for you to make a quick > >> >>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK? > >> >>>>>>>> > >> >>>>>>>> Thanks, > >> >>>>>>>> Vincenzo > >> >>>>>>>> > >> >>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar : > >> >>>>>>>>> Luigi, Vincenzo, > >> >>>>>>>>> > >> >>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's > >> >>>>>>>>> native netmap support. The problem is that netmap_hw_reg now holds an > >> >>>>>>>>> rw_lock around the driver's netmap_on/off routines. It has always been > >> >>>>>>>>> safe for the driver to sleep during these operations but now it panics > >> >>>>>>>>> instead. > >> >>>>>>>>> > >> >>>>>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to disallow > >> >>>>>>>>> sleep on the control path. > >> >>>>>>>>> > >> >>>>>>>>> Regards, > >> >>>>>>>>> Navdeep > >> >>>>>>>>> > >> >>>>>>>>> begin_synchronized_op with the following non-sleepable locks held: > >> >>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff8271d680) locked @ > >> >>>>>>>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95 > >> >>>>>>>>> stack backtrace: > >> >>>>>>>>> #0 0xffffffff810837a5 at witness_debugger+0xe5 > >> >>>>>>>>> #1 0xffffffff81084d88 at witness_warn+0x3b8 > >> >>>>>>>>> #2 0xffffffff83ef2bcc at begin_synchronized_op+0x6c > >> >>>>>>>>> #3 0xffffffff83f14beb at cxgbe_netmap_reg+0x5b > >> >>>>>>>>> #4 0xffffffff809846f1 at netmap_hw_reg+0x81 > >> >>>>>>>>> #5 0xffffffff809806de at netmap_do_regif+0x19e > >> >>>>>>>>> #6 0xffffffff8098121d at netmap_ioctl+0x7ad > >> >>>>>>>>> #7 0xffffffff8098682f at freebsd_netmap_ioctl+0x5f > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> -- > >> >>>>>>>> Vincenzo Maffione > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> 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 > >> >>>>>> _______________________________________________ > >> >>>>>> 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 > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> -----------------------------------------+------------------------------- > >> >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > >> >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > >> >>> TEL +39-050-2217533 . via Diotisalvi 2 > >> >>> Mobile +39-338-6809875 . 56122 PISA (Italy) > >> >>> -----------------------------------------+------------------------------- > >> >> > >> >> > >> >> > >> >> -- > >> >> Vincenzo Maffione > >> > >> > >> > >> > > > > > > -- > > John Baldwin > > > > -- John Baldwin From owner-freebsd-net@freebsd.org Thu Dec 29 02:33:55 2016 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 7ACEEC95E7C for ; Thu, 29 Dec 2016 02:33:55 +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 5F2C417CB for ; Thu, 29 Dec 2016 02:33:55 +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 uBT2XsGG055520 for ; Thu, 29 Dec 2016 02:33:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196361] Constrain IPv6 routes to each FIB (Consistent with IPv4 route behaviour) Date: Thu, 29 Dec 2016 02:33:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhujhiti@adjectivism.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: attachments.created 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, 29 Dec 2016 02:33:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196361 --- Comment #11 from jhujhiti@adjectivism.org --- Created attachment 178370 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178370&action= =3Dedit inet6 test cases (In reply to Alan Somers from comment #10) Hi Alan, Here are the test cases. I've created inet6 variants of loopback_and_network_routes_on_nondefault_fib, default_route_with_multiple_fibs_on_same_subnet, and subnet_route_with_multiple_fibs_on_same_subnet. Regarding same_ip_multiple_ifaces_fib0: should this even work for IPv4? To = me, it seems invalid to allow conflicting local addresses in the same FIB. In a= ny case, neither current HEAD nor my patch allow this situation for inet6. The second address addition will fail with EEXIST. However, assigning the same address to interfaces in different FIBs does make sense and work, so I've created an inet6 variant of same_ip_multiple_ifaces instead. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Dec 29 08:17:52 2016 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 5BBECC958DE for ; Thu, 29 Dec 2016 08:17: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 346D717EA for ; Thu, 29 Dec 2016 08:17:52 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 8D403356C4; Thu, 29 Dec 2016 08:17:51 +0000 (UTC) Date: Thu, 29 Dec 2016 08:17:51 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D8963+325+d689c69326b9ae09@reviews.freebsd.org Subject: [Differential] D8963: ifnet: introduce event handlers for ifup/ifdown events 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: 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: Precedence: bulk In-Reply-To: References: Thread-Index: Y2E4NDdjNWVjOGM5NzQ0Mjk1ZTMzMGM0ZDY2IFhkxq8= 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, 29 Dec 2016 08:17:52 -0000 c2VwaGVyb3NhX2dtYWlsLmNvbSBhZGRlZCByZXZpZXdlcnM6IGdsZWJpdXMsIGdubiwgcndhdHNv bi4Kc2VwaGVyb3NhX2dtYWlsLmNvbSBhZGRlZCBhIHN1YnNjcmliZXI6IGZyZWVic2QtbmV0LWxp c3QuCgpSRVZJU0lPTiBERVRBSUwKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDg5NjMK CkVNQUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3NldHRpbmdz L3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvCgpUbzogZGVjdWlfbWljcm9zb2Z0LmNvbSwgaHNlbGFz a3ksIHNlcGhlcm9zYV9nbWFpbC5jb20sIGNlbSwgbnAsIGttYWN5LCBraWIsIGhvbnpoYW5fbWlj cm9zb2Z0LmNvbSwgaG93YXJkMHN1X2dtYWlsLmNvbSwgamhiLCBhZSwgZGVscGhpaiwgcm95Z2Vy LCBnbGViaXVzLCBnbm4sIHJ3YXRzb24KQ2M6IGZyZWVic2QtbmV0LWxpc3QK From owner-freebsd-net@freebsd.org Thu Dec 29 09:02:34 2016 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 56012C96B15 for ; Thu, 29 Dec 2016 09:02:34 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::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 182921711; Thu, 29 Dec 2016 09:02:34 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id f201so54042947oib.0; Thu, 29 Dec 2016 01:02:34 -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=iZAsT+1mP15/m5IcXIZhGD2eybdSiPVrjEgM1dvTSeo=; b=BzgRlJVR7HMU2jkeI1Uu96OJFTqnbCfEYmEEwM0pbwvb8trmoa3Xx3tX+2Q4zEK4Bd 5wlkz6XdSOeoaoZ5s04UfoWMiNCbjGidOH8zD5n6zsyrcFt29KCJJKOtHEDAE0n3P7+f FOpWuE9TL4U5A621iH36QjK5Sen9KG9x1xj5yehkZMh5xsJirqADKrCL0mnLnoxwnHGq rztctjw0RdMTeY/a2O7lCyFB/rikla9lTATK5pH16nZUyoDjST4B2IeiNxrVW7arvjPl nspM7RqK9WpGUAr5w8yXvJPSaMb724SuuQzyPpcmREWzBEcPSMDV3FPKsWfgjEZob28q JVzQ== 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=iZAsT+1mP15/m5IcXIZhGD2eybdSiPVrjEgM1dvTSeo=; b=hUvPvNQzQceRHzgKY214D8jXvbnqxFkgS6xmgSONKHBemXWGMXUU3A08/AFXd3NYuA KvJ4sXYysNFVg670RUcxLTY96hcv5Tf6hzq1tr1PFZ7lDCMAZihE6JbolAuxms4q5Cp3 qUd8+MfdkQxtQBYa9IzoWRb8eyAVUGEq+2MApiBM9/FbzlJWkTgBSxWARM2U6maWrBrQ eADDbrlSAS62/ssIspDK0NZmNMFPvC2uGgQrqF5UdksfwDBCp2gHNHpoR+Rw8QusbEhp y8HjkM88frmr+arJC88pDF7nKfVncwEgznywnhahWLjRRXLHdRZrPQjuYRFjnLEBJti9 /+ng== X-Gm-Message-State: AIkVDXKmSAvYPSmDKFkBNrpgY7tD6PJB/MkW/VyF7+n6USe5JQUD6QzmtXnfhGX5JmLbLqKgs5jWOv/kwKqvDg== X-Received: by 10.157.16.16 with SMTP id h16mr21569932ote.40.1483002152827; Thu, 29 Dec 2016 01:02:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.200 with HTTP; Thu, 29 Dec 2016 01:02:32 -0800 (PST) In-Reply-To: <9729046.di4hkLAXiP@ralph.baldwin.cx> References: <20161217222812.GA4979@ox> <2698793.0b4KyHrqck@ralph.baldwin.cx> <9729046.di4hkLAXiP@ralph.baldwin.cx> From: Vincenzo Maffione Date: Thu, 29 Dec 2016 10:02:32 +0100 Message-ID: Subject: Re: cxgbe's native netmap support broken since r307394 To: John Baldwin Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Adrian Chadd , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar Content-Type: multipart/mixed; boundary=001a1134f68e8558c00544c858c9 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, 29 Dec 2016 09:02:34 -0000 --001a1134f68e8558c00544c858c9 Content-Type: text/plain; charset=UTF-8 Ok, thanks for the clarification. I change the lock type to MTX_DEF (and did a test). I attached the new patch. Cheers, Vincenzo 2016-12-29 2:06 GMT+01:00 John Baldwin : > On Wednesday, December 28, 2016 07:25:22 PM Vincenzo Maffione wrote: >> Hi, >> The "worker_lock" is taken by nm_os_kthread_wakeup_worker(), which >> in turn is called by nm_pt_host_notify(). The latter function is a >> callback that may be called by a driver interrupt service routine; >> more precisely this happens when the driver calls netmap_tx_irq() or >> netmap_rx_irq(). As far as I know in FreeBSD it is not possible to >> lock a MTX_DEF mtx inside an ISR. Am I wrong on this? > > It depends. Most interrupt handlers run in ithreads and can use MTX_DEF. > Only interrupt handlers that run from a filter are restricted to using > MTX_SPIN. Looking at all the calls to netmap_[tr]x_irq() in the tree, > they are all done from contexts that are safe to use MTX_DEF (and in > general they have to be as the equivalent code for the non-netmap case > is calling routines like if_input or m_freem that can't be invoked from > a filter either). > >> >> Cheers, >> Vincenzo >> >> 2016-12-28 19:06 GMT+01:00 John Baldwin : >> > Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to >> > be a smaller patch and probably more correct for FreeBSD. >> > >> > On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote: >> >> sure go ahead and thank you! >> >> >> >> On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd wrote: >> >> > ok, does anyone mind if I commit it as-is? >> >> > >> >> > >> >> > -a >> >> > >> >> > >> >> > On 21 December 2016 at 13:37, Vincenzo Maffione wrote: >> >> >> Hi Luigi, >> >> >> I attached a minimal change containing two fixes: >> >> >> >> >> >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related >> >> >> to this thread >> >> >> - use the proper locking functions for the "worker_lock", unrelated >> >> >> but needed to avoid the O.S. to trap because of a mismatch between >> >> >> MTX_SPIN and MTX_DEF. >> >> >> >> >> >> Cheers, >> >> >> Vincenzo >> >> >> >> >> >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo : >> >> >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione >> >> >>> wrote: >> >> >>>> Hi, >> >> >>>> There is no commit related to that in the FreeBSD svn or git. >> >> >>>> >> >> >>>> The fix has been published to the github netmap repository here >> >> >>>> (branch master): https://github.com/luigirizzo/netmap >> >> >>>> >> >> >>>> What we should do is to import all the recent updates from the github >> >> >>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me >> >> >>>> know. >> >> >>> >> >> >>> I just checked and the diff between FreeBSD head and netmap head >> >> >>> in github is almost 3k lines due to a lot of recent refactoring. >> >> >>> So, if there is an easy way to extract just the locking change that would >> >> >>> be preferable as an interim solution. >> >> >>> >> >> >>> cheers >> >> >>> luigi >> >> >>> >> >> >>>> >> >> >>>> Cheers, >> >> >>>> Vincenzo >> >> >>>> >> >> >>>> >> >> >>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd : >> >> >>>>> hi, >> >> >>>>> >> >> >>>>> What's the commit? We should get it into -HEAD asap. >> >> >>>>> >> >> >>>>> >> >> >>>>> -adrian >> >> >>>>> >> >> >>>>> >> >> >>>>> On 20 December 2016 at 01:25, Vincenzo Maffione wrote: >> >> >>>>>> Ok, applied to the netmap github repo. >> >> >>>>>> This fix will be published when Luigi does the next commit on FreeBSD. >> >> >>>>>> >> >> >>>>>> Cheers, >> >> >>>>>> Vincenzo >> >> >>>>>> >> >> >>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar : >> >> >>>>>>> IFNET_RLOCK will work, thanks. >> >> >>>>>>> >> >> >>>>>>> Navdeep >> >> >>>>>>> >> >> >>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: >> >> >>>>>>>> Hi Navdeep, >> >> >>>>>>>> >> >> >>>>>>>> Indeed, we have reviewed the code, and we think it is ok to >> >> >>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using >> >> >>>>>>>> IFNET_WLOCK(). >> >> >>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. >> >> >>>>>>>> >> >> >>>>>>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie(). >> >> >>>>>>>> However, on Linux the same lock is also needed to protect the call to >> >> >>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified" >> >> >>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock. >> >> >>>>>>>> >> >> >>>>>>>> Does this make sense to you? Would it be easy for you to make a quick >> >> >>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK? >> >> >>>>>>>> >> >> >>>>>>>> Thanks, >> >> >>>>>>>> Vincenzo >> >> >>>>>>>> >> >> >>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar : >> >> >>>>>>>>> Luigi, Vincenzo, >> >> >>>>>>>>> >> >> >>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's >> >> >>>>>>>>> native netmap support. The problem is that netmap_hw_reg now holds an >> >> >>>>>>>>> rw_lock around the driver's netmap_on/off routines. It has always been >> >> >>>>>>>>> safe for the driver to sleep during these operations but now it panics >> >> >>>>>>>>> instead. >> >> >>>>>>>>> >> >> >>>>>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to disallow >> >> >>>>>>>>> sleep on the control path. >> >> >>>>>>>>> >> >> >>>>>>>>> Regards, >> >> >>>>>>>>> Navdeep >> >> >>>>>>>>> >> >> >>>>>>>>> begin_synchronized_op with the following non-sleepable locks held: >> >> >>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff8271d680) locked @ >> >> >>>>>>>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95 >> >> >>>>>>>>> stack backtrace: >> >> >>>>>>>>> #0 0xffffffff810837a5 at witness_debugger+0xe5 >> >> >>>>>>>>> #1 0xffffffff81084d88 at witness_warn+0x3b8 >> >> >>>>>>>>> #2 0xffffffff83ef2bcc at begin_synchronized_op+0x6c >> >> >>>>>>>>> #3 0xffffffff83f14beb at cxgbe_netmap_reg+0x5b >> >> >>>>>>>>> #4 0xffffffff809846f1 at netmap_hw_reg+0x81 >> >> >>>>>>>>> #5 0xffffffff809806de at netmap_do_regif+0x19e >> >> >>>>>>>>> #6 0xffffffff8098121d at netmap_ioctl+0x7ad >> >> >>>>>>>>> #7 0xffffffff8098682f at freebsd_netmap_ioctl+0x5f >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> -- >> >> >>>>>>>> Vincenzo Maffione >> >> >>>>>>>> _______________________________________________ >> >> >>>>>>>> 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 >> >> >>>>>> _______________________________________________ >> >> >>>>>> 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 >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> -----------------------------------------+------------------------------- >> >> >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> >> >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> >> >>> TEL +39-050-2217533 . via Diotisalvi 2 >> >> >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >> >> >>> -----------------------------------------+------------------------------- >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Vincenzo Maffione >> >> >> >> >> >> >> >> >> > >> > >> > -- >> > John Baldwin >> >> >> >> > > > -- > John Baldwin -- Vincenzo Maffione --001a1134f68e8558c00544c858c9 Content-Type: text/x-patch; charset=US-ASCII; name="netmap-fix-2.patch" Content-Disposition: attachment; filename="netmap-fix-2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ixa54qhv0 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvbmV0bWFwL25ldG1hcF9mcmVlYnNkLmMgYi9zeXMvZGV2L25l dG1hcC9uZXRtYXBfZnJlZWJzZC5jCmluZGV4IGZkNDU5MmI3YjVhLi5kZDQxYzg1OTY1ZSAxMDA2 NDQKLS0tIGEvc3lzL2Rldi9uZXRtYXAvbmV0bWFwX2ZyZWVic2QuYworKysgYi9zeXMvZGV2L25l dG1hcC9uZXRtYXBfZnJlZWJzZC5jCkBAIC05Miw3ICs5Miw3IEBAIG5tX29zX3NlbGluZm9fdW5p bml0KE5NX1NFTElORk9fVCAqc2kpCiB2b2lkCiBubV9vc19pZm5ldF9sb2NrKHZvaWQpCiB7Ci0J SUZORVRfV0xPQ0soKTsKKwlJRk5FVF9STE9DSygpOwogfQogCiB2b2lkCkBAIC0xMDkwLDggKzEw OTAsOCBAQCBubV9rdGhyZWFkX3dvcmtlcih2b2lkICpkYXRhKQogCQkJCWNvbnRpbnVlOwogCQkJ fSBlbHNlIGlmIChubWstPnJ1bikgewogCQkJCS8qIHdhaXQgb24gZXZlbnQgd2l0aCBvbmUgc2Vj b25kIHRpbWVvdXQgKi8KLQkJCQltc2xlZXBfc3Bpbigodm9pZCAqKSh1aW50cHRyX3QpY3R4LT5j Zmcud2NoYW4sCi0JCQkJICAgICZubWstPndvcmtlcl9sb2NrLCAibm1rX2V2IiwgaHopOworCQkJ CW1zbGVlcCgodm9pZCAqKSh1aW50cHRyX3QpY3R4LT5jZmcud2NoYW4sCisJCQkJCSZubWstPndv cmtlcl9sb2NrLCAwLCAibm1rX2V2IiwgaHopOwogCQkJCW5tay0+c2NoZWR1bGVkKys7CiAJCQl9 CiAJCQltdHhfdW5sb2NrKCZubWstPndvcmtlcl9sb2NrKTsKQEAgLTExMjIsNyArMTEyMiw3IEBA IG5tX29zX2t0aHJlYWRfY3JlYXRlKHN0cnVjdCBubV9rdGhyZWFkX2NmZyAqY2ZnLCB1bnNpZ25l ZCBpbnQgY2ZndHlwZSwKIAlpZiAoIW5taykKIAkJcmV0dXJuIE5VTEw7CiAKLQltdHhfaW5pdCgm bm1rLT53b3JrZXJfbG9jaywgIm5tX2t0aHJlYWQgbG9jayIsIE5VTEwsIE1UWF9TUElOKTsKKwlt dHhfaW5pdCgmbm1rLT53b3JrZXJfbG9jaywgIm5tX2t0aHJlYWQgbG9jayIsIE5VTEwsIE1UWF9E RUYpOwogCW5tay0+d29ya2VyX2N0eC53b3JrZXJfZm4gPSBjZmctPndvcmtlcl9mbjsKIAlubWst Pndvcmtlcl9jdHgud29ya2VyX3ByaXZhdGUgPSBjZmctPndvcmtlcl9wcml2YXRlOwogCW5tay0+ d29ya2VyX2N0eC50eXBlID0gY2ZnLT50eXBlOwo= --001a1134f68e8558c00544c858c9-- From owner-freebsd-net@freebsd.org Thu Dec 29 09:28:10 2016 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 545DFC93504 for ; Thu, 29 Dec 2016 09:28:10 +0000 (UTC) (envelope-from admin@x180.save99off.com) Received: from x180.save99off.com (x180.save99off.com [43.251.229.180]) by mx1.freebsd.org (Postfix) with ESMTP id 07D7318DB for ; Thu, 29 Dec 2016 09:28:09 +0000 (UTC) (envelope-from admin@x180.save99off.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=save99off; d=x180.save99off.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=admin@x180.save99off.com; bh=D0nLs2oDIrcaNGIojPheWCki0NE=; b=UiTKinZesrUHr2d0tCnPxD9c752JU5BpSPJEQ6ZSoptPK8Scoq0CAwA7kWV/ZR2CfEItjvA7JvU/ UJzdhPJE3ykfQYGR0NJmRkQc4D/thwsEUZIRRgwdBJPQKqT4pYgtVYRlz13SZYuaSGcT0SiDXzpc aAIaTryn9R6ULf1T2ys= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=save99off; d=x180.save99off.com; b=UTyskSYnKAlAvOun2EYw8AsXzE6BbFnq7giADGc2N/4L3q84PT/MoWRqeB5a6AMEhV+oW5TprNEW AQaMRG5O1lFJqSJyITYGXfN+zhaSalLdzxnT9xUsrsGLsPPJ14RQa+C461X0zp2Kyz/4ZTCJnF7k GtysqZSwMpFCeZ9ndZo=; From: "UGG Australia Boots" To: freebsd-net@freebsd.org Date: 29 Dec 2016 17:17:39 +0800 Subject: Christmas Event: UP to 90% OFF! win 115$ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 29 Dec 2016 09:28:10 -0000 From owner-freebsd-net@freebsd.org Thu Dec 29 12:41:45 2016 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 4B29AC9430D for ; Thu, 29 Dec 2016 12:41:45 +0000 (UTC) (envelope-from sophie.simpson-net=freebsd.org@ccreceipt.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 33FF91BCF for ; Thu, 29 Dec 2016 12:41:45 +0000 (UTC) (envelope-from sophie.simpson-net=freebsd.org@ccreceipt.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3330CC9430C; Thu, 29 Dec 2016 12:41:45 +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 32DC1C9430B for ; Thu, 29 Dec 2016 12:41:45 +0000 (UTC) (envelope-from sophie.simpson-net=freebsd.org@ccreceipt.com) Received: from mail.ccreceipt.com (ccreceipt.com [185.169.229.104]) by mx1.freebsd.org (Postfix) with ESMTP id D0DB41BCB for ; Thu, 29 Dec 2016 12:41:44 +0000 (UTC) (envelope-from sophie.simpson-net=freebsd.org@ccreceipt.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dkim; d=ccreceipt.com; h=Date:From:To:Subject:MIME-Version:Content-Type:List-Unsubscribe:Message-ID; i=sophie.simpson@ccreceipt.com; bh=+ow3juLd8KvpCHmD9cW0wmqL3l4=; b=YynrEwzlrs9XsnVupkCfRlVRyMBFBFyLtzltWjwpRueJefIaKC/fS2zraHerCZgOvddRbYYjR8G6 3tMqKdRS/MsOULXp2L8BHTqRDLW69A05kEdcRBN/l4WdjdGmLd4oZ2DSREWFsGnD4YOReWMp3MV9 CKXr+/HE1V2eNIR+IEk= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=dkim; d=ccreceipt.com; b=dPjps7NRk5GNgfoytUf45vhya5WnvxsSmH5JFHnNu8aqMo6XLPspLn9b7FyQf3V9/U0cVLK4siLV q3YrQ+LOjg2z3f89rkhB8i54sbS8xwdr+AuL6jFwgsVsI61oFekvTl8ZUppmUTCgkxJ2nGg/UPFa 3lClrkMf+Y3G7GhkH4E=; Received: by mail.ccreceipt.com id hck1o00001g1 for ; Thu, 29 Dec 2016 07:21:46 -0500 (envelope-from ) Date: Thu, 29 Dec 2016 07:21:46 -0500 From: "Sophie Simpson" To: Subject: Alert - Your Credit Card has been charged X-SMTPAPI: {"category": "20161229-072109-858-96"} Feedback-ID: 2016122907210985896 Message-ID: <0.0.0.70.1D261CE1F20DD20.2C685F@mail.ccreceipt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 29 Dec 2016 12:41:45 -0000 From owner-freebsd-net@freebsd.org Thu Dec 29 16:09:09 2016 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 1E4A2C96ABC for ; Thu, 29 Dec 2016 16:09:09 +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 F3D231670 for ; Thu, 29 Dec 2016 16:09:08 +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 uBTG98p3068326 for ; Thu, 29 Dec 2016 16:09:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215613] [panic] if if_ixl due to NULL pointer dereference Date: Thu, 29 Dec 2016 16:09:09 +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: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@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, 29 Dec 2016 16:09:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215613 --- Comment #2 from Andrey V. Elsukov --- I looked at the latest driver code (1.6.10), and I think this problem was f= ixed by moving code that initializes/frees queues from ixl_init()/ixl_stop() into ixl_attach()/ixl_detach(). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Dec 29 17:11:32 2016 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 EE5DFC96387 for ; Thu, 29 Dec 2016 17:11:32 +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 DE1A11AE7 for ; Thu, 29 Dec 2016 17:11:32 +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 uBTHBWBI016111 for ; Thu, 29 Dec 2016 17:11:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213237] ndis does not create network interface Date: Thu, 29 Dec 2016 17:11: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-RC1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ota@j.email.ne.jp 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, 29 Dec 2016 17:11:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213237 --- Comment #6 from ota@j.email.ne.jp --- https://svnweb.freebsd.org/base?view=3Drevision&revision=3D286410 was the t= rigger. Per comment, "ndis, ... were not tested. ...But the ndis driver is complex,= and it is likely to be broken with this commit." NDIS causes kernel panic with ssid is specified. When ssid isn't specified, "list scan" works. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Dec 29 18:17:05 2016 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 3919BC96C49 for ; Thu, 29 Dec 2016 18:17:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1112B1B13; Thu, 29 Dec 2016 18:17:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id CF0A710A998; Thu, 29 Dec 2016 13:17:01 -0500 (EST) From: John Baldwin To: Vincenzo Maffione Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Adrian Chadd , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar Subject: Re: cxgbe's native netmap support broken since r307394 Date: Thu, 29 Dec 2016 10:16:58 -0800 Message-ID: <28018209.hrnUzHgbYH@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20161217222812.GA4979@ox> <9729046.di4hkLAXiP@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 29 Dec 2016 13:17:01 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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, 29 Dec 2016 18:17:05 -0000 On Thursday, December 29, 2016 10:02:32 AM Vincenzo Maffione wrote: > Ok, thanks for the clarification. I change the lock type to MTX_DEF > (and did a test). I attached the new patch. Looks good to me, thanks! > Cheers, > Vincenzo > > 2016-12-29 2:06 GMT+01:00 John Baldwin : > > On Wednesday, December 28, 2016 07:25:22 PM Vincenzo Maffione wrote: > >> Hi, > >> The "worker_lock" is taken by nm_os_kthread_wakeup_worker(), which > >> in turn is called by nm_pt_host_notify(). The latter function is a > >> callback that may be called by a driver interrupt service routine; > >> more precisely this happens when the driver calls netmap_tx_irq() or > >> netmap_rx_irq(). As far as I know in FreeBSD it is not possible to > >> lock a MTX_DEF mtx inside an ISR. Am I wrong on this? > > > > It depends. Most interrupt handlers run in ithreads and can use MTX_DEF. > > Only interrupt handlers that run from a filter are restricted to using > > MTX_SPIN. Looking at all the calls to netmap_[tr]x_irq() in the tree, > > they are all done from contexts that are safe to use MTX_DEF (and in > > general they have to be as the equivalent code for the non-netmap case > > is calling routines like if_input or m_freem that can't be invoked from > > a filter either). > > > >> > >> Cheers, > >> Vincenzo > >> > >> 2016-12-28 19:06 GMT+01:00 John Baldwin : > >> > Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to > >> > be a smaller patch and probably more correct for FreeBSD. > >> > > >> > On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote: > >> >> sure go ahead and thank you! > >> >> > >> >> On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd wrote: > >> >> > ok, does anyone mind if I commit it as-is? > >> >> > > >> >> > > >> >> > -a > >> >> > > >> >> > > >> >> > On 21 December 2016 at 13:37, Vincenzo Maffione wrote: > >> >> >> Hi Luigi, > >> >> >> I attached a minimal change containing two fixes: > >> >> >> > >> >> >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related > >> >> >> to this thread > >> >> >> - use the proper locking functions for the "worker_lock", unrelated > >> >> >> but needed to avoid the O.S. to trap because of a mismatch between > >> >> >> MTX_SPIN and MTX_DEF. > >> >> >> > >> >> >> Cheers, > >> >> >> Vincenzo > >> >> >> > >> >> >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo : > >> >> >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione > >> >> >>> wrote: > >> >> >>>> Hi, > >> >> >>>> There is no commit related to that in the FreeBSD svn or git. > >> >> >>>> > >> >> >>>> The fix has been published to the github netmap repository here > >> >> >>>> (branch master): https://github.com/luigirizzo/netmap > >> >> >>>> > >> >> >>>> What we should do is to import all the recent updates from the github > >> >> >>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me > >> >> >>>> know. > >> >> >>> > >> >> >>> I just checked and the diff between FreeBSD head and netmap head > >> >> >>> in github is almost 3k lines due to a lot of recent refactoring. > >> >> >>> So, if there is an easy way to extract just the locking change that would > >> >> >>> be preferable as an interim solution. > >> >> >>> > >> >> >>> cheers > >> >> >>> luigi > >> >> >>> > >> >> >>>> > >> >> >>>> Cheers, > >> >> >>>> Vincenzo > >> >> >>>> > >> >> >>>> > >> >> >>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd : > >> >> >>>>> hi, > >> >> >>>>> > >> >> >>>>> What's the commit? We should get it into -HEAD asap. > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> -adrian > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> On 20 December 2016 at 01:25, Vincenzo Maffione wrote: > >> >> >>>>>> Ok, applied to the netmap github repo. > >> >> >>>>>> This fix will be published when Luigi does the next commit on FreeBSD. > >> >> >>>>>> > >> >> >>>>>> Cheers, > >> >> >>>>>> Vincenzo > >> >> >>>>>> > >> >> >>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar : > >> >> >>>>>>> IFNET_RLOCK will work, thanks. > >> >> >>>>>>> > >> >> >>>>>>> Navdeep > >> >> >>>>>>> > >> >> >>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: > >> >> >>>>>>>> Hi Navdeep, > >> >> >>>>>>>> > >> >> >>>>>>>> Indeed, we have reviewed the code, and we think it is ok to > >> >> >>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using > >> >> >>>>>>>> IFNET_WLOCK(). > >> >> >>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. > >> >> >>>>>>>> > >> >> >>>>>>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie(). > >> >> >>>>>>>> However, on Linux the same lock is also needed to protect the call to > >> >> >>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified" > >> >> >>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock. > >> >> >>>>>>>> > >> >> >>>>>>>> Does this make sense to you? Would it be easy for you to make a quick > >> >> >>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK? > >> >> >>>>>>>> > >> >> >>>>>>>> Thanks, > >> >> >>>>>>>> Vincenzo > >> >> >>>>>>>> > >> >> >>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar : > >> >> >>>>>>>>> Luigi, Vincenzo, > >> >> >>>>>>>>> > >> >> >>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's > >> >> >>>>>>>>> native netmap support. The problem is that netmap_hw_reg now holds an > >> >> >>>>>>>>> rw_lock around the driver's netmap_on/off routines. It has always been > >> >> >>>>>>>>> safe for the driver to sleep during these operations but now it panics > >> >> >>>>>>>>> instead. > >> >> >>>>>>>>> > >> >> >>>>>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to disallow > >> >> >>>>>>>>> sleep on the control path. > >> >> >>>>>>>>> > >> >> >>>>>>>>> Regards, > >> >> >>>>>>>>> Navdeep > >> >> >>>>>>>>> > >> >> >>>>>>>>> begin_synchronized_op with the following non-sleepable locks held: > >> >> >>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff8271d680) locked @ > >> >> >>>>>>>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95 > >> >> >>>>>>>>> stack backtrace: > >> >> >>>>>>>>> #0 0xffffffff810837a5 at witness_debugger+0xe5 > >> >> >>>>>>>>> #1 0xffffffff81084d88 at witness_warn+0x3b8 > >> >> >>>>>>>>> #2 0xffffffff83ef2bcc at begin_synchronized_op+0x6c > >> >> >>>>>>>>> #3 0xffffffff83f14beb at cxgbe_netmap_reg+0x5b > >> >> >>>>>>>>> #4 0xffffffff809846f1 at netmap_hw_reg+0x81 > >> >> >>>>>>>>> #5 0xffffffff809806de at netmap_do_regif+0x19e > >> >> >>>>>>>>> #6 0xffffffff8098121d at netmap_ioctl+0x7ad > >> >> >>>>>>>>> #7 0xffffffff8098682f at freebsd_netmap_ioctl+0x5f > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> -- > >> >> >>>>>>>> Vincenzo Maffione > >> >> >>>>>>>> _______________________________________________ > >> >> >>>>>>>> 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 > >> >> >>>>>> _______________________________________________ > >> >> >>>>>> 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 > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> -- > >> >> >>> -----------------------------------------+------------------------------- > >> >> >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > >> >> >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > >> >> >>> TEL +39-050-2217533 . via Diotisalvi 2 > >> >> >>> Mobile +39-338-6809875 . 56122 PISA (Italy) > >> >> >>> -----------------------------------------+------------------------------- > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> Vincenzo Maffione > >> >> > >> >> > >> >> > >> >> > >> > > >> > > >> > -- > >> > John Baldwin > >> > >> > >> > >> > > > > > > -- > > John Baldwin > > > > -- John Baldwin From owner-freebsd-net@freebsd.org Thu Dec 29 19:08:29 2016 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 89749C96D91 for ; Thu, 29 Dec 2016 19:08:29 +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 63BF8146F for ; Thu, 29 Dec 2016 19:08:29 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id A9D003519E; Thu, 29 Dec 2016 19:08:28 +0000 (UTC) Date: Thu, 29 Dec 2016 19:08:28 +0000 To: freebsd-net@freebsd.org From: "jhb (John Baldwin)" Reply-to: D8905+325+e1c9b54ecf40ba1e@reviews.freebsd.org Subject: [Differential] D8905: if: Defer the if_up until the ifnet.if_ioctl is called. Message-ID: <5773901f2a3de7ab9686cb4e3a323b4b@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: D8905: if: Defer the if_up until the ifnet.if_ioctl is called. 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-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGM0ZmZhMDQxMTU2OTYwMzY1ZTRkNjhiMzkxIFhlXyw= 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, 29 Dec 2016 19:08:29 -0000 amhiIGFkZGVkIGEgY29tbWVudC4KCgogIEkgd291bGQgc3VnZ2VzdCByZXdvcmRpbmcgdGhlIG1l c3NhZ2UgYSBiaXQgdG8gc29tZXRoaW5nIGxpa2U6CiAgCiAgICBEZWZlciBpZl91cCgpIHVudGls IGFmdGVyIHRoZSBpbnRlcmZhY2UncyBpZl9pb2N0bCBtZXRob2QgaXMgY2FsbGVkLgogICAgCiAg ICBUaGlzIGVuc3VyZXMgdGhlIGludGVyZmFjZSBpcyBpbml0aWFsaXplZCBieSB0aGUgaW50ZXJm YWNlIGRyaXZlciBiZWZvcmUKICAgIGl0IGNhbiBiZSB1c2VkIGJ5IHRoZSByZXN0IG9mIHRoZSBz eXN0ZW0uCgpSRVZJU0lPTiBERVRBSUwKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDg5 MDUKCkVNQUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3NldHRp bmdzL3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvCgpUbzogc2VwaGVyb3NhX2dtYWlsLmNvbSwgZGVs cGhpaiwgcm95Z2VyLCBkZWN1aV9taWNyb3NvZnQuY29tLCBob256aGFuX21pY3Jvc29mdC5jb20s IGhvd2FyZDBzdV9nbWFpbC5jb20sIGFkcmlhbiwgaGlyZW4sIGJ6LCBnbm4sIGdsZWJpdXMsIGth cmVscwpDYzogamhiLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Thu Dec 29 21:40:24 2016 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 B400BC96975 for ; Thu, 29 Dec 2016 21:40:24 +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 A34DD1C68 for ; Thu, 29 Dec 2016 21:40:24 +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 uBTLeN6u096942 for ; Thu, 29 Dec 2016 21:40:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196361] Constrain IPv6 routes to each FIB (Consistent with IPv4 route behaviour) Date: Thu, 29 Dec 2016 21:40:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: asomers@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, 29 Dec 2016 21:40:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196361 --- Comment #12 from Alan Somers --- (In reply to jhujhiti from comment #11) Regarding same_ip_multiple_ifaces_fib0, the configuration isn't valid. But that's not the point of the test. As the comment and the PR say, the point= of the test is just to make sure you don't panic if you try to configure a sys= tem that way. For that matter, assigning the same IP to different interfaces on different fibs (as same_ip_multiple_ifaces) tests doesn't really make sense either, b= ut I added a test case for it because it worked on older versions of FreeBSD and some people were actually using that feature. But the situation is much mo= re interesting with IPv6 because of the concept of scopes. With IPv6, it makes sense to assign the same address to multiple interfaces, as long as their scopes are not overlapping. They can even use the same FIB. For example, = the same link-local address can be assigned to two different interfaces, as lon= g as they're on separate networks. Since these patches are starting to get fairly complicated, could you please create an account at https://reviews.freebsd.org/ and upload the patches th= ere? It's far easier to review patches there than on Bugzilla. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Dec 30 01:09:26 2016 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 6B142C97069 for ; Fri, 30 Dec 2016 01:09:26 +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 44E9A14AE for ; Fri, 30 Dec 2016 01:09:26 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id AA7BD3538D; Fri, 30 Dec 2016 01:09:25 +0000 (UTC) Date: Fri, 30 Dec 2016 01:09:25 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D8905+325+e1c9b54ecf40ba1e@reviews.freebsd.org Subject: [Differential] D8905: if: Defer the if_up until the ifnet.if_ioctl is called. Message-ID: <8042fb7ff29051029a54e2817fceac48@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: D8905: if: Defer the if_up until the ifnet.if_ioctl is called. 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-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGM0ZmZhMDQxMTU2OTYwMzY1ZTRkNjhiMzkxIFhls8U= 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, 30 Dec 2016 01:09:26 -0000 c2VwaGVyb3NhX2dtYWlsLmNvbSB1cGRhdGVkIHRoZSBzdW1tYXJ5IGZvciB0aGlzIHJldmlzaW9u LgoKUkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q4OTA1CgpF TUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9zZXR0aW5ncy9w YW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IHNlcGhlcm9zYV9nbWFpbC5jb20sIGRlbHBoaWos IHJveWdlciwgZGVjdWlfbWljcm9zb2Z0LmNvbSwgaG9uemhhbl9taWNyb3NvZnQuY29tLCBob3dh cmQwc3VfZ21haWwuY29tLCBhZHJpYW4sIGhpcmVuLCBieiwgZ25uLCBnbGViaXVzLCBrYXJlbHMK Q2M6IGpoYiwgZnJlZWJzZC1uZXQtbGlzdAo= From owner-freebsd-net@freebsd.org Fri Dec 30 01:09:43 2016 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 D9CA4C970A2 for ; Fri, 30 Dec 2016 01:09:43 +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 B38AB158C for ; Fri, 30 Dec 2016 01:09:43 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 42B32353B9; Fri, 30 Dec 2016 01:09:43 +0000 (UTC) Date: Fri, 30 Dec 2016 01:09:43 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D8905+325+e1c9b54ecf40ba1e@reviews.freebsd.org Subject: [Differential] D8905: if: Defer the if_up until the ifnet.if_ioctl is called. Message-ID: <1d5000af512a2bf1069214a384e26d14@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: D8905: if: Defer the if_up until the ifnet.if_ioctl is called. 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-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGM0ZmZhMDQxMTU2OTYwMzY1ZTRkNjhiMzkxIFhls9c= 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, 30 Dec 2016 01:09:43 -0000 c2VwaGVyb3NhX2dtYWlsLmNvbSBhZGRlZCBhIGNvbW1lbnQuCgoKICBJbiBodHRwczovL3Jldmll d3MuZnJlZWJzZC5vcmcvRDg5MDUjMTg1NTA3LCBAamhiIHdyb3RlOgogIAogID4gSSB3b3VsZCBz dWdnZXN0IHJld29yZGluZyB0aGUgbWVzc2FnZSBhIGJpdCB0byBzb21ldGhpbmcgbGlrZToKICA+ CiAgPiAgIERlZmVyIGlmX3VwKCkgdW50aWwgYWZ0ZXIgdGhlIGludGVyZmFjZSdzIGlmX2lvY3Rs IG1ldGhvZCBpcyBjYWxsZWQuCiAgPiAgCiAgPiAgIFRoaXMgZW5zdXJlcyB0aGUgaW50ZXJmYWNl IGlzIGluaXRpYWxpemVkIGJ5IHRoZSBpbnRlcmZhY2UgZHJpdmVyIGJlZm9yZQogID4gICBpdCBj YW4gYmUgdXNlZCBieSB0aGUgcmVzdCBvZiB0aGUgc3lzdGVtLgogID4KICAKICAKICBEb25lLiAg VGhhbmsgeW91LgoKUkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3Jn L0Q4OTA1CgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9z ZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IHNlcGhlcm9zYV9nbWFpbC5jb20s IGRlbHBoaWosIHJveWdlciwgZGVjdWlfbWljcm9zb2Z0LmNvbSwgaG9uemhhbl9taWNyb3NvZnQu Y29tLCBob3dhcmQwc3VfZ21haWwuY29tLCBhZHJpYW4sIGhpcmVuLCBieiwgZ25uLCBnbGViaXVz LCBrYXJlbHMKQ2M6IGpoYiwgZnJlZWJzZC1uZXQtbGlzdAo= From owner-freebsd-net@freebsd.org Fri Dec 30 09:11:25 2016 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 F3051C9137E for ; Fri, 30 Dec 2016 09:11:25 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::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 AFCD21282; Fri, 30 Dec 2016 09:11:25 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id u15so57349308oie.3; Fri, 30 Dec 2016 01:11:25 -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=J1tqkPrEHKOC/Ocv7GkA7hhpo1vn05Al8TLgy1hFyu0=; b=Tvyvypqo6FdquOl3WJTQGFrJn5CdgjRkveEv7mOWQMzavqeFlUyi/AWd3cP0AOa4at 4gOACRwY0ObYhTNnYDvK/Un1z5SrJBRGrlv9gWr83gjlUGq8Lrs09QAi0Ka+YXGljt4j xwrRhTX2DVMdiHPw5otanxNuUY0Q8aJnseJZhPx0GAz20e/oQ0a6sssraYm6hVngEbCD xLQikgBsrqcruxYffq2sD1lFOOO6ud6QBkw7XpCiSia0hVe7RK9uDp4isfQM4UKRaLGk RAOV09w5EVLTlkDUROc7sUQrMW0k+4RKmLpx9BZO/MVndyNSHAobec5O1V4radzQcqBc AkAg== 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=J1tqkPrEHKOC/Ocv7GkA7hhpo1vn05Al8TLgy1hFyu0=; b=Ck58gVUuXLGdIz+37ynQdqXe4RmYXJuxfjgahO576vFEkxcfLJuzmk24In0nCBdCu6 wGkoubZDPQ/npJ0zy+y9pI0Tr8aLmXLNJwVLo7HcHHO624oJJVRywt0So/5Y3B8hdV7u 3IFetcNkGPSs2Hz9p8C+3OfoL4lLP1tJvkNy6Z/Ct2+WM4/SNNzeIIv/5odVkvdI6wXi pF6nOft/Ovl+q6h/SDfsZYGtoq5qEw+k11vNUXquO0FGTjQdF7uqz8moEEQAcjI1SlS2 QsCWzIVHnoFIXwnpcuvKu3lojBt06OE9I2p5JEumwBUnTxNKXQdoB6DH3xnLuB1GVUcB 8BcQ== X-Gm-Message-State: AIkVDXKv3gzozP8Mt9hDgkZCugC3d8QDlBGA1Gaz4EZybh3m+dn6ZVaZh8ukuH2FHrNagD53RVYBF8VVLe5XHw== X-Received: by 10.157.60.238 with SMTP id t43mr23959223otf.178.1483089084948; Fri, 30 Dec 2016 01:11:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.200 with HTTP; Fri, 30 Dec 2016 01:11:24 -0800 (PST) In-Reply-To: <28018209.hrnUzHgbYH@ralph.baldwin.cx> References: <20161217222812.GA4979@ox> <9729046.di4hkLAXiP@ralph.baldwin.cx> <28018209.hrnUzHgbYH@ralph.baldwin.cx> From: Vincenzo Maffione Date: Fri, 30 Dec 2016 10:11:24 +0100 Message-ID: Subject: Re: cxgbe's native netmap support broken since r307394 To: John Baldwin Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Adrian Chadd , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar 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: Fri, 30 Dec 2016 09:11:26 -0000 Ok! Can anyone commit this? Luigi seems to be ok with the change. Thanks, Vincenzo 2016-12-29 19:16 GMT+01:00 John Baldwin : > On Thursday, December 29, 2016 10:02:32 AM Vincenzo Maffione wrote: >> Ok, thanks for the clarification. I change the lock type to MTX_DEF >> (and did a test). I attached the new patch. > > Looks good to me, thanks! > >> Cheers, >> Vincenzo >> >> 2016-12-29 2:06 GMT+01:00 John Baldwin : >> > On Wednesday, December 28, 2016 07:25:22 PM Vincenzo Maffione wrote: >> >> Hi, >> >> The "worker_lock" is taken by nm_os_kthread_wakeup_worker(), which >> >> in turn is called by nm_pt_host_notify(). The latter function is a >> >> callback that may be called by a driver interrupt service routine; >> >> more precisely this happens when the driver calls netmap_tx_irq() or >> >> netmap_rx_irq(). As far as I know in FreeBSD it is not possible to >> >> lock a MTX_DEF mtx inside an ISR. Am I wrong on this? >> > >> > It depends. Most interrupt handlers run in ithreads and can use MTX_DEF. >> > Only interrupt handlers that run from a filter are restricted to using >> > MTX_SPIN. Looking at all the calls to netmap_[tr]x_irq() in the tree, >> > they are all done from contexts that are safe to use MTX_DEF (and in >> > general they have to be as the equivalent code for the non-netmap case >> > is calling routines like if_input or m_freem that can't be invoked from >> > a filter either). >> > >> >> >> >> Cheers, >> >> Vincenzo >> >> >> >> 2016-12-28 19:06 GMT+01:00 John Baldwin : >> >> > Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to >> >> > be a smaller patch and probably more correct for FreeBSD. >> >> > >> >> > On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote: >> >> >> sure go ahead and thank you! >> >> >> >> >> >> On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd wrote: >> >> >> > ok, does anyone mind if I commit it as-is? >> >> >> > >> >> >> > >> >> >> > -a >> >> >> > >> >> >> > >> >> >> > On 21 December 2016 at 13:37, Vincenzo Maffione wrote: >> >> >> >> Hi Luigi, >> >> >> >> I attached a minimal change containing two fixes: >> >> >> >> >> >> >> >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related >> >> >> >> to this thread >> >> >> >> - use the proper locking functions for the "worker_lock", unrelated >> >> >> >> but needed to avoid the O.S. to trap because of a mismatch between >> >> >> >> MTX_SPIN and MTX_DEF. >> >> >> >> >> >> >> >> Cheers, >> >> >> >> Vincenzo >> >> >> >> >> >> >> >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo : >> >> >> >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione >> >> >> >>> wrote: >> >> >> >>>> Hi, >> >> >> >>>> There is no commit related to that in the FreeBSD svn or git. >> >> >> >>>> >> >> >> >>>> The fix has been published to the github netmap repository here >> >> >> >>>> (branch master): https://github.com/luigirizzo/netmap >> >> >> >>>> >> >> >> >>>> What we should do is to import all the recent updates from the github >> >> >> >>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me >> >> >> >>>> know. >> >> >> >>> >> >> >> >>> I just checked and the diff between FreeBSD head and netmap head >> >> >> >>> in github is almost 3k lines due to a lot of recent refactoring. >> >> >> >>> So, if there is an easy way to extract just the locking change that would >> >> >> >>> be preferable as an interim solution. >> >> >> >>> >> >> >> >>> cheers >> >> >> >>> luigi >> >> >> >>> >> >> >> >>>> >> >> >> >>>> Cheers, >> >> >> >>>> Vincenzo >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd : >> >> >> >>>>> hi, >> >> >> >>>>> >> >> >> >>>>> What's the commit? We should get it into -HEAD asap. >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> -adrian >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> On 20 December 2016 at 01:25, Vincenzo Maffione wrote: >> >> >> >>>>>> Ok, applied to the netmap github repo. >> >> >> >>>>>> This fix will be published when Luigi does the next commit on FreeBSD. >> >> >> >>>>>> >> >> >> >>>>>> Cheers, >> >> >> >>>>>> Vincenzo >> >> >> >>>>>> >> >> >> >>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar : >> >> >> >>>>>>> IFNET_RLOCK will work, thanks. >> >> >> >>>>>>> >> >> >> >>>>>>> Navdeep >> >> >> >>>>>>> >> >> >> >>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: >> >> >> >>>>>>>> Hi Navdeep, >> >> >> >>>>>>>> >> >> >> >>>>>>>> Indeed, we have reviewed the code, and we think it is ok to >> >> >> >>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using >> >> >> >>>>>>>> IFNET_WLOCK(). >> >> >> >>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. >> >> >> >>>>>>>> >> >> >> >>>>>>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie(). >> >> >> >>>>>>>> However, on Linux the same lock is also needed to protect the call to >> >> >> >>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified" >> >> >> >>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock. >> >> >> >>>>>>>> >> >> >> >>>>>>>> Does this make sense to you? Would it be easy for you to make a quick >> >> >> >>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK? >> >> >> >>>>>>>> >> >> >> >>>>>>>> Thanks, >> >> >> >>>>>>>> Vincenzo >> >> >> >>>>>>>> >> >> >> >>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar : >> >> >> >>>>>>>>> Luigi, Vincenzo, >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's >> >> >> >>>>>>>>> native netmap support. The problem is that netmap_hw_reg now holds an >> >> >> >>>>>>>>> rw_lock around the driver's netmap_on/off routines. It has always been >> >> >> >>>>>>>>> safe for the driver to sleep during these operations but now it panics >> >> >> >>>>>>>>> instead. >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to disallow >> >> >> >>>>>>>>> sleep on the control path. >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> Regards, >> >> >> >>>>>>>>> Navdeep >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> begin_synchronized_op with the following non-sleepable locks held: >> >> >> >>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff8271d680) locked @ >> >> >> >>>>>>>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95 >> >> >> >>>>>>>>> stack backtrace: >> >> >> >>>>>>>>> #0 0xffffffff810837a5 at witness_debugger+0xe5 >> >> >> >>>>>>>>> #1 0xffffffff81084d88 at witness_warn+0x3b8 >> >> >> >>>>>>>>> #2 0xffffffff83ef2bcc at begin_synchronized_op+0x6c >> >> >> >>>>>>>>> #3 0xffffffff83f14beb at cxgbe_netmap_reg+0x5b >> >> >> >>>>>>>>> #4 0xffffffff809846f1 at netmap_hw_reg+0x81 >> >> >> >>>>>>>>> #5 0xffffffff809806de at netmap_do_regif+0x19e >> >> >> >>>>>>>>> #6 0xffffffff8098121d at netmap_ioctl+0x7ad >> >> >> >>>>>>>>> #7 0xffffffff8098682f at freebsd_netmap_ioctl+0x5f >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> -- >> >> >> >>>>>>>> Vincenzo Maffione >> >> >> >>>>>>>> _______________________________________________ >> >> >> >>>>>>>> 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 >> >> >> >>>>>> _______________________________________________ >> >> >> >>>>>> 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 >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> -- >> >> >> >>> -----------------------------------------+------------------------------- >> >> >> >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> >> >> >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> >> >> >>> TEL +39-050-2217533 . via Diotisalvi 2 >> >> >> >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >> >> >> >>> -----------------------------------------+------------------------------- >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Vincenzo Maffione >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > John Baldwin >> >> >> >> >> >> >> >> >> > >> > >> > -- >> > John Baldwin >> >> >> >> > > > -- > John Baldwin -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri Dec 30 14:40:08 2016 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 3D85FC97975 for ; Fri, 30 Dec 2016 14:40:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wj0-x243.google.com (mail-wj0-x243.google.com [IPv6:2a00:1450:400c:c01::243]) (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 DF2841104; Fri, 30 Dec 2016 14:40:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wj0-x243.google.com with SMTP id kp2so60941053wjc.0; Fri, 30 Dec 2016 06:40:07 -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=xxs8oMcLAvvLck0uuFk46dtlnpk3wQ80+kp57paAKoA=; b=gZt+PQxuT3Y4ya9nwNBkmFqeXjqGOxpy6eru0Y+wErCMhIhsmpMJIY1b47IadxJiJE AB2uq+Dm/PtP3S34yJBQdgHVnwyU5HhsGf5/WsBq5+ejmCPDqgym+iYhuG5WntGr6nwR LHB927g+3ttWLoOPwMPKPyPVM17x4UTvoLZnUKhdJ4NQJ6QG6Byb6Qsln0w5vR10V2Qw +o6fO5L3UUloMtsTsgaXAKwEuC5UPxB7a+/R8Wa3eLjDPOG1hPjMF1DNtxBSZnjjtEYt EVVMlENyqs7J28/BzlPmnxf4epEaDvc7fKH1/TBxV8VkvNA5Uj2p8Sbf/5kL+51+B13d 6ivw== 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=xxs8oMcLAvvLck0uuFk46dtlnpk3wQ80+kp57paAKoA=; b=HFbQ7OICRnpKWR/HIAMAMlKenbE7cP7GTdYIkJEXh/Z/C+vShC1qsGTBVcSmbEJfl3 DRhBGakCQ3x98h4lq+whwVx8D06Bo392qK/eZqCKqugWPxJlgUIv1eLQM0feRhlz+qwb 0kl1vr65gL5gR/Bfw+EGxQX4XpJMMZwVL/modAhL5CAHFk2L7iE1ejQ5Wa6LCfHD/elP +AlcGyc+plIN3pQBitQ3oJ7vlShorBYPbxY1h+NYdFbvvOZrFu3i5PbvwhtJOOxJIdKt oee/fEDXKr4umXvVS+mlvNVJZ3srcXdcpySspIja474w+sv2MRpoMxkZPSUURkZxdUmA oU2A== X-Gm-Message-State: AIkVDXICbXUic3dqL/Y575WMV4UAAB1VAi6N6TQoAwiUIQBcKyq3k1Akzt8w1UGeKr/SOu6G0t8E02VRXhMHjA== X-Received: by 10.194.205.34 with SMTP id ld2mr39875937wjc.211.1483108806201; Fri, 30 Dec 2016 06:40:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.44.1 with HTTP; Fri, 30 Dec 2016 06:40:05 -0800 (PST) In-Reply-To: References: <20161217222812.GA4979@ox> <9729046.di4hkLAXiP@ralph.baldwin.cx> <28018209.hrnUzHgbYH@ralph.baldwin.cx> From: Adrian Chadd Date: Fri, 30 Dec 2016 06:40:05 -0800 Message-ID: Subject: Re: cxgbe's native netmap support broken since r307394 To: Vincenzo Maffione Cc: John Baldwin , "freebsd-net@freebsd.org" , Luigi Rizzo , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar 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: Fri, 30 Dec 2016 14:40:08 -0000 Hi, I'll do it in a sec. -a On 30 December 2016 at 01:11, Vincenzo Maffione wrote: > Ok! Can anyone commit this? > Luigi seems to be ok with the change. > > Thanks, > Vincenzo > > 2016-12-29 19:16 GMT+01:00 John Baldwin : >> On Thursday, December 29, 2016 10:02:32 AM Vincenzo Maffione wrote: >>> Ok, thanks for the clarification. I change the lock type to MTX_DEF >>> (and did a test). I attached the new patch. >> >> Looks good to me, thanks! >> >>> Cheers, >>> Vincenzo >>> >>> 2016-12-29 2:06 GMT+01:00 John Baldwin : >>> > On Wednesday, December 28, 2016 07:25:22 PM Vincenzo Maffione wrote: >>> >> Hi, >>> >> The "worker_lock" is taken by nm_os_kthread_wakeup_worker(), which >>> >> in turn is called by nm_pt_host_notify(). The latter function is a >>> >> callback that may be called by a driver interrupt service routine; >>> >> more precisely this happens when the driver calls netmap_tx_irq() or >>> >> netmap_rx_irq(). As far as I know in FreeBSD it is not possible to >>> >> lock a MTX_DEF mtx inside an ISR. Am I wrong on this? >>> > >>> > It depends. Most interrupt handlers run in ithreads and can use MTX_DEF. >>> > Only interrupt handlers that run from a filter are restricted to using >>> > MTX_SPIN. Looking at all the calls to netmap_[tr]x_irq() in the tree, >>> > they are all done from contexts that are safe to use MTX_DEF (and in >>> > general they have to be as the equivalent code for the non-netmap case >>> > is calling routines like if_input or m_freem that can't be invoked from >>> > a filter either). >>> > >>> >> >>> >> Cheers, >>> >> Vincenzo >>> >> >>> >> 2016-12-28 19:06 GMT+01:00 John Baldwin : >>> >> > Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to >>> >> > be a smaller patch and probably more correct for FreeBSD. >>> >> > >>> >> > On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote: >>> >> >> sure go ahead and thank you! >>> >> >> >>> >> >> On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd wrote: >>> >> >> > ok, does anyone mind if I commit it as-is? >>> >> >> > >>> >> >> > >>> >> >> > -a >>> >> >> > >>> >> >> > >>> >> >> > On 21 December 2016 at 13:37, Vincenzo Maffione wrote: >>> >> >> >> Hi Luigi, >>> >> >> >> I attached a minimal change containing two fixes: >>> >> >> >> >>> >> >> >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related >>> >> >> >> to this thread >>> >> >> >> - use the proper locking functions for the "worker_lock", unrelated >>> >> >> >> but needed to avoid the O.S. to trap because of a mismatch between >>> >> >> >> MTX_SPIN and MTX_DEF. >>> >> >> >> >>> >> >> >> Cheers, >>> >> >> >> Vincenzo >>> >> >> >> >>> >> >> >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo : >>> >> >> >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione >>> >> >> >>> wrote: >>> >> >> >>>> Hi, >>> >> >> >>>> There is no commit related to that in the FreeBSD svn or git. >>> >> >> >>>> >>> >> >> >>>> The fix has been published to the github netmap repository here >>> >> >> >>>> (branch master): https://github.com/luigirizzo/netmap >>> >> >> >>>> >>> >> >> >>>> What we should do is to import all the recent updates from the github >>> >> >> >>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me >>> >> >> >>>> know. >>> >> >> >>> >>> >> >> >>> I just checked and the diff between FreeBSD head and netmap head >>> >> >> >>> in github is almost 3k lines due to a lot of recent refactoring. >>> >> >> >>> So, if there is an easy way to extract just the locking change that would >>> >> >> >>> be preferable as an interim solution. >>> >> >> >>> >>> >> >> >>> cheers >>> >> >> >>> luigi >>> >> >> >>> >>> >> >> >>>> >>> >> >> >>>> Cheers, >>> >> >> >>>> Vincenzo >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd : >>> >> >> >>>>> hi, >>> >> >> >>>>> >>> >> >> >>>>> What's the commit? We should get it into -HEAD asap. >>> >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> -adrian >>> >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> On 20 December 2016 at 01:25, Vincenzo Maffione wrote: >>> >> >> >>>>>> Ok, applied to the netmap github repo. >>> >> >> >>>>>> This fix will be published when Luigi does the next commit on FreeBSD. >>> >> >> >>>>>> >>> >> >> >>>>>> Cheers, >>> >> >> >>>>>> Vincenzo >>> >> >> >>>>>> >>> >> >> >>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar : >>> >> >> >>>>>>> IFNET_RLOCK will work, thanks. >>> >> >> >>>>>>> >>> >> >> >>>>>>> Navdeep >>> >> >> >>>>>>> >>> >> >> >>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: >>> >> >> >>>>>>>> Hi Navdeep, >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> Indeed, we have reviewed the code, and we think it is ok to >>> >> >> >>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using >>> >> >> >>>>>>>> IFNET_WLOCK(). >>> >> >> >>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie(). >>> >> >> >>>>>>>> However, on Linux the same lock is also needed to protect the call to >>> >> >> >>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified" >>> >> >> >>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock. >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> Does this make sense to you? Would it be easy for you to make a quick >>> >> >> >>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK? >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> Thanks, >>> >> >> >>>>>>>> Vincenzo >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar : >>> >> >> >>>>>>>>> Luigi, Vincenzo, >>> >> >> >>>>>>>>> >>> >> >> >>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's >>> >> >> >>>>>>>>> native netmap support. The problem is that netmap_hw_reg now holds an >>> >> >> >>>>>>>>> rw_lock around the driver's netmap_on/off routines. It has always been >>> >> >> >>>>>>>>> safe for the driver to sleep during these operations but now it panics >>> >> >> >>>>>>>>> instead. >>> >> >> >>>>>>>>> >>> >> >> >>>>>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to disallow >>> >> >> >>>>>>>>> sleep on the control path. >>> >> >> >>>>>>>>> >>> >> >> >>>>>>>>> Regards, >>> >> >> >>>>>>>>> Navdeep >>> >> >> >>>>>>>>> >>> >> >> >>>>>>>>> begin_synchronized_op with the following non-sleepable locks held: >>> >> >> >>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff8271d680) locked @ >>> >> >> >>>>>>>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95 >>> >> >> >>>>>>>>> stack backtrace: >>> >> >> >>>>>>>>> #0 0xffffffff810837a5 at witness_debugger+0xe5 >>> >> >> >>>>>>>>> #1 0xffffffff81084d88 at witness_warn+0x3b8 >>> >> >> >>>>>>>>> #2 0xffffffff83ef2bcc at begin_synchronized_op+0x6c >>> >> >> >>>>>>>>> #3 0xffffffff83f14beb at cxgbe_netmap_reg+0x5b >>> >> >> >>>>>>>>> #4 0xffffffff809846f1 at netmap_hw_reg+0x81 >>> >> >> >>>>>>>>> #5 0xffffffff809806de at netmap_do_regif+0x19e >>> >> >> >>>>>>>>> #6 0xffffffff8098121d at netmap_ioctl+0x7ad >>> >> >> >>>>>>>>> #7 0xffffffff8098682f at freebsd_netmap_ioctl+0x5f >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> -- >>> >> >> >>>>>>>> Vincenzo Maffione >>> >> >> >>>>>>>> _______________________________________________ >>> >> >> >>>>>>>> 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 >>> >> >> >>>>>> _______________________________________________ >>> >> >> >>>>>> 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 >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> -- >>> >> >> >>> -----------------------------------------+------------------------------- >>> >> >> >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >>> >> >> >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>> >> >> >>> TEL +39-050-2217533 . via Diotisalvi 2 >>> >> >> >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>> >> >> >>> -----------------------------------------+------------------------------- >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> -- >>> >> >> >> Vincenzo Maffione >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > -- >>> >> > John Baldwin >>> >> >>> >> >>> >> >>> >> >>> > >>> > >>> > -- >>> > John Baldwin >>> >>> >>> >>> >> >> >> -- >> John Baldwin > > > > -- > Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri Dec 30 15:34:30 2016 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 18F3AC97B48 for ; Fri, 30 Dec 2016 15:34:30 +0000 (UTC) (envelope-from dbelleisle@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 C97961E76 for ; Fri, 30 Dec 2016 15:34:29 +0000 (UTC) (envelope-from dbelleisle@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id x186so243390961vkd.1 for ; Fri, 30 Dec 2016 07:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GMU8r915VEQI/ruvj0LtsUxuQvhmEDoP1PQjwBp7Ljk=; b=HFGucMLv7ZMtETyQZiuLJxo5qDL4LSN7M8xs+EYcEUySXV6DuRSG78XXFC01RGKL+l ypCuossh2kVAC0OAW+25JLHXzWlDytPQ3d6Ksy4ro/7sWcOBUOPLDUwuZGXPzV+8tYCl 0HhU464IgCzo4QqTzkuyB+jO9EcNpvBSYncXCcXPZ3i+O4Gx+0Y95gj3VKEVyexnSpmv Wn63chuaj3arssaIC57fjiyOmw42YSnvI2aMzMvc7SrKKT/wfdlmPQZ26B5dskOrnl1+ i7bYNSTEFFpsrGPh/mw2G/eKrhDZdKSY7ZJ39G/j5xe0zIrfY/vAZroS5AUJj63HnK+6 Xzzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GMU8r915VEQI/ruvj0LtsUxuQvhmEDoP1PQjwBp7Ljk=; b=dJ9dl7GpHs84GcSB09mxlRWvePtZ2jUK260iPAWNrCh3/I0FJZlQsPe6xvU9hjBXZG JZ9IuSYNFh34zLMejmGXj2tdxChYruypCJXDaHIHSIYLTNVHh5cFqh/TbDNbamDrpg+L WZbI6SCy2Ov3D+kHC5/tygdG2sfT/EJw35/+lqod0wumOTRBU+ciqWjBKlGyiGJr5d4L n0jCFMAzJMqOwCmV24+HY2fw5A/NP1eotM9/VMUZI4RfebPQTZVDhBVnwZBolywqf5/e zLEKLvRwUmCLkDRlYxcL69nP94ZcvJYXNiNpRUH8ihNFhC5rZwcKmJEnf3M6IPsulk+R GT2w== X-Gm-Message-State: AIkVDXKh0MYCGzV7KcpOZfVMIK/JiyMzGRuS3ir4y+RDJdhYMamDDz8JQd1imPrRKnvpJiIkXe2zONFaMfPOwg== X-Received: by 10.31.149.138 with SMTP id x132mr16559247vkd.86.1483112068851; Fri, 30 Dec 2016 07:34:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.49.75 with HTTP; Fri, 30 Dec 2016 07:34:08 -0800 (PST) From: David Belle-Isle Date: Fri, 30 Dec 2016 10:34:08 -0500 Message-ID: Subject: Changing NIC ring weight in indirection table To: freebsd-net@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: Fri, 30 Dec 2016 15:34:30 -0000 Hi, Can anyone tell me how to set the weight of a ring from the indirection table on FreeBSD? My plan is to yank out a TX ring and to use it solely with netmap to receive packets but want to make sure the kernel won't be receiving any packets on this ring. Based on a quick search this is something that ethtool would be able to do on Linux but I doubt this can be done on FreeBSD using the same tool? Thanks for your help, David From owner-freebsd-net@freebsd.org Fri Dec 30 21:55:24 2016 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 9A807C972A4 for ; Fri, 30 Dec 2016 21:55:24 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wj0-x236.google.com (mail-wj0-x236.google.com [IPv6:2a00:1450:400c:c01::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 22CE212B7 for ; Fri, 30 Dec 2016 21:55:24 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wj0-x236.google.com with SMTP id v7so386276580wjy.2 for ; Fri, 30 Dec 2016 13:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=MgGMBnM50aYckas6wa6j3irQcnPwEDf4+8w2IYZiHA8=; b=LsQa9rYOwbn2+Vfa+wjgRSjkxqPPmW4hUBAB0jhVpv5E56wB47pfNNKgfZZZnZwzDh etVIUOQ8fVoeHXup04THjuY8KHBTxG5xQuiWT585vROL7+XkHRa+TNpIe+ezkiA9wi30 hdJmyPAxXdXbrikBtm3MAK8i1amUTRO1tqMGu7CnoAYrDJXyzqa9mWhRkbEYTDcIqyOZ /CchD0KeZvXFGrssdwjxDjQzQxy4NJUsV0oj4byEyeoM1RHpHl2i0WzrT0DSL0Zu3hD8 VUounnbVD+cSFsQDPYqHH4G1S/nyQy1GJ6O7Ro4r6jWML+dpytKS5KU3eE4OpX+Hhe7P yT1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=MgGMBnM50aYckas6wa6j3irQcnPwEDf4+8w2IYZiHA8=; b=R3HFnZFmlFdEu35m5FvoG6vg31RwUPtSvwJpBXcWdllxOCu5/ek18CAnzQa6WhwkI1 MLtErbxxmYmaf6sAsUE+x9BeqHNdMbbA4FbBSwqq0ky4wKfpJEqpGyK1ViI7TO3X0SAX lgeopCuz7APd2l/daiT3yuyJDswrspcsXqsVvm8uEvF8jehOK4f1cFsuQNyikU1ynbSp ZfeqBju5mvi3A1UVt4W5DRmjWh1p7FmfZN8OQvW4XsDWeZR0vV/gOMsBf6w/PgmIcBEo TRMUUzAOz0vydVLmsYG/B7J5RK8s/h8BtHWqBaGgv/ktD9LEVCgJcfv5lObANvWdMDuU JybQ== X-Gm-Message-State: AIkVDXKvSgkkS/3ggQqFlTPPj4BHhYmSyRrTgSWt4hlAKYiiBr8B5hhFEMsblmWy8t6cVQ== X-Received: by 10.194.90.83 with SMTP id bu19mr41753656wjb.68.1483134921224; Fri, 30 Dec 2016 13:55:21 -0800 (PST) Received: from ben.home (LFbn-1-7159-4.w90-116.abo.wanadoo.fr. [90.116.90.4]) by smtp.gmail.com with ESMTPSA id k2sm75624089wjv.11.2016.12.30.13.55.20 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 30 Dec 2016 13:55:20 -0800 (PST) From: Ben RUBSON Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: iSCSI failing, MLX rx_ring errors ? Message-Id: <486A6DA0-54C8-40DF-8437-F6E382DA01A8@gmail.com> Date: Fri, 30 Dec 2016 22:55:19 +0100 To: FreeBSD Net Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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, 30 Dec 2016 21:55:24 -0000 Hello, 2 FreeBSD 11.0-p3 servers, one iSCSI initiator, one target. Both with Mellanox ConnectX-3 40G. Since a few days, sometimes, under undetermined circumstances, as soon = as there is some (very low) iSCSI traffic, some of the disks get = disconnected : kernel: WARNING: 192.168.2.2 (iqn......): no ping reply (NOP-Out) after = 5 seconds; dropping connection At the same moment, sysctl counters hw.mlxen1.stat.rx_ring*.error grow = on initiator side. I then tried to reproduce these network errors burning the link at 40G = full-duplex using iPerf. But I did not manage to increase these error counters. It's strange because it's a sporadic issue, I can have traffic on iSCSI = disks without any issue, and sometimes, they get disconnected with = errors growing. What should I look at ? What do these rx_ring*.error counters mean ? Hardware errors ? Below are some numbers to help with the investigation. (strangely enough for MLX guys, all hw.mlxen*.stat.tx_*_bytes_packets = counters are 0) Tank you very much for your help & support ! Best regards, Ben # uname -r 11.0-RELEASE-p3 # ifconfig mlxen1 mlxen1: flags=3D8843 metric 0 = mtu 9020 = options=3Ded07bb ether XX:XX:XX:XX:XX:XX inet 192.168.2.1 netmask 0xffff0000 broadcast 192.168.255.255=20 nd6 options=3D29 media: Ethernet autoselect (40Gbase-CR4 ) status: active # mst status MST devices: ------------ pci0:133:0:0 - MT27500 Family [ConnectX-3] # flint -d pci0:133:0:0 q Image type: FS2 FW Version: 2.36.5000 FW Release Date: 26.1.2016 Product Version: 02.36.50.00 Rom Info: type=3DPXE version=3D3.4.718 devid=3D4099 PSID: MT_1090110023 [initiator]# netstat -I mlxen1 Name Mtu Network Address Ipkts Ierrs Idrop = Opkts Oerrs Coll mlxen 9020 XX:XX:XX:XX:XX:XX 4095609916 0 0 = 3321316930 0 0 mlxen - 192.168.0.0/1 initiator 2020732710 - - = 3242031277 - - [target]# netstat -I mlxen1 Name Mtu Network Address Ipkts Ierrs Idrop = Opkts Oerrs Coll mlxen 9020 XX:XX:XX:XX:XX:XX 3798170324 0 0 = 5098312540 0 0 mlxen - 192.168.0.0/1 target 2462248779 - - = 5057776404 - - [initiator]# sysctl hw.mlxen1 hw.mlxen1.stat.rx_ring15.error: 52 hw.mlxen1.stat.rx_ring15.bytes: 3477976760 hw.mlxen1.stat.rx_ring15.packets: 7360524 hw.mlxen1.stat.rx_ring14.error: 77 hw.mlxen1.stat.rx_ring14.bytes: 791762343420 hw.mlxen1.stat.rx_ring14.packets: 142943349 hw.mlxen1.stat.rx_ring13.error: 33 hw.mlxen1.stat.rx_ring13.bytes: 2284826126 hw.mlxen1.stat.rx_ring13.packets: 7781479 hw.mlxen1.stat.rx_ring12.error: 20 hw.mlxen1.stat.rx_ring12.bytes: 730312221216 hw.mlxen1.stat.rx_ring12.packets: 155950019 hw.mlxen1.stat.rx_ring11.error: 57 hw.mlxen1.stat.rx_ring11.bytes: 114233581104 hw.mlxen1.stat.rx_ring11.packets: 69633934 hw.mlxen1.stat.rx_ring10.error: 49 hw.mlxen1.stat.rx_ring10.bytes: 10775291086886 hw.mlxen1.stat.rx_ring10.packets: 1389173314 hw.mlxen1.stat.rx_ring9.error: 68 hw.mlxen1.stat.rx_ring9.bytes: 35171979154 hw.mlxen1.stat.rx_ring9.packets: 86633073 hw.mlxen1.stat.rx_ring8.error: 81 hw.mlxen1.stat.rx_ring8.bytes: 23210482350 hw.mlxen1.stat.rx_ring8.packets: 68058961 hw.mlxen1.stat.rx_ring7.error: 49 hw.mlxen1.stat.rx_ring7.bytes: 5093871869318 hw.mlxen1.stat.rx_ring7.packets: 744833265 hw.mlxen1.stat.rx_ring6.error: 37 hw.mlxen1.stat.rx_ring6.bytes: 90764137790 hw.mlxen1.stat.rx_ring6.packets: 130626431 hw.mlxen1.stat.rx_ring5.error: 7 hw.mlxen1.stat.rx_ring5.bytes: 641902292152 hw.mlxen1.stat.rx_ring5.packets: 76754874 hw.mlxen1.stat.rx_ring4.error: 59 hw.mlxen1.stat.rx_ring4.bytes: 28894253498 hw.mlxen1.stat.rx_ring4.packets: 12545685 hw.mlxen1.stat.rx_ring3.error: 87 hw.mlxen1.stat.rx_ring3.bytes: 1581250152646 hw.mlxen1.stat.rx_ring3.packets: 255027061 hw.mlxen1.stat.rx_ring2.error: 19 hw.mlxen1.stat.rx_ring2.bytes: 47056101376 hw.mlxen1.stat.rx_ring2.packets: 11670049 hw.mlxen1.stat.rx_ring1.error: 76 hw.mlxen1.stat.rx_ring1.bytes: 6673057117060 hw.mlxen1.stat.rx_ring1.packets: 917070315 hw.mlxen1.stat.rx_ring0.error: 21 hw.mlxen1.stat.rx_ring0.bytes: 65223989496 hw.mlxen1.stat.rx_ring0.packets: 19600719 hw.mlxen1.stat.tx_ring23.bytes: 829090401622 hw.mlxen1.stat.tx_ring23.packets: 336892256 hw.mlxen1.stat.tx_ring22.bytes: 793782461006 hw.mlxen1.stat.tx_ring22.packets: 110951927 hw.mlxen1.stat.tx_ring21.bytes: 133908896030 hw.mlxen1.stat.tx_ring21.packets: 15515669 hw.mlxen1.stat.tx_ring20.bytes: 64369317656 hw.mlxen1.stat.tx_ring20.packets: 9666791 hw.mlxen1.stat.tx_ring19.bytes: 50388926288 hw.mlxen1.stat.tx_ring19.packets: 46840752 hw.mlxen1.stat.tx_ring18.bytes: 828058240322 hw.mlxen1.stat.tx_ring18.packets: 332214476 hw.mlxen1.stat.tx_ring17.bytes: 2405121596404 hw.mlxen1.stat.tx_ring17.packets: 514331797 hw.mlxen1.stat.tx_ring16.bytes: 74310025468 hw.mlxen1.stat.tx_ring16.packets: 9385759 hw.mlxen1.stat.tx_ring15.bytes: 113497610894 hw.mlxen1.stat.tx_ring15.packets: 13184789 hw.mlxen1.stat.tx_ring14.bytes: 2277138343902 hw.mlxen1.stat.tx_ring14.packets: 307498601 hw.mlxen1.stat.tx_ring13.bytes: 52566528570 hw.mlxen1.stat.tx_ring13.packets: 16261361 hw.mlxen1.stat.tx_ring12.bytes: 490379207044 hw.mlxen1.stat.tx_ring12.packets: 58488779 hw.mlxen1.stat.tx_ring11.bytes: 71659340140 hw.mlxen1.stat.tx_ring11.packets: 12239602 hw.mlxen1.stat.tx_ring10.bytes: 912427288872 hw.mlxen1.stat.tx_ring10.packets: 349927049 hw.mlxen1.stat.tx_ring9.bytes: 72551256540 hw.mlxen1.stat.tx_ring9.packets: 51930045 hw.mlxen1.stat.tx_ring8.bytes: 111389160186 hw.mlxen1.stat.tx_ring8.packets: 12694233 hw.mlxen1.stat.tx_ring7.bytes: 1706882082390 hw.mlxen1.stat.tx_ring7.packets: 203421211 hw.mlxen1.stat.tx_ring6.bytes: 184536049610 hw.mlxen1.stat.tx_ring6.packets: 24060941 hw.mlxen1.stat.tx_ring5.bytes: 118658630412 hw.mlxen1.stat.tx_ring5.packets: 14390742 hw.mlxen1.stat.tx_ring4.bytes: 679672951824 hw.mlxen1.stat.tx_ring4.packets: 137562479 hw.mlxen1.stat.tx_ring3.bytes: 2390933455110 hw.mlxen1.stat.tx_ring3.packets: 295791371 hw.mlxen1.stat.tx_ring2.bytes: 178631018408 hw.mlxen1.stat.tx_ring2.packets: 30935420 hw.mlxen1.stat.tx_ring1.bytes: 1773565506936 hw.mlxen1.stat.tx_ring1.packets: 206723306 hw.mlxen1.stat.tx_ring0.bytes: 1818793974890 hw.mlxen1.stat.tx_ring0.packets: 210483166 hw.mlxen1.stat.tx_gt_1548_bytes_packets: 0 hw.mlxen1.stat.tx_1548_bytes_packets: 0 hw.mlxen1.stat.tx_1522_bytes_packets: 0 hw.mlxen1.stat.tx_1518_bytes_packets: 0 hw.mlxen1.stat.tx_1023_bytes_packets: 0 hw.mlxen1.stat.tx_511_bytes_packets: 0 hw.mlxen1.stat.tx_255_bytes_packets: 0 hw.mlxen1.stat.tx_127_bytes_packets: 0 hw.mlxen1.stat.tx_lt_64_bytes_packets: 0 hw.mlxen1.stat.tx_dropped: 0 hw.mlxen1.stat.tx_errors: 0 hw.mlxen1.stat.tx_broadcast_packets: 4518 hw.mlxen1.stat.tx_multicast_packets: 0 hw.mlxen1.stat.tx_bytes: 18145597836008 hw.mlxen1.stat.tx_packets: 3321392471 hw.mlxen1.stat.rx_gt_1548_bytes_packets: 3049781443 hw.mlxen1.stat.rx_1548_bytes_packets: 5 hw.mlxen1.stat.rx_1522_bytes_packets: 0 hw.mlxen1.stat.rx_1518_bytes_packets: 1498044 hw.mlxen1.stat.rx_1023_bytes_packets: 683359 hw.mlxen1.stat.rx_511_bytes_packets: 1593761 hw.mlxen1.stat.rx_255_bytes_packets: 2074222 hw.mlxen1.stat.rx_127_bytes_packets: 1039982287 hw.mlxen1.stat.rx_lt_64_bytes_packets: 50631 hw.mlxen1.stat.rx_out_range_length_error: 0 hw.mlxen1.stat.rx_in_range_length_error: 0 hw.mlxen1.stat.rx_jabbers: 0 hw.mlxen1.stat.rx_crc_errors: 0 hw.mlxen1.stat.rx_over_errors: 0 hw.mlxen1.stat.rx_length_errors: 0 hw.mlxen1.stat.rx_dropped: 0 hw.mlxen1.stat.rx_errors: 0 hw.mlxen1.stat.rx_broadcast_packets: 1047 hw.mlxen1.stat.rx_multicast_packets: 26 hw.mlxen1.stat.rx_packets: 4095663752 hw.mlxen1.stat.rx_bytes: 26714147524337 hw.mlxen1.stat.tx_chksum_offload: 1798163742 hw.mlxen1.stat.rx_chksum_none: 0 hw.mlxen1.stat.rx_chksum_good: 118 hw.mlxen1.stat.rx_alloc_failed: 0 hw.mlxen1.stat.tx_oversized_packets: 0 hw.mlxen1.stat.tx_timeout: 0 hw.mlxen1.stat.wake_queue: 599 hw.mlxen1.stat.queue_stopped: 599 hw.mlxen1.stat.tso_packets: 373869842 hw.mlxen1.conf.eeprom_info: 0 hw.mlxen1.conf.coalesce.adaptive_rx_coal: 1 hw.mlxen1.conf.coalesce.sample_interval: 0 hw.mlxen1.conf.coalesce.rx_usecs_high: 128 hw.mlxen1.conf.coalesce.pkt_rate_high: 450000 hw.mlxen1.conf.coalesce.rx_usecs_low: 0 hw.mlxen1.conf.coalesce.pkt_rate_low: 400000 hw.mlxen1.conf.device_name: mlx4_core0 hw.mlxen1.conf.port_num: 2 hw.mlxen1.conf.rx_ppp: 0 hw.mlxen1.conf.tx_ppp: 0 hw.mlxen1.conf.tx_size: 1024 hw.mlxen1.conf.rx_size: 1024 hw.mlxen1.conf.tx_rings: 24 hw.mlxen1.conf.rx_rings: 16 hw.mlxen1.conf.msg_enable: 20 [target]# sysctl hw.mlxen1 hw.mlxen1.stat.rx_ring15.error: 0 hw.mlxen1.stat.rx_ring15.bytes: 245362991998 hw.mlxen1.stat.rx_ring15.packets: 125007210 hw.mlxen1.stat.rx_ring14.error: 0 hw.mlxen1.stat.rx_ring14.bytes: 69938348448 hw.mlxen1.stat.rx_ring14.packets: 12006397 hw.mlxen1.stat.rx_ring13.error: 0 hw.mlxen1.stat.rx_ring13.bytes: 801100594458 hw.mlxen1.stat.rx_ring13.packets: 324484029 hw.mlxen1.stat.rx_ring12.error: 0 hw.mlxen1.stat.rx_ring12.bytes: 500584314630 hw.mlxen1.stat.rx_ring12.packets: 63722864 hw.mlxen1.stat.rx_ring11.error: 0 hw.mlxen1.stat.rx_ring11.bytes: 133319524538 hw.mlxen1.stat.rx_ring11.packets: 15553073 hw.mlxen1.stat.rx_ring10.error: 0 hw.mlxen1.stat.rx_ring10.bytes: 1204971095886 hw.mlxen1.stat.rx_ring10.packets: 473964848 hw.mlxen1.stat.rx_ring9.error: 0 hw.mlxen1.stat.rx_ring9.bytes: 3587005798210 hw.mlxen1.stat.rx_ring9.packets: 423516917 hw.mlxen1.stat.rx_ring8.error: 0 hw.mlxen1.stat.rx_ring8.bytes: 1603198498178 hw.mlxen1.stat.rx_ring8.packets: 517866399 hw.mlxen1.stat.rx_ring7.error: 0 hw.mlxen1.stat.rx_ring7.bytes: 769432176604 hw.mlxen1.stat.rx_ring7.packets: 125552308 hw.mlxen1.stat.rx_ring6.error: 0 hw.mlxen1.stat.rx_ring6.bytes: 3616464682348 hw.mlxen1.stat.rx_ring6.packets: 431320453 hw.mlxen1.stat.rx_ring5.error: 0 hw.mlxen1.stat.rx_ring5.bytes: 147803881652 hw.mlxen1.stat.rx_ring5.packets: 30514582 hw.mlxen1.stat.rx_ring4.error: 0 hw.mlxen1.stat.rx_ring4.bytes: 59936047126 hw.mlxen1.stat.rx_ring4.packets: 16529062 hw.mlxen1.stat.rx_ring3.error: 0 hw.mlxen1.stat.rx_ring3.bytes: 305461527316 hw.mlxen1.stat.rx_ring3.packets: 120780446 hw.mlxen1.stat.rx_ring2.error: 0 hw.mlxen1.stat.rx_ring2.bytes: 1663980980828 hw.mlxen1.stat.rx_ring2.packets: 576915628 hw.mlxen1.stat.rx_ring1.error: 0 hw.mlxen1.stat.rx_ring1.bytes: 2341832227428 hw.mlxen1.stat.rx_ring1.packets: 332370776 hw.mlxen1.stat.rx_ring0.error: 0 hw.mlxen1.stat.rx_ring0.bytes: 1718316360628 hw.mlxen1.stat.rx_ring0.packets: 208016985 hw.mlxen1.stat.tx_ring23.bytes: 761640234844 hw.mlxen1.stat.tx_ring23.packets: 140570741 hw.mlxen1.stat.tx_ring22.bytes: 235825746846 hw.mlxen1.stat.tx_ring22.packets: 47582760 hw.mlxen1.stat.tx_ring21.bytes: 6307679416 hw.mlxen1.stat.tx_ring21.packets: 13587887 hw.mlxen1.stat.tx_ring20.bytes: 489519672798 hw.mlxen1.stat.tx_ring20.packets: 56191717 hw.mlxen1.stat.tx_ring19.bytes: 10121686810 hw.mlxen1.stat.tx_ring19.packets: 4241850 hw.mlxen1.stat.tx_ring18.bytes: 4558715397262 hw.mlxen1.stat.tx_ring18.packets: 639846327 hw.mlxen1.stat.tx_ring17.bytes: 32286951370 hw.mlxen1.stat.tx_ring17.packets: 22959085 hw.mlxen1.stat.tx_ring16.bytes: 1899512819522 hw.mlxen1.stat.tx_ring16.packets: 282998424 hw.mlxen1.stat.tx_ring15.bytes: 117297176370 hw.mlxen1.stat.tx_ring15.packets: 27096254 hw.mlxen1.stat.tx_ring14.bytes: 11272324536 hw.mlxen1.stat.tx_ring14.packets: 136151702 hw.mlxen1.stat.tx_ring13.bytes: 5085846009768 hw.mlxen1.stat.tx_ring13.packets: 653473793 hw.mlxen1.stat.tx_ring12.bytes: 3172283876 hw.mlxen1.stat.tx_ring12.packets: 12387380 hw.mlxen1.stat.tx_ring11.bytes: 1815249849862 hw.mlxen1.stat.tx_ring11.packets: 227269892 hw.mlxen1.stat.tx_ring10.bytes: 5099264496730 hw.mlxen1.stat.tx_ring10.packets: 655527719 hw.mlxen1.stat.tx_ring9.bytes: 945986137300 hw.mlxen1.stat.tx_ring9.packets: 303182670 hw.mlxen1.stat.tx_ring8.bytes: 942441980 hw.mlxen1.stat.tx_ring8.packets: 2898885 hw.mlxen1.stat.tx_ring7.bytes: 3123343187824 hw.mlxen1.stat.tx_ring7.packets: 357250514 hw.mlxen1.stat.tx_ring6.bytes: 51356715444 hw.mlxen1.stat.tx_ring6.packets: 11868226 hw.mlxen1.stat.tx_ring5.bytes: 991389854 hw.mlxen1.stat.tx_ring5.packets: 7233820 hw.mlxen1.stat.tx_ring4.bytes: 72483778448 hw.mlxen1.stat.tx_ring4.packets: 13382952 hw.mlxen1.stat.tx_ring3.bytes: 26534426276 hw.mlxen1.stat.tx_ring3.packets: 7776173 hw.mlxen1.stat.tx_ring2.bytes: 5089185758862 hw.mlxen1.stat.tx_ring2.packets: 658036115 hw.mlxen1.stat.tx_ring1.bytes: 10793041110 hw.mlxen1.stat.tx_ring1.packets: 80825537 hw.mlxen1.stat.tx_ring0.bytes: 5109262741542 hw.mlxen1.stat.tx_ring0.packets: 735938500 hw.mlxen1.stat.tx_gt_1548_bytes_packets: 0 hw.mlxen1.stat.tx_1548_bytes_packets: 0 hw.mlxen1.stat.tx_1522_bytes_packets: 0 hw.mlxen1.stat.tx_1518_bytes_packets: 0 hw.mlxen1.stat.tx_1023_bytes_packets: 0 hw.mlxen1.stat.tx_511_bytes_packets: 0 hw.mlxen1.stat.tx_255_bytes_packets: 0 hw.mlxen1.stat.tx_127_bytes_packets: 0 hw.mlxen1.stat.tx_lt_64_bytes_packets: 0 hw.mlxen1.stat.tx_dropped: 0 hw.mlxen1.stat.tx_errors: 0 hw.mlxen1.stat.tx_broadcast_packets: 1769 hw.mlxen1.stat.tx_multicast_packets: 0 hw.mlxen1.stat.tx_bytes: 34577305063732 hw.mlxen1.stat.tx_packets: 5098278918 hw.mlxen1.stat.rx_gt_1548_bytes_packets: 2205482837 hw.mlxen1.stat.rx_1548_bytes_packets: 2738 hw.mlxen1.stat.rx_1522_bytes_packets: 1 hw.mlxen1.stat.rx_1518_bytes_packets: 4075320 hw.mlxen1.stat.rx_1023_bytes_packets: 492236 hw.mlxen1.stat.rx_511_bytes_packets: 3810259 hw.mlxen1.stat.rx_255_bytes_packets: 3183982 hw.mlxen1.stat.rx_127_bytes_packets: 1581068219 hw.mlxen1.stat.rx_lt_64_bytes_packets: 6402 hw.mlxen1.stat.rx_out_range_length_error: 0 hw.mlxen1.stat.rx_in_range_length_error: 0 hw.mlxen1.stat.rx_jabbers: 0 hw.mlxen1.stat.rx_crc_errors: 0 hw.mlxen1.stat.rx_over_errors: 0 hw.mlxen1.stat.rx_length_errors: 0 hw.mlxen1.stat.rx_dropped: 0 hw.mlxen1.stat.rx_errors: 0 hw.mlxen1.stat.rx_broadcast_packets: 3355 hw.mlxen1.stat.rx_multicast_packets: 27 hw.mlxen1.stat.rx_packets: 3798121994 hw.mlxen1.stat.rx_bytes: 18783901543019 hw.mlxen1.stat.tx_chksum_offload: 2003355285 hw.mlxen1.stat.rx_chksum_none: 0 hw.mlxen1.stat.rx_chksum_good: 10 hw.mlxen1.stat.rx_alloc_failed: 0 hw.mlxen1.stat.tx_oversized_packets: 0 hw.mlxen1.stat.tx_timeout: 0 hw.mlxen1.stat.wake_queue: 26759 hw.mlxen1.stat.queue_stopped: 26759 hw.mlxen1.stat.tso_packets: 549442205 hw.mlxen1.conf.eeprom_info: 0 hw.mlxen1.conf.coalesce.adaptive_rx_coal: 1 hw.mlxen1.conf.coalesce.sample_interval: 0 hw.mlxen1.conf.coalesce.rx_usecs_high: 128 hw.mlxen1.conf.coalesce.pkt_rate_high: 450000 hw.mlxen1.conf.coalesce.rx_usecs_low: 0 hw.mlxen1.conf.coalesce.pkt_rate_low: 400000 hw.mlxen1.conf.device_name: mlx4_core0 hw.mlxen1.conf.port_num: 2 hw.mlxen1.conf.rx_ppp: 0 hw.mlxen1.conf.tx_ppp: 0 hw.mlxen1.conf.tx_size: 1024 hw.mlxen1.conf.rx_size: 1024 hw.mlxen1.conf.tx_rings: 24 hw.mlxen1.conf.rx_rings: 16 hw.mlxen1.conf.msg_enable: 20 From owner-freebsd-net@freebsd.org Sat Dec 31 17:45:31 2016 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 BBDC6C99264 for ; Sat, 31 Dec 2016 17:45:31 +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 965191903 for ; Sat, 31 Dec 2016 17:45:31 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 22D3E354D9; Sat, 31 Dec 2016 17:45:31 +0000 (UTC) Date: Sat, 31 Dec 2016 17:45:31 +0000 To: freebsd-net@freebsd.org From: "karels (Mike Karels)" Reply-to: D8905+325+e1c9b54ecf40ba1e@reviews.freebsd.org Subject: [Differential] D8905: if: Defer the if_up until the ifnet.if_ioctl is called. Message-ID: <9cb130de921cfefbd6ad720e52a5b6ad@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: D8905: if: Defer the if_up until the ifnet.if_ioctl is called. 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-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGM0ZmZhMDQxMTU2OTYwMzY1ZTRkNjhiMzkxIFhn7rs= 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: Sat, 31 Dec 2016 17:45:31 -0000 a2FyZWxzIGFkZGVkIGEgY29tbWVudC4KCgogIFNlZW1zIGZpbmUgdG8gbWU7IHdpbGwgbGV0IHNv bWVvbmUgZWxzZSBhcHByb3ZlLgoKUkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZy ZWVic2Qub3JnL0Q4OTA1CgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVl YnNkLm9yZy9zZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IHNlcGhlcm9zYV9n bWFpbC5jb20sIGRlbHBoaWosIHJveWdlciwgZGVjdWlfbWljcm9zb2Z0LmNvbSwgaG9uemhhbl9t aWNyb3NvZnQuY29tLCBob3dhcmQwc3VfZ21haWwuY29tLCBhZHJpYW4sIGhpcmVuLCBieiwgZ25u LCBnbGViaXVzLCBrYXJlbHMKQ2M6IGpoYiwgZnJlZWJzZC1uZXQtbGlzdAo= From owner-freebsd-net@freebsd.org Sat Dec 31 17:47:14 2016 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 0FC34C99311 for ; Sat, 31 Dec 2016 17:47:14 +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 D9DD71A05 for ; Sat, 31 Dec 2016 17:47:13 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 6D4753561F; Sat, 31 Dec 2016 17:47:13 +0000 (UTC) Date: Sat, 31 Dec 2016 17:47:13 +0000 To: freebsd-net@freebsd.org From: "karels (Mike Karels)" Reply-to: D8904+325+7336aa65c010aea9@reviews.freebsd.org Subject: [Differential] D8904: inet: Fix routing issue by calling if_up() 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: D8904: inet: Fix routing issue by calling if_up() 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-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZjczN2EyNTY0YWQ0YjU5MTFiOTVmNTcwYjRkIFhn7yE= 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: Sat, 31 Dec 2016 17:47:14 -0000 a2FyZWxzIGFkZGVkIGEgY29tbWVudC4KCgogIEkgdGhpbmsgdGhlIGNoYW5nZSBpcyBhIHN0ZXAg aW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gIENlcnRhaW5seSwgImlmY29uZmlnIHh4TiBkb3duIiBm b2xsb3dlZCBieSBhbiBpbXBsaWNpdCBVUCBzaG91bGQgbm90IGNhdXNlIGFueSBjaGFuZ2UgdG8g dGhlIHJvdXRpbmcgdGFibGUuICBEb2VzIGFueW9uZSBrbm93IHdoeSB0aGUgImRvd24iIGlzIHJl bW92aW5nIHRoZSByb3V0ZT8gIFRoYXQgc2VlbXMgd3JvbmcgdG8gbWUuCgpSRVZJU0lPTiBERVRB SUwKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDg5MDQKCkVNQUlMIFBSRUZFUkVOQ0VT CiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3NldHRpbmdzL3BhbmVsL2VtYWlscHJlZmVy ZW5jZXMvCgpUbzogc2VwaGVyb3NhX2dtYWlsLmNvbSwgZGVscGhpaiwgcm95Z2VyLCBkZWN1aV9t aWNyb3NvZnQuY29tLCBob256aGFuX21pY3Jvc29mdC5jb20sIGhvd2FyZDBzdV9nbWFpbC5jb20s IGFkcmlhbiwgYnosIGdubiwgaGlyZW4sIGdsZWJpdXMsIHJ3YXRzb24sIGthcmVscwpDYzogaHJz LCBmcmVlYnNkLW5ldC1saXN0Cg==