From owner-freebsd-net@freebsd.org Sun Apr 16 11:11:53 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34F34D416EE for ; Sun, 16 Apr 2017 11:11:53 +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 107BD82D for ; Sun, 16 Apr 2017 11:11:53 +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 v3GBBnNb031414 for ; Sun, 16 Apr 2017 11:11:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211219] NIC status does not pass into a state of "no carrier" after disconnecting the cable. Date: Sun, 16 Apr 2017 11:11:49 +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: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: franco@opnsense.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED 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, 16 Apr 2017 11:11:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211219 --- Comment #18 from Franco Fichtner --- The second line in the if statement still differs in the way introduced by = the original commit causing the regression: Original Intel driver and requested in this this PR/attached commit: ims_mask |=3D EM_MSIX_MASK; Current state on all branches: ims_mask |=3D adapter->ims; In our conversations you asked me which of the two lines were needed, becau= se the chip documentation wasn't clear. The testing result for a good result (for two distinct devices I have) was: if (hw->mac.type =3D=3D e1000_82574) { E1000_WRITE_REG(hw, EM_EIAC, adapter->ims); }=20 The current FreeBSD state was changed to read this: if (hw->mac.type =3D=3D e1000_82574) { E1000_WRITE_REG(hw, EM_EIAC, adapter->ims); ims_mask |=3D adapter->ims; } Which still differs from the good tested result or the original Intel state. Either the second line should be dropped or changed to how it reads in the Intel driver. Cheers, Franco --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Apr 16 19:45:29 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3310CD417EB for ; Sun, 16 Apr 2017 19:45: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 17B2C1345 for ; Sun, 16 Apr 2017 19:45: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 v3GJjRwL045804 for ; Sun, 16 Apr 2017 19:45:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211219] NIC status does not pass into a state of "no carrier" after disconnecting the cable. Date: Sun, 16 Apr 2017 19:45:28 +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: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED 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, 16 Apr 2017 19:45:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211219 --- Comment #19 from Sean Bruno --- (In reply to Franco Fichtner from comment #18) Is it possible that you are looking at a different source tree than I? stable/11 currently has the following: static void em_enable_intr(struct adapter *adapter) { struct e1000_hw *hw =3D &adapter->hw; u32 ims_mask =3D IMS_ENABLE_MASK; if (hw->mac.type =3D=3D e1000_82574) { E1000_WRITE_REG(hw, EM_EIAC, EM_MSIX_MASK); ims_mask |=3D adapter->ims; } E1000_WRITE_REG(hw, E1000_IMS, ims_mask); } --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Apr 16 21:01:09 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EBBFD41F44 for ; Sun, 16 Apr 2017 21:01: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 6112A1C81 for ; Sun, 16 Apr 2017 21:01: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 v3GL01nd022636 for ; Sun, 16 Apr 2017 21:01:09 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201704162101.v3GL01nd022636@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, 16 Apr 2017 21:01:09 +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, 16 Apr 2017 21:01:09 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 165622 | [ndis][panic][patch] Unregistered use of FPU in k In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 In Progress | 206581 | bxe_ioctl_nvram handler is faulty New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic New | 213410 | [carp] service netif restart causes hang only whe New | 215874 | [patch] [icmp] [mbuf_tags] teach icmp_error() opt New | 217748 | sys/dev/ixgbe/if_ix.c: PVS-Studio: Assignment to Open | 173444 | socket: IPV6_USE_MIN_MTU and TCP is broken Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211031 | [panic] in ng_uncallout when argument is NULL Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ 18 problems total for which you should take action. From owner-freebsd-net@freebsd.org Mon Apr 17 02:22:36 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10B08D3F63D for ; Mon, 17 Apr 2017 02:22:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0B831144 for ; Mon, 17 Apr 2017 02:22:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3H2MZql086914 for ; Mon, 17 Apr 2017 02:22:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218653] Intel e1000 network link drops under high network load Date: Mon, 17 Apr 2017 02:22:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kaho@elam.kais.kyoto-u.ac.jp X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? 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, 17 Apr 2017 02:22:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218653 Kaho Toshikazu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kaho@elam.kais.kyoto-u.ac.j | |p --- Comment #3 from Kaho Toshikazu --- (In reply to nn from comment #1) I think the link drop itself is caused by a Tx error, but you have many Rx errors shown by the Ierrs of the netstat output and you should investigate what errors occur at first. Can you see a `sysctl dev.em.0` result? Can you get which knobs related errors are increasing their counters?=20 For example, does rx_overrun or crc_errs has a non-zero value? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Apr 17 03:09:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42D24D40051 for ; Mon, 17 Apr 2017 03:09:27 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 243F5180 for ; Mon, 17 Apr 2017 03:09:26 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 2C5D03AF7B for ; Sun, 16 Apr 2017 20:01:17 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org Subject: Small socket programming question Date: Sun, 16 Apr 2017 20:01:16 -0700 Message-ID: <83113.1492398076@segfault.tristatelogic.com> 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, 17 Apr 2017 03:09:27 -0000 Sorry, I -think- I know that answer to this question, but I'd prefer to ask and make sure, in case I have misunderstood things. I am aware that for any open socket, the kernel sets aside some amount of buffer space for that socket. (And yes, I *do* also know that the specific amount set aside may be programatically controlled.) So anyway, let's say that I have either a RAW or UDP (datagram) socket open and my program is running on a nice fast machine, but it's outbound connection is via a rather slow link. So if my program writes and writes and writes to this socket, eventually, I'll have used up all of the buffer space that the kernel has associated with the socket. My question is just this: What happens then? Will further writes to the socket block until some more packets get sent out, you know, so that there is once again room in the outbound buffer that's associated with this socket? Or will I instead get some error back from the call to write(), like for instance EAGAIN or ENOSPC or maybe ENOBUFS? Or does the kernel in such cases just silently discard one or more of my precious outbound packets without even telling me? (I guess this is my way of asking whether or not the FreeBSD kernel may, in some cases, itself be a source of "packet loss".) Thanks in advance for any & all enlightening replies. From owner-freebsd-net@freebsd.org Mon Apr 17 04:51:18 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 804C2D403A3 for ; Mon, 17 Apr 2017 04:51:18 +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 6C58B24B for ; Mon, 17 Apr 2017 04:51:18 +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 v3H4pIop066697 for ; Mon, 17 Apr 2017 04:51:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218687] [patch] use uninitialized fields of struct inpcb Date: Mon, 17 Apr 2017 04:51:18 +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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Mon, 17 Apr 2017 04:51:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218687 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Apr 17 10:00:46 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBB36D3FDB3 for ; Mon, 17 Apr 2017 10:00:46 +0000 (UTC) (envelope-from Joe@stream-technologies.com) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0042.outbound.protection.outlook.com [104.47.2.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47A271E37 for ; Mon, 17 Apr 2017 10:00:45 +0000 (UTC) (envelope-from Joe@stream-technologies.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=streamtechnologiesuk.onmicrosoft.com; s=selector1-streamtechnologies-com01e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nljq6ir6y3NA4oxt/NEypcWcKT6M8BVVWYMpnWOtFms=; b=sYXR2qxcBHVPevwjKjHXrof6uoDa7wFJJtXQhlwk1knVmFNb+VJ592ED1duO1P3zWqiZWoPrSXCbpQSm0pUvdlnQiBqS5pKECSnLBLzPUCHrcnfpdGAgMcXtorPs8o47QLXhEMKt6CCFl/bM2wh1k2CbJyGIlbO145uXwE96LWE= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=stream-technologies.com; Received: from [192.168.6.128] (212.20.240.118) by VI1PR07MB1040.eurprd07.prod.outlook.com (10.161.111.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Mon, 17 Apr 2017 10:00:41 +0000 Subject: Re: cxgbe netmap promiscuous mode? To: "freebsd-net@freebsd.org" References: <58D3C6F4.6010500@stream-technologies.com> <58D521C0.1000804@stream-technologies.com> <58F0E683.7050806@stream-technologies.com> <20170414163215.GA9358@ox> From: Joe Jones Message-ID: <58F49246.801@stream-technologies.com> Date: Mon, 17 Apr 2017 11:00:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20170414163215.GA9358@ox> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [212.20.240.118] X-ClientProxiedBy: AM4PR0501CA0050.eurprd05.prod.outlook.com (10.172.222.146) To VI1PR07MB1040.eurprd07.prod.outlook.com (10.161.111.144) X-MS-Office365-Filtering-Correlation-Id: e39b0f80-1a55-4e31-f31d-08d485789bbd X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:VI1PR07MB1040; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1040; 3:+PoQ40+DHPbUNlo3mcjwQc+PTUPMmLgrNSjAXGXWPeqsWflfLz2qHruEia8HY68heJdwZ4o0ii3yryOQmrDSuRptELh4oh0wpyMUfPzr4ITQXILzN9xkPLxDx267UWe2/ajY7+29XXX/4NBRy5K9La65/RssjyVlG3wpBIAKQeYAgqz0nW0fxbpx/v1JQWzXClIuz+IgTvaqSSY5PhKg1p2mBKk2Zyr7qa8JEuyfijC5MA0ZBWC3GoxDJc9JEuem2cOou8w340Jg/DwrpHxj1c2Bw9IXsxFKXBn722kmLr6ylnRzaIh6xKHUitPuQVDwYP1EVVY6lwbRVtiiQXpxhg==; 25:4Lu5XculJxiDLx8Nx30qR8yzgAiXFHgTNpV9r3CgW7+agQrXrc0GPnl3vcW5jOVWRKL3NBQT83f3Fg/AVCwrg16fK7vyNixeI1sAKov88z3uQHQp0VfM4Kg6Fwp3F9U7fQH9aCowF6OViJE9aviuzZ/GUVcSkZAbCY/7TEDm6YP5N8qlabqz1AC16RggIW7iOx9jOT4XHgtaONaM9+lHkPVZSMSrOWe047s7CgdZN9KIVpM3FHy2geJihd8t7tZDyKjHk5oLpzs5FKlPIxQ2uNvpZV0pViSdzOvtt+vaoa1kj4hkLWEjA63SQi0ZiTuzjGBQTyto8l5XW/WT89OiAQuHfIDqOoI7RGNCurkkHfvj4Ta0tSHmb/uI7RjDlTxvgogLMt5o7lA+WETmejqT6Tz06i2AW6VvvfQWh+Fj6TY2wSGDmAvrIEeUVXJhZH/OK0VwEnc5mmPkTd0B9U2wGfCRhLCxNLp3qIovpQcuwFw= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1040; 31:XrATAeWChnmJUu0Wpmsj6hJ9ayFlul5nOePd8ZLu5yZLQrlmit81cla+f2ZQMtvA4Esv18cJxRKjgT9b2RHwKzT4FHRBzK8FG2u4XNjaLK3QlRWKbZFDdNqXFOpueK3i87snnHsPoShFJ8zgd5qUOEunY3nQRSZo4oZG3F8SKWcAditdoqBAFLx88cLLSNuRalkpo/meiYXGrc+o42kEcn6FJhHvUlvURMq/n5PAdmrrgDbQWlStj1/RcHDuSoKgsezgG7Feea/6PFQKgUnCyg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(20558992708506); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:VI1PR07MB1040; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1040; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1040; 4:hql2RPB/VyWU6YMe4D8ZIF3s+RVE73zDOALD7k3aEZ2qCF9dHoBKDKgjRUKwMNtcuJLbXk+tm4jUr5vsejB5g2XGL/LQwjeHWpAipnc4wbg/O33/8h4uagFSVwjqCY+MKFmuBk54Se/d/LV6naQIkzhYk4hpwWTGa7UcA4b+imRcc56ADmWSlBMrlIaepQDMC3F4WYuvRXcYfTs5RzKTelmvfohVbVbq330m7rz72Gy80MZGtmXeE8kL6tmMPSAqbKPaxKciKgXxVhNHoRSgCh8WVB2q8afDoTZ7Mltz9A7XFNdU9chicOg5mirHbnq7zcxZcXHhX+QfKG/swc6OuBII4QdmIUqA2yozDRrRKg4RiG4gdmNmahT+JYhUAL+P15wZaDsr5S1NJAFpfoea7a1bYwkDBkSTFCHglDiInF2EYqLH4og5m6xA5XJgjDkoe4d73CEsyijWMwCmF9deo1qEXu0Df9vRaR9e1kuiXjMm+pZRby5/jPaaqCSdEpIYIkY6yJ/iz5cKlBG1rr7bC3n+3w5Nbyx3zL4sOaeTBZexf8AGM6uhe37jBeUt0bghvywRQksPcueCKZqmAYYiJsjY9JNRrm4zlJoa0LuhOkhBxNAtd+bPp90x8PYvbe5U5siZ6YI7WcUKsXQB06HgBbrTXvr04Hmgx0lI+0xgqsRshEXJJa7ZbmSu7l/4+De1wmItorOlp6J+4OLjiBMaUWJcLCfsfrZemQsf+SssTNiT0J/t5Ea4PVbd6Em5r9eHWQOGU6TuykaWFXVz9OrLk6t9IkY5mJVPStqGNKujmIo= X-Forefront-PRVS: 02801ACE41 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(39830400002)(39450400003)(39410400002)(39400400002)(24454002)(83506001)(3480700004)(64126003)(23746002)(50466002)(25786009)(90366009)(2351001)(66066001)(6246003)(47776003)(189998001)(65956001)(65806001)(8676002)(4001350100001)(36756003)(2501003)(38730400002)(86362001)(81166006)(110136004)(5660300001)(7736002)(3846002)(229853002)(6916009)(42186005)(2950100002)(5640700003)(33656002)(230700001)(53546009)(117156002)(6486002)(54356999)(2906002)(77096006)(93886004)(6666003)(305945005)(76176999)(65816999)(50986999)(6116002)(80792005)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1040; H:[192.168.6.128]; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR07MB1040; 23:DuaaNmwiF65dobNsUwM/VUechbAj/lmPqK5KV?= =?Windows-1252?Q?OyjaONXvGXnKySdzrAeRiiJ/CF6FFQBfn6jnGG0BvNQEPLXltWNbROrV?= =?Windows-1252?Q?itg8Iv2lrBqhMHlBE1wNdGwtSTNaeReofF2CwwJVscFQqA5WvkJp2EKl?= =?Windows-1252?Q?vnVLRnY17j9s2cR6yCMxvZ6O6V1wxLW5byfpj6g/QEK3LJaJd7vzBs+Q?= =?Windows-1252?Q?sK3/oH5RtM5VIJ+fIAKIEjB+JzlJdU6aeyPs7Ew/opSc3cZLXPQcP7zV?= =?Windows-1252?Q?4ut8olBvH/+6HkvIA/1Ud0boNdANvP+2nl0BZ4tQnfmbmr8498iWmSWD?= =?Windows-1252?Q?mT1SxWrz5kxQO3jO6HaBObmg2TR4/TGXXDVg1J5jlS56AhJXhpILxZEr?= =?Windows-1252?Q?rsr+/q/Vf5LUICe+n9EVxRLPQQitf2n/8d6Zk1yV0jWeEWT9M/juObZK?= =?Windows-1252?Q?ToXhhg55V4SzIeU+1vLu/1rS5qoFjnmW3gUlzU+4ptErOQHLWSWK+Dsr?= =?Windows-1252?Q?RTPXsA/UntZ0VoJaIxI2kyiE7ol1eokuvcimEL3ckG6WEPEcl51IMTei?= =?Windows-1252?Q?ANJBz9Rb5iO9f/ef5ZG8yjAqyynxbdW/9Sx3Jmgm2I73imQIOVBuX2rU?= =?Windows-1252?Q?DqYtcNgHGhq8Qd+dLwJLJKl1mpID15zQCvnhG9gv2V+++ZjBNIWJhL04?= =?Windows-1252?Q?FhtFX1GnYD3kxSMAE/xOphM4JTBa9Q/MJ1vOzQ0Rr51qbea8OaH3nLDz?= =?Windows-1252?Q?RCVOCvvzceItIIhJJOOs0U+gPsum010RuTHCEdS8ypDKz88iKRxpYsi5?= =?Windows-1252?Q?ON7Mq48qddez7cLeXONi2PBtPzjuSBkTW1NNpK/cN7etYpM+K5hyqUUE?= =?Windows-1252?Q?p3XWFVAfCPXFsEoUDfDuhgVHlJ8ydoeNBs5HBq4whFAeNur2EM8HquV7?= =?Windows-1252?Q?07GBkJM9ysfZJS5TIa8v4n0yRLCSe2iyaUEC1tqbYtpjmns0S2q+lkVN?= =?Windows-1252?Q?44nuoQRfew1+J5ufYnZjhTIKT7Bhs5ef0yMxW5L9alEhCEg+NtLMsurq?= =?Windows-1252?Q?L5WgSNs8kO3J/jhnAe+PPe2kp1P1PYSWOa3hsmlTG3ICvucyStKIPlQz?= =?Windows-1252?Q?+w+5j93Q73Swa6ArvDt6vD6vMmMyDis0PBBPPtLOSy9ySzurkx/YgtcM?= =?Windows-1252?Q?DrUXC9AhZHomAEVJDTgB8zJ6KSUDO6D6KrudOcuSB+kOBbq3mzPMhmqP?= =?Windows-1252?Q?ul8/wc9zOBDOxkCNzjgLz60JUsYKohP/hPa7IIivOlPeUEhYMhxFXACX?= =?Windows-1252?Q?vro0RVm0opRK/BvALso5ar6FfC6iAvk6bFMtIYpV50HUxZl8zXSAQTjO?= =?Windows-1252?Q?JibF1IfmAI6CppYQIViQI5qwvMMSwF85qT0soznnpZUdbih3WNqvHly/?= =?Windows-1252?Q?ml7U2goO3txOQPw/AuPdyKFj59s+TpOOFZWQYW25A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1040; 6:7eE4Xyd4I6xHygUPdcCL2JUE3zptjIujUo7uxTPouBf3RPpPE7aDjpWtpFOAdzlrYiYpjhQRgqnrWy3WjjxbYJnvuYYcFBal2o20vXlwD2b3lbDPkZ2KcFtbWT7QHuwnnOP9D5xfvOnQB/Sk+B+bfxI2zSvvyXK8PUcHqhz/LwtNFT0TYrphFaPEchz4A/atztjTRsbHxFBggkcjnjPwKSDFaQ3q8sB0aT0njIIubF4v5Irk88JnabuM4hiA3735JJkNwEs0yxo8uSPY9x3vhyr/8qqMJ3PL2mophsBTDO6WnJCOM0qzVHIZlwCWDbREXXEYdFC6l9P0AME3tEcvsYtS5f3LyNn/7Fui+894LmZI8UQ8eedXyG5flEyW9ID+xO/U7BRdckbJW0a3ck/JS+2nG1teJ3MRZjzSMP1obMsljAQutx9gTpO/2AtRnc1e+rq966i9Sgw5mtb1Mq+DXEizYBN/+YuVDR+LW8qD6VECXqRHz7mQxVtlHwlI97+FRRFmtpdUtup68zdZftwFbw==; 5:TSE2FPGg++fHm6qIuOW4x+DuXRQ7X4e4te3OK1/5bv99SQjwvlSv2TaXovA4kNFnQGsyd3HaI2Qh24CBiSlc5PhZIxyl6Frb88n0VchzTglkgeIlgF0mZ2NZRhDlqtntrpM/vx5Kyl97+h1Q2S4ukw==; 24:NiAGJcHvew5UJ4rUhwB1eyzRCUa9fStU4tFx+6nIbGMgIZLRxT93U0ZOMDPGzhua+PodwTTnsWVy3R8R+5sR1CUJYQllwWgccLdE2Azo6T4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1040; 7:flP7wmjwcfSY8ZdMXy8weULlpe2+/th01d4gQoA9asqOION+JSAwZsH7eHJwCSiDpBqAxpRH3DuWKyqki+MfC2rxqAWQHeZBH554w5o7t1eqOT3gh7a3h1Hr1KxDoUY5CGQt2IuQtIaG/DttFY0Xx0WHsNv8EIGFFvbs8U6XA8Yx6AQz5SP4epqj2mkAG9woeJEup7FuKLDNCc9Su3o+dPR3la30y94n1k7TNtZYsItY+69FuHjGutUjL0s+DeIhPXuztLQM3Eve0d/AD/kTEIRM40oB0Jddxq55k1wZUOwL14uvHyY5BUd0OH5/hAt/OiL4Iu6CO0yMhkuBqCTRMA== X-OriginatorOrg: stream-technologies.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2017 10:00:41.9694 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1040 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, 17 Apr 2017 10:00:47 -0000 Hi Navdeep running "ifconfig up" and then "ifconfig promisc" works. Running "ifconfig promisc" and then "ifconfig up" does not work. Running "ifconfig up promisc" together does work. Running "ifconfig promisc up" does not work. The combination that does not work leaves the interface in a state where it reports it's self as being in promiscuous mode. Joe Jones On 14/04/17 17:32, Navdeep Parhar wrote: > On Fri, Apr 14, 2017 at 04:10:59PM +0100, Joe Jones wrote: >> Hi Navdeep, >> >> I think I have found a driver bug. Earlier today I set up the switch I'm >> using so that two of the ports mirror the traffic on one of the other ports. >> We are planning on using a similar setup to allow packet tracing without >> stressing the boxes our application is running on any more then they are >> already. >> >> I connected both ports to one of our cxgbe cards, My intention was to use >> tcpdump to check that my switch config was doing what I thought it should. I >> ran >> >> ifconfig cxl? promisc -vlanhwtag up > Does the problem occur only if you use this form of ifconfig? Can you > please try "ifconfig up" and "ifconfig cxl? promisc" separately and see > what happens? > > Regards, > Navdeep > >> on both interfaces, this is what the interfaces looked like >> >> cxl0: flags=28943 >> metric 0 mtu 1500 >> options=ec07ab >> ether 00:07:43:33:8a:20 >> nd6 options=29 >> media: Ethernet 10Gbase-Twinax >> status: active >> vcxl0: flags=8802 metric 0 mtu 1500 >> options=ec07bb >> ether 00:07:43:33:8a:22 >> nd6 options=29 >> media: Ethernet 10Gbase-Twinax >> status: active >> cxl1: flags=28943 >> metric 0 mtu 1500 >> options=ec07ab >> ether 00:07:43:33:8a:28 >> nd6 options=29 >> media: Ethernet 10Gbase-Twinax >> status: active >> vcxl1: flags=8802 metric 0 mtu 1500 >> options=ec07bb >> ether 00:07:43:33:8a:2a >> nd6 options=29 >> media: Ethernet 10Gbase-Twinax >> status: active >> >> The interesting thing is, a tcpdump on cxl0 showed all the traffic I >> expected to see, while tcpdump on cxl1 showed only broadcast traffic. After >> playing with the switch config to make sure the difference was not on the >> switch I pulled both patch cables out and into another server with the same >> card. On the second server I could use tcpdump and see all the traffic I >> expected on either interface. >> >> Then back on the original server, I reloaded the device driver and tried >> again. Now I got only broadcast on cxl0 and cxl1. Then finally I got all the >> traffic to show up by doing >> >> ifconfig cxl1 -promisc >> ifconfig cxl1 promisc >> >> It would appearer to me that the card can get into a state where ifconfig >> reports that it is in promiscuous mode when it is not. >> >> >> Joe Jones From owner-freebsd-net@freebsd.org Mon Apr 17 13:34:48 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6BEDD41E49 for ; Mon, 17 Apr 2017 13:34:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 88175F4B for ; Mon, 17 Apr 2017 13:34:47 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 2510F602B7 for ; Mon, 17 Apr 2017 08:34:47 -0500 (CDT) Subject: Re: Small socket programming question To: freebsd-net@freebsd.org References: <83113.1492398076@segfault.tristatelogic.com> From: Karl Denninger Message-ID: Date: Mon, 17 Apr 2017 08:34:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <83113.1492398076@segfault.tristatelogic.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050707010509070007030304" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 13:34:48 -0000 This is a cryptographically signed message in MIME format. --------------ms050707010509070007030304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/16/2017 22:01, Ronald F. Guilmette wrote: > Sorry, I -think- I know that answer to this question, but > I'd prefer to ask and make sure, in case I have misunderstood > things. > > I am aware that for any open socket, the kernel sets aside > some amount of buffer space for that socket. (And yes, I > *do* also know that the specific amount set aside may be > programatically controlled.) > > So anyway, let's say that I have either a RAW or UDP > (datagram) socket open and my program is running on a > nice fast machine, but it's outbound connection is via > a rather slow link. So if my program writes and writes > and writes to this socket, eventually, I'll have used up > all of the buffer space that the kernel has associated > with the socket. > > My question is just this: What happens then? Will further > writes to the socket block until some more packets get sent > out, you know, so that there is once again room in the > outbound buffer that's associated with this socket? Or will > I instead get some error back from the call to write(), like > for instance EAGAIN or ENOSPC or maybe ENOBUFS? > > Or does the kernel in such cases just silently discard > one or more of my precious outbound packets without even > telling me? (I guess this is my way of asking whether or > not the FreeBSD kernel may, in some cases, itself be a > source of "packet loss".) > > Thanks in advance for any & all enlightening replies. What happens depends on whether you have set the socket to nonblocking or not. If it is set to blocking then the call should block until space is available. If it is set to nonblocking then you get a -1 back (instead of the number of octets actually written) and errno is set to indicate the reason. EAGAIN should be returned if the call would have blocked if the socket was set to blocking mode (the output buffer is full); you can also get ENOBUFS, but that is supposed to mean system buffer congestion (rather than your *specific* socket's buffer set being full.) Note that you generally need to use sendto and friends instead of write for connectionless operation since it specifies a destination and option flags (in other words you don't need to call connect), and write() doesn't return the full set of error conditions that sendto does. A kernel (FreeBSD or otherwise) may be *forced* to discard data should it run out of buffer space on the receive side and in that instance there's nobody to notify since the cause of the overrun is not on the local machine. That's the "least bad" outcome for that involuntary situation. But in the event that a local process *would* cause a buffer overrun the kernel will instead return an error to the calling process and *not* toss the data on the floor. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050707010509070007030304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA0MTcxMzM0NDZaME8GCSqGSIb3DQEJBDFCBEDVKSWn /fUGOHBJGInZO/kevpc12QtFmEjZhL9Voc7hIkTj0s+T7VlKXIQaCpBdarB6mzLP25wGkqVv 2bI5QngVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAkFs2pxvyBbRj JuKg4eZUe27TyWYWHwLYrVOUvd8RPjOTYG1IEFDNyrxt/LJP9gWX1//5eoPgaV26UXiUK1ch q01w8ilVWgSJJeJbcD6YJvvYCmnEm+2a5e82o7k+TA/7h3oUTrF+oWndT07aRdTo4toIpad4 qPju18xXvm/64ui4gV8P5mnVCGG/YLJSECQWU1L+N9ByeOJABeyIdq+25WwEgT0x0Aoakzca CqK1ttqAej3NWQDLf1/lxpTkMpdCZDScHqxtPVgyPsP4f57ukEB+/WALE1ffT8zHWSjgwNvH 0V9QHre2ylATrfZjcMCco21db4uAjaalbozyPvg1KsUkOfRSALjQPQa5XC7eY1R9m61vnoFo fVB0YRQ+3wHlfKtHcvXIIFpLpVhV3dMM2AMQVaWEjW5pem67pGq3xig+uo58rKE6xuUsNUnq nH+Hiu/qBgCWlJ1OyIewFpKFpBB1ajMisOKK6VeRyT0mzAlh7/RWa0x51quatz3gaqKFA1fP qKLUAGuzkNzyKkXCZATw/qgmfEa1+W4uodrHV4poDOSmq+gne1+N+9ggZLvRB0n9umURfl1u ywNkL/wyhHACJydz0ok09yljY2eC/CnUaF16zAr9qUFgX2lt8sKP3zwV4DBgAMYQbHTMpCvz X7f4bI70frJGIIj1jNwWbmwAAAAAAAA= --------------ms050707010509070007030304-- From owner-freebsd-net@freebsd.org Mon Apr 17 13:58:55 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 371B8D4243A for ; Mon, 17 Apr 2017 13:58:55 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (mail.torek.net [96.90.199.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "elf.torek.net", Issuer "elf.torek.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1072ED4B for ; Mon, 17 Apr 2017 13:58:54 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.15.2/8.15.2) with ESMTP id v3HDwmF3071624 for ; Mon, 17 Apr 2017 06:58:48 -0700 (PDT) (envelope-from torek@torek.net) Message-Id: <201704171358.v3HDwmF3071624@elf.torek.net> From: Chris Torek To: freebsd-net@freebsd.org Subject: three multicast fixes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71622.1492437528.1@elf.torek.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Apr 2017 06:58:48 -0700 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (elf.torek.net [127.0.0.1]); Mon, 17 Apr 2017 06:58:48 -0700 (PDT) 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, 17 Apr 2017 13:58:55 -0000 The first is mostly cosmetic, it's just something I observed when I turned on multicast debug to find the bug that the second patch is for. The second patch is a kludge and if anyone has a better fix, have at it. :-) Note that it's also hard to provoke the bug. The only way I know to observe it somewhat reliably is to create and destroy bridge interfaces, using a debug kernel with memory debug enabled, while adding and deleting hardware interfaces to the bridge so that they repeatedly join and leave multicast groups. Eventually you hit the race and crash. The third is simple enough to observe. It may affect only the lagg driver, which implements SIOCDELMULTI by removing and re-adding all the multicast addresses other than the one actually deleted (which is of course really-removed by then). If running lagg on a VIMAGE kernel, leaving a multicast group causes this occasional crash: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x28 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80adf6ea stack pointer =3D 0x28:0xfffffe009117e810 frame pointer =3D 0x28:0xfffffe009117e8b0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (thread taskq) rt_newmaddrmsg() at rt_newmaddrmsg+0x2a/frame 0xfffffe009117e8b0 if_addmulti() at if_addmulti+0x24c/frame 0xfffffe009117e940 lagg_ether_cmdmulti() at lagg_ether_cmdmulti+0x168/frame 0xfffffe009117e= 980 lagg_ioctl() at lagg_ioctl+0xad/frame 0xfffffe009117ea60 in_leavegroup() at in_leavegroup+0xb9/frame 0xfffffe009117eab0 inp_gcmoptions() at inp_gcmoptions+0x1a8/frame 0xfffffe009117eb20 taskqueue_run_locked() at taskqueue_run_locked+0x117/frame 0xfffffe00911= 7eb80 taskqueue_thread_loop() at taskqueue_thread_loop+0xc8/frame 0xfffffe0091= 17ebb0 fork_exit() at fork_exit+0x85/frame 0xfffffe009117ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe009117ebf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- Here, "curvnet" is NULL in the lagg_ioctl(), so that when rt_newmaddrmsg() does: if (V_route_cb.any_count =3D=3D 0) we crash with the offset of the per-vnet route_cb data. (The patches are in Git format, I applied them to the read-only freebsd master tree on GitHub.) Chris =46rom 65145b74d3dae68feddcf8a2aad235c3f0a981e9 Mon Sep 17 00:00:00 2001 From: Chris Torek Date: Mon, 8 Feb 2016 18:55:30 -0800 Subject: [PATCH 1/3] ip multicast debug: fix strings vs defines Turning on multicast debug made multicast failure worse because the strings and #define values no longer matched up. Fix them, and make sure they stay matched-up. --- sys/netinet/in_mcast.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/sys/netinet/in_mcast.c b/sys/netinet/in_mcast.c index c7fff9463128..eef560e7aca7 100644 --- a/sys/netinet/in_mcast.c +++ b/sys/netinet/in_mcast.c @@ -2920,7 +2920,14 @@ sysctl_ip_mcast_filters(SYSCTL_HANDLER_ARGS) = #if defined(KTR) && (KTR_COMPILE & KTR_IGMPV3) = -static const char *inm_modestrs[] =3D { "un", "in", "ex" }; +static const char *inm_modestrs[] =3D { + [MCAST_UNDEFINED] =3D "un", + [MCAST_INCLUDE] =3D "in", + [MCAST_EXCLUDE] =3D "ex", +}; +_Static_assert(MCAST_UNDEFINED =3D=3D 0 && + MCAST_EXCLUDE + 1 =3D=3D nitems(inm_modestrs), + "inm_modestrs: no longer matches #defines"); = static const char * inm_mode_str(const int mode) @@ -2932,16 +2939,20 @@ inm_mode_str(const int mode) } = static const char *inm_statestrs[] =3D { - "not-member", - "silent", - "idle", - "lazy", - "sleeping", - "awakening", - "query-pending", - "sg-query-pending", - "leaving" + [IGMP_NOT_MEMBER] =3D "not-member", + [IGMP_SILENT_MEMBER] =3D "silent", + [IGMP_REPORTING_MEMBER] =3D "reporting", + [IGMP_IDLE_MEMBER] =3D "idle", + [IGMP_LAZY_MEMBER] =3D "lazy", + [IGMP_SLEEPING_MEMBER] =3D "sleeping", + [IGMP_AWAKENING_MEMBER] =3D "awakening", + [IGMP_G_QUERY_PENDING_MEMBER] =3D "query-pending", + [IGMP_SG_QUERY_PENDING_MEMBER] =3D "sg-query-pending", + [IGMP_LEAVING_MEMBER] =3D "leaving", }; +_Static_assert(IGMP_NOT_MEMBER =3D=3D 0 && + IGMP_LEAVING_MEMBER + 1 =3D=3D nitems(inm_statestrs), + "inm_statetrs: no longer matches #defines"); = static const char * inm_state_str(const int state) -- = 2.12.1 =46rom 099e1b2c059fe962c1dd91af0a6735f02f611ac3 Mon Sep 17 00:00:00 2001 From: Chris Torek Date: Wed, 10 Feb 2016 18:41:39 -0800 Subject: [PATCH 2/3] ip multicast: fix use-after-free During if_detach(), we get a race where a closing socket is releasing multicast data (via inp_freemoptions()) at the same time as igmp_ifdetach() is releasing all multicast data for the interface, resulting in a potential double teardown and double free. This bug has been present since late 2011: Author: jhb Defer the work of freeing IPv4 multicast options from a socket to an asychronous task. ... It is very hard to trip over. You must create and delete interfaces (bridges that join real interfaces are good candidates) repeatedly, and even then, if M_IPMADDR (in_multi data structure) memory is not reused for something else during the race, the reference count in inm->inm_refcount is an unsigned int, so it decrements from the left-over 0 to 4294967295, avoiding a second free. Turning on the memory debug options (scribbling values over freed memory) catches the problem more quickly, though you still must create and destroy interfaces that partcipate in multicast to see it. The fix here is a kludge, but should serve until the entire network locking code and up/downcall system is reworked. --- sys/netinet/in.c | 4 ++++ sys/netinet/in_mcast.c | 11 +++++++++++ sys/netinet/ip_var.h | 1 + 3 files changed, 16 insertions(+) diff --git a/sys/netinet/in.c b/sys/netinet/in.c index e1611d50b4f0..50cfb188c442 100644 --- a/sys/netinet/in.c +++ b/sys/netinet/in.c @@ -1013,6 +1013,8 @@ in_purgemaddrs(struct ifnet *ifp) struct in_multi *inm, *tinm; struct ifmultiaddr *ifma; = + inp_freemopt_wait(); /* XXX kludge */ + LIST_INIT(&purgeinms); IN_MULTI_LOCK(); = @@ -1043,6 +1045,8 @@ in_purgemaddrs(struct ifnet *ifp) igmp_ifdetach(ifp); = IN_MULTI_UNLOCK(); + + inp_freemopt_wait(); /* XXX kludge */ } = struct in_llentry { diff --git a/sys/netinet/in_mcast.c b/sys/netinet/in_mcast.c index eef560e7aca7..1d1258701fa2 100644 --- a/sys/netinet/in_mcast.c +++ b/sys/netinet/in_mcast.c @@ -1585,6 +1585,17 @@ inp_freemoptions(struct ip_moptions *imo) taskqueue_enqueue(taskqueue_thread, &imo_gc_task); } = +/* + * Wait for inp_freemoptions() to complete any current work. + * Used because inp_freemoptions is no longer synchronous. + */ +void +inp_freemopt_wait(void) +{ + + taskqueue_drain(taskqueue_thread, &imo_gc_task); +} + static void inp_freemoptions_internal(struct ip_moptions *imo) { diff --git a/sys/netinet/ip_var.h b/sys/netinet/ip_var.h index f7e58d18635a..e51bcffc4fc2 100644 --- a/sys/netinet/ip_var.h +++ b/sys/netinet/ip_var.h @@ -200,6 +200,7 @@ extern struct pr_usrreqs rip_usrreqs; #define V_drop_redirect VNET(drop_redirect) = void inp_freemoptions(struct ip_moptions *); +void inp_freemopt_wait(void); int inp_getmoptions(struct inpcb *, struct sockopt *); int inp_setmoptions(struct inpcb *, struct sockopt *); = -- = 2.12.1 =46rom e27ff26bd086c46f2b1cce8eb95f4625cc4333fc Mon Sep 17 00:00:00 2001 From: Chris Torek Date: Sat, 5 Mar 2016 15:02:33 -0800 Subject: [PATCH 3/3] ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). --- sys/netinet/in_mcast.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys/netinet/in_mcast.c b/sys/netinet/in_mcast.c index 1d1258701fa2..4549c952e058 100644 --- a/sys/netinet/in_mcast.c +++ b/sys/netinet/in_mcast.c @@ -1275,12 +1275,12 @@ in_leavegroup_locked(struct in_multi *inm, /*const= */ struct in_mfilter *imf) CTR1(KTR_IGMPV3, "%s: doing igmp downcall", __func__); CURVNET_SET(inm->inm_ifp->if_vnet); error =3D igmp_change_state(inm); - CURVNET_RESTORE(); if (error) CTR1(KTR_IGMPV3, "%s: failed igmp downcall", __func__); = CTR2(KTR_IGMPV3, "%s: dropping ref on %p", __func__, inm); inm_release_locked(inm); + CURVNET_RESTORE(); = return (error); } -- = 2.12.1 From owner-freebsd-net@freebsd.org Mon Apr 17 22:49:24 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB0FDD421F8 for ; Mon, 17 Apr 2017 22:49:24 +0000 (UTC) (envelope-from jk@kornberger.name) Received: from digineo.de (mail.digineo.de [IPv6:2a00:c380:c0de:0:5054:ff:fed4:52c2]) (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 91BF71B8F for ; Mon, 17 Apr 2017 22:49:24 +0000 (UTC) (envelope-from jk@kornberger.name) Received: from [192.168.180.23] (p4FF91622.dip0.t-ipconnect.de [79.249.22.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jk) by digineo.de (Postfix) with ESMTPSA id 8813860773; Tue, 18 Apr 2017 00:49:23 +0200 (CEST) To: freebsd-net@freebsd.org From: "Julian K." Subject: Deadlock in ifaddr_change() while removing IPFW rules Message-ID: <1ae1a996-7218-77b3-3617-b9ed4e45621b@kornberger.name> Date: Tue, 18 Apr 2017 00:49:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:49:25 -0000 Hello, I wrote a kernel module [1] for a the fastd UDP tunneling protocol. Like the if_tun it calls if_purgeaddrs() on destruction of interfaces. When I delete IPFW rules a the same time the kernel runs into a deadlock. It seems to be a general problem that also affects other network drivers. Could someone please take a closer look at this issue? Below I attached some debugging outputs. Regards Julian [1] https://github.com/digineo/fastd/blob/master/kmod/fastd.c db> sh allchain chain 1: thread 100108 (pid 822, moind) blocked on lock 0xffffffff80ede7d8 (rw) "IPFW UH lock" thread 100146 (pid 15746, ipfw) blocked on lock 0xffffffff80ede740 (rm) "IPFW static rules" thread 100027 (pid 12, irq266: virtio_pci0) blocked on lock 0xffffffff80ede780 (sleep mutex) "IPFW static rules" thread 100146 (pid 15746, ipfw) blocked on lock 0xffffffff80ede740 (rm) "IPFW static rules" thread 100027 (pid 12, irq266: virtio_pci0) blocked on lock 0xffffffff80ede780 (sleep mutex) "IPFW static rules" thread 100146 (pid 15746, ipfw) blocked on lock 0xffffffff80ede740 (rm) "IPFW static rules" thread 100027 (pid 12, irq266: virtio_pci0) blocked on lock 0xffffffff80ede780 (sleep mutex) "IPFW static rules" thread 100146 (pid 15746, ipfw) blocked on lock 0xffffffff80ede740 (rm) "IPFW static rules" thread 100027 (pid 12, irq266: virtio_pci0) blocked on lock 0xffffffff80ede780 (sleep mutex) "IPFW static rules" thread 100146 (pid 15746, ipfw) blocked on lock 0xffffffff80ede740 (rm) "IPFW static rules" thread 100027 (pid 12, irq266: virtio_pci0) blocked on lock 0xffffffff80ede780 (sleep mutex) "IPFW static rules" thread 100146 (pid 15746, ipfw) blocked on lock 0xffffffff80ede740 (rm) "IPFW static rules" ... [repeats] db> thread 100108 [ thread pid 822 tid 100108 ] sched_switch+0x6cb: movl %gs:0x34,%r14d db> trace Tracing pid 822 tid 100108 td 0xfffff80005a1e500 sched_switch() at sched_switch+0x6cb/frame 0xfffffe0098330490 mi_switch() at mi_switch+0xd2/frame 0xfffffe00983304c0 turnstile_wait() at turnstile_wait+0x408/frame 0xfffffe0098330510 __rw_wlock_hard() at __rw_wlock_hard+0x94/frame 0xfffffe00983305a0 ifaddr_change() at ifaddr_change+0x43/frame 0xfffffe00983305d0 in_difaddr_ioctl() at in_difaddr_ioctl+0x4e4/frame 0xfffffe0098330640 in_control() at in_control+0x47f/frame 0xfffffe00983306d0 if_purgeaddrs() at if_purgeaddrs+0xf4/frame 0xfffffe0098330780 fastd_teardown() at fastd_teardown+0xb0/frame 0xfffffe00983307b0 fastd_clone_destroy() at fastd_clone_destroy+0x2a/frame 0xfffffe00983307d0 if_clone_destroyif() at if_clone_destroyif+0x22a/frame 0xfffffe0098330820 if_clone_destroy() at if_clone_destroy+0x12e/frame 0xfffffe0098330850 kern_ioctl() at kern_ioctl+0x2d4/frame 0xfffffe00983308c0 sys_ioctl() at sys_ioctl+0x171/frame 0xfffffe0098330990 amd64_syscall() at amd64_syscall+0x4ce/frame 0xfffffe0098330ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0098330ab0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80166e82a, rsp = 0x7fffdf7f9e68, rbp = 0x7fffdf7f9ea0 --- db> thread 100146 [ thread pid 15746 tid 100146 ] sched_switch+0x6cb: movl %gs:0x34,%r14d db> trace Tracing pid 15746 tid 100146 td 0xfffff80005cb8500 sched_switch() at sched_switch+0x6cb/frame 0xfffffe00983df3b0 mi_switch() at mi_switch+0xd2/frame 0xfffffe00983df3e0 turnstile_wait() at turnstile_wait+0x408/frame 0xfffffe00983df430 _rm_wlock() at _rm_wlock+0x2ac/frame 0xfffffe00983df4a0 delete_range() at delete_range+0x31f/frame 0xfffffe00983df520 del_rules() at del_rules+0x73/frame 0xfffffe00983df550 ipfw_ctl3() at ipfw_ctl3+0x6e8/frame 0xfffffe00983df830 rip_ctloutput() at rip_ctloutput+0x1f2/frame 0xfffffe00983df860 sogetopt() at sogetopt+0xf1/frame 0xfffffe00983df8f0 kern_getsockopt() at kern_getsockopt+0xde/frame 0xfffffe00983df960 sys_getsockopt() at sys_getsockopt+0x50/frame 0xfffffe00983df990 amd64_syscall() at amd64_syscall+0x4ce/frame 0xfffffe00983dfab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00983dfab0 --- syscall (118, FreeBSD ELF64, sys_getsockopt), rip = 0x800b3881a, rsp = 0x7fffffffd8a8, rbp = 0x7fffffffd930 --- db> thread 100027 [ thread pid 12 tid 100027 ] sched_switch+0x6cb: movl %gs:0x34,%r14d db> trace Tracing pid 12 tid 100027 td 0xfffff80001544000 sched_switch() at sched_switch+0x6cb/frame 0xfffffe0098192bb0 mi_switch() at mi_switch+0xd2/frame 0xfffffe0098192be0 turnstile_wait() at turnstile_wait+0x408/frame 0xfffffe0098192c30 __mtx_lock_sleep() at __mtx_lock_sleep+0x13d/frame 0xfffffe0098192cb0 _rm_rlock() at _rm_rlock+0x3c6/frame 0xfffffe0098192cf0 ipfw_chk() at ipfw_chk+0xa42/frame 0xfffffe0098192ee0 ipfw_check_packet() at ipfw_check_packet+0xeb/frame 0xfffffe0098193040 pfil_run_hooks() at pfil_run_hooks+0x83/frame 0xfffffe00981930d0 ip_output() at ip_output+0xdd7/frame 0xfffffe0098193220 icmp_reflect() at icmp_reflect+0x553/frame 0xfffffe00981932e0 icmp_error() at icmp_error+0x525/frame 0xfffffe0098193330 ipfw_chk() at ipfw_chk+0x30bb/frame 0xfffffe0098193520 ipfw_check_packet() at ipfw_check_packet+0xeb/frame 0xfffffe0098193680 pfil_run_hooks() at pfil_run_hooks+0x83/frame 0xfffffe0098193710 ip_input() at ip_input+0x39d/frame 0xfffffe0098193770 netisr_dispatch_src() at netisr_dispatch_src+0xa5/frame 0xfffffe00981937d0 ether_demux() at ether_demux+0x12a/frame 0xfffffe0098193800 ether_nh_input() at ether_nh_input+0x322/frame 0xfffffe0098193860 netisr_dispatch_src() at netisr_dispatch_src+0xa5/frame 0xfffffe00981938c0 ether_input() at ether_input+0x26/frame 0xfffffe00981938e0 vtnet_rxq_eof() at vtnet_rxq_eof+0x84c/frame 0xfffffe00981939b0 vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x93/frame 0xfffffe00981939e0 intr_event_execute_handlers() at intr_event_execute_handlers+0x20f/frame 0xfffffe0098193a20 ithread_loop() at ithread_loop+0xc6/frame 0xfffffe0098193a70 fork_exit() at fork_exit+0x85/frame 0xfffffe0098193ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0098193ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- From owner-freebsd-net@freebsd.org Mon Apr 17 23:49:51 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91FB8D4202F for ; Mon, 17 Apr 2017 23:49:51 +0000 (UTC) (envelope-from dreadiscool@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B9AF1731 for ; Mon, 17 Apr 2017 23:49:51 +0000 (UTC) (envelope-from dreadiscool@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id u2so41944776wmu.0 for ; Mon, 17 Apr 2017 16:49:51 -0700 (PDT) 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=BKSDMALF6E8jipnwE6DfuTxboRFE5uMhF48zd0Q3LkQ=; b=RZH+l3y9D4EFPjfq9iEhvNvKEETCrXp0hqOJ2oQ5Ce6/VU+D0MqFmWTzkizhoOFVzZ aMkcCZRRTQmf4FP9pSfjsk2Z85Pqb2AZcZl2SFFH9ZSCukBy1/jgi5pq9Pe4/8M8ZRoC 3A6kfgcnM5ySTfPxiloAIGAzU5oOv4eR2K9+80GMoXms1IQxA4PrZ8ElY68KKn87sKbb 0e/QZvYvXC5mytIY+f+Erhi7vxs38391qz7qdFztckmDL/zn3mnHNvFKrgiOYhxg9Nol 2G+DlZ/0FJhWJc+LhzRTl3EQBXfwYLlSIrsEQ9DE17MGeAL6kVApbqR6Hpp5YaNvc+S0 9tRQ== 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=BKSDMALF6E8jipnwE6DfuTxboRFE5uMhF48zd0Q3LkQ=; b=OPYKyyy0krRURO7P20JdCALTz9IntojFUhrdUQC7nJInIIlAvfk8cRyyC5ZWewcfFg xSNVUm2U1Q4SYug/a5UpLgOfgVxy0/D14N80r+GvDt3wvDQeZdYLCDLOlHAZhCQcw7dt 0FQbBSett9Dv+iNk+AqVB3qsAK1GHnhOW+6XM7vG38thtvXeUB5yOkjEq25jpJrPqJrx YSkQG311VgaeJxzrrzc7mr+OI3uG93f0KFytVPnCxsmCIzpfNWNCmhQQgOBZWTpvAcj1 nshI2rWPMusYbuuC4Sa8qDc9CQSuWtCougWdal23g0X/97uM+3dkXwb7IOtluQ+sxYgI eB0Q== X-Gm-Message-State: AN3rC/6qQK/dbOOwb0NJxLqVnni9GHAVDxVM4YgNM/IcH6XZksXRa5rq 4zCXzTrfQcrphRmMJm9aEgvIivFC6aT+ X-Received: by 10.28.0.201 with SMTP id 192mr10984834wma.126.1492472986122; Mon, 17 Apr 2017 16:49:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.165.68 with HTTP; Mon, 17 Apr 2017 16:49:45 -0700 (PDT) From: Paras Jha Date: Mon, 17 Apr 2017 19:49:45 -0400 Message-ID: Subject: Netmap zero-copy with multiple NICs To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 23:49:51 -0000 Is it still possible to share ring buffers across multiple physical network cards for zero-copy mode, or does the application need to take this into account and perform a one-copy? From owner-freebsd-net@freebsd.org Tue Apr 18 07:33:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8871D43C4B for ; Tue, 18 Apr 2017 07:33:27 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 9D174112F for ; Tue, 18 Apr 2017 07:33:27 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id r203so167146823oib.3 for ; Tue, 18 Apr 2017 00:33:27 -0700 (PDT) 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=96fJQ3gJBRrAFWg8Uxgx17AY1vsLou3n0Ap8np1opIc=; b=KgG2Ak2Vk+n75jYdavZKOHVkds+tZDYgRwLCtGFG8auvKV9IFOi5qn/7pMHDad6CWR Zs4wEBaZdC9YxTSl0Sri07CjOttlhIqqteTEj91vOwf/aR9AoZ5B21aFuLZUIJppV7Aq 72HkLHk3ZQHpdvfovtnLEJQCg06s5i0hXLzE34ThDlbZPSNdtz1iIJYWIuOCdoEdYGKp XLFIOoDlzc7Ht/ExOR9Wfdnp7O7D39wXtbgGWfZUtllTXceRAZ3vQxWJ2si3bZ3zkzPY A9pVBp+CYc64+EOtcMDi08cVcnpBMm56h78dh11BYaBYB+sUpuJmqUJZtSdpYulRnHng 7KCw== 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=96fJQ3gJBRrAFWg8Uxgx17AY1vsLou3n0Ap8np1opIc=; b=EIIXlhnRLVLTRStdwZn9fnK2u0k1y8DV9imAlWZL7sZL5jnKMMXtarWpcHNZItGPsy aS0lXA3aCumoCAC/I7bOpIubMbQy4PxzR2rrdCkkMa2ACTbaonxGwn12lwrc3fb6l5Xe fUodbcBdsKapFw2re0AWayEq2S50reiD7Orr7u8K+XWy3/iJjsLDtrtF6hhBPAs4wG27 F7MTT8cXjTlJUJdhkFMCcl8rQLY++qSDKgwO/t6MwAwLyDI2Ri6hzg66t2XCchGmNAdg A32zpDQH/8AYgXdV5MI0BDwA8D666TRONW2o+tYID6SKRUXBTmgPlVBdh/79a0RHwfDx M2ow== X-Gm-Message-State: AN3rC/4nbVHMtLna30D7/IRtO6E7v+hiAUluuM6Nw6YSFkI1Q16+oTFb XXVTnl2SiSsQjrMpvR+9ZHVwDX2bjQ== X-Received: by 10.157.42.170 with SMTP id e39mr6367430otb.56.1492500806890; Tue, 18 Apr 2017 00:33:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.5.10 with HTTP; Tue, 18 Apr 2017 00:33:26 -0700 (PDT) Received: by 10.157.5.10 with HTTP; Tue, 18 Apr 2017 00:33:26 -0700 (PDT) In-Reply-To: References: From: Vincenzo Maffione Date: Tue, 18 Apr 2017 09:33:26 +0200 Message-ID: Subject: Re: Netmap zero-copy with multiple NICs To: Paras Jha Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:33:27 -0000 Hi, Yes, by default netmap packet buffers for all physical nics on your machine are allocated from the same memory area. This means that you can do zcopy with the usual swap of netmap slots. The bridge application is an example. It does zcopy if possible, otherwise it falls back to copying. Cheers, Vincenzo Il 18 apr 2017 1:49 AM, "Paras Jha" ha scritto: Is it still possible to share ring buffers across multiple physical network cards for zero-copy mode, or does the application need to take this into account and perform a one-copy? _______________________________________________ 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 Apr 18 09:33:13 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D671D4203B for ; Tue, 18 Apr 2017 09:33:13 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5p.cmail.yandex.net (forward5p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::15]) (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 01706EFF for ; Tue, 18 Apr 2017 09:33:12 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward5p.cmail.yandex.net (Yandex) with ESMTP id DEADD20EFE; Tue, 18 Apr 2017 12:33:00 +0300 (MSK) Received: from smtp1h.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id B21958C063E; Tue, 18 Apr 2017 12:32:58 +0300 (MSK) Received: by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id NtSNbWcRKs-WwT8Jri5; Tue, 18 Apr 2017 12:32:58 +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=1492507978; bh=yOENhEBunu8vsadV9SZ43CjybNCiRq8C7ZmMMwo6GKI=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=fiSsLxyd6i4h6l+3eLN5RAPRk5ftFAbiPLmir5lXXFOFuvcHiZAApNb3iJ+JABYQT rx9MssDLmwfyznBIER+3CxPbQCR9OY53A4rSQSF+Hb9pa2xmvL/gmiD0maM6MkSPc8 rCY9aHGvDIo/Jz0veC4F59m4G7UWARHlkaBZO8B4= Authentication-Results: smtp1h.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: Deadlock in ifaddr_change() while removing IPFW rules To: "Julian K." , freebsd-net@freebsd.org References: <1ae1a996-7218-77b3-3617-b9ed4e45621b@kornberger.name> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: Date: Tue, 18 Apr 2017 12:32:14 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <1ae1a996-7218-77b3-3617-b9ed4e45621b@kornberger.name> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QpAKSMIitA7Gbp3cfUbTtkIQan0i0Xj6D" 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, 18 Apr 2017 09:33:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QpAKSMIitA7Gbp3cfUbTtkIQan0i0Xj6D Content-Type: multipart/mixed; boundary="l59gSRQ8ac2vO7XPwV19wWUix64tkIAgC"; protected-headers="v1" From: "Andrey V. Elsukov" To: "Julian K." , freebsd-net@freebsd.org Message-ID: Subject: Re: Deadlock in ifaddr_change() while removing IPFW rules References: <1ae1a996-7218-77b3-3617-b9ed4e45621b@kornberger.name> In-Reply-To: <1ae1a996-7218-77b3-3617-b9ed4e45621b@kornberger.name> --l59gSRQ8ac2vO7XPwV19wWUix64tkIAgC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 18.04.2017 01:49, Julian K. wrote: > I wrote a kernel module [1] for a the fastd UDP tunneling protocol. Lik= e > the if_tun it calls if_purgeaddrs() on destruction of interfaces. When = I > delete IPFW rules a the same time the kernel runs into a deadlock. It > seems to be a general problem that also affects other network drivers. >=20 > Could someone please take a closer look at this issue? Below I attached= > some debugging outputs. > ipfw_chk() at ipfw_chk+0xa42/frame 0xfffffe0098192ee0 > ipfw_check_packet() at ipfw_check_packet+0xeb/frame 0xfffffe0098193040 > pfil_run_hooks() at pfil_run_hooks+0x83/frame 0xfffffe00981930d0 > ip_output() at ip_output+0xdd7/frame 0xfffffe0098193220 > icmp_reflect() at icmp_reflect+0x553/frame 0xfffffe00981932e0 > icmp_error() at icmp_error+0x525/frame 0xfffffe0098193330 > ipfw_chk() at ipfw_chk+0x30bb/frame 0xfffffe0098193520 > ipfw_check_packet() at ipfw_check_packet+0xeb/frame 0xfffffe0098193680 > pfil_run_hooks() at pfil_run_hooks+0x83/frame 0xfffffe0098193710 > ip_input() at ip_input+0x39d/frame 0xfffffe0098193770 > netisr_dispatch_src() at netisr_dispatch_src+0xa5/frame 0xfffffe0098193= 7d0 What FreeBSD version do you use? There were several changes in head/ and stable/11, that could change this behavior. Can you try the same on recent revision? --=20 WBR, Andrey V. Elsukov --l59gSRQ8ac2vO7XPwV19wWUix64tkIAgC-- --QpAKSMIitA7Gbp3cfUbTtkIQan0i0Xj6D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlj13R4ACgkQAcXqBBDI oXoqZggAt6yX9/9SRUoAZ8glvGdsXIV7ePsf3ClnsaJmWs/B+q5vX3rqjsyEzABv aoqtmE6RdhFjdWHYrZJAQoJ+lQ4UIH+kPtHA/r2uFia/TvaEIDt85W2cA+ZNRulz CBePyAQF86+9q6LP45wm6V7qT07hvCF5QVVMCrgA0bNfrBc+Ni5cjuEQ5jb5Hkkl HKj5giVnaalMNTLG9eRRRYu8mNW2nrSnUKHkZFn776dJvo8EzbqpgmwppywZXVQF NzJc5kXiR3Bgywy5KP11+otWvituYJFjnOTfZ9JtjAASniQD15W7b6P7qwSxn5vK JudyNF3BLoWmGjPLl7QYOE59XIIxvQ== =GhgS -----END PGP SIGNATURE----- --QpAKSMIitA7Gbp3cfUbTtkIQan0i0Xj6D-- From owner-freebsd-net@freebsd.org Tue Apr 18 09:39:39 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72914D42535 for ; Tue, 18 Apr 2017 09:39:39 +0000 (UTC) (envelope-from jk@kornberger.name) Received: from digineo.de (mail.digineo.de [IPv6:2a00:c380:c0de:0:5054:ff:fed4:52c2]) (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 3E0D11253 for ; Tue, 18 Apr 2017 09:39:39 +0000 (UTC) (envelope-from jk@kornberger.name) Received: from [192.168.180.20] (p4FF901F3.dip0.t-ipconnect.de [79.249.1.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jk) by digineo.de (Postfix) with ESMTPSA id 345415FE53; Tue, 18 Apr 2017 11:39:37 +0200 (CEST) Subject: Re: Deadlock in ifaddr_change() while removing IPFW rules To: "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <1ae1a996-7218-77b3-3617-b9ed4e45621b@kornberger.name> From: Julian Kornberger Message-ID: Date: Tue, 18 Apr 2017 11:39:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 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, 18 Apr 2017 09:39:39 -0000 On 18.04.2017 11:32, Andrey V. Elsukov wrote: > What FreeBSD version do you use? > There were several changes in head/ and stable/11, that could change > this behavior. Can you try the same on recent revision? I built a custom kernel with the current https://svn.FreeBSD.org/base/releng/11.0 . Thanks for the hint. I will try the current stable/11 branch. Regards, Julian From owner-freebsd-net@freebsd.org Tue Apr 18 23:45:04 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8234D458BD for ; Tue, 18 Apr 2017 23:45:04 +0000 (UTC) (envelope-from David.Somayajulu@cavium.com) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0058.outbound.protection.outlook.com [104.47.34.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1B7FD3B for ; Tue, 18 Apr 2017 23:45:04 +0000 (UTC) (envelope-from David.Somayajulu@cavium.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3H7VIVAKyT5DiG0a+yyq6Uj0ckNqd83F5XZdEiKbmbw=; b=GTkGJDnIqMJGkMjxjI52LA+EyKfIbkbsckkgEFOWRv9ZfNwkgdbtV8+jHWen9O9tq+F/2z4g4pL05q5GO9LrYKaHOSzxMHi1UinxSJazl0qDv4ivheOfB9LtBfLZlSf6Gjh6hL8Jt47BhQbAJjXSeZxeZBly8Q6lE46IRGEmmgg= Received: from BY2PR07MB1474.namprd07.prod.outlook.com (10.162.76.152) by BY2PR07MB1473.namprd07.prod.outlook.com (10.162.76.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Tue, 18 Apr 2017 23:45:02 +0000 Received: from BY2PR07MB1474.namprd07.prod.outlook.com ([10.162.76.152]) by BY2PR07MB1474.namprd07.prod.outlook.com ([10.162.76.152]) with mapi id 15.01.1034.015; Tue, 18 Apr 2017 23:45:02 +0000 From: "Somayajulu, David" To: "freebsd-net@freebsd.org" Subject: Question on taskqueue_drain Thread-Topic: Question on taskqueue_drain Thread-Index: AdK4na5gtgOJ17dzQtGmCh0Dkfpjpg== Date: Tue, 18 Apr 2017 23:45:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=cavium.com; x-originating-ip: [198.186.0.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR07MB1473; 7:n8wH/hCDruyQVAFsHwsOJQX8PVxnhd30PyBB/N67nbTGOQeFl3e1y6woaoo21RnAYk9Q/dBjfR3K57J4pB9TIaECUam5HmuEAmmzMdv4ikCBRl9wcPDf+/TXCpwIh8J6ckzo4sCYx28osFUSySRUQRKE4ZQdTvanRA4dJNrk1+O4b0OMcPzCYWExWY3bvBdWHp/1mRZKapOZY0RKrdws8UfekmVSly0bk6eScst1E56tb0GENWNeMIj95slHfKQUhYr/zAv3V5AK6XY8KlRB1kVgGcbn0hyU1L5M0/Bc3YgKmhD3RzB9yVgRT2l9jG8tqu04cj5O7l2K1zNZB8DmGg== x-ms-office365-filtering-correlation-id: f0aa5ed4-4ed4-4867-2203-08d486b4eed8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR07MB1473; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:BY2PR07MB1473; BCL:0; PCL:0; RULEID:; SRVR:BY2PR07MB1473; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39850400002)(39840400002)(39410400002)(39400400002)(8676002)(81166006)(9326002)(8936002)(66066001)(50986999)(2351001)(33656002)(54356999)(790700001)(102836003)(6116002)(558084003)(3280700002)(9686003)(99286003)(54896002)(5640700003)(6306002)(3846002)(55016002)(25786009)(6506006)(2906002)(2501003)(6436002)(53936002)(5630700001)(77096006)(5660300001)(110136004)(2900100001)(3660700001)(7116003)(6916009)(122556002)(38730400002)(189998001)(7696004)(86362001)(74316002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR07MB1473; H:BY2PR07MB1474.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2017 23:45:02.1926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR07MB1473 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 23:45:04 -0000 Hi, Is it ok to call taskqueue_drain() when the MTX_DEF lock is held ? Thanks David S. From owner-freebsd-net@freebsd.org Wed Apr 19 00:18:49 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82721D43346 for ; Wed, 19 Apr 2017 00:18:49 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E116FB0 for ; Wed, 19 Apr 2017 00:18:49 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pf0-x22d.google.com with SMTP id a188so3957607pfa.0 for ; Tue, 18 Apr 2017 17:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=QmiREUAEHQCqER1PkIOPSWQ7UoicVGXE4PF858PhJbc=; b=glfgsumRWA0JxIU61S4Gx3kxJHvL+s1fp13Rt+2oBOCeWdKoGAOHwix/ptliXYYMJv Xw5rH4HFoBLVAprGRcDLdhsQroAcOC9NujhaM57WaUYdXZxlqk9oEA3ST014jTrS2YsV zRi9SJHzHYk2R1sx2wR2F134wOlbKd05/UiAZj89tNHkaQumVYWU86RzVpv8Y0r1iSg9 XVkPmM2qiUizf4PL2OeeTJCEOiw+MEN0B4NJSq8FExtHLe31y5h598zgJMILNtUdJsDc opafo5CwwEmElg5pcqHXYfm2Iz7iP3NEheK+y5UB9c6HPlUMG+3ZkNj5WFoVp+XdvbOm zVrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=QmiREUAEHQCqER1PkIOPSWQ7UoicVGXE4PF858PhJbc=; b=KsjPliQ+XEn4/F2BNYxHUhWNCMAfEMFZS7uFhBQasiRCk31CoKXp7QH0V4EsmWmCbV kwEYeFvGgeGts4x8KtazvmdT1dphy7MALxHOaLP0mGVn11ENrko4cArruwGENMrPDIUF 1eM7zdWAJrYokSkuwZI1k1Q8tly8Ihe+usxDwcnz7+IyshgyT+JJfvVlYkYdhHWVMP2L JLDMRyo74HW3OUZHQr39SdrGCGr9Kwi4N+VZ+8rvmPd9092KXry4Rtb4n4rWFBnbx0Tz xZ9UbysgdmcNgYK5uAI2XifK8bLeze0+Z5Ogwf2EQ2P8s+++g1TTOxWJO+tIuLDn+/al GRIA== X-Gm-Message-State: AN3rC/496Jny7lsjJnl3mUjsAIEWoOgAycYIJ0m3Y4n1/nRE8vmn+kYp if6sF5Tp2Zaut0lo X-Received: by 10.84.229.7 with SMTP id b7mr215921plk.72.1492561128659; Tue, 18 Apr 2017 17:18:48 -0700 (PDT) Received: from ox ([2601:641:c000:b800:d74:e025:bd80:1c2e]) by smtp.gmail.com with ESMTPSA id l7sm625180pgn.10.2017.04.18.17.18.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 17:18:47 -0700 (PDT) Date: Tue, 18 Apr 2017 17:18:36 -0700 From: Navdeep Parhar To: Joe Jones Cc: "freebsd-net@freebsd.org" Subject: Re: cxgbe netmap promiscuous mode? Message-ID: <20170419001836.GA4461@ox> Mail-Followup-To: Joe Jones , "freebsd-net@freebsd.org" References: <58D3C6F4.6010500@stream-technologies.com> <58D521C0.1000804@stream-technologies.com> <58F0E683.7050806@stream-technologies.com> <20170414163215.GA9358@ox> <58F49246.801@stream-technologies.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58F49246.801@stream-technologies.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 19 Apr 2017 00:18:49 -0000 On Mon, Apr 17, 2017 at 11:00:38AM +0100, Joe Jones wrote: > Hi Navdeep > > running "ifconfig up" and then "ifconfig promisc" works. Running "ifconfig > promisc" and then "ifconfig up" does not work. Running "ifconfig up promisc" > together does work. Running "ifconfig promisc up" does not work. What version of FreeBSD is this? I couldn't reproduce this on head with a T6 card. Can you please run this in parallel with your ifconfig commands, note what dtrace logs in response to what command(s), and send the output to me? # dtrace -n 'fbt::t4_set_rxmode:entry {trace(arg4)}' > > The combination that does not work leaves the interface in a state where it > reports it's self as being in promiscuous mode. In my experiments the interface did function in promiscuous mode whether I did "ifconfig cc0 promisc up" or "ifconfig cc0 up promisc". Regards, Navdeep From owner-freebsd-net@freebsd.org Wed Apr 19 01:13:43 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C858D445E1 for ; Wed, 19 Apr 2017 01:13:43 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (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 4CC25B52 for ; Wed, 19 Apr 2017 01:13:42 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: by mail-oi0-f54.google.com with SMTP id x184so11531370oia.1 for ; Tue, 18 Apr 2017 18:13:42 -0700 (PDT) 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=HEWnpytiIiVRnr/dYrRyllZ75jKEd65iPp2e6fbAt40=; b=lfTjdDTFPOBzmm8i8xKduI2T1wn+lAOzoTOB5CcSRg6ZBzkIIm/BrPC/JN9yK0oHmv ydoapcGNVT6FsBZoCn5LoTn7G7meE/OUh9uCLgy76ffkFZ+jUlOF30FRQlrFz6sh+eF/ DHhf4HoZlKZAquVJWt+bblQJOwegMUi/v9NYLz6DqmqHx7VZ1gwW5cQg2R2c+Y3Et5h+ +0oQBYkd4yBWullkwm28UDCOMGeMguOmwSD9nRkJVumlS6WXnncp8B9ZrQfvNXyM91Se 3pi9fXjC5lLiIx9J3AlUDRC+NW8ypAJGMPNxHzlLy7eE/Hq0lhQNG5fTdJifaNVen/us /neQ== X-Gm-Message-State: AN3rC/6PxO2wFnzYJdLI0UgCHo7qTWMC4/OT7T7n9yZHuIuVbUQgT8LJ NRvaEsIsws2EQA== X-Received: by 10.157.41.36 with SMTP id d33mr129249otb.24.1492563017382; Tue, 18 Apr 2017 17:50:17 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com. [209.85.218.52]) by smtp.gmail.com with ESMTPSA id s100sm409336ota.43.2017.04.18.17.50.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 17:50:16 -0700 (PDT) Received: by mail-oi0-f52.google.com with SMTP id j201so11002342oih.2 for ; Tue, 18 Apr 2017 17:50:16 -0700 (PDT) X-Received: by 10.157.6.195 with SMTP id 61mr92171otx.119.1492563016272; Tue, 18 Apr 2017 17:50:16 -0700 (PDT) MIME-Version: 1.0 From: Eric Joyner Date: Wed, 19 Apr 2017 00:50:05 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Differential review to add new media types to if_media.h 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: Wed, 19 Apr 2017 01:13:43 -0000 https://reviews.freebsd.org/D10425 I didn't add any reviewers yet because we have yet to test this, and I didn't have a good idea of who would be interested in these. Suggestions on the string to give the active optical/copper cable types would be welcome; I gave them the acronyms I saw in SFF-8024, but I also considered spelling them out, like e.g. "25GBase-Active-Optical". - Eric From owner-freebsd-net@freebsd.org Wed Apr 19 02:39:04 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96433D44C29 for ; Wed, 19 Apr 2017 02:39:04 +0000 (UTC) (envelope-from David.Somayajulu@cavium.com) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0087.outbound.protection.outlook.com [104.47.37.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 517C0DBF for ; Wed, 19 Apr 2017 02:39:03 +0000 (UTC) (envelope-from David.Somayajulu@cavium.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JtDUoFLsneMCgHhptPCz5++OYv6vaKfXQcMoVcGpbu4=; b=gGxmMj5PFa7V75EswS+E0tfA9Eq4ngWJsWUvIbe/1nZOgkvHcyjYeClyCdjfeciJTeZrEzdYwCGZODvhQhI3/apo9CEPEIu1eKSMX5bfvoGxDhbsjWn4Rv6/puCqPKikUQbr7kS+JhwlA0jbH8Nhr9Dm4sUiy4wn+WNMvNU62Uo= Received: from BY2PR07MB1474.namprd07.prod.outlook.com (10.162.76.152) by BY2PR07MB1476.namprd07.prod.outlook.com (10.162.76.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 02:39:01 +0000 Received: from BY2PR07MB1474.namprd07.prod.outlook.com ([10.162.76.152]) by BY2PR07MB1474.namprd07.prod.outlook.com ([10.162.76.152]) with mapi id 15.01.1034.015; Wed, 19 Apr 2017 02:39:00 +0000 From: "Somayajulu, David" To: "freebsd-net@freebsd.org" Subject: RE: Question on taskqueue_drain Thread-Topic: Question on taskqueue_drain Thread-Index: AdK4na5gtgOJ17dzQtGmCh0DkfpjpgAGAVKw Date: Wed, 19 Apr 2017 02:39:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=cavium.com; x-originating-ip: [198.186.0.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR07MB1476; 7:7OuXzUGZtZbtiEF+2io2XsLh8M5h6bjWGFWq3w/FCBY0mmoYYe617EqHnVqp4L8RAJF+Pe22rDBrOZjpnY0TUqUEypNuVmYYoMea9DhhPcjr8vSVWZPMFc9TMW3YnjNLhRVKswbDNFTFWwz96UtwKpKAp2m31WfcK3Y6Csz7Gi3FvZJqwTF9wyKlMeok7Kcy4NOrEh+/lKF6sxiK+I2SiOnX6C6wH0bWtHALxRTLqGGOfdZzX3nEv6H5bTqy/OAx+/OVP3Gof+wRdkqdSmJEWTGe7kXXTycfHS13YJJdhS+Bx7vLct53YnRgHJroOIgZNcTEAztUf7ajXM68euEIhA== x-ms-office365-filtering-correlation-id: a63e5f94-d801-4525-20e3-08d486cd3ca1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR07MB1476; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:BY2PR07MB1476; BCL:0; PCL:0; RULEID:; SRVR:BY2PR07MB1476; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(54356999)(3660700001)(3280700002)(8936002)(7116003)(7696004)(5660300001)(81166006)(33656002)(2906002)(66066001)(8676002)(76176999)(25786009)(3846002)(6116002)(229853002)(189998001)(102836003)(2950100002)(86362001)(6916009)(2900100001)(110136004)(50986999)(38730400002)(99286003)(558084003)(122556002)(2351001)(55016002)(305945005)(2501003)(6436002)(77096006)(53936002)(74316002)(6506006)(5640700003)(6246003)(7736002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR07MB1476; H:BY2PR07MB1474.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 02:39:00.7421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR07MB1476 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, 19 Apr 2017 02:39:04 -0000 Sorry what I meant to ask was, whether it is O.K to call taskqueue_drain(),= when an MTX_DEF lock is grabbed prior to calling taskqueue_drain(). Thanks David S. (davidcs@freebsd.org) From owner-freebsd-net@freebsd.org Wed Apr 19 03:37:17 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73549D443D9 for ; Wed, 19 Apr 2017 03:37:17 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AFF81FC2 for ; Wed, 19 Apr 2017 03:37:17 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-ua0-x234.google.com with SMTP id q26so6990833uaa.0 for ; Tue, 18 Apr 2017 20:37:17 -0700 (PDT) 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=rwby7A0jbSNQgdEl8Yf/e8lMsFZoqe+S+jm60ElhII8=; b=HZ5iyqgxrfLJ4BpD8ZVBTkcNwadgRvf9QVdMw/l+qN9HneeY/FiLGRgzIoYhaxxb/F XHAfRC5rEuT4A957dGF2NHd/T+RnxT/usKOYN6WuG94yLGSzkyMaroXxNueaSIcukqZI 4Qh1jqYvQjgs9h2NHO0zgLrTlRYjnMoL1qLAvsYSYTB+wr6QzattbPrWbYZcQ2fmn9o+ iBV2btEkqrVAfkyQdms1JdWvmtOCjJBWTmhjSaNDGyLWp2iM5aTB2HaLtaePC4dEA/S+ tYLxnVrcOnLfxCz6y8OJB2aYDRRh9Q4dGKzqY7OXnMpgfbV3NmoBHlmi1Ldt5lk1S+Lh FsKQ== 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=rwby7A0jbSNQgdEl8Yf/e8lMsFZoqe+S+jm60ElhII8=; b=X1Tb/fpM/vGQDf0Fa6FYVsUEF60hfCY+4Rs7ZlVzHcrFPaATuyFBxyoj63/Qv3ZhKb M5KT7I4Kd8kMJxn3PabLDw7S+ZGWgJQNKJ3ip5MZUZpguKkzjBBN968yHWgXy7Y2Ztq5 cwdLeTqhHlsjk0Hn5fA6Y2QeXFht88+SlXZbdGsKjf85Gm3MFSVWvtbFRNDWAhZ0LPIi 2PH7Qt911WR8w18m6srq6Isg4Xoww/rZiUE5A1ArXIP5ZjIb9JKfgkRXAEAFkHIocxeB f5M0SjkjvUgv/mUxiZMO7z3vDd+rZlcYOz6vEg/msKlDoi3F6fYtLbOpCh+6e3dehmqY YNAQ== X-Gm-Message-State: AN3rC/7JSoFFPwnUt7NAJg4IgfPPBnkGLCENZqtpPb+pbIwG2Y8Q/Gni ph/b2RsE/ZhZ11TG6tAFNuAeEhxYuQ== X-Received: by 10.176.5.194 with SMTP id e60mr317569uae.71.1492573036287; Tue, 18 Apr 2017 20:37:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.97 with HTTP; Tue, 18 Apr 2017 20:37:15 -0700 (PDT) In-Reply-To: References: From: Sepherosa Ziehau Date: Wed, 19 Apr 2017 11:37:15 +0800 Message-ID: Subject: Re: Question on taskqueue_drain To: "Somayajulu, David" Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 03:37:17 -0000 On Wed, Apr 19, 2017 at 10:39 AM, Somayajulu, David wrote: > Sorry what I meant to ask was, whether it is O.K to call taskqueue_drain(), when an MTX_DEF lock is grabbed prior to calling taskqueue_drain(). > You will hit WITNESS, if the drain needs to wait; that's probably the best case. If the lock will be acquired in the task being drained, this leads to deadlock. Thanks, sephe -- Tomorrow Will Never Die From owner-freebsd-net@freebsd.org Wed Apr 19 04:24:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8522BD45361 for ; Wed, 19 Apr 2017 04:24:27 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4EA91FC for ; Wed, 19 Apr 2017 04:24:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id BBE001FE022; Wed, 19 Apr 2017 06:24:17 +0200 (CEST) Subject: Re: Question on taskqueue_drain To: Sepherosa Ziehau , "Somayajulu, David" References: Cc: "freebsd-net@freebsd.org" From: Hans Petter Selasky Message-ID: <1fb80f2b-9086-0260-2f63-bdaf8afc1c4c@selasky.org> Date: Wed, 19 Apr 2017 06:22:28 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 04:24:27 -0000 On 04/19/17 05:37, Sepherosa Ziehau wrote: > On Wed, Apr 19, 2017 at 10:39 AM, Somayajulu, David > wrote: >> Sorry what I meant to ask was, whether it is O.K to call taskqueue_drain(), when an MTX_DEF lock is grabbed prior to calling taskqueue_drain(). >> > > You will hit WITNESS, if the drain needs to wait; that's probably the > best case. If the lock will be acquired in the task being drained, > this leads to deadlock. > Hi, No sleeping functions like taskqueue_drain() can be called when the MTX_DEF lock is grabbed. --HPS From owner-freebsd-net@freebsd.org Wed Apr 19 09:29:13 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6346BD43EB0 for ; Wed, 19 Apr 2017 09:29:13 +0000 (UTC) (envelope-from Joe@stream-technologies.com) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0057.outbound.protection.outlook.com [104.47.0.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A12A410E for ; Wed, 19 Apr 2017 09:29:11 +0000 (UTC) (envelope-from Joe@stream-technologies.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=streamtechnologiesuk.onmicrosoft.com; s=selector1-streamtechnologies-com01e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NdtjmN4KkNoEWCT3oIh9m4FWnkx747kVK5IShQfdWfA=; b=YOsI/vmygW4ZaJ4ZQqdfT08ZcgBzoyAdL/vUdMr7qxH+5dS8xnRcoRmeDix6pgR6Zd9w3QYTd6xWxFtRhFqMynKb9pg599Mm+7l003qEfsOj9nwHVk8RXYA4oCb5SYWIsiTyDT6C8FBA0AChHxZW+4LiZ0VgU0rF/Gu8tkU9zhY= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=stream-technologies.com; Received: from [192.168.6.128] (212.20.240.118) by AM2PR07MB1025.eurprd07.prod.outlook.com (2a01:111:e400:8444::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Wed, 19 Apr 2017 09:29:08 +0000 Subject: Re: cxgbe netmap promiscuous mode? To: "freebsd-net@freebsd.org" References: <58D3C6F4.6010500@stream-technologies.com> <58D521C0.1000804@stream-technologies.com> <58F0E683.7050806@stream-technologies.com> <20170414163215.GA9358@ox> <58F49246.801@stream-technologies.com> <20170419001836.GA4461@ox> From: Joe Jones Message-ID: <58F72DE2.40503@stream-technologies.com> Date: Wed, 19 Apr 2017 10:29:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20170419001836.GA4461@ox> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [212.20.240.118] X-ClientProxiedBy: AM5PR0701CA0059.eurprd07.prod.outlook.com (2603:10a6:203:2::21) To AM2PR07MB1025.eurprd07.prod.outlook.com (2a01:111:e400:8444::22) X-MS-Office365-Filtering-Correlation-Id: 9d4437b7-7853-4d95-d8a0-08d48706882f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM2PR07MB1025; X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB1025; 3:9tmcpY8ESDkl2VHajTcc5LDZkJW4oT6Nwr3jCgSZ2nJAocy31+t0ao9Tm6oF1G24Am+H/2Yz4jJ8bGS02ZP9pN4j72sq5TMYPsAfmbfvc7X7m1r17m3PqCLz6QnklX5d2KbL+pIABToXcxYL+Hg709B5Sq2w2hQnekoqmNZX5v1x8ERbJt83huLa1Yxv6n4bWUbHWsCwvcNuc+w0fBIpW7DgDMETSrBDRkn5hMkBTW6SX0+N0nHbtPgX8iDjn8leBn6rj9pB7gduU2rt79kX6U7KEAUE6eaYmuVpLcutR70JG6GmGBuY0m5Qwkzz0pxS0oqNvALyzorhCfn3lZKf9Q==; 25:OidUcRGiWHsred+Otnq9MC0m7AfQFalKfKaQKdoc3AUbFEGfBoEqZi/57PYklFXWg1AQ9DcT0cHU86WJyZVkLt7W1Vvz9jWgvd8BAQFk0LprFCizXG7SAXF8qvPyc6o4ecaCQNN1oclGs9TrxNdyD0OnQs6q3L+SrgIlZ9TpJ2odp2FgqQGOa7Hv0oL2eEhKW/8v3OFpTwZTPSaoFSlRLgGfpr5Tju78CJFGSPr9rgP2gicAB2k1hQHg9pIvOGNlscQB0O0l8Us//X8tRvv6nfNwChMnWbXNsl2gXFeZfzZenNMTcBcvIj6Lt19Lo4bzt8S/IUIG3PnbTDyIR1IPHXuivlCCd3JHj/4GrxRF4H80MQhbZQ2UADJS1W0wfw5B9I/BxAYHpAKXBrgMgpqx9FdpDwXW2OeVoFWMNg0udSSF1npp7fkaSM4j5VKnbssXFIMARHPz3iiAquSBnG1IUw== X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB1025; 31:Uug2KFK/IHL2agiQMvLHACdWa1xJWa6JIESd/4p8dsZwH1Hc9Pll83CprtPEHF6hbbFAGDEdIKMPy7DE3fEpr/2zAbiP35w3h/3/QdBf+Fhm/mCozzA8pkD/i24pQTNTgzmXICWsGRNhgtupTiGDJxqm5tbfJUfjbu2Aqw8tjjH6YlETOSzFpVG7MdRsv4IhUATyjN8jO7wy13lANWtH1kNnP0T3DcRnZP3uw00bBEyY2Zq3/liLV3rLxhGIktChoOonRr5c/lb4Wey0c5buLkRWnX3MJ3KadhpjxCWu06o= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:AM2PR07MB1025; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB1025; X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB1025; 4:VjzWAaG9a54ePMDJhsWYbTN+VlyC4VH99nRX7R3/kaaeOUua/qgo/5p9qZ0MFyA2zA8YZyMLCZxo/2zfYFYddslvZNjEK4yayd6lRZLplA0RyxyN7e/4FEbt+oo3ku7GxNq/rvb+Pk2ZfTCjrfDNKvDeUbOHwZBGANQy+sFLZLJFid2JH+sUEe1kCovXok3UOzuDXBFHeh2NJSmqaG3Om+yEGAlpaZdBBsjoBHMoXG+z60Om8yk3PpikydW4mkXqMxswvd+TGLljaDuvuUlVZFvD7N2QR6WVRZwlbqHGODnRM52ACQ6GzVipG4DRPiL/NS6VhQcABMdGCc6Q2vv0K8VlgX6YVwHz/x0ggFcR9soj6Tw6Wy3V6zyPIaiQvGCZGXofftoB7VFTNEiKD+1gQWANiNZCpyDoT/IC3JrQO7iItiLgWmPVMteqwZ3zQdqpzsU4NMAAwltN+weZXNsLW4IdCS7wmv4m95H5DcR5tFUaUs4QrUo+XZRqIbqiaM7uWy8/EgTPvH94VLBj6QjRxmfsps3v2HuAC0xk7DZyYB2ENHSm4P84SPa+Itd/ZzCkZb3fgLxwRNzM86mJ62c339M+H3I+krQHM7UHIjqQ7GLvV53noSQidlaM9UZlm0QKq8syD7SPnKbFEAdKnp+HoPUR+iuGcTY3Q6IujRDRyAvgDbu/yh57oBXXN8h1g/mZJ4xF9/8z4pT5OG+hfNt/jDxniEgcykBefE9IPZrN3ElLnIbwQeBBJ4tK9eVvE7w7+qCXku53+T+iLuuxjZF8rQ== X-Forefront-PRVS: 028256169F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(39410400002)(39450400003)(39400400002)(39830400002)(24454002)(65956001)(65806001)(2351001)(36756003)(66066001)(38730400002)(3480700004)(229853002)(7736002)(3846002)(5660300001)(93886004)(8676002)(6116002)(53546009)(80792005)(81166006)(110136004)(2906002)(6916009)(117156002)(4001350100001)(33656002)(53936002)(25786009)(50466002)(23746002)(2950100002)(50986999)(305945005)(64126003)(83506001)(86362001)(230700001)(47776003)(65816999)(42186005)(6486002)(189998001)(76176999)(2501003)(54356999)(77096006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB1025; H:[192.168.6.128]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM2PR07MB1025; 23:DOZYeMhCc2VvX2e3gVaVFd9NKu7VX+l+fA45i?= =?Windows-1252?Q?o7H4O3nFN7jHWCUn+L9tXJH85/Xc18tXcDAyHb7cKkpDNnCa/k6uuIza?= =?Windows-1252?Q?gtmaG6uN8hlHC7tBVa7eqMAhpHVacI9npzTrjjploOS3jbntWrok7QIS?= =?Windows-1252?Q?PExBHq2hqfiVZuZqrFZmdexUzUlU0MIIDIFtyqeobE3DA6KOe2SEzYiP?= =?Windows-1252?Q?sQ73JstEbMJgOBMQeymwF0MNAPeey1WFXPXIYruGjqvaZY52C5MPqdkj?= =?Windows-1252?Q?gQvrlsx2U/sBIdPDhjQllp93uGTAoB9pamtuKQdWGIZu9tj1Kr9OxMIE?= =?Windows-1252?Q?EifsDw93W55tHL7lzBiv114NlNQ63PCCaJvchrnO8BifwDkfaF1y9Q1x?= =?Windows-1252?Q?3YwH7SESDzE3VMaJJjsgfAYCgfUFb0Yccf5M09gocoWa+8Nc47+g25Bw?= =?Windows-1252?Q?bLpdNBRT44gdwxYlPJIVRrLd/ZxAqQFM6w8I0PTRakg+SbvVDoV7tsL7?= =?Windows-1252?Q?eNA/gUq5PzySkDLApYJX/DuMNyo7qQku3u1Bl5eZWjuJaX/LJUH7SW1r?= =?Windows-1252?Q?FEZV4B8ZCo1KGRxFQ5IZgoHr9fQLutubmIMlNil+KbDL9hY088nyk0Dz?= =?Windows-1252?Q?B6LMX3lejAcRgpNiwFezLbSOIFGYQ2JlgDu0lAytYIkyxdnzqd8ZJiBd?= =?Windows-1252?Q?0OuUenerrLTasjcuMuiQnBCaP0Uf1zpuVszvH9iyxOg51AMbQLyrvqYB?= =?Windows-1252?Q?+p+rUtry/131LaBFgXNtt/R9UEvbGsav9My0rbWjLt5IaAuzgtCGnd7t?= =?Windows-1252?Q?R+g6w0gbNVrQL2HOLprDBf93w7o5SdUiS83QUmZdCm7tnguAlS8gurD5?= =?Windows-1252?Q?A64cpPlS/p0Sy1QUIVsF6bqeyuEmQMecze98N63XB6FHj48ki/sK7bhW?= =?Windows-1252?Q?zIUjX5w/mN9yeHF2ULj/KTXGjKr060vb2s3jZqCcE2PpFZ/96PxY58db?= =?Windows-1252?Q?nGZy9KOOCMBCNSRn5LcyYomwZ+uceROr/0fPsUNLPNMpThnz35aDOQyp?= =?Windows-1252?Q?/brKDfdwin5YMGdxHYcBAK9nlshQ48A07pGGZ6jEs5lwZal6i/eUBhGD?= =?Windows-1252?Q?+rXB2sLIXRVLLR2Qkb2oLNEw+hBTUAqb5zy8asCkHyIwwtrn4s5Bmovw?= =?Windows-1252?Q?3K117ekWjQHjQBiY1Y0wL6iB3D+98ucW+gAZR4IxeYKHl/AEotytBFyL?= =?Windows-1252?Q?F9naahvgC7uUzbD1hG9fmUsB7mOK++29d+mjc3fJCQ7WwVZVJncvi8i2?= =?Windows-1252?Q?F994rxxkhIq7St49kh3tEbmUD9MgMp2+Up+GaD7nlASvXgkLHV+8wcQy?= =?Windows-1252?Q?UxWhr3A3cTR?= X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB1025; 6:tYpW7Kb7SwL+m0GapHIV5Lmk7xLFD3S3ZzThSDLoLyzie1ln5XuKfT1DNSoydk8ApffnxCYAOhkFP57IO3xfHVFMncZOJV2x6usqasBpiWao+URUEWlasDXdyqGsOLXhgxpdNxYkpBQCfM0cQ+O0AQ6mGjjbel+tJ1SzqC3IPNqeEOnQ3KVeO999RlVxgCjoncWfCDG4/Kt14GnFaS6S7EY45tLv04v/qYSgzNc6GQZyvcJcctMNPPzZsP4GzTTQuacYR7cQkwUK13cBxYnsc/m+eK1/iH8ZRNyzXW+WLIQ+XgZqem0YK20yOdTEa4mn9VZC6TO6jfCFNwoG+muA7MNSex8NoSf61rGrGgxqLzJb5jSNmTufZphLvCMiE5BBloUKycn88PKkIpQcK03qmAMxFMt/yyBpNvbAScM1Dwk/+JNH5YFQxUds0/wUFr5hGT8EtMAft4xENqi+58/qf7C/pq6lTcSSROuGHG+PZKlqmzFyh01RsCH6cOC79DHv6gmd++REeWUEhfr/t78hSQ==; 5:kACv7i1kdRvnfHYlahJSw2nUCeNB/28Ml50lomk3RdIlssX7cmoRcbfxMa8akhtQM8lbydY+GNDrBJHGBqjve3GBaVibac0hQTGT6ecivFMW39dk0HxX8KFsDFjQurpnTIPgeN0GFFFoXo4nCvnI8Q==; 24:YuGcr6+lgiDBtHnjTH5LkEezmLnAEc5SSyrNAWx41NRtQW8YlH/IfKQ0x3i7J9cJIBGVAD3dDzD+Dr5W0sLoU0vqb+PB9GfBYLV+Dcm8tU0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB1025; 7:Frht1NbKM3PQITuX3J1WrzApk7uJnUxOsKt/eOkLUZO75BtjQsh7hSvOahVvMw/u4csNoODwN8SFYYTd5KK2sP26WpTECZ+lK2CWTzLf3OY3HdiSsz6IIjkcok7+BFLPRiaoSi/oVY5d9ImCkmiiLUsv9BBjnKYwj5CC7aZzzKDD8ThY5Hu5za1ZRgLn4VC+fYeFIEwNc/QajgsFjWlMZMhmYhl7J6ZJKNhEm8OvO5GZGdE28hAtJx6rJJdAn1YULeGs4xCIcoKxw10NlweNZQMz2OawKS0aK+KQ+idXa2k4wZ3L6jghxT2v8iBZc0GRU73Mr6CjPJTdHbJ4T0gSnA== X-OriginatorOrg: stream-technologies.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2017 09:29:08.9252 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB1025 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, 19 Apr 2017 09:29:13 -0000 uname -a FreeBSD goose2 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 The card is a 'T520-SO Unified Wire Ethernet Controller' I ran the following with dtrace running in a separate window ifconfig cxl1 promisc up ( only see broadcast) ifconfig cxl1 -promisc ifconfig cxl1 promisc (now I see traffic) dtrace output was [root@goose2 /usr/home/joe]# dtrace -n 'fbt::t4_set_rxmode:entry {trace(arg4)}' dtrace: description 'fbt::t4_set_rxmode:entry ' matched 1 probe CPU ID FUNCTION:NAME 4 61078 t4_set_rxmode:entry 1 7 61078 t4_set_rxmode:entry 0 5 61078 t4_set_rxmode:entry 1 On 19/04/17 01:18, Navdeep Parhar wrote: > On Mon, Apr 17, 2017 at 11:00:38AM +0100, Joe Jones wrote: >> Hi Navdeep >> >> running "ifconfig up" and then "ifconfig promisc" works. Running "ifconfig >> promisc" and then "ifconfig up" does not work. Running "ifconfig up promisc" >> together does work. Running "ifconfig promisc up" does not work. > What version of FreeBSD is this? I couldn't reproduce this on head with > a T6 card. Can you please run this in parallel with your ifconfig > commands, note what dtrace logs in response to what command(s), and send > the output to me? > > # dtrace -n 'fbt::t4_set_rxmode:entry {trace(arg4)}' > >> The combination that does not work leaves the interface in a state where it >> reports it's self as being in promiscuous mode. > In my experiments the interface did function in promiscuous mode whether > I did "ifconfig cc0 promisc up" or "ifconfig cc0 up promisc". > > Regards, > Navdeep From owner-freebsd-net@freebsd.org Wed Apr 19 15:31:49 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3423D46658 for ; Wed, 19 Apr 2017 15:31:49 +0000 (UTC) (envelope-from Joe@stream-technologies.com) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20069.outbound.protection.outlook.com [40.107.2.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FDDA14C0 for ; Wed, 19 Apr 2017 15:31:48 +0000 (UTC) (envelope-from Joe@stream-technologies.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=streamtechnologiesuk.onmicrosoft.com; s=selector1-streamtechnologies-com01e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JLvPQsReT+oW3sU1jNYvCB2mpz4hPDUvW2xEAzgHKOU=; b=T7jyPoAVdFqKmp5L1j/hqxo9KFuAZOtCn8HDex/lYmjavZipVpdF+40TvveuymzlwHlv3HKrpen9A6m6CmkDN7vl115HFuAO1QTyHrDZWdWgv2jRQ/RCUfUL6ao5ePFd4ds1aXjRamazY1VE9f10kKKOe317ivz0vxBqBudWraE= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=stream-technologies.com; Received: from [192.168.6.128] (212.20.240.118) by HE1PR07MB1035.eurprd07.prod.outlook.com (10.162.27.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 15:31:43 +0000 Subject: Re: cxgbe netmap promiscuous mode? To: Navdeep Parhar References: <58D3C6F4.6010500@stream-technologies.com> <58D521C0.1000804@stream-technologies.com> <58F0E683.7050806@stream-technologies.com> <20170414163215.GA9358@ox> <58F49246.801@stream-technologies.com> <20170419001836.GA4461@ox> <58F72DE2.40503@stream-technologies.com> <20170419143745.GB4461@ox> CC: "freebsd-net@freebsd.org" From: Joe Jones Message-ID: <58F782DA.6060007@stream-technologies.com> Date: Wed, 19 Apr 2017 16:31:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20170419143745.GB4461@ox> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [212.20.240.118] X-ClientProxiedBy: DB6PR04CA0002.eurprd04.prod.outlook.com (10.170.208.15) To HE1PR07MB1035.eurprd07.prod.outlook.com (10.162.27.27) X-MS-Office365-Filtering-Correlation-Id: 45ea13ed-7e45-47bb-459f-08d487392f1c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:HE1PR07MB1035; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1035; 3:EbMS4MYxcu7gM2cNVhGt+3oqZoydeGa32io3+CHdlr9pqImzemmKf1Q0IOmfr/Hs3zJWLLN/tvqu2deK1tLqoNT449Abvcd4O2Lr09pLrMHnvBGpT0BWVGDfbQaqJ5775Xn9AZr2B4+sNiU38znyMdHIw0dnlyJhGLxTbLE0DOMB6yGYfIxYxRxZzj97dezbjE4lZRnfoxZgOW4DgmfiZx/+O6zhu6q6NOqIf8PqiItNnoOYxRHinqdoDCPvEHVGe3BOy8F4j5VWrE0mFJyZ2GgG3Fcnri82mdJkh0uVXpDX/dDf1/EufOsO2iY5QCm+YD2/JfuSttIDXA2XOZgcwg==; 25:FUTX1ay0dj8yAakbKucRnCIYTXhyTLl5GdpWxskMVqI4vpgBl3ss19+c0W5cwvyhOMsdVees4PlL0TE41y32zSXxp+VoRCbm5n3BT4oq2asKTaDONViK2hN7oJ3g8iUmIMEkUGf/cABqq7AgJ8euqlmmYqLPK8Nx0XHeqYMZ0Yz6SPtbJ60a95UzQ6X3O8yvlXHvYKUlrDJV05SE5BoZHx9Bg/RUShzx115R0oQ75QoYc+kEOx/5XP7wVtAA9TqTfb8Bn7i8m6srCJP4lzZUAYVayYpGXAV+mTfQ/XjmgGlvsInuHkeStWEKsYh34hf7DADDYm8/HPyWAiv+ocsX17XK8kFPef5bWiBBG3qITUKEVYSBaRNd7d9jhrAn9RW2aWoPeiG2Z0IOhWbLcJCo2HyG7ZLM6gWVu9EWFHV+TYiADXOIpEkdLK00haoH+jS2mPoeR2up/fUV1H1uGawBiwE/yGrKMKgK52sk+FRVc9E= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1035; 31:kJkoVzY3Z/UxlSOt0F0OBjdSJdl/2o9UDMjGGLV11ehasyF4TwbvkS6MXvXORxmruVao7bqNIi0t3/rFvIFN9+AuZ27PbZZnwB1A6aC6pM2xEHJkwi0g0HzweIamnGXscg0YJH2mxdwkWFdcFPTBMfjd8B4gkWAxvvHi/WWQIJmKgTXTEBFcmGJG8o50xlletN+fy/W/rw9fvIN5ruLezVV9nm8PQFIXqxdzTrfdRXrC2rK0j5JVuDgltPpYMew3NIyhjhUphvoRscbumSK/bA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506)(75325880899374); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:HE1PR07MB1035; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1035; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1035; 4:LjH/2UI0P/50JV9csxoMbstpmdBUBt07T5aIXormn08rRNcAN1kxcAMyEO5GYT/D9YA8tz4NPtZO74d8f3kzUNF9DBWOxjGCzGk2/WqR2qrJ6PrNT4A3/yfISGTo/bRaiUIgY1wcNeQp71yaFItF8BrTWF3gvQ+fqrKj6LSdnCzw6wF8fkZQK0i2wD7v09aCgXV6QzlZ35JfNxWpoyNJrCqDnxSAXBr3gmXsLjjTihh9MOX2WyZB7RVlT1D2kzc6Z1CmsxNthOzUOMNt99fBmwn0DlHvO3m8Gr8Aa/dw/d0iUgTEhZaEskAHVSrpipommONjZWExc85QCInwMk30hZqiVpAL8geyeZxvKB3aotyssHFC4umYJQSGcK2F54DecdaIbXwM/QBFJWFTPQvDw6OhXihUn3vCfmdl+EiXLorUcD7Ny/9V5yMLyBl+/qGWDTp9d7252ZJ59EYb0TdyZNQg8Wq5/QvTuDCIFp2L4m0j/lsJDSPnuGjKVsj2nBj2XneGjj1ymvTNUtFFt+6YWKH8QFy0LGDxuc/Gvq+0HLbl1T8PstMBgKoMWtn6wHUT8EN4yOC86xziY0Kw8mxq43fDxraHmYGQn8u88ebBQBVlIY+5hPjTTdL/7qp1mFlKzsNsWfLjH1EmuR6LOEWAHDI8HR91KF/SZU1kK4GFKDtbjiiaWAsW+9nZC8ZR7eY9LpGeOGSTGLt+IDYHxfW8eqbgeOeiDbce6Jsab21YcnYRnyJMiV0GfliJZJ4h2F6AtlagOwrMy7FaKfdIlAtn4Hu1a5sFjXco2j4EcJA9xhQ= X-Forefront-PRVS: 028256169F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(39400400002)(39830400002)(39410400002)(39450400003)(24454002)(4001350100001)(53936002)(189998001)(65956001)(66066001)(65806001)(6246003)(2906002)(80792005)(83506001)(6916009)(80316001)(50466002)(1411001)(86362001)(6306002)(33656002)(76176999)(6666003)(87266999)(3480700004)(2950100002)(50986999)(93886004)(47776003)(54356999)(110136004)(65816999)(53546009)(5660300001)(4326008)(38730400002)(25786009)(305945005)(42186005)(59896002)(6116002)(36756003)(90366009)(6486002)(3846002)(117156002)(81166006)(230700001)(229853002)(8676002)(77096006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1035; H:[192.168.6.128]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; HE1PR07MB1035; 23:MPvh3C+edVVgAby4V9Fh8L+LBOUWk/bT7/Xku?= =?Windows-1252?Q?kCMwTnFdlRNGFY01PnoKTAXgpc1Alf4jtbpHscoc8j9RTbyXaV/Gr40B?= =?Windows-1252?Q?KfLKVbUoOC1V6I/+VAOt0GZ/DfF8wXgeTD+ljgGdkrsYvm/c5Zt1a0Kl?= =?Windows-1252?Q?islSoF2CdJJUuqBLGGeTpOE83MzA6YQdxbk6CBTSC60A8omN6lbeR1/X?= =?Windows-1252?Q?isWSz182V/xWN/WNNF+S0TNWMw5kQ0tIy76YYVF+iPedx9G6XNMJqOMn?= =?Windows-1252?Q?SI1nkqNfGysLPX7T9eJF95mv96uo8glpDMVMf0OCh+bGihMWEdqmkk7/?= =?Windows-1252?Q?Jbuth5nBbEhwNYYmPly5EPh1CoPG3GzWr1fsgiIZnJC65Eldd7ylqwy8?= =?Windows-1252?Q?1nOLvqnfTLDwgzHj5a01//hVOwNrdGXW17oP94z522B993yXbAjAn0NC?= =?Windows-1252?Q?dYAHtZ/XDLvXIaSZcuVK5qad24emrv8v8NzpgRobmjsKStog6h2CTSZM?= =?Windows-1252?Q?rSvjk0GPIByRZuq8pHMZK71DulOG9y1+RpiVnhN9/wx1xjUet4eb9I/z?= =?Windows-1252?Q?ECSF7sLSBGJWuhb6xDdM1lsuCG8k6sTHZyAjba2z7lMJF0v9kz2dBrnl?= =?Windows-1252?Q?RMOBkl4I2pSOa3stNCYlA+rqP724qEOgdW2CafDpluryHIEReLd/dXte?= =?Windows-1252?Q?dUoq+3frjVjdQZ1RURtVtHPg9PvLmr0PDkTgP9qrS1sPHuL/jvqMISvb?= =?Windows-1252?Q?QDSrHk2ta8ejlD1MO5obo0EvvOKbPJH20xBcQn10IX6g2IdGWnl7XWRm?= =?Windows-1252?Q?5wf39x05KZgf6CbGq2rdh+YduNQ5XfDS37gpXi+xjm/IB+clqte4GD/Q?= =?Windows-1252?Q?v9X0LOwa6Dr9B39ekdqsE5ufHsgK6PlHOLu2knr7dX0oxZWMIqHD5tEN?= =?Windows-1252?Q?BEHKgNUq4WimPD/8o97KHwrovuEhQuMo6BSBaULI5UJWHmjmvvdP8ngs?= =?Windows-1252?Q?VGWvz6Un4TocDB0W/Tlk4WMLm0AMNvqQ2zaaoMyHxDG5KTiXFti6V3aq?= =?Windows-1252?Q?ZdM1ilq/F9vndtYGwWCr7tvWeEeAEkeV2Nna1mAvcrnUqublCal/0fRy?= =?Windows-1252?Q?55MMsPhMO+cJCAI2MjiyWwpsAijX1V0RXEGBW95oYDngN+jngcH72nao?= =?Windows-1252?Q?/lSdHexPxo8MOKdOXeTKjtijkVEudUQ6OXLftAbJw54lCAbdE6mvSG7n?= =?Windows-1252?Q?PJrqSC3MVW10LsAlhVOFcQSjRJaLSm4LfA7x7W1ag+E99gbw//0LA+jY?= =?Windows-1252?Q?pYZ8nhDjC/2G7rSbZ9BRhBuvkEOcPchoXHzkBoA49JCFLheZJVNyo5E9?= =?Windows-1252?Q?N791afLfrDV3Tws5Sj0WwLUbH0ZQa5k1reVoAfS8fTOHsOqyOUZt5VPD?= =?Windows-1252?Q?+aetPQFoWnRknywSC4s?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1035; 6:E5bggqXj+1d27F6VaP1kIic4YIF8ut76wMzzGQ2dPI7SkQXbV7UX4A4Oc5zdA6aXGjVIA5XPzPVOY7+8khBhzuen2F2kdNFxq7KNgeB5mq8BcWvH4fvRKg1DH0tSBKuV4Ilr1PZl6Qn8bW+mLyZ4LiDtpZzUElu8qGGh0pH9hN0uLzlbgklDtVB6GJthEotC5BoHzGCGVMjFJn3C0MN0CE2XZ0VgbmycJ+Hs8fE2dHULoIHEBL4iTbbGnMDrdaprdC8UczmgFh5fyEDrCCH9B+6T2Pw4Q60+jgW8pGb+W3P4w5ClQ8ny+DdrTO3jDY11XkCE5drtR9JplSAAW3jO7fhI7CDEYSsFseS1x/AG0cNyu1dlutaNK5/aZJz8KlgP13cPBQ4+V34pW46J0GGVK0Bm9NUpq0II07RhlkfB6kLimMEO69Rsy475/iCAVv0sO5E2nvdnEzK21XeA79Uz9g==; 5:UfmQ2gKe9mXtAIOI1hX3skVQi1EA7/zjQha/sCJmFeTCBdcm8r44FIbUJ3y5RuBFtcZAWtQuuO6isgjhsNpRbc8zg5/CSzoS/h/fNb1UJC2pgbdNlquEgKi373ea/bjXknfPeCsmgKANJlvvtRbGig==; 24:B2tHABGVLftI/MUJUN1sNLOwlmppkkOlQyPmSWWMLVw+kb/fVyfd/LV+7kUmnkkzH6q3zxvDIq/zyEAt804O2XdyOLxNSBD2CoCfMetep98= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1035; 7:L4wAcuWpX+56KLNaAAO+RNovoAPXR7dbeBBHOeq90iF+atsPaYGOvLZosyVnr8DmHtCNVtYgFCqTUmu4v9ue5uCP2bN0gFv/HAraBr284uP9bKswBrkX+Tyni34HaKZjxm2gc8Q6Sw70gx9ZXIL9N291CWwvaYL91i/rDT4jz8ILVjoK9y+o8moNd/g6AVFrTkJv9S7/5t4oOcNxLzBlBdbCb2U2XwhH+CDaDl7D1WDuU5qfnC2FS9raoj5HuOK2tozxv296y4plnsZ4bokBNnpq4dPxmp9/qRuqtt9T0B7Nfo/QT0QM6vsML5/Ptg+8akF1Jk9dZXx93VyyykH2qw== X-OriginatorOrg: stream-technologies.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2017 15:31:43.5637 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1035 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, 19 Apr 2017 15:31:50 -0000 Hi Navdeep, I already got rid of the hw.cxgbe.num_vis line in loader.conf when I rebooted this morning. dev.t5nex.0.firmware_version: 1.15.37.0 On 19/04/17 15:37, Navdeep Parhar wrote: > What is the firmware version? > > # sysctl dev.t5nex.0.firmware_version > > I'll try to repeat the experiment with a T520-SO with the firmware that > you have on your card. Does the card behave this way if the extra VIs > are not created? Can you please try without hw.cxgbe.num_vis in > loader.conf? > > Regards, > Navdeep > > On Wed, Apr 19, 2017 at 10:29:06AM +0100, Joe Jones wrote: >> uname -a >> FreeBSD goose2 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 >> 08:48:40 UTC 2017 >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >> >> The card is a 'T520-SO Unified Wire Ethernet Controller' >> >> I ran the following with dtrace running in a separate window >> >> ifconfig cxl1 promisc up ( only see broadcast) >> ifconfig cxl1 -promisc >> ifconfig cxl1 promisc (now I see traffic) >> >> dtrace output was >> >> [root@goose2 /usr/home/joe]# dtrace -n 'fbt::t4_set_rxmode:entry >> {trace(arg4)}' >> dtrace: description 'fbt::t4_set_rxmode:entry ' matched 1 probe >> CPU ID FUNCTION:NAME >> 4 61078 t4_set_rxmode:entry 1 >> 7 61078 t4_set_rxmode:entry 0 >> 5 61078 t4_set_rxmode:entry 1 >> >> >> On 19/04/17 01:18, Navdeep Parhar wrote: >>> On Mon, Apr 17, 2017 at 11:00:38AM +0100, Joe Jones wrote: >>>> Hi Navdeep >>>> >>>> running "ifconfig up" and then "ifconfig promisc" works. Running "ifconfig >>>> promisc" and then "ifconfig up" does not work. Running "ifconfig up promisc" >>>> together does work. Running "ifconfig promisc up" does not work. >>> What version of FreeBSD is this? I couldn't reproduce this on head with >>> a T6 card. Can you please run this in parallel with your ifconfig >>> commands, note what dtrace logs in response to what command(s), and send >>> the output to me? >>> >>> # dtrace -n 'fbt::t4_set_rxmode:entry {trace(arg4)}' >>> >>>> The combination that does not work leaves the interface in a state where it >>>> reports it's self as being in promiscuous mode. >>> In my experiments the interface did function in promiscuous mode whether >>> I did "ifconfig cc0 promisc up" or "ifconfig cc0 up promisc". >>> >>> Regards, >>> Navdeep >> _______________________________________________ >> 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 Wed Apr 19 17:36:55 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E0B4D465D7 for ; Wed, 19 Apr 2017 17:36:55 +0000 (UTC) (envelope-from David.Somayajulu@cavium.com) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0050.outbound.protection.outlook.com [104.47.38.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23DB31AA3 for ; Wed, 19 Apr 2017 17:36:54 +0000 (UTC) (envelope-from David.Somayajulu@cavium.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jftCtmVgsRSrJ0HELwHRF4pj+ZupUCLgItEBYDY4T94=; b=OcqRwif/WRQeujyele1cjs6P33aeG2IlQTw+fIptG8fxoGedSTgAZMx+6hxovDM8oHINWkvZYbi30ErpSFLjWkLQK2l3TFhamZ1kXTW5CiH8vGjnnYvp78Cut+5s9uxbhwEuI84Z/5dsdzrp7l4xNCZIfBwBew490DDa0FjHjYw= Received: from BY2PR07MB1474.namprd07.prod.outlook.com (10.162.76.152) by BY2PR07MB1476.namprd07.prod.outlook.com (10.162.76.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 17:36:52 +0000 Received: from BY2PR07MB1474.namprd07.prod.outlook.com ([10.162.76.152]) by BY2PR07MB1474.namprd07.prod.outlook.com ([10.162.76.152]) with mapi id 15.01.1034.015; Wed, 19 Apr 2017 17:36:52 +0000 From: "Somayajulu, David" To: Hans Petter Selasky , Sepherosa Ziehau CC: "freebsd-net@freebsd.org" Subject: RE: Question on taskqueue_drain Thread-Topic: Question on taskqueue_drain Thread-Index: AdK4na5gtgOJ17dzQtGmCh0DkfpjpgAGAVKwAAIiR4AAAZREAAAbs/Ew Date: Wed, 19 Apr 2017 17:36:52 +0000 Message-ID: References: <1fb80f2b-9086-0260-2f63-bdaf8afc1c4c@selasky.org> In-Reply-To: <1fb80f2b-9086-0260-2f63-bdaf8afc1c4c@selasky.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: selasky.org; dkim=none (message not signed) header.d=none;selasky.org; dmarc=none action=none header.from=cavium.com; x-originating-ip: [198.186.0.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR07MB1476; 7:kcaRcEnduA/S16Fiy9UDFU/ABlOVAPEiVpRw3o8dWYf6pjW0+H7k/s6LtmcKozL6pmxSryZNqDfQ4WjvJhC2weMgFnHt3+mfEGvpeR5pvEQFylF4D/6PrJbZfdI229XYMjSi+sYCL4gor1AQJ7gVdsRRNxgYAzRbJg02XON0uQUpwth1plDKNC2tjuTrwEaMPUUKuhTwtankra96krr1lBL8EZg2eJVsbItr2YO2Qtr1glSHjBzYI6fB8KFeCa8k2QHb41v6j1qc/RRrhNMBMXCmuTQpqyicaeOtdTVGFH2KfkHaKYWRiqcuY0XP5iABF29wmON7egNPrhswVX9dPw== x-ms-office365-filtering-correlation-id: a2847aa3-2171-4f79-8c78-08d4874aaac1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR07MB1476; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BY2PR07MB1476; BCL:0; PCL:0; RULEID:; SRVR:BY2PR07MB1476; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(377454003)(51914003)(24454002)(13464003)(3660700001)(3280700002)(54356999)(7696004)(8936002)(5660300001)(7116003)(81166006)(33656002)(2906002)(53546009)(66066001)(8676002)(76176999)(6116002)(93886004)(229853002)(189998001)(102836003)(25786009)(3846002)(2950100002)(2900100001)(86362001)(50986999)(38730400002)(99286003)(39060400002)(305945005)(122556002)(4326008)(6436002)(55016002)(77096006)(53936002)(6506006)(6246003)(74316002)(7736002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR07MB1476; H:BY2PR07MB1474.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 17:36:52.5571 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR07MB1476 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, 19 Apr 2017 17:36:55 -0000 Hans, Thanks for the info. > No sleeping functions like taskqueue_drain() can be called when the MTX_D= EF lock is grabbed. I am guessing this is true irrespective of whether the taskqueue is "fast" = or not. Thanks David S. -----Original Message----- From: Hans Petter Selasky [mailto:hps@selasky.org]=20 Sent: Tuesday, April 18, 2017 9:22 PM To: Sepherosa Ziehau ; Somayajulu, David Cc: freebsd-net@freebsd.org Subject: Re: Question on taskqueue_drain On 04/19/17 05:37, Sepherosa Ziehau wrote: > On Wed, Apr 19, 2017 at 10:39 AM, Somayajulu, David=20 > wrote: >> Sorry what I meant to ask was, whether it is O.K to call taskqueue_drain= (), when an MTX_DEF lock is grabbed prior to calling taskqueue_drain(). >> > > You will hit WITNESS, if the drain needs to wait; that's probably the=20 > best case. If the lock will be acquired in the task being drained,=20 > this leads to deadlock. > Hi, No sleeping functions like taskqueue_drain() can be called when the MTX_DEF= lock is grabbed. --HPS From owner-freebsd-net@freebsd.org Wed Apr 19 17:43:08 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F582D46929 for ; Wed, 19 Apr 2017 17:43:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6825817F for ; Wed, 19 Apr 2017 17:43:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6DB6E1FE021; Wed, 19 Apr 2017 19:43:06 +0200 (CEST) Subject: Re: Question on taskqueue_drain To: "Somayajulu, David" , Sepherosa Ziehau References: <1fb80f2b-9086-0260-2f63-bdaf8afc1c4c@selasky.org> Cc: "freebsd-net@freebsd.org" From: Hans Petter Selasky Message-ID: <9a3b97e4-cb44-0de7-bb10-f9af9f04a089@selasky.org> Date: Wed, 19 Apr 2017 19:41:15 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:43:08 -0000 On 04/19/17 19:36, Somayajulu, David wrote: > Hans, > Thanks for the info. >> No sleeping functions like taskqueue_drain() can be called when the MTX_DEF lock is grabbed. > I am guessing this is true irrespective of whether the taskqueue is "fast" or not. > Thanks Yes, that is correct. --HPS From owner-freebsd-net@freebsd.org Wed Apr 19 19:31:56 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08E0ED46918 for ; Wed, 19 Apr 2017 19:31:56 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) (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 BCFF21E91 for ; Wed, 19 Apr 2017 19:31:55 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.34.119] (helo=smtp11.mnd.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d0vKS-0004IO-6z for freebsd-net@freebsd.org; Wed, 19 Apr 2017 21:31:52 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp11.mnd.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d0vKS-0005q6-5C for freebsd-net@freebsd.org; Wed, 19 Apr 2017 21:31:52 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 0AA957C85 for ; Wed, 19 Apr 2017 21:31:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlzjprroscS0 for ; Wed, 19 Apr 2017 21:31:51 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 8CEC07C80 for ; Wed, 19 Apr 2017 21:31:51 +0200 (CEST) From: peter.blok@bsd4all.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: MFC VIMAGE fixes to 11-stable Message-Id: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> Date: Wed, 19 Apr 2017 21:31:50 +0200 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=KuA94SeN c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=IkcTkHD0fZMA:10 a=AzvcPWV-tVgA:10 a=M250e507MT2xu0IyU1QA:9 a=ZvL-mYWBzcKzQ_JA:21 a=X0RY0KR-N7hnxV2j:21 a=QEXdDO2ut3YA:10 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No 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, 19 Apr 2017 19:31:56 -0000 All, I=E2=80=99m running jails and bhyve using netgraph bridge. The jails are = using Devin Teske=E2=80=99s jng and I have adapted iohyve to use the = same netgraph bridge. I haven=E2=80=99t had any panic=E2=80=99s after applying revisions = 306684, 312943, 315131, 315469, 307235, 313001, 315136 and 315741. Can someone please MFC them to 11-stable? I=E2=80=99m starting and stopping jails in a continous loop. I have = added some extra code to track an occasional panic in = pf_purge_expired_states, but so far no luck. I also have a change in zone_release to fix another panic and leak in = slab_free_item. The issue is that zone_release tries to release a keg = that never belonged to the zone it is trying to release. With my limited = knowledge, i think that should not happen. --- vm/uma_core.c (revision 317156) +++ vm/uma_core.c (working copy) @@ -2846,7 +2846,8 @@ KEG_LOCK(keg); } } - slab_free_item(keg, slab, item); + if (keg =3D=3D slab->us_keg) + slab_free_item(keg, slab, item); if (keg->uk_flags & UMA_ZFLAG_FULL) { if (keg->uk_pages < keg->uk_maxpages) { keg->uk_flags &=3D ~UMA_ZFLAG_FULL; Peter From owner-freebsd-net@freebsd.org Thu Apr 20 10:43:53 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1237AD48C29 for ; Thu, 20 Apr 2017 10:43:53 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FB968C for ; Thu, 20 Apr 2017 10:43:52 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 20 Apr 2017 12:42:35 +0200 Date: Thu, 20 Apr 2017 12:42:56 +0200 From: Marko Zec To: CC: Subject: Re: MFC VIMAGE fixes to 11-stable Message-ID: <20170420124256.1190665d@x23> In-Reply-To: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] 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, 20 Apr 2017 10:43:53 -0000 On Wed, 19 Apr 2017 21:31:50 +0200 wrote: ... > I also have a change in zone_release to fix another panic and leak in > slab_free_item. The issue is that zone_release tries to release a keg > that never belonged to the zone it is trying to release. With my > limited knowledge, i think that should not happen. > > --- vm/uma_core.c (revision 317156) > +++ vm/uma_core.c (working copy) > @@ -2846,7 +2846,8 @@ > KEG_LOCK(keg); > } > } > - slab_free_item(keg, slab, item); > + if (keg == slab->us_keg) > + slab_free_item(keg, slab, item); > if (keg->uk_flags & UMA_ZFLAG_FULL) { > if (keg->uk_pages < keg->uk_maxpages) { > keg->uk_flags &= ~UMA_ZFLAG_FULL; > This change only masks the cause of the panic while still continuing to leak memory, and should never be commited. The real culprit lies somewhere in PF code which operates on a wrong vnet. Without a backtrace it's difficult to guess, but a quick read reveals that pfi_initialize() is called from the default vnet context, and subsequently registers interface eventhandlers so that all interface attach, change and detach events will be always executed in the default vnet, regardless of the real vnet where the interfaces bound to the events actually reside. In other words, pfi_attach_group_event() pfi_change_group_event() pfi_detach_group_event() will operate fine only in the default vnet, but will wreak havoc otherwise. Hence, those handlers should be fixed first. Marko From owner-freebsd-net@freebsd.org Thu Apr 20 12:49:53 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48760D4851B for ; Thu, 20 Apr 2017 12:49:53 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) (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 085AFF92 for ; Thu, 20 Apr 2017 12:49:51 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.135] (helo=smtp11.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d1Asp-00056M-G1; Thu, 20 Apr 2017 14:08:23 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp11.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d1Asp-0004ln-DZ; Thu, 20 Apr 2017 14:08:23 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 325737CBC; Thu, 20 Apr 2017 14:08:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOoUJW8gyrDg; Thu, 20 Apr 2017 14:08:21 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 283937CB7; Thu, 20 Apr 2017 14:08:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: MFC VIMAGE fixes to 11-stable From: peter.blok@bsd4all.org In-Reply-To: <20170420124256.1190665d@x23> Date: Thu, 20 Apr 2017 14:08:20 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E874FFD-735D-443C-A92E-F00E3737441C@bsd4all.org> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> To: Marko Zec X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=QacWhoTv c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=IkcTkHD0fZMA:10 a=AzvcPWV-tVgA:10 a=6Q3WNqvRAAAA:8 a=6I5d2MoRAAAA:8 a=FFJHALQWnkoprFdbjYQA:9 a=yZZpNNtUPswjIHe7:21 a=dHqdDrHz7w_wCe-R:21 a=QEXdDO2ut3YA:10 a=I8PBwKCn76L9oNdl0isp:22 a=IjZwj45LgO3ly-622nXo:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No 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, 20 Apr 2017 12:49:53 -0000 Hi Marko, Thanks for the pointer. It was not my intention to have this committed, = but it helped identify other problems. I have asked this before in = -current, but got no answer so I posted it here to get an answer. If you look inside slab_free_item there is a KASSERT for just this, so = that=E2=80=99s why I tried it. I have added debug information to print the zone=E2=80=99s and the = keg=E2=80=99s and It all looked good. I was not able to find any place = where we operated on the wrong context, but perhaps I missed one. I=E2=80=99ll dig further. Peter > On 20 Apr 2017, at 12:42, Marko Zec wrote: >=20 > On Wed, 19 Apr 2017 21:31:50 +0200 > wrote: > ... >> I also have a change in zone_release to fix another panic and leak in >> slab_free_item. The issue is that zone_release tries to release a keg >> that never belonged to the zone it is trying to release. With my >> limited knowledge, i think that should not happen. >>=20 >> --- vm/uma_core.c (revision 317156) >> +++ vm/uma_core.c (working copy) >> @@ -2846,7 +2846,8 @@ >> KEG_LOCK(keg); >> } >> } >> - slab_free_item(keg, slab, item); >> + if (keg =3D=3D slab->us_keg) >> + slab_free_item(keg, slab, item); >> if (keg->uk_flags & UMA_ZFLAG_FULL) { >> if (keg->uk_pages < keg->uk_maxpages) { >> keg->uk_flags &=3D ~UMA_ZFLAG_FULL; >>=20 >=20 > This change only masks the cause of the panic while still continuing = to > leak memory, and should never be commited. >=20 > The real culprit lies somewhere in PF code which operates on a wrong > vnet. Without a backtrace it's difficult to guess, but a quick read > reveals that >=20 > pfi_initialize() >=20 > is called from the default vnet context, and subsequently registers > interface eventhandlers so that all interface attach, change and = detach > events will be always executed in the default vnet, regardless of the > real vnet where the interfaces bound to the events actually reside. = In > other words, >=20 > pfi_attach_group_event() > pfi_change_group_event() > pfi_detach_group_event() >=20 > will operate fine only in the default vnet, but will wreak havoc > otherwise. Hence, those handlers should be fixed first. >=20 > Marko > _______________________________________________ > 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 Thu Apr 20 13:13:46 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D775D48C12 for ; Thu, 20 Apr 2017 13:13:46 +0000 (UTC) (envelope-from srs0=haqt=34=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCCC21F6A for ; Thu, 20 Apr 2017 13:13:45 +0000 (UTC) (envelope-from srs0=haqt=34=sigsegv.be=kristof@codepro.be) Received: from [172.16.5.2] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 75E5E965A; Thu, 20 Apr 2017 15:13:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1492694023; bh=oUGg27Cnn+blytplCr+Bgebh5qCB9J0dhEu8NNHo4dU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=klQiO3ZuF1LdPmvH+pV3iGFyYYmPaShl6sNAI6h9vc7GuIEL+/y4bkixIAxfOwE6O nPQXf7Q/wojozA2xXLJHjC/uAS2zl01g5oXQQonRLUKFaaa+699FhEjEZFNSo4m3sX 71IWbMrc30z6SXgyBM3tNkR+sDQIQbBXdIV7gAzg= From: "Kristof Provost" To: "Marko Zec" Cc: peter.blok@bsd4all.org, freebsd-net@freebsd.org Subject: Re: MFC VIMAGE fixes to 11-stable Date: Thu, 20 Apr 2017 15:13:42 +0200 Message-ID: <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> In-Reply-To: <20170420124256.1190665d@x23> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6082) 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, 20 Apr 2017 13:13:46 -0000 On 20 Apr 2017, at 12:42, Marko Zec wrote: > The real culprit lies somewhere in PF code which operates on a wrong > vnet. Without a backtrace it's difficult to guess, but a quick read > reveals that > > pfi_initialize() > > is called from the default vnet context, and subsequently registers > interface eventhandlers so that all interface attach, change and > detach > events will be always executed in the default vnet, regardless of the > real vnet where the interfaces bound to the events actually reside. > In > other words, > > pfi_attach_group_event() > pfi_change_group_event() > pfi_detach_group_event() > > will operate fine only in the default vnet, but will wreak havoc > otherwise. Hence, those handlers should be fixed first. > I don’t think that’s right. The event handler doesn’t carry vnet information. It’s just called in whatever vnet is active when it’s invoked. There's no CURVNET_SET() in the EVENTHANDLER_INVOKE() macro. That means that we end up in pf_attach_group_event() with CURVNET set to the relevant vnet, not to the default vnet. There are certainly still issues with pf and vnets, but I don't think this is one. Regards, Kristof From owner-freebsd-net@freebsd.org Thu Apr 20 13:28:38 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53483D480EE for ; Thu, 20 Apr 2017 13:28:38 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2138A5F for ; Thu, 20 Apr 2017 13:28:36 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 20 Apr 2017 15:28:33 +0200 Date: Thu, 20 Apr 2017 15:28:53 +0200 From: Marko Zec To: Kristof Provost CC: , Subject: Re: MFC VIMAGE fixes to 11-stable Message-ID: <20170420152853.019e5480@x23> In-Reply-To: <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [161.53.63.210] 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, 20 Apr 2017 13:28:38 -0000 On Thu, 20 Apr 2017 15:13:42 +0200 Kristof Provost wrote: > On 20 Apr 2017, at 12:42, Marko Zec wrote: > > The real culprit lies somewhere in PF code which operates on a wrong > > vnet. Without a backtrace it's difficult to guess, but a quick read > > reveals that > > > > pfi_initialize() > > > > is called from the default vnet context, and subsequently registers > > interface eventhandlers so that all interface attach, change and=20 > > detach > > events will be always executed in the default vnet, regardless of > > the real vnet where the interfaces bound to the events actually > > reside. In > > other words, > > > > pfi_attach_group_event() > > pfi_change_group_event() > > pfi_detach_group_event() > > > > will operate fine only in the default vnet, but will wreak havoc > > otherwise. Hence, those handlers should be fixed first. > > =20 > I don=E2=80=99t think that=E2=80=99s right. >=20 > The event handler doesn=E2=80=99t carry vnet information. It=E2=80=99s j= ust called=20 > in whatever vnet is active when it=E2=80=99s invoked. > There's no CURVNET_SET() in the EVENTHANDLER_INVOKE() macro. >=20 > That means that we end up in pf_attach_group_event() with CURVNET set > to the relevant vnet, not to the default vnet. Right. But pfi_attach_group_event() and the other handlers cited above _do_ in fact invoke CURVNET_SET(vnet0) on entry, overriding the proper vnet choice from the caller. Therefore the proper fix should be as simple as removing CURVNET_SET() / CURVNET_RESTORE() macro pairs from the cited handlers. Marko >=20 > There are certainly still issues with pf and vnets, but I don't think=20 > this is > one. >=20 > Regards, > Kristof From owner-freebsd-net@freebsd.org Thu Apr 20 13:32:33 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 451E9D482F6 for ; Thu, 20 Apr 2017 13:32:33 +0000 (UTC) (envelope-from srs0=haqt=34=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FD4AEC3 for ; Thu, 20 Apr 2017 13:32:33 +0000 (UTC) (envelope-from srs0=haqt=34=sigsegv.be=kristof@codepro.be) Received: from [172.16.5.2] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id CFBDC96A1; Thu, 20 Apr 2017 15:32:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1492695150; bh=V769rYNIuf3ziW+ETqxA5DJUPLaeQiDAQQxIv/pEFGE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HJGy5/A8qIe/IpajAIEjhVNgb9lmzG1oOMde0qQVgtY/zLns+cc5di2JMoqLLNDAV VKd2Zn+zXAaoIKzqLwJ4WTLDCP5YjywzW8LNdrnnY3skVqd3Ln1yyCyGKPyC/N9F83 qGUb0iGe7ll3cpulszk7Z9OSEakksfP8fmz731B4= From: "Kristof Provost" To: "Marko Zec" Cc: freebsd-net@freebsd.org, peter.blok@bsd4all.org Subject: Re: MFC VIMAGE fixes to 11-stable Date: Thu, 20 Apr 2017 15:32:29 +0200 Message-ID: In-Reply-To: <20170420152853.019e5480@x23> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> <20170420152853.019e5480@x23> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6082) 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, 20 Apr 2017 13:32:33 -0000 On 20 Apr 2017, at 15:28, Marko Zec wrote: > Right. But pfi_attach_group_event() and the other handlers cited > above > _do_ in fact invoke CURVNET_SET(vnet0) on entry, overriding the proper > vnet choice from the caller. > Yes, that does look wrong. I should have looked a bit further. > Therefore the proper fix should be as simple as removing CURVNET_SET() > / > CURVNET_RESTORE() macro pairs from the cited handlers. > Hopefully, yes. I’ve still got some other pf/vnet issues on my todo list, but I’ve now added this too. It might actually explain some other bug report I’ve seen (but not looked at in any depth). Regards, Kristof From owner-freebsd-net@freebsd.org Thu Apr 20 13:38:35 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19AE8D48401 for ; Thu, 20 Apr 2017 13:38:35 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) (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 CC799142 for ; Thu, 20 Apr 2017 13:38:34 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.136] (helo=smtp12.tb.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d1CI3-0002jg-LC; Thu, 20 Apr 2017 15:38:31 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp12.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d1CI3-0003vk-FC; Thu, 20 Apr 2017 15:38:31 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 20EA77616; Thu, 20 Apr 2017 15:38:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP0sBVVi1b6P; Thu, 20 Apr 2017 15:38:30 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 0D2617611; Thu, 20 Apr 2017 15:38:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: MFC VIMAGE fixes to 11-stable From: peter.blok@bsd4all.org In-Reply-To: Date: Thu, 20 Apr 2017 15:38:29 +0200 Cc: Marko Zec , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> <20170420152853.019e5480@x23> To: Kristof Provost X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=V8IN6avi c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=IkcTkHD0fZMA:10 a=AzvcPWV-tVgA:10 a=6I5d2MoRAAAA:8 a=8wqUZSj_QJ7EFpuCjcoA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No 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, 20 Apr 2017 13:38:35 -0000 I=E2=80=99ll test this today. > On 20 Apr 2017, at 15:32, Kristof Provost wrote: >=20 > On 20 Apr 2017, at 15:28, Marko Zec wrote: >> Right. But pfi_attach_group_event() and the other handlers cited = above >> _do_ in fact invoke CURVNET_SET(vnet0) on entry, overriding the = proper >> vnet choice from the caller. >>=20 > Yes, that does look wrong. > I should have looked a bit further. >=20 >> Therefore the proper fix should be as simple as removing = CURVNET_SET() / >> CURVNET_RESTORE() macro pairs from the cited handlers. >>=20 > Hopefully, yes. I=E2=80=99ve still got some other pf/vnet issues on my = todo list, but > I=E2=80=99ve now added this too. It might actually explain some other = bug report I=E2=80=99ve > seen (but not looked at in any depth). >=20 > Regards, > Kristof > _______________________________________________ > 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 Thu Apr 20 17:55:56 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76673D48B68 for ; Thu, 20 Apr 2017 17:55:56 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 59B65D6C for ; Thu, 20 Apr 2017 17:55:56 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5608CD48B67; Thu, 20 Apr 2017 17:55:56 +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 55B0DD48B66 for ; Thu, 20 Apr 2017 17:55:56 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 271E6D6B for ; Thu, 20 Apr 2017 17:55:55 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (97-123-4-62.albq.qwest.net [97.123.4.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 2131B1928AC; Thu, 20 Apr 2017 17:55:48 +0000 (UTC) Subject: Re: Intel 82545 & TSO To: Vijay Singh Cc: "freebsd-net@freebsd.org" References: <793b585e-8af4-56e3-97eb-942efbc8d06c@freebsd.org> From: Sean Bruno Message-ID: Date: Thu, 20 Apr 2017 11:55:45 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hRg6PwXm6Fq1K7uf5cFDRUVoVKQfOOR9A" 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, 20 Apr 2017 17:55:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hRg6PwXm6Fq1K7uf5cFDRUVoVKQfOOR9A Content-Type: multipart/mixed; boundary="VO3TdtQ1u1TQCtRC2gb2JESnwaOq6vXra"; protected-headers="v1" From: Sean Bruno To: Vijay Singh Cc: "freebsd-net@freebsd.org" Message-ID: Subject: Re: Intel 82545 & TSO References: <793b585e-8af4-56e3-97eb-942efbc8d06c@freebsd.org> In-Reply-To: --VO3TdtQ1u1TQCtRC2gb2JESnwaOq6vXra Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/05/17 15:54, Vijay Singh wrote: > This is from FreeBSD 10.3. >=20 > On Wed, Apr 5, 2017 at 2:53 PM, Sean Bruno > wrote: >=20 >=20 >=20 > On 04/05/17 10:26, Vijay Singh wrote: > > I am running FreeBSD as a guest on ESX 5.x and see Intel device > 0x100F in > > the guest. The man page for em(4) says: > > > > " The driver supports Transmit/Receive checksum offload and Jumbo= > > Frames on all but 82542-based adapters. Furthermore it supports T= CP > > segmentation offload (TSO) on all adapters but those based on the= > > 82543, 82544 and 82547 controller chips." > > > > This particular device is probed by the if_lem.c driver, but I se= e no > > support for TSO in that file. I have verified that TSO is enabled= on > > the host. What am I missing? > > > > em0@pci0:2:0:0: class=3D0x020000 card=3D0x075015ad chip=3D0x100f8= 086 > rev=3D0x01 hdr=3D0x00 > > vendor =3D 'Intel Corporation' > > device =3D '82545EM Gigabit Ethernet Controller (Copper)'= > > class =3D network > > subclass =3D ethernet > > > > ifconfig -vvvm em0 > > em0: flags=3D8843 metric = 0 > mtu 1500 > > =20 > options=3D8009b > > =20 > capabilities=3D9009b > > ether 02:a0:98:ec:26:1d > > media: Ethernet autoselect (1000baseT ) > > status: active > > supported media: > > media autoselect > > media 100baseTX mediaopt full-duplex > > media 100baseTX > > media 10baseT/UTP mediaopt full-duplex > > media 10baseT/UTP > > > > > > -vijay > > _______________________________________________ >=20 > Just so that I'm sure, what version of FreeBSD is this from? >=20 > sean >=20 >=20 I believe this a confusion from the fact that the 82545EM is controled by the "lem" driver and not the "em" driver. The "lem" driver does not support TSO. If you want TSO support, you should be able to use a different ethernet card model in ESX, no? sean --VO3TdtQ1u1TQCtRC2gb2JESnwaOq6vXra-- --hRg6PwXm6Fq1K7uf5cFDRUVoVKQfOOR9A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAlj49iFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y fmQ1Mwf/T9kTxCfyKOczY1Jq9Rjxz9s7ziDgiv5fevPJSY8JR8csCaaX5dDRNMYR QvBNcnm1Kakc5R70LwnBLADv0daEfdM+cjJ1R9yOx0OaAInUDqPmfi7hycUKBMPX cU17ZfKhBZdHcjB+/ZOQ8H8YdMrR6C3CnTvyEKC/Zmbci3T5zLee++/1LXv9rO5L +nePHGdbg4w+ngz1AjNWjo6TepAz3birOP/h/MvnFcAO/yVAW7+CeHam6yNWXjzO HVgEsWBAR91XftBRW60Rpxry76Qi58SXQdDe1nk+z5qhaDXT/0O+t0TZp3XJPxVY /PrC79iaDuSZAdSDPG9phaIpjRnKCA== =PRrw -----END PGP SIGNATURE----- --hRg6PwXm6Fq1K7uf5cFDRUVoVKQfOOR9A-- From owner-freebsd-net@freebsd.org Thu Apr 20 18:28:44 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70ED9D48791 for ; Thu, 20 Apr 2017 18:28:44 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1513C4 for ; Thu, 20 Apr 2017 18:28:44 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4B8F5D48790; Thu, 20 Apr 2017 18:28:44 +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 4B2B9D4878F for ; Thu, 20 Apr 2017 18:28:44 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 C58103C3; Thu, 20 Apr 2017 18:28:43 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id 75so33553572lfs.2; Thu, 20 Apr 2017 11:28:43 -0700 (PDT) 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=NTKJn1kBCkRwSjw0qcso4J4KCupxrHWXNx9edAseRU0=; b=Nkf7K7G7446S45ljlRiT9NQG3/V/OuVyd3cpfhe6HddUx4H7KIOGImwXJgS2RIGWvF 1R+HPT8SKr9MikL9/kE0rlXqXb8ZjN5EqNLKarJBFA+BiGuF3kRH9HZox1FtYQx7DlVR lpvFrKLbADUz1iLkevqR9C09LLS4xzD7milCQJSTjbYKKf/HllHybTkOgNxOVyKGmCmW mfW6nr7IupQOqx65VNusNLlFlLQamWDbFfngQrrqsE2MqtoYoeNq+T6TS5v4rv7gh+3c QQi3t2oZiwvZi8vq039seUp5WGBVOzsi9Ud8H/9eNiq5KJPXh3Aobrg1zUnRWa9fMgGk JWbQ== 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=NTKJn1kBCkRwSjw0qcso4J4KCupxrHWXNx9edAseRU0=; b=IEc9w2xKE4/ztqjuN6tFrkgArft9SP7lw8gQP492X1oo2LPs3BSa8phvoqDD1H9cKs PySS/06j/S4qC+L0opIjwFCb5OtJPRjLnxaOASb4xaPu8aESLwFUHImgWh6LoL3ZlTui gXWZJoAYyb6ja5K5EQVNieJAdQEttPhiYcShYLDqpX804iDbJ4AMRoGtb51YzSLsOa9I EpC8cGwSIGQvw5cbzRkUpSDQ3TTCwaZjAr7LAnbQLTl75RfC7Wnn9+qp9Vvmv3g/e5Gu SjyHKB9zw2gdIF5WJjbJOP2eNSrLdjQVnHv0U8m9PZeGndT3JyjF5NGykC4AZpaDFDzm W0tw== X-Gm-Message-State: AN3rC/6T5YzeSjGyamOrWsu6//hDboRSwo41Zcgr6c91/jvhorQwj8c3 cdXs1SMR4IlR8oebHds3jAzybvyOTw== X-Received: by 10.25.233.213 with SMTP id j82mr3363161lfk.20.1492712921579; Thu, 20 Apr 2017 11:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.29.130 with HTTP; Thu, 20 Apr 2017 11:28:41 -0700 (PDT) In-Reply-To: References: <793b585e-8af4-56e3-97eb-942efbc8d06c@freebsd.org> From: Vijay Singh Date: Thu, 20 Apr 2017 11:28:41 -0700 Message-ID: Subject: Re: Intel 82545 & TSO To: Sean Bruno Cc: "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: Thu, 20 Apr 2017 18:28:44 -0000 Sure I can do that, but I don't have control over the ESX systems we are running on. If the hardware supports TSO, then it shouldn't be too hard to supplement "lem" to support it as well. The descriptor format seems to be the same, so most likely copying over some code from "em" should do it. On Thu, Apr 20, 2017 at 10:55 AM, Sean Bruno wrote: > > > On 04/05/17 15:54, Vijay Singh wrote: > > This is from FreeBSD 10.3. > > > > On Wed, Apr 5, 2017 at 2:53 PM, Sean Bruno > > wrote: > > > > > > > > On 04/05/17 10:26, Vijay Singh wrote: > > > I am running FreeBSD as a guest on ESX 5.x and see Intel device > > 0x100F in > > > the guest. The man page for em(4) says: > > > > > > " The driver supports Transmit/Receive checksum offload and Jumbo > > > Frames on all but 82542-based adapters. Furthermore it supports TCP > > > segmentation offload (TSO) on all adapters but those based on the > > > 82543, 82544 and 82547 controller chips." > > > > > > This particular device is probed by the if_lem.c driver, but I see > no > > > support for TSO in that file. I have verified that TSO is enabled > on > > > the host. What am I missing? > > > > > > em0@pci0:2:0:0: class=0x020000 card=0x075015ad chip=0x100f8086 > > rev=0x01 hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = '82545EM Gigabit Ethernet Controller (Copper)' > > > class = network > > > subclass = ethernet > > > > > > ifconfig -vvvm em0 > > > em0: flags=8843 metric 0 > > mtu 1500 > > > > > options=8009b HWCSUM,LINKSTATE> > > > > > capabilities=9009b HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER,LINKSTATE> > > > ether 02:a0:98:ec:26:1d > > > media: Ethernet autoselect (1000baseT ) > > > status: active > > > supported media: > > > media autoselect > > > media 100baseTX mediaopt full-duplex > > > media 100baseTX > > > media 10baseT/UTP mediaopt full-duplex > > > media 10baseT/UTP > > > > > > > > > -vijay > > > _______________________________________________ > > > > Just so that I'm sure, what version of FreeBSD is this from? > > > > sean > > > > > > I believe this a confusion from the fact that the 82545EM is controled > by the "lem" driver and not the "em" driver. > > The "lem" driver does not support TSO. > > If you want TSO support, you should be able to use a different ethernet > card model in ESX, no? > > sean > > From owner-freebsd-net@freebsd.org Thu Apr 20 19:20:34 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D9C1D48E4F for ; Thu, 20 Apr 2017 19:20:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D7211ED for ; Thu, 20 Apr 2017 19:20:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3KJKYD2053471 for ; Thu, 20 Apr 2017 19:20:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Thu, 20 Apr 2017 19:20:34 +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: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress 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, 20 Apr 2017 19:20:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #81 from commit-hook@freebsd.org --- A commit references this bug: Author: tuexen Date: Thu Apr 20 19:19:34 UTC 2017 New revision: 317208 URL: https://svnweb.freebsd.org/changeset/base/317208 Log: Syncoockies can be used in combination with the syncache. If the cache overflows, syncookies are used. This patch restricts the usage of syncookies in this case: accept syncookies only if there was an overflow of the syncache recently. This mitigates a problem reported in PR217637, where is syncookie was accepted without any recent drops. Thanks to glebius@ for suggesting an improvement. PR: 217637 Reviewed by: gnn, glebius MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D10272 Changes: head/sys/netinet/tcp_syncache.c head/sys/netinet/tcp_syncache.h --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Apr 20 19:24:41 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5ABF7D48498 for ; Thu, 20 Apr 2017 19:24:41 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) (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 19C41915 for ; Thu, 20 Apr 2017 19:24:40 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.34.118] (helo=smtp10.mnd.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d1Hgy-0004XH-NO; Thu, 20 Apr 2017 21:24:36 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp10.mnd.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d1Hgy-00069U-LZ; Thu, 20 Apr 2017 21:24:36 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 4D71F717B; Thu, 20 Apr 2017 21:24:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsENQovQhqlI; Thu, 20 Apr 2017 21:24:34 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 0D457716C; Thu, 20 Apr 2017 21:24:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: MFC VIMAGE fixes to 11-stable From: peter.blok@bsd4all.org In-Reply-To: Date: Thu, 20 Apr 2017 21:24:33 +0200 Cc: Marko Zec , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> <20170420152853.019e5480@x23> To: Kristof Provost X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=OpI/823t c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=IkcTkHD0fZMA:10 a=AzvcPWV-tVgA:10 a=6I5d2MoRAAAA:8 a=M6HhRil2J2dywf6zO5gA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No 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, 20 Apr 2017 19:24:41 -0000 It doesn=E2=80=99t solve my problem, but below is the stack back trace = that leads to the problem that allocation doen for the default vnet are = given back as part of the vnet destroy. #0 0xffffffff807ff275 at pfr_destroy_kentry+0x35 #1 0xffffffff807fe47c at pfr_remove_kentries+0x1fc #2 0xffffffff808053cd at pfr_setflags_ktable+0xcd #3 0xffffffff80802108 at pfr_clr_tables+0x248 #4 0xffffffff807ecd75 at vnet_pf_uninit+0x4a5 #5 0xffffffff806a9d2c at vnet_destroy+0x13c #6 0xffffffff8056cdcf at prison_deref+0x2af #7 0xffffffff805ee287 at taskqueue_run_locked+0x127 #8 0xffffffff805ef428 at taskqueue_thread_loop+0xc8 #9 0xffffffff80565505 at fork_exit+0x85 #10 0xffffffff808d245e at fork_trampoline+0xe > On 20 Apr 2017, at 15:32, Kristof Provost wrote: >=20 > On 20 Apr 2017, at 15:28, Marko Zec wrote: >> Right. But pfi_attach_group_event() and the other handlers cited = above >> _do_ in fact invoke CURVNET_SET(vnet0) on entry, overriding the = proper >> vnet choice from the caller. >>=20 > Yes, that does look wrong. > I should have looked a bit further. >=20 >> Therefore the proper fix should be as simple as removing = CURVNET_SET() / >> CURVNET_RESTORE() macro pairs from the cited handlers. >>=20 > Hopefully, yes. I=E2=80=99ve still got some other pf/vnet issues on my = todo list, but > I=E2=80=99ve now added this too. It might actually explain some other = bug report I=E2=80=99ve > seen (but not looked at in any depth). >=20 > Regards, > Kristof > _______________________________________________ > 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 Thu Apr 20 19:41:12 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD71AD48AED for ; Thu, 20 Apr 2017 19:41:12 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64BF0661 for ; Thu, 20 Apr 2017 19:41:11 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (31.147.110.161) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 20 Apr 2017 21:41:08 +0200 Date: Thu, 20 Apr 2017 21:41:28 +0200 From: Marko Zec To: CC: Kristof Provost , Subject: Re: MFC VIMAGE fixes to 11-stable Message-ID: <20170420214128.29379fdb@x23> In-Reply-To: References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> <20170420152853.019e5480@x23> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [31.147.110.161] 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, 20 Apr 2017 19:41:12 -0000 On Thu, 20 Apr 2017 21:24:33 +0200 wrote: > It doesn=E2=80=99t solve my problem, but below is the stack back trace th= at > leads to the problem that allocation doen for the default vnet are > given back as part of the vnet destroy. >=20 > #0 0xffffffff807ff275 at pfr_destroy_kentry+0x35 > #1 0xffffffff807fe47c at pfr_remove_kentries+0x1fc > #2 0xffffffff808053cd at pfr_setflags_ktable+0xcd > #3 0xffffffff80802108 at pfr_clr_tables+0x248 > #4 0xffffffff807ecd75 at vnet_pf_uninit+0x4a5 > #5 0xffffffff806a9d2c at vnet_destroy+0x13c > #6 0xffffffff8056cdcf at prison_deref+0x2af > #7 0xffffffff805ee287 at taskqueue_run_locked+0x127 > #8 0xffffffff805ef428 at taskqueue_thread_loop+0xc8 > #9 0xffffffff80565505 at fork_exit+0x85 > #10 0xffffffff808d245e at fork_trampoline+0xe Having absolutely no clue what the PF code does or is supposed to do, I'd bet that V_irtualizing pfr_ktablehead, and probably pfr_nulltable and pfr_ktable_cnt as well, would help here. Marko >=20 >=20 > > On 20 Apr 2017, at 15:32, Kristof Provost > > wrote: > >=20 > > On 20 Apr 2017, at 15:28, Marko Zec wrote: =20 > >> Right. But pfi_attach_group_event() and the other handlers cited > >> above _do_ in fact invoke CURVNET_SET(vnet0) on entry, overriding > >> the proper vnet choice from the caller. > >> =20 > > Yes, that does look wrong. > > I should have looked a bit further. > > =20 > >> Therefore the proper fix should be as simple as removing > >> CURVNET_SET() / CURVNET_RESTORE() macro pairs from the cited > >> handlers.=20 > > Hopefully, yes. I=E2=80=99ve still got some other pf/vnet issues on my = todo > > list, but I=E2=80=99ve now added this too. It might actually explain s= ome > > other bug report I=E2=80=99ve seen (but not looked at in any depth). > >=20 > > Regards, > > Kristof > > _______________________________________________ > > 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" =20 >=20 From owner-freebsd-net@freebsd.org Thu Apr 20 19:50:23 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3FA2D47101 for ; Thu, 20 Apr 2017 19:50:23 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B23DCA9 for ; Thu, 20 Apr 2017 19:50:23 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (31.147.110.161) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 20 Apr 2017 21:50:20 +0200 Date: Thu, 20 Apr 2017 21:50:40 +0200 From: Marko Zec To: CC: Kristof Provost , Subject: Re: MFC VIMAGE fixes to 11-stable Message-ID: <20170420215040.4ee94610@x23> In-Reply-To: <20170420214128.29379fdb@x23> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> <20170420152853.019e5480@x23> <20170420214128.29379fdb@x23> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [31.147.110.161] 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, 20 Apr 2017 19:50:23 -0000 On Thu, 20 Apr 2017 21:41:28 +0200 Marko Zec wrote: > [This sender failed our fraud detection checks and may not be who > they appear to be. Learn about spoofing at > http://aka.ms/LearnAboutSpoofing] >=20 > On Thu, 20 Apr 2017 21:24:33 +0200 > wrote: >=20 > > It doesn=E2=80=99t solve my problem, but below is the stack back trace = that > > leads to the problem that allocation doen for the default vnet are > > given back as part of the vnet destroy. > > > > #0 0xffffffff807ff275 at pfr_destroy_kentry+0x35 > > #1 0xffffffff807fe47c at pfr_remove_kentries+0x1fc > > #2 0xffffffff808053cd at pfr_setflags_ktable+0xcd > > #3 0xffffffff80802108 at pfr_clr_tables+0x248 > > #4 0xffffffff807ecd75 at vnet_pf_uninit+0x4a5 > > #5 0xffffffff806a9d2c at vnet_destroy+0x13c > > #6 0xffffffff8056cdcf at prison_deref+0x2af > > #7 0xffffffff805ee287 at taskqueue_run_locked+0x127 > > #8 0xffffffff805ef428 at taskqueue_thread_loop+0xc8 > > #9 0xffffffff80565505 at fork_exit+0x85 > > #10 0xffffffff808d245e at fork_trampoline+0xe =20 >=20 > Having absolutely no clue what the PF code does or is supposed to do, > I'd bet that V_irtualizing pfr_ktablehead, and probably pfr_nulltable > and pfr_ktable_cnt as well, would help here. pf_main_anchor looks suspicious, too, as it is never dereferenced via the VNET() accessor, so effectively it is still used as a single global variable. Marko From owner-freebsd-net@freebsd.org Thu Apr 20 20:20:14 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7DE6D47E7B for ; Thu, 20 Apr 2017 20:20:14 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq6.tb.mail.iss.as9143.net (smtpq6.tb.mail.iss.as9143.net [212.54.42.169]) (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 841A0172 for ; Thu, 20 Apr 2017 20:20:14 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.134] (helo=smtp10.tb.mail.iss.as9143.net) by smtpq6.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d1IYf-0003RR-To; Thu, 20 Apr 2017 22:20:05 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp10.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d1IYf-000335-Qq; Thu, 20 Apr 2017 22:20:05 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 7C19771E5; Thu, 20 Apr 2017 22:20:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28sjx7UWf5ke; Thu, 20 Apr 2017 22:20:03 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 4DAA571D9; Thu, 20 Apr 2017 22:20:03 +0200 (CEST) From: peter.blok@bsd4all.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: MFC VIMAGE fixes to 11-stable Date: Thu, 20 Apr 2017 22:20:02 +0200 In-Reply-To: <20170420214128.29379fdb@x23> Cc: Kristof Provost , freebsd-net@freebsd.org To: Marko Zec References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23> <60C3FBF7-7CF3-49AF-9DDF-0589AE9D9146@sigsegv.be> <20170420152853.019e5480@x23> <20170420214128.29379fdb@x23> X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=Yup/f8QX c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=AzvcPWV-tVgA:10 a=6Q3WNqvRAAAA:8 a=6I5d2MoRAAAA:8 a=vZYt9x9TnpZxVKE5IEUA:9 a=QEXdDO2ut3YA:10 a=utYTXG-_v9sLlgilx38A:9 a=vfJ5pP9RgKDJftyY:21 a=_W_S_7VecoQA:10 a=I8PBwKCn76L9oNdl0isp:22 a=IjZwj45LgO3ly-622nXo:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:20:14 -0000 Yeah, you are right. To keep the pf code as unchanged as possible, it is = sometimes unclear whether something is virtualised or not. The SLIST_HEAD and RB_HEAD in pfvar.h need virtualisation as well. > On 20 Apr 2017, at 21:41, Marko Zec wrote: >=20 > On Thu, 20 Apr 2017 21:24:33 +0200 > > wrote: >=20 >> It doesn=E2=80=99t solve my problem, but below is the stack back = trace that >> leads to the problem that allocation doen for the default vnet are >> given back as part of the vnet destroy. >>=20 >> #0 0xffffffff807ff275 at pfr_destroy_kentry+0x35 >> #1 0xffffffff807fe47c at pfr_remove_kentries+0x1fc >> #2 0xffffffff808053cd at pfr_setflags_ktable+0xcd >> #3 0xffffffff80802108 at pfr_clr_tables+0x248 >> #4 0xffffffff807ecd75 at vnet_pf_uninit+0x4a5 >> #5 0xffffffff806a9d2c at vnet_destroy+0x13c >> #6 0xffffffff8056cdcf at prison_deref+0x2af >> #7 0xffffffff805ee287 at taskqueue_run_locked+0x127 >> #8 0xffffffff805ef428 at taskqueue_thread_loop+0xc8 >> #9 0xffffffff80565505 at fork_exit+0x85 >> #10 0xffffffff808d245e at fork_trampoline+0xe >=20 > Having absolutely no clue what the PF code does or is supposed to do, > I'd bet that V_irtualizing pfr_ktablehead, and probably pfr_nulltable > and pfr_ktable_cnt as well, would help here. >=20 > Marko >=20 >>=20 >>=20 >>> On 20 Apr 2017, at 15:32, Kristof Provost >>> wrote: >>>=20 >>> On 20 Apr 2017, at 15:28, Marko Zec wrote: =20 >>>> Right. But pfi_attach_group_event() and the other handlers cited >>>> above _do_ in fact invoke CURVNET_SET(vnet0) on entry, overriding >>>> the proper vnet choice from the caller. >>>>=20 >>> Yes, that does look wrong. >>> I should have looked a bit further. >>>=20 >>>> Therefore the proper fix should be as simple as removing >>>> CURVNET_SET() / CURVNET_RESTORE() macro pairs from the cited >>>> handlers.=20 >>> Hopefully, yes. I=E2=80=99ve still got some other pf/vnet issues on = my todo >>> list, but I=E2=80=99ve now added this too. It might actually = explain some >>> other bug report I=E2=80=99ve seen (but not looked at in any depth). >>>=20 >>> Regards, >>> Kristof >>> _______________________________________________ >>> 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" =20