From owner-freebsd-net@freebsd.org Sun Oct 13 02:55:33 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 83BF3D7C68 for ; Sun, 13 Oct 2019 02:55:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rRBs2Dwpz4LPT for ; Sun, 13 Oct 2019 02:55:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3CD6CD7C67; Sun, 13 Oct 2019 02:55:33 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C8D7D7C65 for ; Sun, 13 Oct 2019 02:55:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rRBr6kWhz4LPN for ; Sun, 13 Oct 2019 02:55:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CC04BE82E for ; Sun, 13 Oct 2019 02:55:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9D2tW6O098911 for ; Sun, 13 Oct 2019 02:55:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9D2tWU8098910 for net@FreeBSD.org; Sun, 13 Oct 2019 02:55:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240609] iflib: Panic with INVARIANTS: sleeping in an epoch section (12.1-pre-QA) (vlan + lagg involved) Date: Sun, 13 Oct 2019 02:55:31 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 13 Oct 2019 02:55:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240609 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|net@FreeBSD.org |glebius@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 18:14:28 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 02B2A138CFF for ; Sun, 13 Oct 2019 18:14:28 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua1-x943.google.com (mail-ua1-x943.google.com [IPv6:2607:f8b0:4864:20::943]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rqb629s2z4N0R; Sun, 13 Oct 2019 18:14:25 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua1-x943.google.com with SMTP id w7so4373354uag.4; Sun, 13 Oct 2019 11:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=i8DEvImMiYscqradGS5pREfPduWFlh0to9iw+vd8gXs=; b=t6ucAKNwGKhCdlqoLBczkv3chMpv/mHqNdc96FsiNJ47i8kv1BG5kU31HjUVkPtwb2 q/ImDsctTMyxh4UrqYXA+tVYV9ucKrgff8SePxJDdl3z0u1YDCP1xOYLtMNeGj843lxz q32UYmderZ1ea814tkxatvQUuZxEuCUABCUmaL0BfKKNJ5C/mqD567QKjDAo6DAhBz26 wyPHnr8zqxrNumz8ijE4QkzuzqDrlGOXCO00xGugGPrBqVT06fWUxeV0u1dcjL3DhROH jGql1vHZ4/A61EKlyo9EOAlDQnSxmQB0CTH7aIf3igoEeU5C9/grp9e7F3wMUksdBOl9 nglg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=i8DEvImMiYscqradGS5pREfPduWFlh0to9iw+vd8gXs=; b=YQgkyGUF0ct3EqJ3gdJYZ7VxLtoAktFlJ/u7jbIudgTlZfPhJ9UtioMEFg7jY/KJFa pF3av91DvuF7vOjJcNACHmL/Cyg0PmzUjrTYHlnLEzEJz6pmSwp5W/iRjgm/Rg0drR1z Khs92WZCAHdwVqapTlATcaleNJfg5sUl/gl7WbJmAmtCbOnqbBVexhvNZGISTYaXtAzk aH0Wj3yzbvqwGDyqjPwqRe2mxyjQnhWfgGGErVxilgtH/R/eemCoU35csDX9TJRevvcC 3Xz4f7Ml1PzoclAuAE9fJGvp0LRoPdboScOKcJcP/6AoeYoUA1SCcYQucvZFM9UWdr5N ubMA== X-Gm-Message-State: APjAAAUpVl9ns+8grRHfMtQyYpwhvWWrHJBa7evseATUnwP35e33mdI0 Ey9/ySf88MnIQ3y3yvgYHHBCtIt3mDNbh6ASwEGn25vC X-Google-Smtp-Source: APXvYqwaQ360sMqclJZXqNtcAVmDO83kZ8HvNsXvtRy9He5176b6a6x76opL1XAPcoriS4vohOQwdF8qU7UU2N1/Tyw= X-Received: by 2002:ab0:30f4:: with SMTP id d20mr8403316uam.71.1570990464530; Sun, 13 Oct 2019 11:14:24 -0700 (PDT) MIME-Version: 1.0 References: <001e01d50b49$176104d0$46230e70$@gmail.com> <20190516.032012.517661495892269813.hrs@allbsd.org> In-Reply-To: From: Ben Woods Date: Mon, 14 Oct 2019 02:14:13 +0800 Message-ID: Subject: Re: DHCPv6 client in base To: Hiroki Sato , brooks@freebsd.org, Julian Elischer , driesm.michiels@gmail.com, freebsd-net , "roy@marples.name" X-Rspamd-Queue-Id: 46rqb629s2z4N0R X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=t6ucAKNw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of woodsb02@gmail.com designates 2607:f8b0:4864:20::943 as permitted sender) smtp.mailfrom=woodsb02@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[5]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.61), ipnet: 2607:f8b0::/32(-2.51), asn: 15169(-2.12), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 13 Oct 2019 18:14:28 -0000 On Fri, 11 Oct 2019 at 08:32, Ben Woods wrote: > On Mon, 7 Oct 2019 at 8:53 am, Ben Woods wrote: > >> On Thu, 16 May 2019 at 2:25 am, Hiroki Sato wrote: >> >>> wrote >>> in <001e01d50b49$176104d0$46230e70$@gmail.com>: >>> >>> dr> Has anyone ever thought or considered integrating an IPv6 DHCP >>> client in >>> dr> base? >>> >> >> I would like to discuss whether dhcpcd is a better option to import into >> FreeBSD base, rather than wide-dhcp6. >> > > Hi everyone, > > I have been working on importing dhcpcd into FreeBSD base over the last > few days, and should be ready to share something on phabricator for revie= w > this weekend. > > In addition to the normal review cycle, given I am a ports committer (I > don=E2=80=99t have a src commit bit), I would need this to be endorsed an= d approved > by a src committer. > > I have heavily utilised the Makefile and rc scripts from DragonFly BSD. > > I don=E2=80=99t intend to include any changes to the kernel for improved = dhcpcd > functionality as a part of this review - these could be made subsequently > if dhcpcd is committed. For now it would just be the same functionality a= s > if you used the net/dhcpcd port. > > Regards, > Ben > -- > > -- > From: Benjamin Woods > woodsb02@gmail.com > Hi everyone, As promised, I have completed my initial work to import dhcpcd into FreeBSD base, and it is ready for review, testing and comment at the link below. https://reviews.freebsd.org/D22012 As per the comment from brooks@, I have opted to have it installed in parallel with dhclient (which remains the default). Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Sun Oct 13 18:49:19 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 673BD139B13 for ; Sun, 13 Oct 2019 18:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46rrMM28SDz4Ptc for ; Sun, 13 Oct 2019 18:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 47E75139B12; Sun, 13 Oct 2019 18:49:19 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 47A73139B11 for ; Sun, 13 Oct 2019 18:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rrMM1Chfz4Ptb for ; Sun, 13 Oct 2019 18:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0D137212D8 for ; Sun, 13 Oct 2019 18:49:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DInIOE082266 for ; Sun, 13 Oct 2019 18:49:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DInIJ7082265 for net@FreeBSD.org; Sun, 13 Oct 2019 18:49:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241121] netinet: In multicast/broadcast udp(6)_input(), compare the IP details after we lock inp as well Date: Sun, 13 Oct 2019 18:49:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: neel@neelc.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc 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.29 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, 13 Oct 2019 18:49:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241121 Neel Chauhan changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|netinet: In |netinet: In |multicast/broadcast |multicast/broadcast |udp_input(), compare the IP |udp(6)_input(), compare the |details after we lock inp |IP details after we lock |as well |inp as well --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 19:34:42 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D259E13BFAB for ; Sun, 13 Oct 2019 19:34:42 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail.allbsd.org (mx.allbsd.org [IPv6:2001:2f0:104:e001::41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.allbsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rsMg48J4z4S1k; Sun, 13 Oct 2019 19:34:38 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail-d.allbsd.org ([IPv6:2409:11:a740:4700:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id x9DJY85G011417 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) (Client CN "/CN=mail-d.allbsd.org", Issuer "/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3"); Mon, 14 Oct 2019 04:34:19 +0900 (JST) (envelope-from hrs@allbsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=allbsd.org; s=20190220; t=1570995268; bh=x4sWjq6OaKfZjliFBybSlY3ivv8xOo4EE/hVeLqZJ2k=; h=Date:To:Cc:From:In-Reply-To:References; b=XIdgDL55ejDJRD/pJ6j8ClpUlj5Voj1T4uFalrRlr0KXBt4OTm+Q5fAPIWCgXTsGj rqD7nApjuwl6X6iky3Ln1655croPvEZozMFIb3GauYGVNUPUUqyFMy+JCsSfDRiFFH t1jmPLw9SDRns6WkY4uf9XZ20cmMs8Qmyks9dmUU= Received: from alph.d.allbsd.org ([IPv6:2409:11:a740:4700:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id x9DJY2cq021889 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 14 Oct 2019 04:34:03 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from localhost (localhost [[UNIX: localhost]]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id x9DJXug3021885; Mon, 14 Oct 2019 04:34:02 +0900 (JST) (envelope-from hrs@allbsd.org) Date: Mon, 14 Oct 2019 04:32:09 +0900 (JST) Message-Id: <20191014.043209.919156653743886519.hrs@allbsd.org> To: woodsb02@gmail.com Cc: hrs@freebsd.org, brooks@freebsd.org, julian@freebsd.org, driesm.michiels@gmail.com, freebsd-net@freebsd.org, roy@marples.name Subject: Re: DHCPv6 client in base From: Hiroki Sato In-Reply-To: References: X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 26.2 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Mon_Oct_14_04_32_09_2019_895)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [IPv6:2001:2f0:104:e001:0:0:0:41]); Mon, 14 Oct 2019 04:34:28 +0900 (JST) X-Rspamd-Queue-Id: 46rsMg48J4z4S1k X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=allbsd.org header.s=20190220 header.b=XIdgDL55; dmarc=none; spf=pass (mx1.freebsd.org: domain of hrs@allbsd.org designates 2001:2f0:104:e001::41 as permitted sender) smtp.mailfrom=hrs@allbsd.org X-Spamd-Result: default: False [-5.43 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[allbsd.org:s=20190220]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[allbsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[allbsd.org:+]; MID_CONTAINS_FROM(1.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7514, ipnet:2001:2f0::/32, country:JP]; IP_SCORE(-2.33)[ip: (-9.15), ipnet: 2001:2f0::/32(-4.36), asn: 7514(1.86), country: JP(-0.01)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 13 Oct 2019 19:34:42 -0000 ----Security_Multipart(Mon_Oct_14_04_32_09_2019_895)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben Woods wrote in : wo> On Fri, 11 Oct 2019 at 08:32, Ben Woods wrote: wo> As promised, I have completed my initial work to import dhcpcd into FreeBSD wo> base, and it is ready for review, testing and comment at the link below. wo> https://reviews.freebsd.org/D22012 wo> wo> As per the comment from brooks@, I have opted to have it installed in wo> parallel with dhclient (which remains the default). How do you want to proceed the discussion? I sent my view and made myself clear that importing dhcpcd into the base system as-is is not a good idea. What is your answer to my concerns? I also agree with Brooks about a need for sandboxing before the import if it will happen. Do you have any plan to add changes to the imported dhcpcd? And, I think there is common mistake about how to invoke dhcpcd in D22012. DHCPv6 client should be invoke upon RA with O-flag received, not invoked independently or by devd(8) upon a link-up event. I do not want people to configure ifconfig_IF_ipv6="DHCP". What people should be aware is if they want to allow receving RA. Whether DHCPv6 is required or not should be controlled by RA, not configuration on the host side. Also, DHCP-PD shuold be handled in rc.d script framework in some way. Doing something similar to IPv4 DHCP client is not enough, and having both rtsold and dhcpcd is just confusing. I want to continue discussion about what is the best or better direction instead of going ahead with D22012. -- Hiroki ----Security_Multipart(Mon_Oct_14_04_32_09_2019_895)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMcEABMKAC0WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXaN7ug8caHJzQGFsbGJz ZC5vcmcACgkQ27B9xm8fc3+oPAIGIO9H2UdoE1mXkVdK2KgcZNGNpovy3R0RJClo T8P8WsQyTom6mFpTsiKS8PwtAa+eTWdHZI1iz/lIwZyaNVaFy4gCBRCVbb87iaWv zRsN6Kmq2iDCva+wOnpWmgthZ7cpvZGX2RCU8EvRV4BzzVnvvcU2aG2rp2pFVtT/ Lm8XxK7Mmgt+ =+sJY -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Oct_14_04_32_09_2019_895)---- From owner-freebsd-net@freebsd.org Sun Oct 13 20:20:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 662DBB499C for ; Sun, 13 Oct 2019 20:20:49 +0000 (UTC) (envelope-from roy@marples.name) Received: from relay2.marples.name (relay2.marples.name [77.68.23.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay2.marples.name", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rtNw2Z4bz4Vys for ; Sun, 13 Oct 2019 20:20:48 +0000 (UTC) (envelope-from roy@marples.name) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 242FC7A2 for ; Sun, 13 Oct 2019 20:20:37 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 665801CD56B; Sun, 13 Oct 2019 21:18:46 +0100 (BST) Subject: Re: DHCPv6 client in base To: Hiroki Sato , woodsb02@gmail.com Cc: hrs@freebsd.org, brooks@freebsd.org, julian@freebsd.org, driesm.michiels@gmail.com, freebsd-net@freebsd.org References: <20191014.043209.919156653743886519.hrs@allbsd.org> From: Roy Marples Message-ID: Date: Sun, 13 Oct 2019 21:20:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191014.043209.919156653743886519.hrs@allbsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46rtNw2Z4bz4Vys X-Spamd-Bar: / X-Spamd-Result: default: False [-0.95 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[marples.name:s=mail]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:relay2.marples.name]; NEURAL_HAM_LONG(-0.97)[-0.970,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; NEURAL_HAM_MEDIUM(-0.88)[-0.883,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[marples.name:+]; DMARC_POLICY_ALLOW(-0.50)[marples.name,quarantine]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.40)[asn: 8560(2.03), country: DE(-0.01)]; ASN(0.00)[asn:8560, ipnet:77.68.0.0/17, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 13 Oct 2019 20:20:49 -0000 On 13/10/2019 20:32, Hiroki Sato wrote: > Ben Woods wrote > in : > > wo> On Fri, 11 Oct 2019 at 08:32, Ben Woods wrote: > wo> As promised, I have completed my initial work to import dhcpcd into FreeBSD > wo> base, and it is ready for review, testing and comment at the link below. > wo> https://reviews.freebsd.org/D22012 > wo> > wo> As per the comment from brooks@, I have opted to have it installed in > wo> parallel with dhclient (which remains the default). > > How do you want to proceed the discussion? I sent my view and made > myself clear that importing dhcpcd into the base system as-is is not > a good idea. What is your answer to my concerns? I also agree with > Brooks about a need for sandboxing before the import if it will > happen. Do you have any plan to add changes to the imported dhcpcd? Sorry if it was not clear. The discussion involves what is the required acceptance for Priviledge Seperation because this is quite new to me. My current idea is to open DHCP, IPv6RA and DHCP6 ports, chroot, drop privs and fork. This concept is pretty standard thus far. These are listening ports only and will dry-run any received message through dhcpcd's two commons paths: 1) extract address and routing information without applying it 2) environment option generation from the whole message Once done, the message is passed verbatim back to dhcpcd for doing the same tasks but actually configuring the host. I've started work on implementing this and hopefully it will add value and security. If anyone thinks this is wrong, or there is a better way or I've missed something blazingly obvious, now is the time to tell me! The tricky part will be handling BPF (for BOOTP and ARP) because of the needs of how dhcpcd works. I think I'll need to spawn an unpriv process per BPF as needed and this part will probably be implemeted last. Roy From owner-freebsd-net@freebsd.org Sun Oct 13 21:01:03 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 13485B5AD8 for ; Sun, 13 Oct 2019 21:01:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rvHL5sfhz4YRG for ; Sun, 13 Oct 2019 21:01:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id C2042B5AD6; Sun, 13 Oct 2019 21:01:02 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C1A88B5AD5 for ; Sun, 13 Oct 2019 21:01:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rvHL3zYzz4YR4 for ; Sun, 13 Oct 2019 21:01:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5F86C22B46 for ; Sun, 13 Oct 2019 21:01:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DL12J6055470 for ; Sun, 13 Oct 2019 21:01:02 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DL12ir055469 for net@FreeBSD.org; Sun, 13 Oct 2019 21:01:02 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201910132101.x9DL12ir055469@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: net@FreeBSD.org Subject: Problem reports for net@FreeBSD.org that need special attention Date: Sun, 13 Oct 2019 21:01:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 13 Oct 2019 21:01:03 -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 | 221146 | [ixgbe] Problem with second laggport In Progress | 235700 | oce(4) driver causes fatal trap 12 on boot with e New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 213410 | [carp] service netif restart causes hang only whe Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 200319 | Bridge+CARP crashes/freezes Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 222273 | igb(4): Kernel panic (fatal trap 12) due to netwo Open | 225438 | panic in6_unlink_ifa() due to race Open | 225792 | ECMP is broken since tryforward() Open | 227720 | Kernel panic in ppp server Open | 236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open | 236983 | bnxt(4) VLAN not operational unless explicit "ifc Open | 237072 | netgraph(4): performance issue [on HardenedBSD]? Open | 237391 | route get returns no result for network addresses Open | 237840 | Removed dummynet dependency on ipfw Open | 238324 | Add XG-C100C/AQtion AQC107 10GbE NIC driver Open | 240320 | ixgbe: EEE state change causes core dump on X552 Open | 240944 | em(4): Crash with Intel 82571EB NIC with AMD Pile Open | 240969 | netinet6: Neighbour reachability detection broken 22 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Oct 13 21:53:46 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 53389B7702 for ; Sun, 13 Oct 2019 21:53:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwSB1ZZHz4bbx for ; Sun, 13 Oct 2019 21:53:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 34404B7701; Sun, 13 Oct 2019 21:53:46 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 34068B7700 for ; Sun, 13 Oct 2019 21:53:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwSB0fXDz4bbw for ; Sun, 13 Oct 2019 21:53:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EDE68235E4 for ; Sun, 13 Oct 2019 21:53:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DLrj3g024421 for ; Sun, 13 Oct 2019 21:53:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DLrjE2024420 for net@FreeBSD.org; Sun, 13 Oct 2019 21:53:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 236309] axe(4): PF & NAT'd outbound traffic has zero checksums with TXCSUM enabled Date: Sun, 13 Oct 2019 21:53:44 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? X-Bugzilla-Changed-Fields: flagtypes.name bug_severity cc see_also keywords bug_status short_desc 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.29 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, 13 Oct 2019 21:53:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236309 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable12? Severity|Affects Only Me |Affects Some People CC| |net@FreeBSD.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 356 | |07 Keywords| |needs-qa Status|New |Open Summary|[axe] pf/nat/txcsum broken |axe(4): PF & NAT'd outbound |on 12 |traffic has zero checksums | |with TXCSUM enabled --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 21:53:47 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A630CB7717 for ; Sun, 13 Oct 2019 21:53:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwSC41MKz4bcC for ; Sun, 13 Oct 2019 21:53:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 89CACB7715; Sun, 13 Oct 2019 21:53:47 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8996FB7712 for ; Sun, 13 Oct 2019 21:53:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwSC356nz4bc9 for ; Sun, 13 Oct 2019 21:53:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4EF55235EC for ; Sun, 13 Oct 2019 21:53:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DLrlOW024455 for ; Sun, 13 Oct 2019 21:53:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DLrlNQ024454 for net@FreeBSD.org; Sun, 13 Oct 2019 21:53:47 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 235607] Incorrect checksums with NAT on vtnet with offloading Date: Sun, 13 Oct 2019 21:53:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also 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.29 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, 13 Oct 2019 21:53:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235607 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 363 | |09 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 21:54:46 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 832FAB7891 for ; Sun, 13 Oct 2019 21:54:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwTL30MJz4bmJ for ; Sun, 13 Oct 2019 21:54:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 66D9BB788E; Sun, 13 Oct 2019 21:54:46 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 66A05B788C for ; Sun, 13 Oct 2019 21:54:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwTL229Pz4bmG for ; Sun, 13 Oct 2019 21:54:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2A1FC235F5 for ; Sun, 13 Oct 2019 21:54:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DLskea025760 for ; Sun, 13 Oct 2019 21:54:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DLsk9J025759 for net@FreeBSD.org; Sun, 13 Oct 2019 21:54:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 234442] libnetgraph race condition Date: Sun, 13 Oct 2019 21:54:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: markj@FreeBSD.org X-Bugzilla-Flags: mfc-stable11+ mfc-stable12+ X-Bugzilla-Changed-Fields: flagtypes.name 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.29 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, 13 Oct 2019 21:54:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234442 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable11+, | |mfc-stable12+ --- Comment #10 from Kubilay Kocak --- ^Triage: Track MFC's --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 21:56:05 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 23464B7996 for ; Sun, 13 Oct 2019 21:56:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwVs08Fwz4bs2 for ; Sun, 13 Oct 2019 21:56:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 04C7FB7995; Sun, 13 Oct 2019 21:56:05 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 048E0B7994 for ; Sun, 13 Oct 2019 21:56:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwVr6NcYz4bry for ; Sun, 13 Oct 2019 21:56:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BF5BB23601 for ; Sun, 13 Oct 2019 21:56:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DLu4tZ027574 for ; Sun, 13 Oct 2019 21:56:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DLu4KG027573 for net@FreeBSD.org; Sun, 13 Oct 2019 21:56:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241088] netinet: Move request window scaling computation to tcp_output() Date: Sun, 13 Oct 2019 21:56:04 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: flagtypes.name resolution keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 13 Oct 2019 21:56:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241088 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable11?, | |mfc-stable12? | Resolution|Not A Bug |Overcome By Events Keywords|needs-qa | --- Comment #2 from Kubilay Kocak --- ^Triage: Correct resolution (see review comments) --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 21:56:24 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B801AB7A49 for ; Sun, 13 Oct 2019 21:56:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwWD4Sq2z4bwW for ; Sun, 13 Oct 2019 21:56:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 9947CB7A45; Sun, 13 Oct 2019 21:56:24 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 990A8B7A43 for ; Sun, 13 Oct 2019 21:56:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwWD3bSBz4bwV for ; Sun, 13 Oct 2019 21:56:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5F11123604 for ; Sun, 13 Oct 2019 21:56:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DLuOxH027978 for ; Sun, 13 Oct 2019 21:56:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DLuObt027977 for net@FreeBSD.org; Sun, 13 Oct 2019 21:56:24 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241088] netinet: Move request window scaling computation to tcp_output() Date: Sun, 13 Oct 2019 21:56:24 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not Accepted X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 13 Oct 2019 21:56:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241088 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|Overcome By Events |Not Accepted --- Comment #3 from Kubilay Kocak --- ^Triage: Use an even more correct resolution --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 22:01:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 34B83B7D42 for ; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwdT0gJVz4cJv for ; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 16DE1B7D3B; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 16A1BB7D39 for ; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwdS6rTZz4cJs for ; Sun, 13 Oct 2019 22:01:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CF37B2377F for ; Sun, 13 Oct 2019 22:01:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DM1mlp044938 for ; Sun, 13 Oct 2019 22:01:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DM1mUW044937 for net@FreeBSD.org; Sun, 13 Oct 2019 22:01:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 237568] nginx causes host panic when closing socket descriptor? Date: Sun, 13 Oct 2019 22:01:47 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: assigned_to flagtypes.name short_desc keywords bug_status cc see_also 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.29 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, 13 Oct 2019 22:01:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237568 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org Flags| |mfc-stable11?, | |mfc-stable12? Summary|Panic when closing socket |nginx causes host panic |descriptor? |when closing socket | |descriptor? Keywords|panic |needs-qa Status|New |Open CC| |net@FreeBSD.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 411 | |62 --- Comment #1 from Kubilay Kocak --- @rlwestlund Could you please also provide: - Complete uname -a - /var/run/dmesg.boot output (as an attachment) - /etc/rc.conf output (sanitized where necessary) as an attachment - nginx configuration (sanitized where necessary) as an attachment - pkg version -v output (as an attachment) --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 22:01:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B39C5B7D5A for ; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwdT4NzLz4cK3 for ; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 96C06B7D4D; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9687FB7D4C for ; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwdT3RDSz4cK0 for ; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5975E23783 for ; Sun, 13 Oct 2019 22:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DM1nEM045007 for ; Sun, 13 Oct 2019 22:01:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DM1n3f045006 for net@FreeBSD.org; Sun, 13 Oct 2019 22:01:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241162] Panic in closefp() triggered by nginx Date: Sun, 13 Oct 2019 22:01:47 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: see_also 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.29 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, 13 Oct 2019 22:01:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241162 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 375 | |68 --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 22:08:18 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 59E13B817C for ; Sun, 13 Oct 2019 22:08:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwmy1nDQz4cb2 for ; Sun, 13 Oct 2019 22:08:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 33508B817B; Sun, 13 Oct 2019 22:08:18 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3317FB817A for ; Sun, 13 Oct 2019 22:08:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwmy0ZLbz4cb1 for ; Sun, 13 Oct 2019 22:08:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EC321237D7 for ; Sun, 13 Oct 2019 22:08:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DM8HZL057179 for ; Sun, 13 Oct 2019 22:08:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DM8Hwb057178 for net@FreeBSD.org; Sun, 13 Oct 2019 22:08:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240608] if_vmx(4): iflib - Panic with INVARIANTS: Memory modified after free (12.1-pre-QA) Date: Sun, 13 Oct 2019 22:08:16 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: short_desc 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.29 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, 13 Oct 2019 22:08:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240608 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|iflib: Panic with |if_vmx(4): iflib - Panic |INVARIANTS: Memory modified |with INVARIANTS: Memory |after free (12.1-pre-QA) |modified after free | |(12.1-pre-QA) --- Comment #5 from Kubilay Kocak --- (In reply to Harald Schmalzbauer from comment #4) @Herald Can you confirm (explicitly) that the panic does *not* occur with j= umbo frames *disabled/not configured* ? --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 22:15:53 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8F3A4B8867 for ; Sun, 13 Oct 2019 22:15:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwxj0xdQz4d5W for ; Sun, 13 Oct 2019 22:15:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 16ACEB8863; Sun, 13 Oct 2019 22:15:53 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1608BB8862 for ; Sun, 13 Oct 2019 22:15:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwxh3Tbmz4d5V for ; Sun, 13 Oct 2019 22:15:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 51D09239A6 for ; Sun, 13 Oct 2019 22:15:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DMFqG6078395 for ; Sun, 13 Oct 2019 22:15:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DMFqpo078394 for net@FreeBSD.org; Sun, 13 Oct 2019 22:15:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 237568] nginx causes host panic when closing socket descriptor? Date: Sun, 13 Oct 2019 22:15:52 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rlwestlund@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 13 Oct 2019 22:15:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237568 --- Comment #2 from rlwestlund@gmail.com --- Sorry, but I'm afraid the server was wiped since then. I'll see if we can reproduce it now. --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 22:16:33 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 18694B89EA for ; Sun, 13 Oct 2019 22:16:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46rwyS6ymxz4dCl for ; Sun, 13 Oct 2019 22:16:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id EEFF2B89E9; Sun, 13 Oct 2019 22:16:32 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EEB9AB89E8 for ; Sun, 13 Oct 2019 22:16:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rwyS66Dmz4dCj for ; Sun, 13 Oct 2019 22:16:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B5482239B9 for ; Sun, 13 Oct 2019 22:16:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DMGWGN079417 for ; Sun, 13 Oct 2019 22:16:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DMGWW7079416 for net@FreeBSD.org; Sun, 13 Oct 2019 22:16:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 210726] tcp connect() can return invalid EADDRINUSE (Eg: multiple jails with the same IP address) Date: Sun, 13 Oct 2019 22:16:30 +0000 X-Bugzilla-Reason: AssignedTo CC 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 Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: cc flagtypes.name keywords short_desc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 13 Oct 2019 22:16:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210726 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koobs@FreeBSD.org Flags| |mfc-stable11?, | |mfc-stable12? Keywords|patch |needs-qa Summary|tcp connect() can return |tcp connect() can return |invalid EADDRINUSE |invalid EADDRINUSE (Eg: | |multiple jails with the | |same IP address) Assignee|bz@FreeBSD.org |net@FreeBSD.org --- Comment #19 from Kubilay Kocak --- @All Please don't *solely* bump issues, unless providing additional informa= tion beyond what already exists. ^Triage:=20 - Assignee timeout (> 1 year), reset assignee @Reporter: Can you please provide: - /etc/rc.conf / /etc/jail.conf configuration/setup that reproduces the iss= ue (as an attachment) @Anyone An updated patch against CURRENT/head would be handy (please obsolete exist= ing patches when attaching the updated one) --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Oct 13 22:21:56 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0217B8E32 for ; Sun, 13 Oct 2019 22:21:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46rx4h5h14z4dXL for ; Sun, 13 Oct 2019 22:21:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id C2FA0B8E31; Sun, 13 Oct 2019 22:21:56 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C2C07B8E30 for ; Sun, 13 Oct 2019 22:21:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46rx4h4m9xz4dXK for ; Sun, 13 Oct 2019 22:21:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 870CA23B33 for ; Sun, 13 Oct 2019 22:21:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9DMLujS005972 for ; Sun, 13 Oct 2019 22:21:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9DMLuII005934 for net@FreeBSD.org; Sun, 13 Oct 2019 22:21:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241223] em(4): E1000 panic: sleeping in an epoch section Date: Sun, 13 Oct 2019 22:21:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc keywords 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.29 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, 13 Oct 2019 22:21:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241223 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|E1000: panic: sleeping in |em(4): E1000 panic: |an epoch section |sleeping in an epoch | |section Keywords|panic |crash CC| |net@FreeBSD.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Oct 14 02:46:19 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D9E92BDA54 for ; Mon, 14 Oct 2019 02:46:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46s2xl5TShz3LhX for ; Mon, 14 Oct 2019 02:46:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BBDCCBDA52; Mon, 14 Oct 2019 02:46:19 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BBA39BDA51 for ; Mon, 14 Oct 2019 02:46:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46s2xl4YjCz3LhV for ; Mon, 14 Oct 2019 02:46:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 80D5926918 for ; Mon, 14 Oct 2019 02:46:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9E2kJ1K031893 for ; Mon, 14 Oct 2019 02:46:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9E2kJXd031890 for net@FreeBSD.org; Mon, 14 Oct 2019 02:46:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241223] em(4): E1000 panic: sleeping in an epoch section Date: Mon, 14 Oct 2019 02:46:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@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.29 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, 14 Oct 2019 02:46:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241223 --- Comment #3 from Gleb Smirnoff --- > I recompiled with r353461...=20 Did you cherry-pick r353461 or did you update all of your kernel sources up= to r353461? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Oct 14 03:06:33 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 084E4BE558 for ; Mon, 14 Oct 2019 03:06:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46s3P46Btfz3Mx5 for ; Mon, 14 Oct 2019 03:06:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id D2BC7BE557; Mon, 14 Oct 2019 03:06:32 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D26D8BE556 for ; Mon, 14 Oct 2019 03:06:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46s3P44Ccnz3Mx0 for ; Mon, 14 Oct 2019 03:06:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7366026D1A for ; Mon, 14 Oct 2019 03:06:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9E36WDS085393 for ; Mon, 14 Oct 2019 03:06:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9E36WhN085392 for net@FreeBSD.org; Mon, 14 Oct 2019 03:06:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241223] em(4): E1000 panic: sleeping in an epoch section Date: Mon, 14 Oct 2019 03:06:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: accornehl@fastmail.fm X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@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.29 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, 14 Oct 2019 03:06:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241223 --- Comment #4 from Anthony Cornehl --- (In reply to Gleb Smirnoff from comment #3) It was built after a svn update of /usr/src from base/head. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Oct 14 04:10:58 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 04A25BF3F2 for ; Mon, 14 Oct 2019 04:10:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46s4qP5szvz3Ppl for ; Mon, 14 Oct 2019 04:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id C9534BF3F1; Mon, 14 Oct 2019 04:10:57 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C91AABF3EE for ; Mon, 14 Oct 2019 04:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46s4qP4qGnz3Ppk for ; Mon, 14 Oct 2019 04:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 89E29278EE for ; Mon, 14 Oct 2019 04:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9E4AvC8085119 for ; Mon, 14 Oct 2019 04:10:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9E4AvsP085118 for net@FreeBSD.org; Mon, 14 Oct 2019 04:10:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241223] em(4): E1000 panic: sleeping in an epoch section Date: Mon, 14 Oct 2019 04:10:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@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.29 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, 14 Oct 2019 04:10:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241223 --- Comment #5 from Gleb Smirnoff --- Please try with kernel after r353484. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Oct 14 04:59:26 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 23D3EBFEFD for ; Mon, 14 Oct 2019 04:59:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46s5vL0CYWz3RJ1 for ; Mon, 14 Oct 2019 04:59:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 050A8BFEFC; Mon, 14 Oct 2019 04:59:26 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 03985BFEFB for ; Mon, 14 Oct 2019 04:59:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46s5vK65x5z3RHy for ; Mon, 14 Oct 2019 04:59:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B0EEAA9 for ; Mon, 14 Oct 2019 04:59:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9E4xPWY031162 for ; Mon, 14 Oct 2019 04:59:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9E4xP5a031161 for net@FreeBSD.org; Mon, 14 Oct 2019 04:59:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241223] em(4): E1000 panic: sleeping in an epoch section Date: Mon, 14 Oct 2019 04:59:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: accornehl@fastmail.fm X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 14 Oct 2019 04:59:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241223 Anthony Cornehl changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Open |Closed --- Comment #6 from Anthony Cornehl --- Rebuilt the kernel at r353485 and I was not able to reproduce the panic from comment 2 or description. Thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Oct 14 06:11:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 03A99F1250 for ; Mon, 14 Oct 2019 06:11:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46s7Vr6P1rz40GC for ; Mon, 14 Oct 2019 06:11:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id DB781F124F; Mon, 14 Oct 2019 06:11:48 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DB3C2F124E for ; Mon, 14 Oct 2019 06:11:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46s7Vr5TC4z40GB for ; Mon, 14 Oct 2019 06:11:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A03A3E9B for ; Mon, 14 Oct 2019 06:11:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9E6Bmf3005598 for ; Mon, 14 Oct 2019 06:11:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9E6BmDf005592 for net@FreeBSD.org; Mon, 14 Oct 2019 06:11:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241223] em(4): E1000 panic: sleeping in an epoch section Date: Mon, 14 Oct 2019 06:11:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@FreeBSD.org X-Bugzilla-Flags: mfc-stable11- mfc-stable12- X-Bugzilla-Changed-Fields: keywords flagtypes.name 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.29 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, 14 Oct 2019 06:11:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241223 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Flags| |mfc-stable11-, | |mfc-stable12- --- Comment #7 from Kubilay Kocak --- ^Triage: Track MFC's, not necessary, issue only present on CURRENT post base r353292 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Oct 14 06:46:02 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9AB0DF1F44 for ; Mon, 14 Oct 2019 06:46:02 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "anubis.delphij.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46s8GK4mjfz41lR; Mon, 14 Oct 2019 06:46:01 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from p51.home.us.delphij.net (unknown [IPv6:2601:646:8600:d04a:e670:b8ff:fe5c:4e69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 3A6B742126; Sun, 13 Oct 2019 23:45:53 -0700 (PDT) Reply-To: d@delphij.net To: Gleb Smirnoff , Mark Johnston Cc: Hans Petter Selasky , Yuri Pankov , freebsd-net , erj@freebsd.org References: <86cc5d82-50d0-93eb-5900-54e8b0032a08@yuripv.net> <050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org> <20191009135616.GC66126@raichu> <20191009144704.GD66126@raichu> <20191009150757.GI1249@FreeBSD.org> From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= mQINBFuSR4oBEACvvEgwRIHs6IcSP/yaDtySF78Ji3rP29qdiQsxhMsOtvtffdbS56VApIWO UFb3/iN2gA8HwLvrmjijN0HEoLVX7na1WARmxRYzQMtApsZIUTtx7hnUYlsi2F5odZa6CDW9 a954DLRzYxiUwYDcu5Zjl9bglK1H8e/N9uC0Vuigr4teWfh86brzOyf819QzwFVYfMIK4ihw QGwMvTzbyVuCFy+LENkmcVYni70oQy6rZ5ktSuYbuOFvu7inRRfhSWPHziV7k+bW88sJ7xhv lBlegcnhkSudWX2M8tZ3MO1PJOcyys0CJlsBY5Weiog2lIPi05h/E9pZ9mc1Vud17iqDaL6w RaggOUhuPfDGCdO5ro82W4BZGeQMRnRF5Ntk+t2ShIH4nn3xRLV0E5nziCiKlgiMqOrz/ZTL QTVbHrCuiwD+fSK14y0oHbkOLYTYLlgh1JbwfY2Ty7elOYiWzyeJ7sJh2dF91NSEneWIOys3 mBpuvtU3nSzzTvAB48VV+Nbg1CpIOgNlPjj7uhIum/Z/VjUaJEyaLpTIRh0MVJVcbP7hXSqZ NA35EEZZVnWEOYdycm4CmEdeNPWkrAf2Ya77iR5VLGypwMlsUMQPh+sKVWDD38M8stFGBBNm d01Hi74Bsq5hKan654dOqMt5eYklrVj0ucMzFQtus7oE502UswARAQABtBxYaW4gTEkgPGRl bHBoaWpAZGVscGhpai5uZXQ+iQJUBBMBCgA+FiEEceNg5NEMZIki80nQQHl/fJX0g08FAluS R/YCGwMFCQmuhAAFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQQHl/fJX0g0+2Og//bWpE F2V5/M5l6YW1T8oLcT9rIOH6oq9M0LMNRgFeiNNnilGIeeIgtOGBRueG4CZiZAvsRPJkrO70 1R2SrdkCIvwGUzUAxx1NfBWb+vgm4fgkW/MotGonceM5v0qfSKKXasWvDctkK28aG+IoQzmi FjXNW4+ju4zeQFYwD4ZDWqw9MqO0hVb24uW3dxtQhbfmOLgJ/PEDMQaFuANbW1c+iR0BQA3D Go/EeMY4kpN8on6Aqt/S/4JVltudfQ9OXdjQsC7netSaB9K3mHGt9aKAAB7RzlRY00DKkYS/ /eQwLzGPmK7yX13M68mMDjBs6mIR8t/E1S5OdBNhHRPNPlEbwugR4KaiCsN5yqzJoSV99fKY z2VyxjWPaG8yhHE+jmKUgIBKTfFUQEfkriQR4EASoeJ+soaMTiFDBij1Zw5n3ndLRFMB1ZCl fZLER36mAgW4m4kP83TWnDiJLxOxSOxifV8HpTFjff902H85cybg9KMwrfPDr6W19GGk5Vo1 fkza5krRMGbKWb7+74Evusi0ZxJLIOFwp5Y8eVqUMZaAD3f1ZX1M3pgXOp20QgAy+2KvMHij rLa4q+tMGRzYYD1BnFVSVdXAX5VOoTmHBcDz67DkuRwk2Byp1sgd407oEOmSwrNJlKS0TPCm xUJ2fdSQF+1/MMSRfee49vtMvz7cOrC5Ag0EW5JHigEQANiBmIFAfRNH3nzYNWC0yC+tfx3z sUwAsH1VaBM/cTib+yKtbBOSIlXWjJZWX3MHwoI/1LeGghB2mxkkX1L0pJ/vj1eXNR+sFZ32 0pYcl61Fxg/5fioG4QDTM4i3i7NR5PxDnc6UVaynSlII93DedRhZ1ROtdn4vyMgzsDiqhbL7 BthDOt5KxjqdRk4qRPSw7BovEqZLOcG5IJtf/zZUzRbM7SBljEbOAfekDGx1Br+RrYSD7/Ef Pwwzou9T8315IpBpIHyQF/dZNk3iFiB9Ed5CA71ZRYV5YoLWE9lL0j9kxOLQ5vHnX3mVq7QZ Bc7nzwZ6UhQgYmrG5+RWvuiPpGwvDRIsugJUGXucYkAQh5kuNblmkwpv6u9rNMjCNbzAylOa qdogra5EW+RUSbRz0b4iIr8nnZeAlh7BihCe7JjOwbDjoBEEEtSfVc4hD/LENqpcYVrChphf aOLB9YIXhnVDTVvMc9OklWT/81HzAaDQqOQCzEfY92199Ct9/CwRoQ2OpO8TO5+8A7b9Nb33 nmxMn09mb48ruRacMrfHxCWbgU4w9SEfbip4GcS5wGG6yTC+hw55Iwnnwus40NrJ0GEr8a4r cdsLbkvlyoNHB8ZGgyJ4aFCQ1V4qE1BnlTk7Z8BYBUkJM1odPSkVvHpCnMUjVpJ3hEOC+73Z YH1dh7lZABEBAAGJAjwEGAEKACYWIQRx42Dk0QxkiSLzSdBAeX98lfSDTwUCW5JHigIbDAUJ Ca6EAAAKCRBAeX98lfSDTz8DEACMh3poeUb+gWNF4RWFZuLteZVo0+E1JLYXQkmtrRBLXviP +Qy0pXyFAVxLM4hNIBoIDYfK9BcwrBYf7AwSKrH0GiNwFpgHCkbZd6qoZy2gB+adTnCpVCTJ KJetsH/8awkrChJWMK0ckGf3EeWMPvawG7kW7FBz70NYEZ0pOMiaEZNVtzD3wwbYWUiDFYth 83XGglOExg+1ShTW5XjQPRrdyJAO+aUW4o3lVjfyUJXMgI4rmhMiLVm06GuNrbpKIF0s+4Vd jQAjhrDQjfoXi9CkfsA/cONseuHNv1JGj3RqHiqHJq1dbrpodXp925zGDAnUGxCOBPoFopAH gVzR89GTut059GpwqsddZmU6y7rqifuam/ekJ+QRwc16vgt7pHqCrTY8WPxRZr2UpFU1wlTo COdeiFep1gq1F9jzFjJnoMaAdmC6k7bgAA+RQusOgIhJL0jIej7DoAHxmxFFCfRy+lDtpXwF gQ8HMvzHI65QWmQnMo7s6SQH/ZH5s1yR6SJq8+3lDz+dCuT42qJVqIPVvxd10LW0FNN+t7HF eLadU6ekSgD13/EYMYXlvNHkw7dAItSDxIzgRyykLz0bCU9xwNWoS4Z43+ifF9anJ+uR0ltW El1j++h6ZrD3LLuCgJIt1so0m49GzdcSpOI7LCwMlacyvafiEyjUn+tSNDsnfw== Organization: The FreeBSD Project Subject: Re: panic: sleeping in an epoch section Message-ID: <528fec5c-9b36-6f6a-5ba7-3237f56103a1@delphij.net> Date: Sun, 13 Oct 2019 23:45:46 -0700 MIME-Version: 1.0 In-Reply-To: <20191009150757.GI1249@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zwucuWf6vqUBnH6is2eCISz6n2J9M63Ix" X-Rspamd-Queue-Id: 46s8GK4mjfz41lR X-Spamd-Bar: ------- X-Spamd-Result: default: False [-7.48 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; HAS_REPLYTO(0.00)[d@delphij.net]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(-2.38)[ip: (-9.88), ipnet: 64.62.128.0/18(1.45), asn: 6939(-3.41), country: US(-0.05)]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 14 Oct 2019 06:46:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zwucuWf6vqUBnH6is2eCISz6n2J9M63Ix Content-Type: multipart/mixed; boundary="T3FT6OuZ8jsjs4c596j8vX0cL62NgO190"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Gleb Smirnoff , Mark Johnston Cc: Hans Petter Selasky , Yuri Pankov , freebsd-net , erj@freebsd.org Message-ID: <528fec5c-9b36-6f6a-5ba7-3237f56103a1@delphij.net> Subject: Re: panic: sleeping in an epoch section References: <86cc5d82-50d0-93eb-5900-54e8b0032a08@yuripv.net> <050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org> <20191009135616.GC66126@raichu> <20191009144704.GD66126@raichu> <20191009150757.GI1249@FreeBSD.org> In-Reply-To: <20191009150757.GI1249@FreeBSD.org> --T3FT6OuZ8jsjs4c596j8vX0cL62NgO190 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2019-10-09 08:07, Gleb Smirnoff wrote: > Yes, I we should allow sleep in ifioctl handlers. So this is my fault, = I'll > handle it today. It seems that -CURRENT as of today would panic with: (kgdb) #0 doadump (textdump=3D1) at src/sys/amd64/include/pcpu_aux.h:55 #1 0xffffffff80bbe550 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:479 #2 0xffffffff80bbe9a6 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:908 #3 0xffffffff80bbe703 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:835 #4 0xffffffff80e0d1f8 in in6ifa_llaonifp (ifp=3D) at /usr/src/sys/netinet6/in6.c:1554 #5 0xffffffff84cb3bcd in lagg_ioctl (ifp=3D0xfffff80019322000, cmd=3D, data=3D) at /usr/src/sys/net/if_lagg.c:1427 #6 0xffffffff80d4c281 in in_control (cmd=3D2152229261, data=3D0xfffffe00e01fd7d0 "lagg0", ifp=3D0xfffff80019322000, td=3D0xfffff80019675000) at /usr/src/sys/netinet/in.c:262 #7 0xffffffff80ccc6be in ifioctl (so=3D0xfffff8001c15c710, cmd=3D2152229= 261, data=3D0xfffffe00e01fd7d0 "lagg0", td=3D0xfffff80019675000) at /usr/src/sys/net/if.c:3106 #8 0xffffffff80c2fc35 in kern_ioctl (td=3D, fd=3D, com=3D, data=3D) at src/sys/sys/file.h:340 #9 0xffffffff80c2f92c in sys_ioctl (td=3D0xfffff80019675000, uap=3D0xfffff800196753c8) at /usr/src/sys/kern/sys_generic.c:709 #10 0xffffffff8102ee45 in amd64_syscall (td=3D0xfffff80019675000, traced=3D= 0) at src/sys/amd64/amd64/../../kern/subr_syscall.c:144 #11 0xffffffff810054e0 in fast_syscall_common () at /usr/src/sys/amd64/amd64/exception.S:581 #12 0x000000080047db8a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal My configuration is somewhat special: I have a lagg0 (failover) group containing em0 and wlan0: ifconfig_wlan0=3D"WPA" ifconfig_em0=3D"ether (ethernet address of wlan0) up" cloned_interfaces=3D"lagg0" ifconfig_lagg0=3D"laggproto failover laggport em0 laggport wlan0 DHCP" ifconfig_lagg0_ipv6=3D"inet6 accept_rtadv" Without that lagg0 setup, with only wlan0 configured to DHCP and accept_rtadv, the system would boot further and network access appears to work. By the way I think there are some recent change (not sure when, but it happen since August) to either e1000 or iflib have made the driver to expose its e1000_delay state quite a bit when ifconfig or dhclient is trying to configure the lagg0 group, when the wired connection is not available. Cheers, --T3FT6OuZ8jsjs4c596j8vX0cL62NgO190-- --zwucuWf6vqUBnH6is2eCISz6n2J9M63Ix Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.17 (FreeBSD) iQIzBAEBCgAdFiEEceNg5NEMZIki80nQQHl/fJX0g08FAl2kGZ8ACgkQQHl/fJX0 g09JQBAAl8/R9vqqW4ivRVcKzJapE6gnqbLIDorMxJa6MNQhdpWPWG3X2yH/9gNg j8SSR96VI3fJs9REzLABBV1x29w8BdTcuOhiwRr6azUdBwxCugL47G8QUldypnEg ltp7WpqORL4Oz95K7c4L1bpDmoWQwvRy7nxHHvgn0UOYVA2XBADGhRXSZRQM/rdN Nc4ma3SYwk3lPCT3IMVkJhk3qeodjtQ6h3XJzeIqN/FCTvLnBVo9eIVwE2M/fjK8 DJpgg/7IyRA9qbOC9l5dGD7Vpz02dy0UR9VwWmgHLExi9Hju+bu8Ae+UeX/Zmt63 ON8X11nfn+GIi0BvPGVUTyCjpxaPgEoOI6tgG8Vv06CJVxVrF/tgTKhLqWTycsKf 8+n6jgWG18ChvcnB6Zaac5c8VJtCZFL890TT+Pdp4IRP99+TtPWUmLN1ULT/VLK7 BCo+EGq+GCkKPt3cgXcceocgZsU19Q7wvMXQ5OhO6sI+AHoRw7Q9Ewlazb0XfMdS 1XJ0FWZcBjZuTMPrzUNqVu8HwSPSc2ke0foW/JqhnCuM+DigIpeOhLq3l3UXgIvm okmfmydFixy4QK2o8ZMlQM0+9IKlgd+oSnPkYWyav7srEJkUeLtHJEDTFuJ8fytC fQaLmOkqAhJVrTJgvcqnEoVldjll28+XTNsNzFRitZI60y11+7Y= =MVoX -----END PGP SIGNATURE----- --zwucuWf6vqUBnH6is2eCISz6n2J9M63Ix-- From owner-freebsd-net@freebsd.org Mon Oct 14 13:22:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C8132FBC46 for ; Mon, 14 Oct 2019 13:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46sK4950LQz4NqX for ; Mon, 14 Oct 2019 13:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id AB63BFBC45; Mon, 14 Oct 2019 13:22:49 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AB29EFBC44 for ; Mon, 14 Oct 2019 13:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sK49443qz4NqW for ; Mon, 14 Oct 2019 13:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6FD865E37 for ; Mon, 14 Oct 2019 13:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9EDMn0I040916 for ; Mon, 14 Oct 2019 13:22:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9EDMnmv040915 for net@FreeBSD.org; Mon, 14 Oct 2019 13:22:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 237568] nginx causes host panic when closing socket descriptor? Date: Mon, 14 Oct 2019 13:22:49 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rlwestlund@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 14 Oct 2019 13:22:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237568 --- Comment #3 from rlwestlund@gmail.com --- We're unable to reproduce it now. It may have been fixed in the patches sin= ce then. I did get another symptom that might have been related before, which = is the jails failing to unmount on jail -r with "Device busy". Previously we traced that error to TCP connections being left open in TIME_WAIT state, bu= t on the server that used to crash it happened always even if the jail had just = been started. Since then we had solved it with a tcpdrop script as an exec.posts= top hook, but with the server I just spun up to test it it still happened a few times. Once I looked into it and couldn't find anything wrong with the tcpd= rop script I couldn't get the Device busy error to happen anymore. I'm not sure= if this is related. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Oct 14 15:34:19 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 00DA2FE94F for ; Mon, 14 Oct 2019 15:34:19 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sMzt3Syzz4VQ1; Mon, 14 Oct 2019 15:34:17 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id x9EFYAE1025219 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 14 Oct 2019 08:34:11 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id x9EFYACh025218; Mon, 14 Oct 2019 08:34:10 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 14 Oct 2019 08:34:10 -0700 From: Gleb Smirnoff To: d@delphij.net Cc: Mark Johnston , Hans Petter Selasky , Yuri Pankov , freebsd-net , erj@freebsd.org Subject: Re: panic: sleeping in an epoch section Message-ID: <20191014153410.GC4086@FreeBSD.org> References: <86cc5d82-50d0-93eb-5900-54e8b0032a08@yuripv.net> <050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org> <20191009135616.GC66126@raichu> <20191009144704.GD66126@raichu> <20191009150757.GI1249@FreeBSD.org> <528fec5c-9b36-6f6a-5ba7-3237f56103a1@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <528fec5c-9b36-6f6a-5ba7-3237f56103a1@delphij.net> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 46sMzt3Syzz4VQ1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.18 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.18)[-0.179,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 14 Oct 2019 15:34:19 -0000 Xin, fixed by r353492 On Sun, Oct 13, 2019 at 11:45:46PM -0700, Xin Li wrote: X> X> X> On 2019-10-09 08:07, Gleb Smirnoff wrote: X> > Yes, I we should allow sleep in ifioctl handlers. So this is my fault, I'll X> > handle it today. X> X> It seems that -CURRENT as of today would panic with: X> X> (kgdb) #0 doadump (textdump=1) at src/sys/amd64/include/pcpu_aux.h:55 X> #1 0xffffffff80bbe550 in kern_reboot (howto=260) X> at /usr/src/sys/kern/kern_shutdown.c:479 X> #2 0xffffffff80bbe9a6 in vpanic (fmt=, X> ap=) at /usr/src/sys/kern/kern_shutdown.c:908 X> #3 0xffffffff80bbe703 in panic (fmt=) X> at /usr/src/sys/kern/kern_shutdown.c:835 X> #4 0xffffffff80e0d1f8 in in6ifa_llaonifp (ifp=) X> at /usr/src/sys/netinet6/in6.c:1554 X> #5 0xffffffff84cb3bcd in lagg_ioctl (ifp=0xfffff80019322000, X> cmd=, data=) X> at /usr/src/sys/net/if_lagg.c:1427 X> #6 0xffffffff80d4c281 in in_control (cmd=2152229261, X> data=0xfffffe00e01fd7d0 "lagg0", ifp=0xfffff80019322000, X> td=0xfffff80019675000) at /usr/src/sys/netinet/in.c:262 X> #7 0xffffffff80ccc6be in ifioctl (so=0xfffff8001c15c710, cmd=2152229261, X> data=0xfffffe00e01fd7d0 "lagg0", td=0xfffff80019675000) X> at /usr/src/sys/net/if.c:3106 X> #8 0xffffffff80c2fc35 in kern_ioctl (td=, X> fd=, com=, X> data=) at src/sys/sys/file.h:340 X> #9 0xffffffff80c2f92c in sys_ioctl (td=0xfffff80019675000, X> uap=0xfffff800196753c8) at /usr/src/sys/kern/sys_generic.c:709 X> #10 0xffffffff8102ee45 in amd64_syscall (td=0xfffff80019675000, traced=0) X> at src/sys/amd64/amd64/../../kern/subr_syscall.c:144 X> #11 0xffffffff810054e0 in fast_syscall_common () X> at /usr/src/sys/amd64/amd64/exception.S:581 X> #12 0x000000080047db8a in ?? () X> Previous frame inner to this frame (corrupt stack?) X> Current language: auto; currently minimal X> X> My configuration is somewhat special: I have a lagg0 (failover) group X> containing em0 and wlan0: X> X> ifconfig_wlan0="WPA" X> ifconfig_em0="ether (ethernet address of wlan0) up" X> cloned_interfaces="lagg0" X> ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP" X> ifconfig_lagg0_ipv6="inet6 accept_rtadv" X> X> Without that lagg0 setup, with only wlan0 configured to DHCP and X> accept_rtadv, the system would boot further and network access appears X> to work. X> X> By the way I think there are some recent change (not sure when, but it X> happen since August) to either e1000 or iflib have made the driver to X> expose its e1000_delay state quite a bit when ifconfig or dhclient is X> trying to configure the lagg0 group, when the wired connection is not X> available. X> X> Cheers, X> -- Gleb Smirnoff From owner-freebsd-net@freebsd.org Mon Oct 14 16:54:01 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3A0A9130713 for ; Mon, 14 Oct 2019 16:54:01 +0000 (UTC) (envelope-from bounce@track-my-url.com) Received: from srv-52.mkzp.com (srv-52.mkzp.com [37.1.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 46sPlr53mJz4b2C for ; Mon, 14 Oct 2019 16:54:00 +0000 (UTC) (envelope-from bounce@track-my-url.com) To: freebsd-net@freebsd.org Subject: =?UTF-8?B?VMSwTS1UU1BCIMSwaHJhY2F0IFlhcGFuIMWeaXJrZXRsZXIgxLDDp2luIEt1ciBSaXNraSBZw7ZuZXRpbWkgUGFuZWxpbmluIEJlxZ9pbmNpIER1cmHEn8SxIE1lcnNpbiE=?= Message-ID: Date: Mon, 14 Oct 2019 16:45:04 +0000 From: "=?UTF-8?B?VMO8cmtpeWUgU2VybWF5ZSBQaXlhc2FsYXLEsSBCaXJsacSfaQ==?=" Reply-To: info@tspb.org.tr MIME-Version: 1.0 X-Mailer-LID: 469 X-Mailer-RecptId: 2389711 X-Mailer-SID: 3801 X-Mailer-Sent-By: 15 X-Rspamd-Queue-Id: 46sPlr53mJz4b2C X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=tspb.org.tr (policy=none); spf=pass (mx1.freebsd.org: domain of bounce@track-my-url.com designates 37.1.145.52 as permitted sender) smtp.mailfrom=bounce@track-my-url.com X-Spamd-Result: default: False [2.67 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[info@tspb.org.tr]; NEURAL_HAM_MEDIUM(-0.66)[-0.659,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:37.1.145.62/28:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; HAS_PHPMAILER_SIG(0.00)[]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; MANY_INVISIBLE_PARTS(0.10)[2]; HAS_INTERSPIRE_SIG(1.00)[]; NEURAL_SPAM_LONG(0.83)[0.827,0]; REPLYTO_ADDR_EQ_FROM(0.00)[]; SUBJECT_ENDS_EXCLAIM(0.00)[]; AUTOGEN_PHP_SPAMMY(1.00)[]; FORGED_SENDER(0.30)[info@tspb.org.tr,bounce@track-my-url.com]; RCVD_COUNT_ZERO(0.00)[0]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:60781, ipnet:37.1.144.0/22, country:NL]; FROM_NEQ_ENVFROM(0.00)[info@tspb.org.tr,bounce@track-my-url.com]; IP_SCORE(0.31)[ip: (0.45), ipnet: 37.1.144.0/22(0.31), asn: 60781(0.78), country: NL(0.02)]; DMARC_POLICY_SOFTFAIL(0.10)[tspb.org.tr : SPF not aligned (relaxed), No valid DKIM, none] Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 14 Oct 2019 16:54:01 -0000 "TİM-TSPB İhracat Yapan Şirketler İçin Kur Riski Yönetimi" Panellerinin Beşinci Durağı Mersin! Tarih : 24 Ekim 2019 Perşembe / 13:30-17:15 Mekan: Akdeniz İhracatçı Birlikleri Genel Sekreterliği Mersin Salonu Bülteni Daha İyi Görüntülemek İçin Tıklayın [http://track-1.n-mailer-premium.com/0011D2389711|10019c00fdf926bb981d59ee664f79715a6a|01003801|1111469|11001627.html]"TİM-TSPB İhracat Yapan Şirketler İçin Kur Riski Yönetimi" Panellerinin Beşinci Durağı Mersin! Tarih : 24 Ekim 2019 Perşembe /13:30-17:15 Mekan: Akdeniz İhracatçı Birlikleri Genel Sekreterliği Mersin Salonu [http://track-1.n-mailer-premium.com/1110L2389711|11113801|000123011|1000T.html] 24 Ekim 2019 tarihinde Akdeniz İhracatçı Birlikleri Genel Sekreterliği Mersin Salonu'ndaki"TİM-TSPB İhracat Yapan Şirketler İçin Kur Riski Yönetimi" Paneline kayıt için tıklayınız [http://track-1.n-mailer-premium.com/1001L2389711|00113801|100023011|0100T.html] Panel Hakkında Türkiye İhracatçılar Meclisi ve Birliğimizce 2019 yılında reel sektör şirketlerine yönelik ücretsiz etkinlikler kapsamında "İhracat Yapan Şirketler İçin Kur Riski Yönetimi" konulu panellerin beşinci durağı Mersin. Türkiye İhracatçılar Meclisi, Türkiye Sermaye Piyasaları Birliği ve Üyelerimizin iş birliği çerçevesinde düzenlenecek panellerin beşinci durağı Mersin olup 24 Ekim 2019 tarihinde Akdeniz İhracatçı Birlikleri Genel Sekreterliği Mersin Salonu'nda gerçekleştirilecektir. Söz konusu paneller ile kur riski taşıyan ihracatçı şirketlerin çalışanlarının, yatırımcıların ve konuya ilgi duyanların bilgilendirilmesi ve farkındalık oluşturulması öngörülmektedir. Panel İhracatçı Birlikleri, Sanayi ve Ticaret Odaları, İş İnsanları Derneklerinin üyeleriyle, banka ve aracı kurum çalışanlarının katılımına açıktır. Ayrıca panellerin öncesinde ve eş zamanlı olarak ihracat yapan şirketlerin üst düzey yöneticileri ile üyelerimiz arasında 1 saat süreli B2B görüşmeleri planlanmaktadır. Panele katılım ücretsiz olup kontenjanın sınırlı olması nedeniyle 21 Ekim 2019 tarihine kadar katılım kaydının tamamlanması gerekmektedir. Panele Kayıt için lütfen buraya tıklayınız [http://track-1.n-mailer-premium.com/0011L2389711|10003801|110023011|0011T.html] B2B Görüşmeleri İçin Lüften Buraya Tıklayınız [http://track-1.n-mailer-premium.com/1100L2389711|00113801|010023012|1011T.html] B2B görüşmeleri ücretsiz olup görüşme randevularını planlayabilmek için 18 Ekim 2019 tarihine kadar kayıtların tamamlanması gerekmektedir. Program İçeriği 13:30-14:00 Kayıt/İkram 14:00-14:10 Açılış Konuşması 14:10-15:30 Panel Başlıyor 15:30-15:50 Kahve Arası 15:50-16:10 Kur Riskinden Korunmanın Mali Tablolarda Gösterimi 16:10-17:00 Türkiye Ekonomisindeki Güncel Gelişmeler 17:00-17:15 Soru-Cevap Konuşmacılar 14:00-14:10 "Açılış Konuşmaları" 14:10-15:30 "Panel Başlıyor" Moderatör: Kerem Aksoy; Borsa İstanbul A.Ş., Türev Piyasalar ve Ürün Geliştirme Yöneticisi Panelist: Coşan Yeğenoğlu; Gedik Yatırım Menkul Değerler A.Ş, Genel Müdür Yardımcısı Panelist: Kerem Aksoy; Borsa İstanbul A.Ş, Türev Piyasalar ve Ürün Geliştirme Yöneticisi Panelist: Engin Küçük; Global Yatırım Menkul Değerler A.Ş, VİOP Birim Müdürü 15:30-15:50 "Kahve Arası" 15:50-16:10 "Kur Riskinden Korunmanın Mali Tablolarda Gösterimi" Muharrem Karataş; KPMG Türkiye Denetim ve Güvence Hizmetleri Direktörü 16:10-17:00 "Türkiye Ekonomisindeki Güncel Gelişmeler" Üzeyir Doğan; Gedik Yatırım Menkul Değerler A.Ş. Yatırım Danışmanlığı Müdürü 17:00-17:15 " Soru Cevap" Panelin gerçekleşeceği adres: Akdeniz İhracatçı Birlikleri Genel Sekreterliği, Limonluk Mah. Vali Hüseyin Aksoy Cad. No: 4 33120 Yenişehir-MersinBu e-posta tarafınıza TSPB tarafından oluşturulan üye veritabanına kayıtlı olduğunuz için gönderilmiştir.Beni bu listeden çıkar [http://track-1.n-mailer-premium.com/0100U2389711|01109c00fdf926bb981d59ee664f79715a6a|0000469|01103801.html] From owner-freebsd-net@freebsd.org Mon Oct 14 18:44:47 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 461511331A0 for ; Mon, 14 Oct 2019 18:44:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46sSCg1DB2z3Dl7 for ; Mon, 14 Oct 2019 18:44:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2818113319F; Mon, 14 Oct 2019 18:44:47 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 27E0C13319C for ; Mon, 14 Oct 2019 18:44:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sSCg0DCvz3Dl5 for ; Mon, 14 Oct 2019 18:44:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DF7BE975D for ; Mon, 14 Oct 2019 18:44:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9EIikw2084136 for ; Mon, 14 Oct 2019 18:44:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9EIikRC084135 for net@FreeBSD.org; Mon, 14 Oct 2019 18:44:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240608] if_vmx(4): iflib - Panic with INVARIANTS: Memory modified after free (12.1-pre-QA) Date: Mon, 14 Oct 2019 18:44:45 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bugzilla.freebsd@omnilan.de X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 14 Oct 2019 18:44:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240608 --- Comment #6 from Harald Schmalzbauer --- (In reply to Kubilay Kocak from comment #5) As far as I could briefly test (some iperf3 streams), using if_vmx(4) does _not_ lead to panic if frames are <=3D 4k (and interface MTU is set to 9000= ). Also, using if_igb(4) with interface MTU of 9000 and frames as big as 9k is working fine with FreeBSD-12_RC1. Maybe 240700-block can be released if man page mentions the 4k frame size limit? Thanks, -harry --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Oct 14 22:41:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EDBF6142709 for ; Mon, 14 Oct 2019 22:41:49 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sYT8729vz41r6; Mon, 14 Oct 2019 22:41:48 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-vs1-xe36.google.com with SMTP id v19so11867221vsv.3; Mon, 14 Oct 2019 15:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gQsealIHNPXKR9QUMJwddnGF7DzVSRg+QxitU5JJBpA=; b=o/Vr+ufbUpO8F1k6b+3QyJxestr69xJqFRf4Mnb0TW1uPjUzA0sw0iO78iW8jDJGp5 Kuh8zMyMSBUyIClF21lrWbzMtD1b4i46P0hmpXWgzIgZgCRmRXz1i0j1RtpJ0OqoL9bJ KopDAAVkThu3KJP9SK/zGjmcuIKKvXX03OwNdhUVeULTTIp6wMbRslrZgCYA/GLTE2t0 IqbdHuLr1ck5ZwN8NnGPcp5XuQS2JH0W+VvE4u6yMz8vgEr12gZXLN8LE/5gCtkkefMH JBZ0i4AGmacVOh5jRwmwIqZd6FBE+Oroq65ZH70uOkammusPS4uexA4uzW7CnVC88RHi tKKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gQsealIHNPXKR9QUMJwddnGF7DzVSRg+QxitU5JJBpA=; b=OIV8YM/kw6+JTqr9Bo5jVz6JMmmxJCcEvZB54QfZJOvXy0Dc3DPOwc/a+ns4+E8NYI uqNKlL3LDZj9Qy8NkcWDTdFzs3V1Dkc1Opeu0yPxJ5RtmgMOhYFHWDpwrldDGy4Ynivf UQu+yldnr15gXO7Gsp56teF2RdFfb/zxUEHC3So98sjtZLS+RDECCnJiPRLd8hoHYSwq 0oWq4FkQQBV4BupWNJKkfMkTi7cyeu1xnAuMvGFC89tpR4J5/9ng5x1JOGgKJWtNZHtI Wu13+60faLSiNcPG1EhwzT1P9PQBkCcZdW1BCBqhP8aH9YAUkAY4QQMbgmxOK/ia+B0h soYw== X-Gm-Message-State: APjAAAWN5jE6jmunTTXU4CXyHNqpe/VWZDpxxK5tFhFS9LY/loxPErEp MJ/UdmThUDG9yrhg14Xvyv7BkZfsQqlMS/NEDoMFKA== X-Google-Smtp-Source: APXvYqyAfH3sFZLPKYu2L9p9+nHf/46AIKGHtREXsPVvRtpQQhJBQSFXvUMi/Fd0PmWGrDDcIjBjhSUjOVgtPEMMBAo= X-Received: by 2002:a67:fe53:: with SMTP id m19mr7994554vsr.98.1571092907589; Mon, 14 Oct 2019 15:41:47 -0700 (PDT) MIME-Version: 1.0 References: <001e01d50b49$176104d0$46230e70$@gmail.com> <20190516.032012.517661495892269813.hrs@allbsd.org> <20191011174520.GC53377@spindle.one-eyed-alien.net> In-Reply-To: <20191011174520.GC53377@spindle.one-eyed-alien.net> From: Ben Woods Date: Tue, 15 Oct 2019 06:41:36 +0800 Message-ID: Subject: Re: DHCPv6 client in base To: Brooks Davis , "roy@marples.name" Cc: Hiroki Sato , driesm.michiels@gmail.com, freebsd-net@freebsd.org X-Rspamd-Queue-Id: 46sYT8729vz41r6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=o/Vr+ufb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of woodsb02@gmail.com designates 2607:f8b0:4864:20::e36 as permitted sender) smtp.mailfrom=woodsb02@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[6.3.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.69), ipnet: 2607:f8b0::/32(-2.49), asn: 15169(-2.11), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 14 Oct 2019 22:41:50 -0000 On Sat, 12 Oct 2019 at 1:45 am, Brooks Davis wrote: > DHCP is one of the most exposed attack surfaces in existence. We expect > it to take input from explicitly untrustworthy networks and perform > actions as root. It might be OK to import this as a stopgap only > supporting IPv6, but without capsicum or privilege separation (as noted > elsewhere in the thread) it seems unlikely to be a good idea enable it > by default or replace the existing IPv4 dhclient. > > -- Brooks > Hi Brooks, Thanks for the feedback. Roy Marples (the main dhcpcd) has already begun working on privilege separating dhcpcd based on your feedback. Have you or Roy got any thoughts on how the privilege separation might be structured? - main process - network listener - packer interpreter - hook runner and scripts It=E2=80=99s obviously the packet interpreter that is the risky part, but d= oes not need privileges. FreeBSD has the =E2=80=9C_dhcp=E2=80=9D user which I assume could be used f= or running these low privilege tasks? Roy is not intending to work on capsicum support in dhcpcd, but I think once the privilege separation has been done it will be easier to add that support. Regards, Ben --=20 -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Mon Oct 14 22:59:42 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B21FA142E5A for ; Mon, 14 Oct 2019 22:59:42 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 46sYsn1x5fz42XC; Mon, 14 Oct 2019 22:59:41 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 3DBAE3C0199; Mon, 14 Oct 2019 22:59:40 +0000 (UTC) Date: Mon, 14 Oct 2019 22:59:40 +0000 From: Brooks Davis To: Ben Woods Cc: Brooks Davis , "roy@marples.name" , Hiroki Sato , driesm.michiels@gmail.com, freebsd-net@freebsd.org Subject: Re: DHCPv6 client in base Message-ID: <20191014225940.GA34287@spindle.one-eyed-alien.net> References: <001e01d50b49$176104d0$46230e70$@gmail.com> <20190516.032012.517661495892269813.hrs@allbsd.org> <20191011174520.GC53377@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 46sYsn1x5fz42XC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-6.50 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; IP_SCORE(-3.60)[ip: (-9.41), ipnet: 199.48.128.0/22(-4.69), asn: 36236(-3.85), country: US(-0.05)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 14 Oct 2019 22:59:42 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2019 at 06:41:36AM +0800, Ben Woods wrote: > On Sat, 12 Oct 2019 at 1:45 am, Brooks Davis wrote: >=20 > > DHCP is one of the most exposed attack surfaces in existence. We expect > > it to take input from explicitly untrustworthy networks and perform > > actions as root. It might be OK to import this as a stopgap only > > supporting IPv6, but without capsicum or privilege separation (as noted > > elsewhere in the thread) it seems unlikely to be a good idea enable it > > by default or replace the existing IPv4 dhclient. > > > > -- Brooks > > > Hi Brooks, >=20 > Thanks for the feedback. >=20 > Roy Marples (the main dhcpcd) has already begun working on privilege > separating dhcpcd based on your feedback. >=20 > Have you or Roy got any thoughts on how the privilege separation might be > structured? > - main process > - network listener > - packer interpreter > - hook runner and scripts >=20 > It???s obviously the packet interpreter that is the risky part, but does = not > need privileges. >=20 > FreeBSD has the ???_dhcp??? user which I assume could be used for running= these > low privilege tasks? It's worth taking a look at the separation in the existing dhclient. They have chosen to drop privilege in the main program and have a child which retains privilege for sending packets, tweaking interface MTU, and running the script. > Roy is not intending to work on capsicum support in dhcpcd, but I think > once the privilege separation has been done it will be easier to add that > support. The capsicum support in our client is pretty limited so that sounds like a good approach. -- Brooks --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJdpP3bAAoJEKzQXbSebgfA3FIIAJRkgx40QTvVpSoSK1odhiPz NIPN2op8gtLa7TycQYebn4p14UZ3AiXFt9KNffs1cWvhSq45nboTYZ4pgMLh9e0I 0OCTVPPZy9REENcMGFJ1UD+xSUTqvv8SXm7PURnNG9+WFPG5y75xjhA08dWvx9so MT1zw7zt21+92hXztG271IP0JTY31qftWO0gly4kK1KI4LWVQkgZRXeT/f+ca7W2 iR2m32Uqs4SeNs8zUPoq9eB96qvGkpRRN8bJ9fY1eEmPsNynPuFcw1Ub4ldHomE7 tLDjBFdFi3dwB7Jl+u+g8lDdauwxXXQsag5jW0mDjjbwlVoovLOWNjW1QroVs5Q= =aL3U -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-net@freebsd.org Mon Oct 14 23:04:50 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B44C1430BB for ; Mon, 14 Oct 2019 23:04:50 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua1-x941.google.com (mail-ua1-x941.google.com [IPv6:2607:f8b0:4864:20::941]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sYzj4XQjz42rZ; Mon, 14 Oct 2019 23:04:49 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua1-x941.google.com with SMTP id k24so5469093uag.10; Mon, 14 Oct 2019 16:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4eqHFaNKbzwXM0DGIxU1q8x5nFPvtsE5vhKhZ6GU0Rs=; b=XpNXYqh4JSSvpgyRz7ilFN4oyUaTE4tiRUG6llAe0snRFExBprFhtcd7rtyhrtCFmD 3IxIJX/BmdN0O5hCH1++nEBETzNoTUsF6ySCqhk7Fwvd7eF2cXeIk4CIwA/AKC2NOD+6 YJMd5hdl5VE+xqDCHTDhgFxtdtJ33ewTRFT0N+SkbtU8U3yvQPttO9SCZHmQa80Ld+3+ 6QHi+kez2Z2uR2XjS2gKwhc4U7ah1t2dLLS0f0Mu/b0B6A7JpDiym10JGsDYad+0AdeN yBXW26RklD7yhZaYfPhigPofzXVwKo9QnfU9MPI/e4prqqKwP2ypeSNEcJ+QcN3O54vD QD1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4eqHFaNKbzwXM0DGIxU1q8x5nFPvtsE5vhKhZ6GU0Rs=; b=rmOm/peZPE6farCtcFhBxydWBJKl9AkdMayk6JU/XlQEeifvKE2txIUbB6nod2/mUH meKNJid+FGO6uv++b7E37VXv+OiAmo9bCzCiqRwHHW6p6RvqTqLq2pRusfKHZkeT8AKX EQi8gt4dZVFK5j5Fo1AI/VYgVdtHutgqBhjFces9VzEdhqWiwrgbMGUxlQqJBfiu8+It KHdy6c9Gkbku52BuXpnOZM4bq14jqHlWNHl3D/4DCXhEnipySdoAYbkw4zkWKPK1qBTB SN1BYZieW+TgDK8HRLYl8AP4fhd28G4F1IW+WVdm+t/xXzyhkGoCUvEJQhatarUwQZZY eyWg== X-Gm-Message-State: APjAAAXRN4aXyfD00LpnnJQtc+OkHJolxrantCw8M7SgWSo6rx/r7BhZ NLyh6DRKiEtIfG7jQVQEcaVZTYRryn+MoCcq7D0= X-Google-Smtp-Source: APXvYqx2BIvvugqBuNKepwU4ATrLsrLKA/IF+L0sLiQVHrzRaDB/2f6fiE9961hvjMR8r5PADutksY8eLURKbEeSlHo= X-Received: by 2002:ab0:30f4:: with SMTP id d20mr11476268uam.71.1571094288421; Mon, 14 Oct 2019 16:04:48 -0700 (PDT) MIME-Version: 1.0 References: <001e01d50b49$176104d0$46230e70$@gmail.com> <20190516.032012.517661495892269813.hrs@allbsd.org> <20191012.044034.19725945241254130.hrs@allbsd.org> In-Reply-To: <20191012.044034.19725945241254130.hrs@allbsd.org> From: Ben Woods Date: Tue, 15 Oct 2019 07:04:37 +0800 Message-ID: Subject: Re: DHCPv6 client in base To: Hiroki Sato Cc: driesm.michiels@gmail.com, freebsd-net@freebsd.org, hrs@freebsd.org, roy@marples.name X-Rspamd-Queue-Id: 46sYzj4XQjz42rZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=XpNXYqh4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of woodsb02@gmail.com designates 2607:f8b0:4864:20::941 as permitted sender) smtp.mailfrom=woodsb02@gmail.com X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.90), ipnet: 2607:f8b0::/32(-2.49), asn: 15169(-2.11), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 14 Oct 2019 23:04:50 -0000 On Sat, 12 Oct 2019 at 3:42 am, Hiroki Sato wrote: > I do not have a strong objection on dhcpcd (I am using it on some of > my FreeBSD boxes actually) but let me explain the reason why I chose > wide-dhcp as the candidate. That is because it is a small, > functional DHCPv6-only implementation. I am planning to rewrite it > to add the missing bits and adjust it for a tighter integration with > kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum. I > feel dhcpcd (or others) is too big for that purpose. One of the main attractions of dhcpcd is that it has been actively maintained for many years, and is already integrated into NetBSD and DragonFlyBSD, ensuring it will continue to be maintained. Whilst they don= =E2=80=99t get offered often, Roy appears quite open to accepting code contributions upstream. On NetBSD and DragonFlyBSD, Roy has also submitted changes to the kernel to introduce tighter integration with dhcpcd. Since receiving feedback from yourself and brooks, Roy has already begun the work to implement privilege separation in dhcpcd. Whilst Roy doesn=E2=80=99t currently plan on working on capsicum support, I= believe adding capsicum support will be easier once privilege separation is completed. I believe Roy would be very open to receiving these contributions upstream (with appropriate ifdefs for operating systems which don=E2=80=99t support capsicum). IMHO, the directions of further developments of IPv6 functionality on > FreeBSD, NetBSD (dhcpcd), OpenBSD (slaacd + others), and DragonFly > BSD (dhcpcd) have already been diverged. For RFC 7217 I already have > an in-kernel implementation (not committed yet), and I am also > working on SeND (RFC 3971, not directly related to DHCPv6 though). > My goal is to integrate these small implementations into the base > system and make them possible to work together. So for DHCPv6, I > think an implementation of only DHCPv6 is the best. > > If people want a more feature-rich implementation or the same one on > other systems, they can still use dhcpcd or ISC's dhclient even after > the import. > > Of course this assumes that wide-dhcp works to some degree. If it > does not, importing it to the base system does not make sense. I > have used it in various scenarios for a long time such as RA + O flag > on native IPv6 over Ethernet, DHCPv6-PD over PPPoE/L2TP, and others > which are complex enough, and understand what works and what is > missing (poor DUID format support, for example). The popular way to > use DHCPv6 is IA_PD, and wide-dhcp works well with it. > > So I have a question. What is missing feature in wide-dhcp which you > are concerned about? I know some, but it has most of the basic > functionality of DHCPv6 and I think it is enough as a minimal > implementation for the base system. My primary reason is that it is > just for DHCPv6 as mentioned earlier and I believe it is maintainable > in the base system. I would like to know other people's opinion if > there is something critical. > > -- Hiroki > Whilst I don=E2=80=99t have anything against wide-dhcp, I personally prefer integrated IPv4/IPv6 tools. ping vs ping6 for example would be better integrated in my opinion. The =E2=80=9Cfeature=E2=80=9D that I believe is missing from wide-dhcp is a= ctive maintenance. I believe that dhcpcd has the right license, adoption elsewhere, and active maintenance to make it successful for FreeBSD in the long run. Importing dhcpcd to the contrib/ tree means the maintenance to update it regularly is greatly simplified (simply import the newer upstream version and test). Anyone can submit any improvements / fixes upstream to Roy. I do agree that we should minimise excess code in FreeBSD also, but I believe that once dhcpcd has been proven to work, we could look at removing dhclient and rtsold. Agree with your comment that before this occurs, we should check what features / security improvements / tighter integration have been added along the way, and ensure they make their way into dhcpcd. If dhcpcd was imported, I believe this would come with a phased approach: - import dhcpcd, but leave dhclient and rtsold as default - add kernel support for tighter dhcpcd integration - switch defaults to dhcpcd, but leave dhclient and rtsold as available - remove dhclient and rtsold Regards, Ben --=20 -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Mon Oct 14 23:52:32 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E054143A94 for ; Mon, 14 Oct 2019 23:52:32 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sb2l211mz44L7; Mon, 14 Oct 2019 23:52:31 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-vs1-xe2e.google.com with SMTP id p13so11940412vsr.4; Mon, 14 Oct 2019 16:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DXLZ7Btm5o6xAoc6DXMSIjbREvF6usjuu8w3n0ki3/8=; b=g7nbz+Yjgcf98CbKSW5SZ0joqfPIPbfAjmwDiL+8jBcrTAQ2MoL8HMCTCFNgbc2Xdd G4sL3Q9bvY2vE+XLL43BDxdFJgpG25D9FziBL+0sE+7stry1mc0wWONyyaZzJ/sg8/dG zqi8C2cv0BzU8yVG1Z6FbcEPKDFLWsQVqogHS2g2/VnmoE5HF8v3Ms8rkTZrnBZFxTP/ i90Z5/ikVT+JoJBYS2TzYI5sitcMBA04TrDGurOtaiC23W0M0S1TGThO+b3ZYUHzakSu eN9eTowNw75mSsI6s8KWg8inQ+x7kIFear+57Q7DfzO20T38AAzn2U1Lz5GuGphVPnhG PmXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DXLZ7Btm5o6xAoc6DXMSIjbREvF6usjuu8w3n0ki3/8=; b=M9dDVKG9ao68WVBSPF4LpaaALZPX1y4yZPwdq5s3J7UaKPcYdCBX5xEFS8fIGWG2R+ ewPKBQYak5fCkc0NR/TlhVZe0FMCYJpDdq8oaJ3zrSR69byg7UbGnEAQBigHRd8VAVt+ Cf9Q9rdQYS3H2CbA8QwgiHjejg65odAkAmGKoBuZx+HyavatFLx6RuYs+zHLC1ciIeV4 m0XlsROzuu0rUS35HKIlpNuVpXZVbk4th1Ea0pM4QWnZ51XNVRsR7IxfLgdLVXnVBE2K AKOdBfOGnusdsvlEGvjvSxvG/smIJrY2vUIfIaVgeCZuZtCVhwA+0uiK5bx7ASo0W/8j woXA== X-Gm-Message-State: APjAAAWiPmr/eyl3DUhOiBNR0BTYkeU49d+esrzzmwPJ9iUOS6sxvU5Z PYhnmUCOU4EDzx8HHq3bAAleiuVwsvyermiIpp8= X-Google-Smtp-Source: APXvYqzkB6eEFyLKpY9HrDg2ewBX5nU7yfX4Ae4XYbwBCUyV4RxngtMazWBdwrjlubrycjQ9kMLxXHt/3PzT9PNITRY= X-Received: by 2002:a67:fe53:: with SMTP id m19mr8121759vsr.98.1571097149523; Mon, 14 Oct 2019 16:52:29 -0700 (PDT) MIME-Version: 1.0 References: <20191014.043209.919156653743886519.hrs@allbsd.org> In-Reply-To: <20191014.043209.919156653743886519.hrs@allbsd.org> From: Ben Woods Date: Tue, 15 Oct 2019 07:52:17 +0800 Message-ID: Subject: Re: DHCPv6 client in base To: Hiroki Sato Cc: brooks@freebsd.org, driesm.michiels@gmail.com, freebsd-net@freebsd.org, hrs@freebsd.org, julian@freebsd.org, roy@marples.name X-Rspamd-Queue-Id: 46sb2l211mz44L7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=g7nbz+Yj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of woodsb02@gmail.com designates 2607:f8b0:4864:20::e2e as permitted sender) smtp.mailfrom=woodsb02@gmail.com X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[e.2.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.54), ipnet: 2607:f8b0::/32(-2.49), asn: 15169(-2.11), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 14 Oct 2019 23:52:32 -0000 On Mon, 14 Oct 2019 at 3:34 am, Hiroki Sato wrote: > How do you want to proceed the discussion? I sent my view and made > myself clear that importing dhcpcd into the base system as-is is not > a good idea. What is your answer to my concerns? I also agree with > Brooks about a need for sandboxing before the import if it will > happen. Do you have any plan to add changes to the imported dhcpcd? To address your comments about duplicate functionality, and FreeBSD only lacking DHCPv6 functionality at the moment - my thoughts are we should import dhcpcd as a whole, with the plan to ultimately remove dhclient and rtsold to remove duplication of code/functionality. This would likely follow a phased approach: - import dhcpcd, but leave dhclient and rtsold as default - add kernel support for tighter dhcpcd integration - switch defaults to dhcpcd, but leave dhclient and rtsold as available - remove dhclient and rtsold Roy Marples (upstream dhcpcd maintainer) is already working on privilege separation for dhcpcd, following feedback from yourself and brooks. Whilst he is not planning on working on capsicum support at this point, I believe this would be easier to add after the privilege separation work is done. What are your thoughts whether the import could occur before privilege separation, or after privilege separation but before capsicum, or only after both? My thoughts were that if it off by default then users are not affected unless they make the conscious decision to enable dhcpcd. This would provide the DHCPv6 functionality in base (with network.subr integration) for users who decide they need it (myself for example). Suggest the switch to default would require one or both of these security mitigations. We could include commentary about the current state of security mitigations in the handbook / rc.conf manpage updates to assist users in making a decision? And, I think there is common mistake about how to invoke dhcpcd in > D22012. DHCPv6 client should be invoke upon RA with O-flag received, > not invoked independently or by devd(8) upon a link-up event. I do > not want people to configure ifconfig_IF_ipv6=3D"DHCP". What people > should be aware is if they want to allow receving RA. Whether DHCPv6 > is required or not should be controlled by RA, not configuration on > the host side. Also, DHCP-PD shuold be handled in rc.d script > framework in some way. Doing something similar to IPv4 DHCP client > is not enough, and having both rtsold and dhcpcd is just confusing. One of the reasons I worked on this change and submitted it for review was for exactly this feedback - what would the rc.conf and network.subr integration look like? So thank you for this feedback. Given that dhcpcd replaces both rtsold and dhclient, I believe network.subr and devd are the right place to initiate dhcpcd. If enabled, it needs to start once the interface comes up to perform both router solicitation and then subsequently DHCPv6 if instructed by the router. Regarding rc.conf, I believe we need to develop an rc.conf user interface that makes this clear that all of the above behaviour will be performed. Rather than ifconfig_IF_ipv6=3D=E2=80=9CDHCP=E2=80=9D do you think ifconfig_IF_ipv6=3D=E2=80=9Caccept_rtadv=E2=80=9D is more clear? The network.subr and rc.conf options I proposed were pulled from DragonFlyBSD, with the options for background_dhclient and synchronous_dhclient added to also support dhcpcd. Doesn=E2=80=99t mean the= y are right, or that we have to accept them, just giving context. I am very open to changing this if it makes sense. I want to continue discussion about what is the best or better > direction instead of going ahead with D22012. > > -- Hiroki I think there is value in discussing what it would look like to import dhcpcd as a whole (with the above migration phases in mind), mainly focusing on the libexec/rc/ elements such as network.subr, devd, and rc.conf. Would you be willing to further the discussion of this? Suggest that if so, D22012 would be a good place to have it. Regards, Ben > -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Tue Oct 15 01:54:30 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5E6621477EE for ; Tue, 15 Oct 2019 01:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46sdlV1sKCz4PXk for ; Tue, 15 Oct 2019 01:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3F79E1477ED; Tue, 15 Oct 2019 01:54:30 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3F3C71477EC for ; Tue, 15 Oct 2019 01:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sdlV0xfrz4PXj for ; Tue, 15 Oct 2019 01:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0305BF782 for ; Tue, 15 Oct 2019 01:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9F1sTaY079221 for ; Tue, 15 Oct 2019 01:54:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9F1sTZW079220 for net@FreeBSD.org; Tue, 15 Oct 2019 01:54:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 237568] nginx causes host panic when closing socket descriptor? Date: Tue, 15 Oct 2019 01:54:27 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: koobs@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: assigned_to keywords resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 15 Oct 2019 01:54:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237568 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|net@FreeBSD.org |koobs@FreeBSD.org Keywords|needs-qa | Resolution|--- |Overcome By Events Status|Open |Closed --- Comment #4 from Kubilay Kocak --- @rlwestlund Please re-open the issue if it becomes reproducible once more --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Oct 15 02:17:40 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6281F14AE39 for ; Tue, 15 Oct 2019 02:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46sfGD2024z4TDf for ; Tue, 15 Oct 2019 02:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 443E814AE38; Tue, 15 Oct 2019 02:17:40 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 43F6314AE37 for ; Tue, 15 Oct 2019 02:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sfGD152Kz4TDd for ; Tue, 15 Oct 2019 02:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0A002FB26 for ; Tue, 15 Oct 2019 02:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9F2HdUt057275 for ; Tue, 15 Oct 2019 02:17:39 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9F2HdoQ057271 for net@FreeBSD.org; Tue, 15 Oct 2019 02:17:39 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240608] if_vmx(4): iflib - Panic with INVARIANTS: Memory modified after free (12.1-pre-QA) Date: Tue, 15 Oct 2019 02:17:39 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 15 Oct 2019 02:17:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240608 --- Comment #7 from Kubilay Kocak --- (In reply to Harald Schmalzbauer from comment #6) We can leave/remove the blocker depending on the necessary/chosen resolutio= n. In my opinion though, crashes (panics) should be resolved whether or not th= ere are intended limits in specific scenarios, ie: "all crashes are bugs" --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Oct 15 10:17:14 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3A7E615A78D for ; Tue, 15 Oct 2019 10:17:14 +0000 (UTC) (envelope-from vm.finance2@gmail.com) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46srvY1llkz414K for ; Tue, 15 Oct 2019 10:17:13 +0000 (UTC) (envelope-from vm.finance2@gmail.com) Received: by mail-io1-xd31.google.com with SMTP id w12so44531762iol.11 for ; Tue, 15 Oct 2019 03:17:13 -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=CAE5jkHCS/TYbHt0TgBNcq3AGL4Eb8aInuwxIUgsRQI=; b=YPxh6+yv/Z2IFiCmSceOzCpTGRgIK9Nl7isy0zprE9JbsU670bI6StMLjWn9f5g167 WMks1hulSE8OWIy3dPmkPuNmiy+iix5DJ3a+oA6Ci5/DkQCmWak2JGe341B2UdMY1iLY BJR6gBU7F0UFWM0YP0dk4FJYGbTFAJlw3HEAxvz8SvXIOPJSfXuCS00LlX8faXJppXqG 7X22X2p2Ifk0DaszUSzbn9vVxGoy7UX4jcRRYWcj24fMcM7X8gFwuFxVTio8LrS92Ccy c3+ahErx1so02qM9Ymw4lDHE+8abt95Vu7HHZGM/xIU+ZhuLzcT55UF7TNePl/odAVpo FIew== 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=CAE5jkHCS/TYbHt0TgBNcq3AGL4Eb8aInuwxIUgsRQI=; b=jeqokgZpmm5XwboN5g+dQk0KpxxS+wi6HUYTSNzspobZ3pNrUqDlpcnUnDyTIeWXCs agw6qqJCVHVGd7ZuMQ5tnbpvfpshDcdPcIGX2PZzII3ucHhEWl2jJmCY30b0Ug+VoBDa Q0zbzOZHGHIhGxaKi3ji1vjIUCS/b9yaxUWPvERbs2Hg8/gBs3p/n7cvWwo8bhI45M2G bEXZZWP5efFTHdede4Kipitz/s9W6b1GeBQ8oFS7NpYmsegnQZ5C+JnDNSADoCdWj9b7 ctTsJoZSVVr3MpKEL1Bam6rb7UGfI+Con5AZtj8fPFOodqT4Oe3cbKNFcP8pTJb8h9sC ncYA== X-Gm-Message-State: APjAAAWJdq3HfOcVKcq9HM/alm5FB1Gid0MbOls7EStlQ12rkQfqlMkI AGCywXlzeQGVSXAfscX4dq9QtYQD/wW++EVD/REycVqE X-Google-Smtp-Source: APXvYqzDPqcfr1LWtrla3NoYkUWAdbHArwg9vlvfcDFaV63WgztqHMMvp29C7jlASmd995BcgqyRoswFwSKkoMxyL0k= X-Received: by 2002:a02:69cd:: with SMTP id e196mr21133269jac.88.1571134632180; Tue, 15 Oct 2019 03:17:12 -0700 (PDT) MIME-Version: 1.0 From: vm finance Date: Tue, 15 Oct 2019 03:17:01 -0700 Message-ID: Subject: logs/traces To: freebsd-net X-Rspamd-Queue-Id: 46srvY1llkz414K X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=YPxh6+yv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vmfinance2@gmail.com designates 2607:f8b0:4864:20::d31 as permitted sender) smtp.mailfrom=vmfinance2@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; IP_SCORE(0.00)[ip: (-6.11), ipnet: 2607:f8b0::/32(-2.48), asn: 15169(-2.11), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.3.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 15 Oct 2019 10:17:14 -0000 Hi, Could someone please guide me on how to turn on tracing/log? I would like to follow/track how packets go in/out of TCP code block... Please let me know what knobs are available to achieve this. Thanks for any pointers. From owner-freebsd-net@freebsd.org Tue Oct 15 13:00:36 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 77D8315E2C1 for ; Tue, 15 Oct 2019 13:00:36 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail.allbsd.org (mx.allbsd.org [IPv6:2001:2f0:104:e001::41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.allbsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46swX160qxz49jh; Tue, 15 Oct 2019 13:00:33 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail-d.allbsd.org ([IPv6:2409:11:a740:4700:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id x9FD030g043943 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) (Client CN "/CN=mail-d.allbsd.org", Issuer "/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3"); Tue, 15 Oct 2019 22:00:14 +0900 (JST) (envelope-from hrs@allbsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=allbsd.org; s=20190220; t=1571144422; bh=z5fZKxvkKDq9VGNiKf+yFfoq1bPg90lcES2G+WGpFxs=; h=Date:To:Cc:From:In-Reply-To:References; b=bzLIdVAnN7JuSS/DVtCGo6qBuQWqLuibTzIn2PfKVSv7tMtHlfVaWStEJuv/FrCqj YA+76e0IX9CdDx9cZV84ZoxUzkZR83DQ5uPqMYH4Oerd+4SrpLuZC2pMw9MzAXU4u4 yoqL8Knw+cY1gAUN9Kt7v62SFW1xgFZ1C89HoGPU= Received: from alph.d.allbsd.org ([IPv6:2409:11:a740:4700:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id x9FCxv0Y058548 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 15 Oct 2019 21:59:58 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from localhost (localhost [[UNIX: localhost]]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id x9FCxrok058544; Tue, 15 Oct 2019 21:59:57 +0900 (JST) (envelope-from hrs@allbsd.org) Date: Tue, 15 Oct 2019 21:57:32 +0900 (JST) Message-Id: <20191015.215732.1618848784026596315.hrs@allbsd.org> To: roy@marples.name Cc: woodsb02@gmail.com, hrs@freebsd.org, brooks@freebsd.org, julian@freebsd.org, driesm.michiels@gmail.com, freebsd-net@freebsd.org Subject: Re: DHCPv6 client in base From: Hiroki Sato In-Reply-To: References: <20191014.043209.919156653743886519.hrs@allbsd.org> X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 26.2 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Tue_Oct_15_21_57_32_2019_580)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [IPv6:2001:2f0:104:e001:0:0:0:41]); Tue, 15 Oct 2019 22:00:22 +0900 (JST) X-Rspamd-Queue-Id: 46swX160qxz49jh X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=allbsd.org header.s=20190220 header.b=bzLIdVAn; dmarc=none; spf=pass (mx1.freebsd.org: domain of hrs@allbsd.org designates 2001:2f0:104:e001::41 as permitted sender) smtp.mailfrom=hrs@allbsd.org X-Spamd-Result: default: False [-5.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[allbsd.org:s=20190220]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[allbsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[allbsd.org:+]; MID_CONTAINS_FROM(1.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7514, ipnet:2001:2f0::/32, country:JP]; FREEMAIL_CC(0.00)[gmail.com]; IP_SCORE(-2.35)[ip: (-9.18), ipnet: 2001:2f0::/32(-4.38), asn: 7514(1.80), country: JP(-0.00)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 15 Oct 2019 13:00:36 -0000 ----Security_Multipart(Tue_Oct_15_21_57_32_2019_580)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roy Marples wrote in : ro> On 13/10/2019 20:32, Hiroki Sato wrote: ro> > Ben Woods wrote ro> > in ro> > : ro> > wo> On Fri, 11 Oct 2019 at 08:32, Ben Woods ro> > wrote: ro> > wo> As promised, I have completed my initial work to import dhcpcd ro> > into FreeBSD ro> > wo> base, and it is ready for review, testing and comment at the link ro> > below. ro> > wo> https://reviews.freebsd.org/D22012 ro> > wo> ro> > wo> As per the comment from brooks@, I have opted to have it installed ro> > in ro> > wo> parallel with dhclient (which remains the default). ro> > How do you want to proceed the discussion? I sent my view and made ro> > myself clear that importing dhcpcd into the base system as-is is not ro> > a good idea. What is your answer to my concerns? I also agree with ro> > Brooks about a need for sandboxing before the import if it will ro> > happen. Do you have any plan to add changes to the imported dhcpcd? ro> ro> Sorry if it was not clear. The discussion involves what is the ro> required acceptance for Priviledge Seperation because this is quite ro> new to me. ro> ro> My current idea is to open DHCP, IPv6RA and DHCP6 ports, chroot, drop ro> privs and fork. This concept is pretty standard thus far. These are ro> listening ports only and will dry-run any received message through ro> dhcpcd's two commons paths: ro> 1) extract address and routing information without applying it ro> 2) environment option generation from the whole message A typical separation is three process model which contains processes for 1) sending/accepting packets (and parsing them), 2) state machine for each protocol handling, and 3) global namespace access (file, routing socket, network interface state, etc). The superuser privilege can be dropped in 1) and 2) completely. 1) and 3) communicate with 2) on demand or event-driven basis. 1) do not communicate directly with 3). Protocol-specific routines are in 1) and 2)---the former handles its wire-format, and the latter deals with protocol-specific state machines. However, this is often an overkill for a small, single-protocol network daemon. A two process model which contains one for 1)+2) and another for 3) above is used in sbin/dhclient, for example. I think this separation is the minimum level. 3) performs privileged tasks such as ioctls for network interfaces. I believe the three process model is appropriate for dhcpcd because of the nature of multi-protocol support. Parsing is one of the attack surfaces. For instances, a dhcp6_findoption() loop in dhcp6_recv() should be in process 1 and changes of D6_STATE(ifp) should be managed in process 2. The current dhcp6_bind() directly uses dhcp6_findmoption() to extract options from a DHCP message on demand and also directly accesses the global namespace by using dhcp6_writelease(ifp). These packet inspection and file access can be replaced with IPC requests to process 1 or 3 in the model, and it can be realized without a big structural change to the original logic in dhcp6.c (though it requires a certain amount of changes to the current code). In the ideal world everything should work fine and this kind of separation just sounds to make the program complex unnecessary, but an incomplete separation between the possible attack surfaces and access to the global namespace does not provide a good security even if the superuser privilege dropped. Note that these are just my own view, not a requirement for something nor feature request. I think lack of privsep must be considered if dhclient is replaced, but I also think replacing dhclient is beyond the discussion of DHCPv6. Anyway, You might want to create a new email thread for sandboxing of dhcpcd on FreeBSD if you want to continue to discuss it. Probably developers with more expertise in security can make a comment. -- Hiroki ----Security_Multipart(Tue_Oct_15_21_57_32_2019_580)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMgEABMKAC0WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXaXCPA8caHJzQGFsbGJz ZC5vcmcACgkQ27B9xm8fc38CIgII/hD4mR1YsB/K7QbwPZLR7o6PfASISWjM/L+s xxNG5lLgGynT3R/n3djH8jiedsI6dRspHAhbaLO8ociGbPHbl4kCCQElqiwSOwWN 1++Z4kyMrb2GWuILrAdZXctcVAsAZ8l9sXNkjhVJNQ5UiE6WuCTdvSec9FFi4F/0 uXoy5hgsSKZGeg== =DapJ -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct_15_21_57_32_2019_580)---- From owner-freebsd-net@freebsd.org Tue Oct 15 14:22:44 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 55991148709 for ; Tue, 15 Oct 2019 14:22:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46syLr1Z54z4HMX for ; Tue, 15 Oct 2019 14:22:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 35B10148708; Tue, 15 Oct 2019 14:22:44 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 35716148707 for ; Tue, 15 Oct 2019 14:22:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46syLr0gmzz4HMW for ; Tue, 15 Oct 2019 14:22:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EEB031FDE9 for ; Tue, 15 Oct 2019 14:22:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9FEMh5Y087983 for ; Tue, 15 Oct 2019 14:22:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9FEMhSP087948 for net@FreeBSD.org; Tue, 15 Oct 2019 14:22:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241162] Panic in closefp() triggered by nginx Date: Tue, 15 Oct 2019 14:22:44 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: amdmi3@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 15 Oct 2019 14:22:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241162 --- Comment #4 from Dmitry Marakasov --- I've built 12.0-RELEASE kernel with the patch from 239893, but this didn't help. However, I've discovered what has triggered the panic - I have uwsgi behing nginx setup on that box, and the panic appears every ~1-3 hours if sendfile is enabled in uwsgi (sendfile is disabled in nginx). I'll try upda= ting to 12.1-RC now --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Oct 15 15:22:01 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B1F4A14A6DE for ; Tue, 15 Oct 2019 15:22:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46szgF4MCFz4MKb for ; Tue, 15 Oct 2019 15:22:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 9586F14A6DC; Tue, 15 Oct 2019 15:22:01 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 954D314A6DA for ; Tue, 15 Oct 2019 15:22:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46szgF3YkSz4MKZ for ; Tue, 15 Oct 2019 15:22:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5F178208D8 for ; Tue, 15 Oct 2019 15:22:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9FFM1Wu086999 for ; Tue, 15 Oct 2019 15:22:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9FFM1sI086877 for net@FreeBSD.org; Tue, 15 Oct 2019 15:22:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241162] Panic in closefp() triggered by nginx Date: Tue, 15 Oct 2019 15:21:59 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: Mark.Martinec@ijs.si X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 15 Oct 2019 15:22:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241162 Mark.Martinec@ijs.si changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Mark.Martinec@ijs.si --- Comment #5 from Mark.Martinec@ijs.si --- Similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222259 (also nginx+uwsgi+sendfile), although that was fixed in 2017. --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Oct 15 21:56:43 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 202A2155816 for ; Tue, 15 Oct 2019 21:56:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46t8Qg056mz3QPc for ; Tue, 15 Oct 2019 21:56:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 00F84155815; Tue, 15 Oct 2019 21:56:43 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 00BA4155814 for ; Tue, 15 Oct 2019 21:56:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46t8Qf6FtXz3QPZ for ; Tue, 15 Oct 2019 21:56:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BB4FE250B7 for ; Tue, 15 Oct 2019 21:56:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9FLugLs017367 for ; Tue, 15 Oct 2019 21:56:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9FLugwQ017366 for net@FreeBSD.org; Tue, 15 Oct 2019 21:56:42 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240320] ixgbe: EEE state change causes core dump on X552 Date: Tue, 15 Oct 2019 21:56:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, crash, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@freebsd.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: cc 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.29 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, 15 Oct 2019 21:56:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240320 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erj@freebsd.org Assignee|net@FreeBSD.org |erj@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Oct 16 01:09:50 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CF81215859E for ; Wed, 16 Oct 2019 01:09:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46tDjV5D66z43Wv for ; Wed, 16 Oct 2019 01:09:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id B330215859D; Wed, 16 Oct 2019 01:09:50 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B2ED015859C for ; Wed, 16 Oct 2019 01:09:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tDjV4LDLz43Ws for ; Wed, 16 Oct 2019 01:09:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 78A5D27274 for ; Wed, 16 Oct 2019 01:09:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9G19oML003185 for ; Wed, 16 Oct 2019 01:09:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9G19oi5003182 for net@FreeBSD.org; Wed, 16 Oct 2019 01:09:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241162] Panic in closefp() triggered by nginx (uwsgi with sendfile(2) enabled) Date: Wed, 16 Oct 2019 01:09:49 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: cc see_also short_desc bug_severity 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.29 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, 16 Oct 2019 01:09:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241162 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glebius@FreeBSD.org, | |kbowling@freebsd.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 398 | |93, | |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 222 | |59 Summary|Panic in closefp() |Panic in closefp() |triggered by nginx |triggered by nginx (uwsgi | |with sendfile(2) enabled) Severity|Affects Only Me |Affects Some People --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Oct 16 01:10:37 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1ABB0158686 for ; Wed, 16 Oct 2019 01:10:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46tDkN6tpxz43fB for ; Wed, 16 Oct 2019 01:10:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id EC725158685; Wed, 16 Oct 2019 01:10:36 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC2C2158684 for ; Wed, 16 Oct 2019 01:10:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tDkN5vXVz43f8 for ; Wed, 16 Oct 2019 01:10:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id AF4BA27294 for ; Wed, 16 Oct 2019 01:10:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9G1Aan8005356 for ; Wed, 16 Oct 2019 01:10:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9G1AaGx005352 for net@FreeBSD.org; Wed, 16 Oct 2019 01:10:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241162] Panic in closefp() triggered by nginx (uwsgi with sendfile(2) enabled) Date: Wed, 16 Oct 2019 01:10:36 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 16 Oct 2019 01:10:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241162 --- Comment #6 from Kubilay Kocak --- (In reply to Dmitry Marakasov from comment #4) @Dmitry Could you attach the nginx / uwsgi configurations, as an attachment, sanitized if necessary, that reproduce the issue --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Oct 16 01:11:43 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9948715885C for ; Wed, 16 Oct 2019 01:11:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tDlf69RCz43xW for ; Wed, 16 Oct 2019 01:11:42 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-oi1-x22d.google.com with SMTP id k9so18585897oib.7 for ; Tue, 15 Oct 2019 18:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qaF+CzOoaiM7Q/VLjFAtbpoegDMiEOVX0MRAWZzBzR8=; b=aquY+L5Lwmu7XCExj1ds0G0npjaH1nXaFB71ljPEy9x4gREf8AAJXZOSkFh+pnn4bv 3RkV1oY7jjBL2MSXgXAJvSJNYrLzk3I7Py7gPoCdExk/gVh0hryUd9foS2WLQ3k3cAbP eTcyObTsVD4zKM2pHhup4hJ1tC1JXb/PhKNjMHL5urxxt4Dvr9oYCUNUz7uLCwsgnuJe RUbP7+1i9rvH5zCohRHZGikkf6KUytOHde9w5MoxE0708EGkUIZMIfXFMvdClQXeHWZ6 of4IyRAKCT8dNKbuMSc0NIHPIWufP2kRbPi8NcpovHj1fE15mY9Vg6duu5j10zSxfh8O t1ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qaF+CzOoaiM7Q/VLjFAtbpoegDMiEOVX0MRAWZzBzR8=; b=ADeN5eD8+ldEcHcen7Cj5t8wDnwi1QqodGjooUI3MQN/skGglobrMqXAXx7qW+nJ58 7TFbCFPgePaCGoTvjRmgACjiLb3BKivnz6g/2byoFJ59q80XX03KlYOoszVLyEPfIBUB BC6MSURW32clNjwdszVp2WGM6ddWfC3zWMUUzmticUgP5ChE5WUiXgUKmpVBBpRekP6s C2jhS+ZpDI2ohgJVilmVHBKkNKeX78YbQ38aNB7FBfGaHj9owS3gBZ/kbTwNLNc/HrWX hjz9gXU3icl9jS9BUkoF11xjnLYTmPZ3j4VydpUt4BR/mLYFhex8MrecjliIAPR+22JM V/mQ== X-Gm-Message-State: APjAAAW8gnfRSJL18nFJgjXH+dCzOy5q4NDjNt2gMPQj27acEwkROopp hrQ65vcjvECH4pd3HtmQf5RuotWcmOdQfqAxUF0= X-Google-Smtp-Source: APXvYqxg62bgo+JqAMr8GGIU6BWpsmWLIQ3A/RQFT+3IFNn4STossfxJNF2AJacG6JNSJIeoA+iq+mmsTPWUGRmRtOE= X-Received: by 2002:a05:6808:687:: with SMTP id k7mr1199308oig.133.1571188301398; Tue, 15 Oct 2019 18:11:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Oberman Date: Tue, 15 Oct 2019 18:11:21 -0700 Message-ID: Subject: Re: logs/traces To: vm finance Cc: freebsd-net X-Rspamd-Queue-Id: 46tDlf69RCz43xW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=aquY+L5L; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::22d as permitted sender) smtp.mailfrom=kob6558@gmail.com X-Spamd-Result: default: False [-1.70 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; IP_SCORE(0.00)[ip: (-7.79), ipnet: 2607:f8b0::/32(-2.48), asn: 15169(-2.10), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 01:11:43 -0000 Use tcpdump(1) and/or net/wireshark(5). See man tcpdump and pcap-filter for usage details. wireshark can analyze files collected by tcpdump and dissect the packets. It can also do packet capture, itself. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Tue, Oct 15, 2019 at 3:17 AM vm finance wrote: > Hi, > > Could someone please guide me on how to turn on tracing/log? > > I would like to follow/track how packets go in/out of TCP code block... > Please let me know what knobs are available to achieve this. > > Thanks for any pointers. > _______________________________________________ > 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 Oct 16 02:15:40 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF077159AC7 for ; Wed, 16 Oct 2019 02:15:40 +0000 (UTC) (envelope-from vm.finance2@gmail.com) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tG9R5xXtz46qk for ; Wed, 16 Oct 2019 02:15:39 +0000 (UTC) (envelope-from vm.finance2@gmail.com) Received: by mail-io1-xd29.google.com with SMTP id v2so51629807iob.10 for ; Tue, 15 Oct 2019 19:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pnWwC3OEtJp4qDh3ydbFeFB9cPwe6pLry5NZ3z32/bg=; b=dcuGeSG6HTT81aXpS8a/7gUpPDfBnuurlAgSJHMIMqh2DqSfknfRUbi9XiEdJvPPy4 U99T2m/qVQIIXnrrEctNOJHo0ovCEkUERi5WT7dr/aJtoDPwz/W/TLpEx70SioaUZaVI FITIkHoRTgIW9PvfFSXSN+sDOG8VFyz+boI5la8AlHprUNJUXGA+mwoGt5CJZialCXKx /c/o3BB4A9XquXtSlPYbmxp7dzbfgzCrITjBgzKLG7MVOh2J7Ixdtx7g/Cq89DiPFcV2 LqXanblvOqeVUkJAINBDwQ3iTTXWlUgSdYxSFcI4Qpu467p/4DSmyC37PMmtNyVtYYHB mU7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pnWwC3OEtJp4qDh3ydbFeFB9cPwe6pLry5NZ3z32/bg=; b=R0bWaccb2OHdsd8jM7ABKpEDLxAWv3HoU1KBC44jKZVhWCgb1rg4LqIJWX5dgDo78x uusIJctTSArj4ti27R0qZhbYoex9hbGeX0WdE8vlCSQCfgUFFpZ7idISfd+3mzMknfEi ChGOqLnsFNd//ndyFmYuapXzBo8WrYofK9uwO8XWKD75vZWt0tJSfefnjqKkSHMV7I1z tDLBpRkmAZ748YJsjHHgXLKDpEh9F10HNbsWBoirhLRibBtvy2m8e2Yq4JE8dkfOka13 Tz7m2GPuS1CG/10T9IUmS/mtZZzjL70TG7lVZak9dlzAm5g6BThK4h4pLl1raIgV76ZY 7Nfg== X-Gm-Message-State: APjAAAV65c+7d3+94PhMdSIQidWH6+bTFkQbH14b8yvbzPIAzKSCZmd5 hKnl1oFWysdY3/qzK6TpibDn7zhMZVwNKAZYMC0= X-Google-Smtp-Source: APXvYqw6hA45vMxpzCH33P5VAmEADd0/XOfVM5eljSrMKVQNlXGHtWgk+dbYqX6UPDSoRDT4JzZ2SmcXWm8rDzBW9tg= X-Received: by 2002:a05:6638:3a6:: with SMTP id z6mr29035183jap.33.1571192138560; Tue, 15 Oct 2019 19:15:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vm finance Date: Tue, 15 Oct 2019 19:15:27 -0700 Message-ID: Subject: Re: logs/traces To: Kevin Oberman Cc: freebsd-net X-Rspamd-Queue-Id: 46tG9R5xXtz46qk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=dcuGeSG6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vmfinance2@gmail.com designates 2607:f8b0:4864:20::d29 as permitted sender) smtp.mailfrom=vmfinance2@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-5.38), ipnet: 2607:f8b0::/32(-2.48), asn: 15169(-2.10), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[9.2.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 02:15:41 -0000 Hi Kevin, I am looking to enable traces/log messages (like syslog or /var/log/messages) inside the codebase... any pointers for tcp/ip. tcpdump shows what is going on wire - but I would like to trace code internals...printk.. Thanks a lot! On Tue, Oct 15, 2019 at 6:11 PM Kevin Oberman wrote: > Use tcpdump(1) and/or net/wireshark(5). See man tcpdump and pcap-filter > for usage details. wireshark can analyze files collected by tcpdump and > dissect the packets. It can also do packet capture, itself. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > On Tue, Oct 15, 2019 at 3:17 AM vm finance wrote: > >> Hi, >> >> Could someone please guide me on how to turn on tracing/log? >> >> I would like to follow/track how packets go in/out of TCP code block... >> Please let me know what knobs are available to achieve this. >> >> Thanks for any pointers. >> _______________________________________________ >> 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 Oct 16 02:53:14 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0F7E315A290 for ; Wed, 16 Oct 2019 02:53:14 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tH0m4wMDz48Br for ; Wed, 16 Oct 2019 02:53:12 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pl1-x632.google.com with SMTP id c3so10536216plo.2 for ; Tue, 15 Oct 2019 19:53:12 -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=xO+D1CA8eeS2HZjvySQ3as26aMdk7IDcXuupVPrPtrk=; b=Hv3o0QGsVEalswM7CnfkPcxQZ+KBNsNPP+h8C4VSOfQ52B5jrkkND+fgyMvHKPrzHw gbATa9J1Db+wUFUm1BpAtzjPxti8AMzrIChYufnCBYYW0z0ABMOmye6QJ72HOaY7IyYE 6gpwfeCM5cDx1t5rB3yYjMkd68TOSk/vAS8aDFtJ0Lwl9OV2leqiqQqLZUKXZQvjz+KW MO5wFvMlxMyYtLlzOckdeRDqe/K1qMwxAmA5buSjxEsNqdS5YUc+RQUeW0b2969woJnO pakayf6BQs0DeBobcY/1Mk9EuJBKL+OK/3xHm856xpMPn8S6U8odlOK0dgZ3Ux2RzGEy 0xig== 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=xO+D1CA8eeS2HZjvySQ3as26aMdk7IDcXuupVPrPtrk=; b=noAtIg4IpuRayUq1ibkixg3Ntg8jYfqnthgNUTdvSM/xDXUX45Yz8pgqfatLzJV59E LmKMlNR/o73+2/Yz7dcidDQ3HbTaRcdBlqqJ+mwnWJjndTKncrNqUCObwk0aPtI8Zohg zFDL1PUY3/uZrvbchzn9UHH8v0E3zJXc46xXaE16o+HifIRsPLnvjObSug3/XLXIPFg/ lFoKZNXnf7Lu/9uvI92qn+C2unr6oGCZP8Hy197PUa/UGsqf8uxmr8r6+JNkP8V3O+Z0 PsyAbczy+KaHWPdIj93sM/g1bZzQe9jlQfmDlXO2acYwJt23NlqOH4J/BqFcjDY/vRYd 379g== X-Gm-Message-State: APjAAAWR/RkAPOfgPNVjUCECFv5G1bD9Zsrt7vEDXlOBacg9dBRmF8N5 1j0Si0O7bGSKxBy4EMzc4bQ= X-Google-Smtp-Source: APXvYqwvqqTPzg+rg7fvSvbPyh+biuw4xvBs07byJopVMF+QzWLwapRuZSR2lWnkV5yikCbqABRD7g== X-Received: by 2002:a17:902:a404:: with SMTP id p4mr38891854plq.42.1571194390916; Tue, 15 Oct 2019 19:53:10 -0700 (PDT) Received: from x270 ([2601:641:c000:3700:71cc:bb31:bcf1:b99]) by smtp.gmail.com with ESMTPSA id x10sm28413501pfr.44.2019.10.15.19.53.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 15 Oct 2019 19:53:10 -0700 (PDT) Date: Tue, 15 Oct 2019 19:53:04 -0700 From: Navdeep Parhar To: vm finance Cc: Kevin Oberman , freebsd-net Subject: Re: logs/traces Message-ID: <20191016025233.GA14421@x270> Mail-Followup-To: vm finance , Kevin Oberman , freebsd-net References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 46tH0m4wMDz48Br X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Hv3o0QGs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of nparhar@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=nparhar@gmail.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; IP_SCORE(0.00)[ip: (-9.57), ipnet: 2607:f8b0::/32(-2.48), asn: 15169(-2.10), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.3.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 02:53:14 -0000 Have you looked at siftr(4) or dtrace_tcp(4)? Regards, Navdeep On Tue, Oct 15, 2019 at 07:15:27PM -0700, vm finance wrote: > Hi Kevin, > > I am looking to enable traces/log messages (like syslog or > /var/log/messages) inside the codebase... any pointers for tcp/ip. > tcpdump shows what is going on wire - but I would like to trace code > internals...printk.. > > Thanks a lot! > > On Tue, Oct 15, 2019 at 6:11 PM Kevin Oberman wrote: > > > Use tcpdump(1) and/or net/wireshark(5). See man tcpdump and pcap-filter > > for usage details. wireshark can analyze files collected by tcpdump and > > dissect the packets. It can also do packet capture, itself. > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkoberman@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > > > > On Tue, Oct 15, 2019 at 3:17 AM vm finance wrote: > > > >> Hi, > >> > >> Could someone please guide me on how to turn on tracing/log? > >> > >> I would like to follow/track how packets go in/out of TCP code block... > >> Please let me know what knobs are available to achieve this. > >> > >> Thanks for any pointers. > >> _______________________________________________ > >> 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" > >> > > > _______________________________________________ > 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 Oct 16 09:23:53 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 395E516046A for ; Wed, 16 Oct 2019 09:23:53 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tRgX13YJz4VZQ; Wed, 16 Oct 2019 09:23:51 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 59C9D8D4A218; Wed, 16 Oct 2019 09:23:49 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id CA725E707D3; Wed, 16 Oct 2019 09:23:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 7FtmqMnsph8M; Wed, 16 Oct 2019 09:23:46 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:284a:89d7:f546:4d57]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6F9AEE707CA; Wed, 16 Oct 2019 09:23:46 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Ben Woods" Cc: freebsd-net@freebsd.org, hrs@freebsd.org, roy@marples.name Subject: Re: DHCPv6 client in base Date: Wed, 16 Oct 2019 09:23:45 +0000 X-Mailer: MailMate (2.0BETAr6142) Message-ID: <8016D7B2-5201-4D95-B61F-C949289BDAE6@lists.zabbadoz.net> In-Reply-To: References: <001e01d50b49$176104d0$46230e70$@gmail.com> <20190516.032012.517661495892269813.hrs@allbsd.org> <20191012.044034.19725945241254130.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 46tRgX13YJz4VZQ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-5.14 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.84)[ip: (-8.83), ipnet: 195.201.0.0/16(-3.56), asn: 24940(-1.81), country: DE(-0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 09:23:53 -0000 On 14 Oct 2019, at 23:04, Ben Woods wrote: > Whilst I don’t have anything against wide-dhcp, I personally prefer > integrated IPv4/IPv6 tools. ping vs ping6 for example would be better > integrated in my opinion. I have a totally different opinion on this. I prefer to have a tool that does one job. K.I.S.S. In addition I consider IPv4 dead. Let it die. Stop thinking IPv4. Don’t screw the users over on the way out of the protocol by making changes to how things worked for a decade or two or three in the last minute. Never change a running system. If you want to touch IPv4 along, I am out on the IPv6 change. Further I really, very soon, want to get rid of more IPv4 code for a lot of systems I am building as less code less attack surface. We started compiling INET out in 2011 in addition to INET6. I have a way more eager hobby project at the moment which does remove IPv4 entirely from the tree. I do that by splattering more #ifdef code around all IPv4 code I can find and then remove it. (two step needed to be able to merge-track FreeBSD still). I can tell you even just doing that for libc is a pain. If it takes us another 6-8 years until the rest of the world gets there, I’ll be happy (very much like it took the world to get to the IPv6-only discussions we have everywhere actively these days). > The “feature” that I believe is missing from wide-dhcp is active > maintenance. I am not sure but I’d assume that’s a lot also to the fact of its current state as to where it is living. If it were in head with a bit of infrastructure and not as a “import from upstream” project I think some people might “commit to it” a lot more. > I do agree that we should minimise excess code in FreeBSD also, but I > believe that once dhcpcd has been proven to work, we could look at > removing > dhclient and rtsold. Agree with your comment that before this occurs, > we > should check what features / security improvements / tighter > integration > have been added along the way, and ensure they make their way into > dhcpcd. > > If dhcpcd was imported, I believe this would come with a phased > approach: > - import dhcpcd, but leave dhclient and rtsold as default - Make sure all the security concerns are rooted out. - Update documentation, handbook, samples, .. and educate our users. > - add kernel support for tighter dhcpcd integration > - switch defaults to dhcpcd, but leave dhclient and rtsold as > available > - remove dhclient and rtsold If you really want a proper smooth transition you probably need at least one major release overlap and that’s half a decade of maintaining two software sets. /bz From owner-freebsd-net@freebsd.org Wed Oct 16 17:14:46 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8749314B948 for ; Wed, 16 Oct 2019 17:14:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tf6s4tHYz432p for ; Wed, 16 Oct 2019 17:14:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x835.google.com with SMTP id n17so17844307qtr.4 for ; Wed, 16 Oct 2019 10:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EC2sSG6pBEWCBU+ek8xt5aS3b7UvPM1z+iEyFi1W9o4=; b=Da5o3R0aoO8Y7jNHRH66rUmtrHxJsKfCiXkjMRNPY9oYnAQjK1naQ6DbFNCkHjX4UN hQGQlZiR2qP28Osy/JnASSnLwTz+b9o4RYqNrqCaeknM9dWfyIZ60cIFgf456/ISKDl1 Y0tfoefyRgUMsCWNa+SXCDpX8qSAU0n397OmZOU4/3BVxgTZvMD6L2vJLhZd8TypkabU i2Kb74799OrULJVjRo5soUOnyeKD38WsAvKy5XqRqzcUMTw1jVxEzSrvgh5FAhPcM3f1 GZ9WlPI9bC2+vaW+k/1t+F8j2Kj90lzi3M8QUf8TqhGdVZIcy4HPb5hwVNSWFDMmL4Dy LGcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=EC2sSG6pBEWCBU+ek8xt5aS3b7UvPM1z+iEyFi1W9o4=; b=pqjEywbrnlwZfxwrYu0wPmoTG43bCSvjWAcIjhyeqgQIut1I3zwU0J5M+olbdbX99Y gRTigjfJFGSeqJwU8GRWHs+X+cTWwlmCJN2AFPGOdzhATM+OhM+EzIwGV72lA5/I1XDm WxKNG0Iaqg8g0DDjPQsR/Mwb1+aQQ/zUMOhfVLGa3ZGNxcpTgFFBlGTlyt08vHbnmg3j 50SWd0luu6ti6PH+1nUJiI7ZW/jLzaYv8ZIGLa1n28KAbYmhJBHsuajCLkouF6KGEUdy nvqyNHtm78CwRA3/ePjeotol+7IWCtQpdtypnxdU+WVphbSkkZfn238zKcDJgIc4r3Pc eA/w== X-Gm-Message-State: APjAAAVF/ZVTBSG5hCffDoHaaqA4RFjH+qO4O3mPq3fNvIiZD7dWqFzk nLoaQvF4pLcXmwEOMNtdeIo= X-Google-Smtp-Source: APXvYqyauN2s64RXaTPcLzHJx3kiRlifUZemE3Tepc3nA9qU4M15sTOwLkxZ08fUm/9XgT0YLIX9MA== X-Received: by 2002:a0c:f9c1:: with SMTP id j1mr20635254qvo.244.1571246083473; Wed, 16 Oct 2019 10:14:43 -0700 (PDT) Received: from raichu (toroon0560w-lp130-05-69-158-183-252.dsl.bell.ca. [69.158.183.252]) by smtp.gmail.com with ESMTPSA id c26sm16194696qtk.93.2019.10.16.10.14.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2019 10:14:42 -0700 (PDT) Sender: Mark Johnston Date: Wed, 16 Oct 2019 13:14:40 -0400 From: Mark Johnston To: Dheeraj Kandula Cc: freebsd-net@freebsd.org Subject: Re: sol_upcall in FreeBSD 12 Message-ID: <20191016171440.GE82455@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 46tf6s4tHYz432p X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Da5o3R0a; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-4.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[5.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.80)[ip: (-9.38), ipnet: 2607:f8b0::/32(-2.47), asn: 15169(-2.10), country: US(-0.05)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 17:14:46 -0000 On Thu, Aug 01, 2019 at 04:06:34PM -0400, Dheeraj Kandula wrote: > When going through the code of FreeBSD12, I see that the socket code has > undergone significant change. > > The socket is now either a regular socket or a listen socket. > The listen socket has two new fields besides others: > > sol_upcall and sol_upcallarg > > My understanding is that this callback will be used to notify the accept > socket's consumers when the 3 way handshake is completed and the socket is > ready to be accepted. Right, it is called from solisten_wakeup() when a new connection is established. > However in soisconnected function, when the accept filter is set, the code > still sets the receive socket buffer's upcall. Right. The accept filter is supposed to process incoming data on that socket until it accepts or rejects the connection. To do this, we must set the socket buffer upcall. When the accept filter returns SU_ISCONNECTED, the receive socket transitions to the connected state, and the listen socket upcall, if any, is invoked. > Shouldn't we set the > sol_upcall in line 3773 below instead. If not, when should the sol_upcall > be set. An example will help clarify the usage. I don't really follow: line 3773 is setting an upcall for the new socket, not the listening socket. If the listening socket has set sol_upcall, and an accept filter is configured, sol_upcall will be invoked once the accept filter has accepted the connection. From owner-freebsd-net@freebsd.org Wed Oct 16 17:33:38 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1512D14C0D6 for ; Wed, 16 Oct 2019 17:33:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tfXd288Cz44LW for ; Wed, 16 Oct 2019 17:33:37 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82d.google.com with SMTP id c21so37248779qtj.12 for ; Wed, 16 Oct 2019 10:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=IgYmMWEOUeo1bGIvAujMHqsbVOhWtEeehdL9uNTKPlo=; b=XwX9SfKy0V3qxm7YRboQu/T8vcde7c0yy2Sn9hI7BLKnExAB3TuJWoimoK9YxADLMX omHHaHtLciDyymkS4HuHeIHJkCXEnYFwxIm3gYuLdpxhrKQ5usCq2WqAwqVI8NPdr1WT duasoG4DIC/OKIgT/zRXnPdwOeKk1xvCt+qrX9oCr++5nRHUjFVhweyXL1+PyPz4u7r6 5mt0hkJYVQ/6xS30A36djHWiyh+yXuAy890EcEtkunNy/RYEd10jjnADNTEicQbQ9s15 H/zMqwdXprokMizijKHL98ixF3eOzL9cke1VK5BqevHDapnf7Ez//6cwi8suUkiedy8h rqxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=IgYmMWEOUeo1bGIvAujMHqsbVOhWtEeehdL9uNTKPlo=; b=g+N40YtPaahx4jYXHr2pRlT4cm10H3Wp9jAYHOsXe2on+gXIDvtp5ll0gdjJ6jUhff FNSPKCCD6O9z8R4e7GSiFFIdRj3Rn6As765KVgZFhtpYW1wMkGiRk2FwtJw2FfF2aQRi FWzgFEyeA6cOXF9cwV/Eukay7otEXwOvsNx6vQegt8gccrgSem3Rwp1g7iG7vTN26J0N bp5n9Wzzh25nF5fvxkaMpGO2rvT0g4ROKM0XD1m6TD9l/D7/10QrQ7kjn/9Smv9P7pPR XLhdBKBUyTJNJgHTq+WjlxWvhxRuyt/US6jiRZf/vRrntjbhf6m5qEfZ5PYnBUkcrK/X xK3w== X-Gm-Message-State: APjAAAWFrK4b63ICNpTFgJECh0e39LWy+M0dyXtnbzv/Gwfye3/TmwGc Z/YSWJgD9uR279mbPM5XOqg= X-Google-Smtp-Source: APXvYqxiQ2EB8Yxo3MT4pd+45UoeX9GRUlZYHXPNWCVZIWvQM/kfC7aEGAk+07FXLkIfJ4aapX9V8Q== X-Received: by 2002:ad4:5044:: with SMTP id m4mr44391481qvq.85.1571247215959; Wed, 16 Oct 2019 10:33:35 -0700 (PDT) Received: from raichu (toroon0560w-lp130-05-69-158-183-252.dsl.bell.ca. [69.158.183.252]) by smtp.gmail.com with ESMTPSA id n42sm16373079qta.31.2019.10.16.10.33.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2019 10:33:34 -0700 (PDT) Sender: Mark Johnston Date: Wed, 16 Oct 2019 13:33:32 -0400 From: Mark Johnston To: Dheeraj Kandula Cc: freebsd-net@freebsd.org Subject: Re: Socket Sleep and Wakeup clarification Message-ID: <20191016173332.GF82455@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 46tfXd288Cz44LW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=XwX9SfKy; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-4.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[d.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.80)[ip: (-9.37), ipnet: 2607:f8b0::/32(-2.47), asn: 15169(-2.10), country: US(-0.05)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 17:33:38 -0000 On Wed, Jul 31, 2019 at 04:36:08PM -0400, Dheeraj Kandula wrote: > Hi All, > I am reading through the socket code in uipc_socket.c file of FreeBSD > 12. > > The code invokes wakeup with the channel as so->so_timeo in the following > functions: > soisconnected > soisdisconnected > soisdisconnecting and > soshutdown > > The callers of soconnect invoke sleep so that the thread that invokes > soconnect wakes up when the TCP 3 way handshake is done. The soconnect in > kernel returns immediately unlike user space connect which sleeps. > > I also see tsleep in soclose when the socket's state is SS_ISCONNECTED. > > My questions: > 1. Is it possible to close a socket when the application is sleeping > after the application invokes soconnect. Basically I am trying to figure > out how multiple threads can access the same socket for soconnect and > soclose to happen at the same time. I don't see any particular synchronization between soclose() and the sleep you are referring to, so there might be a bug here. In particular, I would expect soclose() on a connecting socket to wake up sleepers, but I cannot see how that happens. > 2. soshutdown also invokes wakeup. This wakeup again corresponds to > the sleep by soconnect. Isn't it? How can we have two threads accessing the > same socket with one thread sleeping on a socket for the soconnect, while > another shuts down the same socket in either the RD or WR or RW direction. Yes, wakeup(&so->so_timeo) should be called whenever the connection state of a socket changes. From owner-freebsd-net@freebsd.org Wed Oct 16 20:13:25 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B92914EFC4 for ; Wed, 16 Oct 2019 20:13:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46tk510wHYz4D9Q for ; Wed, 16 Oct 2019 20:13:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1D62314EFC3; Wed, 16 Oct 2019 20:13:25 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1D28214EFC2 for ; Wed, 16 Oct 2019 20:13:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tk5100BNz4D9P for ; Wed, 16 Oct 2019 20:13:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D178BC683 for ; Wed, 16 Oct 2019 20:13:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9GKDOp5004565 for ; Wed, 16 Oct 2019 20:13:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9GKDOp9004564 for net@FreeBSD.org; Wed, 16 Oct 2019 20:13:24 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241106] tun/ppp: panic: vm_fault: fault on nofault entry when bringing ppp interface down Date: Wed, 16 Oct 2019 20:13:24 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lenzi.sergio@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: cc attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 20:13:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241106 lenzi.sergio@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lenzi.sergio@gmail.com --- Comment #4 from lenzi.sergio@gmail.com --- Created attachment 208370 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D208370&action= =3Dedit this patch test for null pointer in rtsock.c system panics on rtsock.c for the reason that rt->rt_ifp->if_addr have a nu= ll pointer.=20 It is not clear the reason rt->rt_ifp->if_addr have a null pointer but when= =20 try to access rt->rt_ifp->if_addr->ifa_addr near line 1578 of rtsock.c the system panics...=20 I also insert code of RTSOCK_LOCK/RTSOCK_UNLOCK on any ioctl call, and sin= ce than, the system does not panic any more.. A more study must be done where/why rt->rt_ifp->if_addr comes NULL, and in that case the colunm Netif from the command: netstat -4rn either shows "" (nothing) or "---". when this happens, the system panics some minutes later... --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Oct 16 21:16:28 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D8B951500A9 for ; Wed, 16 Oct 2019 21:16:28 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orsmga104.jf.intel.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tlTl1cw0z4Gkw; Wed, 16 Oct 2019 21:16:26 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2019 14:16:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,305,1566889200"; d="scan'208,217";a="208492722" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by fmsmga001.fm.intel.com with ESMTP; 16 Oct 2019 14:16:23 -0700 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 16 Oct 2019 14:16:23 -0700 Received: from orsmsx121.amr.corp.intel.com ([169.254.10.88]) by ORSMSX114.amr.corp.intel.com ([169.254.8.228]) with mapi id 14.03.0439.000; Wed, 16 Oct 2019 14:16:23 -0700 From: "Keller, Jacob E" To: "freebsd-net@freebsd.org" CC: "shurd@llnw.com" , "Joyner, Eric" , John Baldwin Subject: panic on invalid ifp pointer in iflib drivers Thread-Topic: panic on invalid ifp pointer in iflib drivers Thread-Index: AdWEZQwvUgSbd6eoRs2vy4mdxXWSPw== Date: Wed, 16 Oct 2019 21:16:22 +0000 Message-ID: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGQ5MjU0NDgtN2Y3MS00OWRjLWFkZGMtYzNkOTQ3NjIzZTMyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTU5jc2NMVkhRQ04wNG5PUVgweENBUnExVVpvN1doMU5KVlhvR2xcL2g3MlZPMGk2c1Fuc0pObk12ejdSQ054QXoifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.139] MIME-Version: 1.0 X-Rspamd-Queue-Id: 46tlTl1cw0z4Gkw X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=intel.com; spf=pass (mx1.freebsd.org: domain of jacob.e.keller@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=jacob.e.keller@intel.com X-Spamd-Result: default: False [-7.77 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:134.134.136.31/32]; NEURAL_HAM_LONG(-0.00)[nan,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(-3.77)[ip: (-9.89), ipnet: 134.134.136.0/24(-4.95), asn: 4983(-3.96), country: US(-0.05)]; NEURAL_HAM_MEDIUM(-0.00)[nan,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[31.136.134.134.list.dnswl.org : 127.0.9.2]; DMARC_POLICY_ALLOW(-0.50)[intel.com,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:4983, ipnet:134.134.136.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; WHITELIST_SPF_DKIM(-3.00)[intel.com:s:+] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 21:16:28 -0000 Hi, I'm investigating an issue on the iflib ixl driver in 11.3-RELEASE as well = as 12-RELEASE. We found a panic in that occurs if SCTP/IPv6 traffic is bein= g transmitted while the device is detached: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xfffffe0000411e38 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80c84700 stack pointer =3D 0x28:0xfffffe2f4351b600 frame pointer =3D 0x28:0xfffffe2f4351b650 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 12 (swi4: clock (0)) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe2f4351b= 2c0 vpanic() at vpanic+0x17e/frame 0xfffffe2f4351b320 panic() at panic+0x43/frame 0xfffffe2f4351b380 trap_fatal() at trap_fatal+0x369/frame 0xfffffe2f4351b3d0 trap_pfault() at trap_pfault+0x62/frame 0xfffffe2f4351b420 trap() at trap+0x2b3/frame 0xfffffe2f4351b530 calltrap() at calltrap+0x8/frame 0xfffffe2f4351b530 --- trap 0xc, rip =3D 0xffffffff80c84700, rsp =3D 0xfffffe2f4351b600, rbp = =3D 0xfffffe2f4351b650 --- in6_selecthlim() at in6_selecthlim+0x20/frame 0xfffffe2f4351b650 sctp_lowlevel_chunk_output() at sctp_lowlevel_chunk_output+0xeb2/frame 0xff= fffe2f4351b790 sctp_chunk_output() at sctp_chunk_output+0x68c/frame 0xfffffe2f4351c110 sctp_timeout_handler() at sctp_timeout_handler+0x2d8/frame 0xfffffe2f4351c1= 80 softclock_call_cc() at softclock_call_cc+0x15b/frame 0xfffffe2f4351c230 softclock() at softclock+0x7c/frame 0xfffffe2f4351c260 intr_event_execute_handlers() at intr_event_execute_handlers+0x9a/frame 0xf= ffffe2f4351c2a0 ithread_loop() at ithread_loop+0xb7/frame 0xfffffe2f4351c2f0 fork_exit() at fork_exit+0x84/frame 0xfffffe2f4351c330 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe2f4351c330 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- KDB: enter: panic >From what I've gathered so far, it appears that the issue is a use-after-fr= ee where the SCTP stack gets an ifp pointer that's no longer valid. We've r= eproduced this issue on multiple iflib-based drivers, including ixl and the= recently published ice driver code (available on phabricator). Additionally, we cannot reproduce it on legacy-stack drivers for ixl, or a = mellanox 100G board we have. This leads me to believe that it's an issue in= iflib rather than in the specific device drivers. I am not sure exactly what's going wrong here... anyone have suggestions? I= thought it might be an issue of when ether_ifdetach is called. That functi= on is supposed to clear all of the pre-existing routes from the route entry= list. I'm thinking maybe somehow a route gets added after ether_ifdetach i= s called. In the iflib_device_deregister function, ether_ifdetach is called just afte= r iflib_stop, (which would call a device's if_stop routine), and then the t= ask queues are shutdown, a driver's ifdi_detach handler is called, and the = ifp is free'd at the end. In the ixl legacy driver, ether_ifdetach is calle= d prior to the stop routine. However, in the mlx5 driver, it's called after= a call to close_locked()... So I'm really not sure exactly what could cause a stale ifp pointer to get = into the route entry list. Thanks, Jake From owner-freebsd-net@freebsd.org Wed Oct 16 22:07:19 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4325B15164D for ; Wed, 16 Oct 2019 22:07:19 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orsmga101.jf.intel.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tmcP4K11z4LWW; Wed, 16 Oct 2019 22:07:17 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2019 15:07:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,305,1566889200"; d="scan'208";a="208501114" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga001.fm.intel.com with ESMTP; 16 Oct 2019 15:07:14 -0700 Received: from orsmsx126.amr.corp.intel.com (10.22.240.126) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 16 Oct 2019 15:07:14 -0700 Received: from orsmsx121.amr.corp.intel.com ([169.254.10.88]) by ORSMSX126.amr.corp.intel.com ([169.254.4.48]) with mapi id 14.03.0439.000; Wed, 16 Oct 2019 15:07:14 -0700 From: "Keller, Jacob E" To: "freebsd-net@freebsd.org" CC: "shurd@llnw.com" , "jhb@freebsd.org" , "Joyner, Eric" Subject: Re: panic on invalid ifp pointer in iflib drivers Thread-Topic: panic on invalid ifp pointer in iflib drivers Thread-Index: AdWEZQwvUgSbd6eoRs2vy4mdxXWSPwAQ6/EA Date: Wed, 16 Oct 2019 22:07:13 +0000 Message-ID: References: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> In-Reply-To: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.32.4 (3.32.4-1.fc30) x-originating-ip: [10.166.244.172] Content-Type: text/plain; charset="utf-8" Content-ID: <1E7D39F79B135A47A78BD2D957BFF6C7@intel.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Rspamd-Queue-Id: 46tmcP4K11z4LWW X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=intel.com; spf=pass (mx1.freebsd.org: domain of jacob.e.keller@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=jacob.e.keller@intel.com X-Spamd-Result: default: False [-9.67 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:134.134.136.20/32]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[20.136.134.134.list.dnswl.org : 127.0.9.2]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[intel.com,none]; IP_SCORE(-3.77)[ip: (-9.88), ipnet: 134.134.136.0/24(-4.95), asn: 4983(-3.96), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4983, ipnet:134.134.136.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; WHITELIST_SPF_DKIM(-3.00)[intel.com:s:+] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 16 Oct 2019 22:07:19 -0000 T24gV2VkLCAyMDE5LTEwLTE2IGF0IDIxOjE2ICswMDAwLCBLZWxsZXIsIEphY29iIEUgd3JvdGU6 DQo+IEhpLA0KPiAgDQo+IEnigJltIGludmVzdGlnYXRpbmcgYW4gaXNzdWUgb24gdGhlIGlmbGli IGl4bCBkcml2ZXIgaW4gMTEuMy1SRUxFQVNFIGFzDQo+IHdlbGwgYXMgMTItUkVMRUFTRS4gV2Ug Zm91bmQgYSBwYW5pYyBpbiB0aGF0IG9jY3VycyBpZiBTQ1RQL0lQdjYNCj4gdHJhZmZpYyBpcyBi ZWluZyB0cmFuc21pdHRlZCB3aGlsZSB0aGUgZGV2aWNlIGlzIGRldGFjaGVkOg0KPiAgDQoNCkkn dmUganVzdCBiZWVuIHRvbGQgaXQgaGFzIHJlcHJvZHVjZWQgdGhpcyBvbiB0aGUgbGF0ZXN0IDEy LXN0YWJsZSBhcw0Kd2VsbC4NCg0KPiBGYXRhbCB0cmFwIDEyOiBwYWdlIGZhdWx0IHdoaWxlIGlu IGtlcm5lbCBtb2RlDQo+IGNwdWlkID0gMDsgYXBpYyBpZCA9IDAwDQo+IGZhdWx0IHZpcnR1YWwg YWRkcmVzcyAgID0gMHhmZmZmZmUwMDAwNDExZTM4DQo+IGZhdWx0IGNvZGUgICAgICAgICAgICAg ID0gc3VwZXJ2aXNvciByZWFkIGRhdGEsIHBhZ2Ugbm90IHByZXNlbnQNCj4gaW5zdHJ1Y3Rpb24g cG9pbnRlciAgICAgPSAweDIwOjB4ZmZmZmZmZmY4MGM4NDcwMA0KPiBzdGFjayBwb2ludGVyICAg ICAgICAgICA9IDB4Mjg6MHhmZmZmZmUyZjQzNTFiNjAwDQo+IGZyYW1lIHBvaW50ZXIgICAgICAg ICAgID0gMHgyODoweGZmZmZmZTJmNDM1MWI2NTANCj4gY29kZSBzZWdtZW50ICAgICAgICAgICAg PSBiYXNlIDB4MCwgbGltaXQgMHhmZmZmZiwgdHlwZSAweDFiDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgID0gRFBMIDAsIHByZXMgMSwgbG9uZyAxLCBkZWYzMiAwLCBncmFuIDENCj4gcHJvY2Vz c29yIGVmbGFncyAgICAgICAgPSBpbnRlcnJ1cHQgZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMA0K PiBjdXJyZW50IHByb2Nlc3MgICAgICAgICA9IDEyIChzd2k0OiBjbG9jayAoMCkpDQo+IHRyYXAg bnVtYmVyICAgICAgICAgICAgID0gMTINCj4gcGFuaWM6IHBhZ2UgZmF1bHQNCj4gY3B1aWQgPSAw DQo+IEtEQjogc3RhY2sgYmFja3RyYWNlOg0KPiBkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBk Yl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYi9mcmFtZQ0KPiAweGZmZmZmZTJmNDM1MWIyYzANCj4g dnBhbmljKCkgYXQgdnBhbmljKzB4MTdlL2ZyYW1lIDB4ZmZmZmZlMmY0MzUxYjMyMA0KPiBwYW5p YygpIGF0IHBhbmljKzB4NDMvZnJhbWUgMHhmZmZmZmUyZjQzNTFiMzgwDQo+IHRyYXBfZmF0YWwo KSBhdCB0cmFwX2ZhdGFsKzB4MzY5L2ZyYW1lIDB4ZmZmZmZlMmY0MzUxYjNkMA0KPiB0cmFwX3Bm YXVsdCgpIGF0IHRyYXBfcGZhdWx0KzB4NjIvZnJhbWUgMHhmZmZmZmUyZjQzNTFiNDIwDQo+IHRy YXAoKSBhdCB0cmFwKzB4MmIzL2ZyYW1lIDB4ZmZmZmZlMmY0MzUxYjUzMA0KPiBjYWxsdHJhcCgp IGF0IGNhbGx0cmFwKzB4OC9mcmFtZSAweGZmZmZmZTJmNDM1MWI1MzANCj4gLS0tIHRyYXAgMHhj LCByaXAgPSAweGZmZmZmZmZmODBjODQ3MDAsIHJzcCA9IDB4ZmZmZmZlMmY0MzUxYjYwMCwgcmJw DQo+ID0gMHhmZmZmZmUyZjQzNTFiNjUwIC0tLQ0KPiBpbjZfc2VsZWN0aGxpbSgpIGF0IGluNl9z ZWxlY3RobGltKzB4MjAvZnJhbWUgMHhmZmZmZmUyZjQzNTFiNjUwDQo+IHNjdHBfbG93bGV2ZWxf Y2h1bmtfb3V0cHV0KCkgYXQNCj4gc2N0cF9sb3dsZXZlbF9jaHVua19vdXRwdXQrMHhlYjIvZnJh bWUgMHhmZmZmZmUyZjQzNTFiNzkwDQo+IHNjdHBfY2h1bmtfb3V0cHV0KCkgYXQgc2N0cF9jaHVu a19vdXRwdXQrMHg2OGMvZnJhbWUNCj4gMHhmZmZmZmUyZjQzNTFjMTEwDQo+IHNjdHBfdGltZW91 dF9oYW5kbGVyKCkgYXQgc2N0cF90aW1lb3V0X2hhbmRsZXIrMHgyZDgvZnJhbWUNCj4gMHhmZmZm ZmUyZjQzNTFjMTgwDQo+IHNvZnRjbG9ja19jYWxsX2NjKCkgYXQgc29mdGNsb2NrX2NhbGxfY2Mr MHgxNWIvZnJhbWUNCj4gMHhmZmZmZmUyZjQzNTFjMjMwDQo+IHNvZnRjbG9jaygpIGF0IHNvZnRj bG9jaysweDdjL2ZyYW1lIDB4ZmZmZmZlMmY0MzUxYzI2MA0KPiBpbnRyX2V2ZW50X2V4ZWN1dGVf aGFuZGxlcnMoKSBhdA0KPiBpbnRyX2V2ZW50X2V4ZWN1dGVfaGFuZGxlcnMrMHg5YS9mcmFtZSAw eGZmZmZmZTJmNDM1MWMyYTANCj4gaXRocmVhZF9sb29wKCkgYXQgaXRocmVhZF9sb29wKzB4Yjcv ZnJhbWUgMHhmZmZmZmUyZjQzNTFjMmYwDQo+IGZvcmtfZXhpdCgpIGF0IGZvcmtfZXhpdCsweDg0 L2ZyYW1lIDB4ZmZmZmZlMmY0MzUxYzMzMA0KPiBmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUrMHhlL2ZyYW1lIDB4ZmZmZmZlMmY0MzUxYzMzMA0KPiAtLS0gdHJhcCAwLCByaXAg PSAwLCByc3AgPSAwLCByYnAgPSAwIC0tLQ0KPiBLREI6IGVudGVyOiBwYW5pYw0KPiAgDQo+ICAN Cj4gRnJvbSB3aGF0IEnigJl2ZSBnYXRoZXJlZCBzbyBmYXIsIGl0IGFwcGVhcnMgdGhhdCB0aGUg aXNzdWUgaXMgYSB1c2UtDQo+IGFmdGVyLWZyZWUgd2hlcmUgdGhlIFNDVFAgc3RhY2sgZ2V0cyBh biBpZnAgcG9pbnRlciB0aGF04oCZcyBubyBsb25nZXINCj4gdmFsaWQuIFdl4oCZdmUgcmVwcm9k dWNlZCB0aGlzIGlzc3VlIG9uIG11bHRpcGxlIGlmbGliLWJhc2VkIGRyaXZlcnMsDQo+IGluY2x1 ZGluZyBpeGwgYW5kIHRoZSByZWNlbnRseSBwdWJsaXNoZWQgaWNlIGRyaXZlciBjb2RlIChhdmFp bGFibGUNCj4gb24gcGhhYnJpY2F0b3IpLg0KPiANCj4gQWRkaXRpb25hbGx5LCB3ZSBjYW5ub3Qg cmVwcm9kdWNlIGl0IG9uIGxlZ2FjeS1zdGFjayBkcml2ZXJzIGZvciBpeGwsDQo+IG9yIGEgbWVs bGFub3ggMTAwRyBib2FyZCB3ZSBoYXZlLiBUaGlzIGxlYWRzIG1lIHRvIGJlbGlldmUgdGhhdCBp dOKAmXMNCj4gYW4gaXNzdWUgaW4gaWZsaWIgcmF0aGVyIHRoYW4gaW4gdGhlIHNwZWNpZmljIGRl dmljZSBkcml2ZXJzLg0KPiAgDQo+IEkgYW0gbm90IHN1cmUgZXhhY3RseSB3aGF04oCZcyBnb2lu ZyB3cm9uZyBoZXJlLi4uIGFueW9uZSBoYXZlDQo+IHN1Z2dlc3Rpb25zPyBJIHRob3VnaHQgaXQg bWlnaHQgYmUgYW4gaXNzdWUgb2Ygd2hlbiBldGhlcl9pZmRldGFjaCBpcw0KPiBjYWxsZWQuIFRo YXQgZnVuY3Rpb24gaXMgc3VwcG9zZWQgdG8gY2xlYXIgYWxsIG9mIHRoZSBwcmUtZXhpc3RpbmcN Cj4gcm91dGVzIGZyb20gdGhlIHJvdXRlIGVudHJ5IGxpc3QuIEnigJltIHRoaW5raW5nIG1heWJl IHNvbWVob3cgYSByb3V0ZQ0KPiBnZXRzIGFkZGVkIGFmdGVyIGV0aGVyX2lmZGV0YWNoIGlzIGNh bGxlZC4NCj4gIA0KPiBJbiB0aGUgaWZsaWJfZGV2aWNlX2RlcmVnaXN0ZXIgZnVuY3Rpb24sIGV0 aGVyX2lmZGV0YWNoIGlzIGNhbGxlZA0KPiBqdXN0IGFmdGVyIGlmbGliX3N0b3AsICh3aGljaCB3 b3VsZCBjYWxsIGEgZGV2aWNl4oCZcyBpZl9zdG9wIHJvdXRpbmUpLA0KPiBhbmQgdGhlbiB0aGUg dGFzayBxdWV1ZXMgYXJlIHNodXRkb3duLCBhIGRyaXZlcuKAmXMgaWZkaV9kZXRhY2ggaGFuZGxl cg0KPiBpcyBjYWxsZWQsIGFuZCB0aGUgaWZwIGlzIGZyZWXigJlkIGF0IHRoZSBlbmQuIEluIHRo ZSBpeGwgbGVnYWN5DQo+IGRyaXZlciwgZXRoZXJfaWZkZXRhY2ggaXMgY2FsbGVkIHByaW9yIHRv IHRoZSBzdG9wIHJvdXRpbmUuIEhvd2V2ZXIsDQo+IGluIHRoZSBtbHg1IGRyaXZlciwgaXTigJlz IGNhbGxlZCBhZnRlciBhIGNhbGwgdG8gY2xvc2VfbG9ja2VkKCkuLi4NCj4gIA0KPiBTbyBJ4oCZ bSByZWFsbHkgbm90IHN1cmUgZXhhY3RseSB3aGF0IGNvdWxkIGNhdXNlIGEgc3RhbGUgaWZwIHBv aW50ZXINCj4gdG8gZ2V0IGludG8gdGhlIHJvdXRlIGVudHJ5IGxpc3QuDQo+ICANCj4gVGhhbmtz LA0KPiBKYWtlDQoNCg== From owner-freebsd-net@freebsd.org Thu Oct 17 10:24:02 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4307414D4F1 for ; Thu, 17 Oct 2019 10:24:02 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46v4yT3npkz43sK for ; Thu, 17 Oct 2019 10:24:01 +0000 (UTC) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-net@freebsd.org Received: from [10.58.0.4] (188-123-32-240.rdtc.ru [188.123.32.240] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x9HANu7h086164 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Oct 2019 10:23:57 GMT (envelope-from eugen@grosbein.net) Subject: Re: ipsec on multicore VM To: Victor Gamov , freebsd-net@freebsd.org References: From: Eugene Grosbein Message-ID: <60e6d692-ed74-9aa3-98b0-24d13eb61be7@grosbein.net> Date: Thu, 17 Oct 2019 17:23:55 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, DATE_IN_FUTURE_96_Q,LOCAL_FROM autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.8 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46v4yT3npkz43sK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.60)[ip: (-4.08), ipnet: 2a01:4f8::/29(-2.11), asn: 24940(-1.81), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 17 Oct 2019 10:24:02 -0000 09.10.2019 2:05, Victor Gamov wrote: > I have FreeBSD 11.2-STABLE #0 r343863 VM with 2 CPU and vxnet3 NIC. This host uses many if_ipsec and strongswan-5.7.2 to make site-to-site ipsec connections. > > When I use `tcpdump -nn -i src and esp` then I got many reordered IPsec packets. > > Does tcpdump give me a real picture and I have reordering somewhere "on the wire" or packets may be reordered due more then one CPU read packets from NIC ? You may easily verify your suspiction disabling SMP inside the guest system temporary: nextboot -k kernel echo kern.smp.disabled=1 >> /boot/nextboot.conf shutdown -r now This way, the system will perform one-time boot with all cores but one disabled. Should it experience any problems booting this way, another reset of the VM will boot it normally, otherwise try running tcpdump while single CPU is used by kernel. From owner-freebsd-net@freebsd.org Thu Oct 17 16:31:23 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0FABD156C6E for ; Thu, 17 Oct 2019 16:31:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vF6L6hqlz4PMP; Thu, 17 Oct 2019 16:31:22 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 3B45799EB; Thu, 17 Oct 2019 16:31:22 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: panic on invalid ifp pointer in iflib drivers To: "Keller, Jacob E" , "freebsd-net@freebsd.org" Cc: "shurd@llnw.com" , "Joyner, Eric" References: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <23f1e835-5dbb-055b-3768-f361311a9387@FreeBSD.org> Date: Thu, 17 Oct 2019 09:31:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 17 Oct 2019 16:31:23 -0000 On 10/16/19 2:16 PM, Keller, Jacob E wrote: > Hi, > > I'm investigating an issue on the iflib ixl driver in 11.3-RELEASE as well as 12-RELEASE. We found a panic in that occurs if SCTP/IPv6 traffic is being transmitted while the device is detached: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xfffffe0000411e38 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80c84700 > stack pointer = 0x28:0xfffffe2f4351b600 > frame pointer = 0x28:0xfffffe2f4351b650 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi4: clock (0)) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe2f4351b2c0 > vpanic() at vpanic+0x17e/frame 0xfffffe2f4351b320 > panic() at panic+0x43/frame 0xfffffe2f4351b380 > trap_fatal() at trap_fatal+0x369/frame 0xfffffe2f4351b3d0 > trap_pfault() at trap_pfault+0x62/frame 0xfffffe2f4351b420 > trap() at trap+0x2b3/frame 0xfffffe2f4351b530 > calltrap() at calltrap+0x8/frame 0xfffffe2f4351b530 > --- trap 0xc, rip = 0xffffffff80c84700, rsp = 0xfffffe2f4351b600, rbp = 0xfffffe2f4351b650 --- > in6_selecthlim() at in6_selecthlim+0x20/frame 0xfffffe2f4351b650 > sctp_lowlevel_chunk_output() at sctp_lowlevel_chunk_output+0xeb2/frame 0xfffffe2f4351b790 > sctp_chunk_output() at sctp_chunk_output+0x68c/frame 0xfffffe2f4351c110 > sctp_timeout_handler() at sctp_timeout_handler+0x2d8/frame 0xfffffe2f4351c180 > softclock_call_cc() at softclock_call_cc+0x15b/frame 0xfffffe2f4351c230 > softclock() at softclock+0x7c/frame 0xfffffe2f4351c260 > intr_event_execute_handlers() at intr_event_execute_handlers+0x9a/frame 0xfffffe2f4351c2a0 > ithread_loop() at ithread_loop+0xb7/frame 0xfffffe2f4351c2f0 > fork_exit() at fork_exit+0x84/frame 0xfffffe2f4351c330 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe2f4351c330 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > > > From what I've gathered so far, it appears that the issue is a use-after-free where the SCTP stack gets an ifp pointer that's no longer valid. We've reproduced this issue on multiple iflib-based drivers, including ixl and the recently published ice driver code (available on phabricator). > > Additionally, we cannot reproduce it on legacy-stack drivers for ixl, or a mellanox 100G board we have. This leads me to believe that it's an issue in iflib rather than in the specific device drivers. > > I am not sure exactly what's going wrong here... anyone have suggestions? I thought it might be an issue of when ether_ifdetach is called. That function is supposed to clear all of the pre-existing routes from the route entry list. I'm thinking maybe somehow a route gets added after ether_ifdetach is called. > > In the iflib_device_deregister function, ether_ifdetach is called just after iflib_stop, (which would call a device's if_stop routine), and then the task queues are shutdown, a driver's ifdi_detach handler is called, and the ifp is free'd at the end. In the ixl legacy driver, ether_ifdetach is called prior to the stop routine. However, in the mlx5 driver, it's called after a call to close_locked()... > > So I'm really not sure exactly what could cause a stale ifp pointer to get into the route entry list. Nominally, ifnet drivers should call ether_ifdetach first to remove public references to the ifnet and only call their stop routine after that has returned. This ensures any open if_ioctl invocations have completed, etc. before the stop routine is invoked. Otherwise you are open to a race where the inteface can be upped via an ioctl after you have stopped the hardware. Any other references to the ifnet via eventhandlers, etc. should also be deregistered before calling the stop routine. After the hardware is stopped, interrupt handlers should be torn down and callouts and tasks drained to ensure there are no other references to the ifp outside of the thread running detach. After that you can release device resources, destroy mutexes, free the ifp, etc. Note that drivers have to be prepared for ether_ifdetach to invoke if_ioctl (e.g. when detaching bpf), but of the drivers I've looked at this has generally been a non-issue. It sounds like iflib should be doing the detach before calling iflib_stop. -- John Baldwin From owner-freebsd-net@freebsd.org Thu Oct 17 19:31:02 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DDCBE15BCF8 for ; Thu, 17 Oct 2019 19:31:02 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fmsmga104.fm.intel.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vK5d1d7xz4cLH; Thu, 17 Oct 2019 19:31:00 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2019 12:30:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,308,1566889200"; d="scan'208";a="186591176" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga007.jf.intel.com with ESMTP; 17 Oct 2019 12:30:49 -0700 Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 17 Oct 2019 12:30:49 -0700 Received: from orsmsx121.amr.corp.intel.com ([169.254.10.88]) by ORSMSX154.amr.corp.intel.com ([169.254.11.174]) with mapi id 14.03.0439.000; Thu, 17 Oct 2019 12:30:49 -0700 From: "Keller, Jacob E" To: John Baldwin , "freebsd-net@freebsd.org" CC: "shurd@llnw.com" , "Joyner, Eric" Subject: RE: panic on invalid ifp pointer in iflib drivers Thread-Topic: panic on invalid ifp pointer in iflib drivers Thread-Index: AdWEZQwvUgSbd6eoRs2vy4mdxXWSPwA3ezeAAAiyLPA= Date: Thu, 17 Oct 2019 19:30:48 +0000 Message-ID: <02874ECE860811409154E81DA85FBB5896931107@ORSMSX121.amr.corp.intel.com> References: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> <23f1e835-5dbb-055b-3768-f361311a9387@FreeBSD.org> In-Reply-To: <23f1e835-5dbb-055b-3768-f361311a9387@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTJkZDBkMjctM2UxMy00MjgxLTk1N2EtMGQ3NzkyNjczYmUxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSjZEZWxlbHdDVlBsOTM0cFZDZHJPaWtGQVB0azIwRER2RDk3MEgrOTg0VE9mYm5kT3Q1R1JnckZEZGZiOXplRCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 46vK5d1d7xz4cLH X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=intel.com; spf=pass (mx1.freebsd.org: domain of jacob.e.keller@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=jacob.e.keller@intel.com X-Spamd-Result: default: False [-9.78 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:192.55.52.120/32]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-3.78)[ip: (-9.91), ipnet: 192.55.52.0/24(-4.96), asn: 4983(-3.96), country: US(-0.05)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[120.52.55.192.list.dnswl.org : 127.0.9.2]; DMARC_POLICY_ALLOW(-0.50)[intel.com,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4983, ipnet:192.55.52.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; WHITELIST_SPF_DKIM(-3.00)[intel.com:s:+] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 17 Oct 2019 19:31:02 -0000 > -----Original Message----- > From: John Baldwin > Sent: Thursday, October 17, 2019 9:31 AM > To: Keller, Jacob E ; freebsd-net@freebsd.org > Cc: shurd@llnw.com; Joyner, Eric > Subject: Re: panic on invalid ifp pointer in iflib drivers >=20 > On 10/16/19 2:16 PM, Keller, Jacob E wrote: > > Hi, > > > > I'm investigating an issue on the iflib ixl driver in 11.3-RELEASE as w= ell as 12- > RELEASE. We found a panic in that occurs if SCTP/IPv6 traffic is being tr= ansmitted > while the device is detached: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0xfffffe0000411e38 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff80c84700 > > stack pointer =3D 0x28:0xfffffe2f4351b600 > > frame pointer =3D 0x28:0xfffffe2f4351b650 > > 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 12 (swi4: clock (0)) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe2f4351b2c0 > > vpanic() at vpanic+0x17e/frame 0xfffffe2f4351b320 > > panic() at panic+0x43/frame 0xfffffe2f4351b380 > > trap_fatal() at trap_fatal+0x369/frame 0xfffffe2f4351b3d0 > > trap_pfault() at trap_pfault+0x62/frame 0xfffffe2f4351b420 > > trap() at trap+0x2b3/frame 0xfffffe2f4351b530 > > calltrap() at calltrap+0x8/frame 0xfffffe2f4351b530 > > --- trap 0xc, rip =3D 0xffffffff80c84700, rsp =3D 0xfffffe2f4351b600, r= bp =3D > 0xfffffe2f4351b650 --- > > in6_selecthlim() at in6_selecthlim+0x20/frame 0xfffffe2f4351b650 > > sctp_lowlevel_chunk_output() at sctp_lowlevel_chunk_output+0xeb2/frame > 0xfffffe2f4351b790 > > sctp_chunk_output() at sctp_chunk_output+0x68c/frame 0xfffffe2f4351c110 > > sctp_timeout_handler() at sctp_timeout_handler+0x2d8/frame > 0xfffffe2f4351c180 > > softclock_call_cc() at softclock_call_cc+0x15b/frame 0xfffffe2f4351c230 > > softclock() at softclock+0x7c/frame 0xfffffe2f4351c260 > > intr_event_execute_handlers() at intr_event_execute_handlers+0x9a/frame > 0xfffffe2f4351c2a0 > > ithread_loop() at ithread_loop+0xb7/frame 0xfffffe2f4351c2f0 > > fork_exit() at fork_exit+0x84/frame 0xfffffe2f4351c330 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe2f4351c330 > > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > > KDB: enter: panic > > > > > > From what I've gathered so far, it appears that the issue is a use-afte= r-free > where the SCTP stack gets an ifp pointer that's no longer valid. We've re= produced > this issue on multiple iflib-based drivers, including ixl and the recentl= y published > ice driver code (available on phabricator). > > > > Additionally, we cannot reproduce it on legacy-stack drivers for ixl, o= r a > mellanox 100G board we have. This leads me to believe that it's an issue = in iflib > rather than in the specific device drivers. > > > > I am not sure exactly what's going wrong here... anyone have suggestion= s? I > thought it might be an issue of when ether_ifdetach is called. That funct= ion is > supposed to clear all of the pre-existing routes from the route entry lis= t. I'm > thinking maybe somehow a route gets added after ether_ifdetach is called. > > > > In the iflib_device_deregister function, ether_ifdetach is called just = after > iflib_stop, (which would call a device's if_stop routine), and then the t= ask queues > are shutdown, a driver's ifdi_detach handler is called, and the ifp is fr= ee'd at the > end. In the ixl legacy driver, ether_ifdetach is called prior to the stop= routine. > However, in the mlx5 driver, it's called after a call to close_locked()..= . > > > > So I'm really not sure exactly what could cause a stale ifp pointer to = get into the > route entry list. >=20 > Nominally, ifnet drivers should call ether_ifdetach first to remove publi= c > references to the ifnet and only call their stop routine after that has r= eturned. > This ensures any open if_ioctl invocations have completed, etc. before th= e > stop routine is invoked. Otherwise you are open to a race where the inte= face > can be upped via an ioctl after you have stopped the hardware. >=20 So we should (a) move ether_ifdetach before the stop, and... > Any other references to the ifnet via eventhandlers, etc. should also be > deregistered before calling the stop routine. >=20 (b) make sure all of the event handlers are moved before the stop too. > After the hardware is stopped, interrupt handlers should be torn down and > callouts > and tasks drained to ensure there are no other references to the ifp outs= ide of > the thread running detach. >=20 > After that you can release device resources, destroy mutexes, free the if= p, etc. > Note that drivers have to be prepared for ether_ifdetach to invoke if_ioc= tl (e.g. > when detaching bpf), but of the drivers I've looked at this has generally= been a > non-issue. >=20 > It sounds like iflib should be doing the detach before calling iflib_stop= . >=20 Right. I think also the VLAN event handlers need to be moved too. Let me give that a try out to see if it fixes things. Thanks, Jake > -- > John Baldwin From owner-freebsd-net@freebsd.org Thu Oct 17 23:22:18 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 01EAB15FFE7 for ; Thu, 17 Oct 2019 23:22:18 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fmsmga106.fm.intel.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vQDS5D6Bz3MfP; Thu, 17 Oct 2019 23:22:16 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2019 16:22:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,309,1566889200"; d="scan'208";a="347915192" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga004.jf.intel.com with ESMTP; 17 Oct 2019 16:22:13 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 17 Oct 2019 16:22:12 -0700 Received: from orsmsx121.amr.corp.intel.com ([169.254.10.88]) by ORSMSX152.amr.corp.intel.com ([169.254.8.128]) with mapi id 14.03.0439.000; Thu, 17 Oct 2019 16:22:12 -0700 From: "Keller, Jacob E" To: John Baldwin , "freebsd-net@freebsd.org" CC: "shurd@llnw.com" , "Joyner, Eric" Subject: RE: panic on invalid ifp pointer in iflib drivers Thread-Topic: panic on invalid ifp pointer in iflib drivers Thread-Index: AdWEZQwvUgSbd6eoRs2vy4mdxXWSPwA3ezeAAACRPQA= Date: Thu, 17 Oct 2019 23:22:12 +0000 Message-ID: <02874ECE860811409154E81DA85FBB5896931470@ORSMSX121.amr.corp.intel.com> References: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> <23f1e835-5dbb-055b-3768-f361311a9387@FreeBSD.org> In-Reply-To: <23f1e835-5dbb-055b-3768-f361311a9387@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTA4ODA1YjktMjJkYy00Mzg1LThkNDYtNjNjZGI2MzVkZDkxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiMVwvSkExYlg2XC9TZDRtK2pBNzdVSFUydE1sS00ya1E0T1crejBnMHljTnplWnhCSjlGVGdWdGNEMnQ2ZzJLWFpKIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 46vQDS5D6Bz3MfP X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=intel.com; spf=pass (mx1.freebsd.org: domain of jacob.e.keller@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=jacob.e.keller@intel.com X-Spamd-Result: default: False [-9.78 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:192.55.52.136/32]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-3.78)[ip: (-9.91), ipnet: 192.55.52.0/24(-4.96), asn: 4983(-3.96), country: US(-0.05)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[136.52.55.192.list.dnswl.org : 127.0.9.2]; DMARC_POLICY_ALLOW(-0.50)[intel.com,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4983, ipnet:192.55.52.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; WHITELIST_SPF_DKIM(-3.00)[intel.com:s:+] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 17 Oct 2019 23:22:18 -0000 > -----Original Message----- > From: John Baldwin > Sent: Thursday, October 17, 2019 9:31 AM > To: Keller, Jacob E ; freebsd-net@freebsd.org > Cc: shurd@llnw.com; Joyner, Eric > Subject: Re: panic on invalid ifp pointer in iflib drivers >=20 > Nominally, ifnet drivers should call ether_ifdetach first to remove publi= c > references to the ifnet and only call their stop routine after that has r= eturned. > This ensures any open if_ioctl invocations have completed, etc. before th= e > stop routine is invoked. Otherwise you are open to a race where the inte= face > can be upped via an ioctl after you have stopped the hardware. >=20 > Any other references to the ifnet via eventhandlers, etc. should also be > deregistered before calling the stop routine. Looks like iflib moved this much later when we refactored to add a shared f= unction to deregister VLAN handlers... >=20 > After the hardware is stopped, interrupt handlers should be torn down and > callouts > and tasks drained to ensure there are no other references to the ifp outs= ide of > the thread running detach. >=20 > After that you can release device resources, destroy mutexes, free the if= p, etc. > Note that drivers have to be prepared for ether_ifdetach to invoke if_ioc= tl (e.g. > when detaching bpf), but of the drivers I've looked at this has generally= been a > non-issue. >=20 > It sounds like iflib should be doing the detach before calling iflib_stop= . >=20 I tested a patch that moved ether_ifdetach above the call to iflib_stop. This seems to have made the issue significantly harder to reproduce, but af= ter multiple attach/detach cycles with IPv6 traffic: (INVARIANTS and WITNES= S are enabled, as well as meguard protecting ifnet) Unread portion of the kernel message buffer: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ip6qlock (ip6qlock) r =3D 0 (0xfffffe00007aa848) lock= ed @ /usr/src/sys/netinet6/frag6.c:849 shared rw vnet_rwlock (vnet_rwlock) r =3D 0 (0xffffffff820be700) locked @ /= usr/src/sys/netinet6/frag6.c:845 stack backtrace: #0 0xffffffff80bb6f83 at witness_debugger+0x73 #1 0xffffffff80bb7fa2 at witness_warn+0x442 #2 0xffffffff8108a0f3 at trap_pfault+0x53 #3 0xffffffff810896e4 at trap+0x2b4 #4 0xffffffff8106201c at calltrap+0x8 #5 0xffffffff80d8c07a at icmp6_error+0x4aa #6 0xffffffff80d8b30e at frag6_freef+0x10e #7 0xffffffff80d8b551 at frag6_slowtimo+0x111 #8 0xffffffff80bdcda4 at pfslowtimo+0x54 #9 0xffffffff80b65bdf at softclock_call_cc+0x13f #10 0xffffffff80b65f9c at softclock+0x7c #11 0xffffffff80b0f857 at ithread_loop+0x187 #12 0xffffffff80b0c4a4 at fork_exit+0x84 #13 0xffffffff8106305e at fork_trampoline+0xe Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xfffffe0000825dd8 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80d8c5b2 stack pointer =3D 0x28:0xfffffe1fc28c6ff0 frame pointer =3D 0x28:0xfffffe1fc28c7090 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 12 (swi4: clock (0)) trap number =3D 12 panic: page fault cpuid =3D 0 time =3D 1571354026 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1fc28c6= cb0 vpanic() at vpanic+0x19d/frame 0xfffffe1fc28c6d00 panic() at panic+0x43/frame 0xfffffe1fc28c6d60 trap_fatal() at trap_fatal+0x39c/frame 0xfffffe1fc28c6dc0 trap_pfault() at trap_pfault+0x62/frame 0xfffffe1fc28c6e10 trap() at trap+0x2b4/frame 0xfffffe1fc28c6f20 calltrap() at calltrap+0x8/frame 0xfffffe1fc28c6f20 --- trap 0xc, rip =3D 0xffffffff80d8c5b2, rsp =3D 0xfffffe1fc28c6ff0, rbp = =3D 0xfffffe1fc28c7090 --- icmp6_reflect() at icmp6_reflect+0x242/frame 0xfffffe1fc28c7090 icmp6_error() at icmp6_error+0x4aa/frame 0xfffffe1fc28c70e0 frag6_freef() at frag6_freef+0x10e/frame 0xfffffe1fc28c7130 frag6_slowtimo() at frag6_slowtimo+0x111/frame 0xfffffe1fc28c7180 pfslowtimo() at pfslowtimo+0x54/frame 0xfffffe1fc28c71b0 softclock_call_cc() at softclock_call_cc+0x13f/frame 0xfffffe1fc28c7260 softclock() at softclock+0x7c/frame 0xfffffe1fc28c7290 ithread_loop() at ithread_loop+0x187/frame 0xfffffe1fc28c72f0 fork_exit() at fork_exit+0x84/frame 0xfffffe1fc28c7330 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe1fc28c7330 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- KDB: enter: panic Hmm.. now that I look at that more closely I think it's a separate issue. > -- > John Baldwin From owner-freebsd-net@freebsd.org Thu Oct 17 23:33:59 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0AF21603D3 for ; Thu, 17 Oct 2019 23:33:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vQTz5K9nz3NHm; Thu, 17 Oct 2019 23:33:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id E5404C9A3; Thu, 17 Oct 2019 23:33:58 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: panic on invalid ifp pointer in iflib drivers To: "Keller, Jacob E" , "freebsd-net@freebsd.org" Cc: "shurd@llnw.com" , "Joyner, Eric" References: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> <23f1e835-5dbb-055b-3768-f361311a9387@FreeBSD.org> <02874ECE860811409154E81DA85FBB5896931470@ORSMSX121.amr.corp.intel.com> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <80ba676b-1b26-5384-b7ef-0d853988616d@FreeBSD.org> Date: Thu, 17 Oct 2019 16:33:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <02874ECE860811409154E81DA85FBB5896931470@ORSMSX121.amr.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 17 Oct 2019 23:33:59 -0000 On 10/17/19 4:22 PM, Keller, Jacob E wrote: > Hmm.. now that I look at that more closely I think it's a separate issue. This may just be the rcvif issue where we don't reference count the ifp we store in rcvif in mbufs? That was my reaction to your first e-mail except that you said it wasn't reproducible on some other drivers. I wonder if other drivers would also provoke this if you just ran them in a detach/attach loop long enough. -- John Baldwin From owner-freebsd-net@freebsd.org Thu Oct 17 23:34:24 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A1162160479 for ; Thu, 17 Oct 2019 23:34:24 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orsmga105.jf.intel.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vQVR60LCz3NMb; Thu, 17 Oct 2019 23:34:23 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2019 16:34:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,309,1566889200"; d="scan'208";a="199534948" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga003.jf.intel.com with ESMTP; 17 Oct 2019 16:34:10 -0700 Received: from orsmsx159.amr.corp.intel.com (10.22.240.24) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 17 Oct 2019 16:34:09 -0700 Received: from orsmsx121.amr.corp.intel.com ([169.254.10.88]) by ORSMSX159.amr.corp.intel.com ([169.254.11.61]) with mapi id 14.03.0439.000; Thu, 17 Oct 2019 16:34:09 -0700 From: "Keller, Jacob E" To: 'John Baldwin' , "'freebsd-net@freebsd.org'" CC: "'shurd@llnw.com'" , "Joyner, Eric" Subject: RE: panic on invalid ifp pointer in iflib drivers Thread-Topic: panic on invalid ifp pointer in iflib drivers Thread-Index: AdWEZQwvUgSbd6eoRs2vy4mdxXWSPwA3ezeAAACRPQAAAINf4A== Date: Thu, 17 Oct 2019 23:34:09 +0000 Message-ID: <02874ECE860811409154E81DA85FBB58969314A1@ORSMSX121.amr.corp.intel.com> References: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> <23f1e835-5dbb-055b-3768-f361311a9387@FreeBSD.org> <02874ECE860811409154E81DA85FBB5896931470@ORSMSX121.amr.corp.intel.com> In-Reply-To: <02874ECE860811409154E81DA85FBB5896931470@ORSMSX121.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTA4ODA1YjktMjJkYy00Mzg1LThkNDYtNjNjZGI2MzVkZDkxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiMVwvSkExYlg2XC9TZDRtK2pBNzdVSFUydE1sS00ya1E0T1crejBnMHljTnplWnhCSjlGVGdWdGNEMnQ2ZzJLWFpKIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 46vQVR60LCz3NMb X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=intel.com; spf=pass (mx1.freebsd.org: domain of jacob.e.keller@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=jacob.e.keller@intel.com X-Spamd-Result: default: False [-9.77 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:134.134.136.100/32]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-3.77)[ip: (-9.88), ipnet: 134.134.136.0/24(-4.95), asn: 4983(-3.96), country: US(-0.05)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[100.136.134.134.list.dnswl.org : 127.0.9.2]; DMARC_POLICY_ALLOW(-0.50)[intel.com,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4983, ipnet:134.134.136.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; WHITELIST_SPF_DKIM(-3.00)[intel.com:s:+] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 17 Oct 2019 23:34:24 -0000 > -----Original Message----- > From: Keller, Jacob E > Sent: Thursday, October 17, 2019 4:22 PM > To: John Baldwin ; freebsd-net@freebsd.org > Cc: shurd@llnw.com; Joyner, Eric > Subject: RE: panic on invalid ifp pointer in iflib drivers >=20 > > -----Original Message----- > > From: John Baldwin > > Sent: Thursday, October 17, 2019 9:31 AM > > To: Keller, Jacob E ; freebsd-net@freebsd.org > > Cc: shurd@llnw.com; Joyner, Eric > > Subject: Re: panic on invalid ifp pointer in iflib drivers > > > > Nominally, ifnet drivers should call ether_ifdetach first to remove pub= lic > > references to the ifnet and only call their stop routine after that has= returned. > > This ensures any open if_ioctl invocations have completed, etc. before = the > > stop routine is invoked. Otherwise you are open to a race where the in= teface > > can be upped via an ioctl after you have stopped the hardware. > > > > Any other references to the ifnet via eventhandlers, etc. should also b= e > > deregistered before calling the stop routine. >=20 > Looks like iflib moved this much later when we refactored to add a shared > function to deregister VLAN handlers... >=20 > > > > After the hardware is stopped, interrupt handlers should be torn down a= nd > > callouts > > and tasks drained to ensure there are no other references to the ifp ou= tside of > > the thread running detach. > > > > After that you can release device resources, destroy mutexes, free the = ifp, etc. > > Note that drivers have to be prepared for ether_ifdetach to invoke if_i= octl (e.g. > > when detaching bpf), but of the drivers I've looked at this has general= ly been a > > non-issue. > > > > It sounds like iflib should be doing the detach before calling iflib_st= op. > > >=20 > I tested a patch that moved ether_ifdetach above the call to iflib_stop. >=20 > This seems to have made the issue significantly harder to reproduce, but = after > multiple attach/detach cycles with IPv6 traffic: (INVARIANTS and WITNESS = are > enabled, as well as meguard protecting ifnet) >=20 > Unread portion of the kernel message buffer: > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex ip6qlock (ip6qlock) r =3D 0 (0xfffffe00007aa848) lo= cked @ > /usr/src/sys/netinet6/frag6.c:849 > shared rw vnet_rwlock (vnet_rwlock) r =3D 0 (0xffffffff820be700) locked @ > /usr/src/sys/netinet6/frag6.c:845 > stack backtrace: > #0 0xffffffff80bb6f83 at witness_debugger+0x73 > #1 0xffffffff80bb7fa2 at witness_warn+0x442 > #2 0xffffffff8108a0f3 at trap_pfault+0x53 > #3 0xffffffff810896e4 at trap+0x2b4 > #4 0xffffffff8106201c at calltrap+0x8 > #5 0xffffffff80d8c07a at icmp6_error+0x4aa > #6 0xffffffff80d8b30e at frag6_freef+0x10e > #7 0xffffffff80d8b551 at frag6_slowtimo+0x111 > #8 0xffffffff80bdcda4 at pfslowtimo+0x54 > #9 0xffffffff80b65bdf at softclock_call_cc+0x13f > #10 0xffffffff80b65f9c at softclock+0x7c > #11 0xffffffff80b0f857 at ithread_loop+0x187 > #12 0xffffffff80b0c4a4 at fork_exit+0x84 > #13 0xffffffff8106305e at fork_trampoline+0xe >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0xfffffe0000825dd8 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80d8c5b2 > stack pointer =3D 0x28:0xfffffe1fc28c6ff0 > frame pointer =3D 0x28:0xfffffe1fc28c7090 > 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 12 (swi4: clock (0)) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > time =3D 1571354026 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe1fc28c6cb0 > vpanic() at vpanic+0x19d/frame 0xfffffe1fc28c6d00 > panic() at panic+0x43/frame 0xfffffe1fc28c6d60 > trap_fatal() at trap_fatal+0x39c/frame 0xfffffe1fc28c6dc0 > trap_pfault() at trap_pfault+0x62/frame 0xfffffe1fc28c6e10 > trap() at trap+0x2b4/frame 0xfffffe1fc28c6f20 > calltrap() at calltrap+0x8/frame 0xfffffe1fc28c6f20 > --- trap 0xc, rip =3D 0xffffffff80d8c5b2, rsp =3D 0xfffffe1fc28c6ff0, rbp= =3D > 0xfffffe1fc28c7090 --- > icmp6_reflect() at icmp6_reflect+0x242/frame 0xfffffe1fc28c7090 > icmp6_error() at icmp6_error+0x4aa/frame 0xfffffe1fc28c70e0 > frag6_freef() at frag6_freef+0x10e/frame 0xfffffe1fc28c7130 > frag6_slowtimo() at frag6_slowtimo+0x111/frame 0xfffffe1fc28c7180 > pfslowtimo() at pfslowtimo+0x54/frame 0xfffffe1fc28c71b0 > softclock_call_cc() at softclock_call_cc+0x13f/frame 0xfffffe1fc28c7260 > softclock() at softclock+0x7c/frame 0xfffffe1fc28c7290 > ithread_loop() at ithread_loop+0x187/frame 0xfffffe1fc28c72f0 > fork_exit() at fork_exit+0x84/frame 0xfffffe1fc28c7330 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe1fc28c7330 > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > KDB: enter: panic >=20 >=20 > Hmm.. now that I look at that more closely I think it's a separate issue. >=20 KGDB shows this as the spot where it panics: (kgdb) list /usr/src/sys/netinet6/icmp6.c:2129 2124 src6 =3D ia->ia_addr.sin6_addr; 2125 srcp =3D &src6; 2126 2127 if (m->m_pkthdr.rcvif !=3D NULL) { 2128 /* XXX: This may not be the outgoin= g interface */ 2129 hlim =3D ND_IFINFO(m->m_pkthdr.rcvi= f)->chlim; 2130 } else 2131 hlim =3D V_ip6_defhlim; 2132 } 2133 if (ia !=3D NULL) It looks like a received packet ends up with the stale IFP pointer... Thanks, Jake > > -- > > John Baldwin From owner-freebsd-net@freebsd.org Thu Oct 17 23:57:14 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0F820160D8D for ; Thu, 17 Oct 2019 23:57:14 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fmsmga103.fm.intel.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vR0m5Szjz3PVr; Thu, 17 Oct 2019 23:57:12 +0000 (UTC) (envelope-from jacob.e.keller@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2019 16:57:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,309,1566889200"; d="scan'208";a="221567660" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by fmsmga004.fm.intel.com with ESMTP; 17 Oct 2019 16:57:10 -0700 Received: from orsmsx125.amr.corp.intel.com (10.22.240.125) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 17 Oct 2019 16:57:09 -0700 Received: from orsmsx121.amr.corp.intel.com ([169.254.10.88]) by ORSMSX125.amr.corp.intel.com ([169.254.3.167]) with mapi id 14.03.0439.000; Thu, 17 Oct 2019 16:57:09 -0700 From: "Keller, Jacob E" To: John Baldwin , "freebsd-net@freebsd.org" CC: "shurd@llnw.com" , "Joyner, Eric" Subject: RE: panic on invalid ifp pointer in iflib drivers Thread-Topic: panic on invalid ifp pointer in iflib drivers Thread-Index: AdWEZQwvUgSbd6eoRs2vy4mdxXWSPwA3ezeAAACRPQAADjDzAAAN6Eww Date: Thu, 17 Oct 2019 23:57:08 +0000 Message-ID: <02874ECE860811409154E81DA85FBB5896931509@ORSMSX121.amr.corp.intel.com> References: <02874ECE860811409154E81DA85FBB589692E0D4@ORSMSX121.amr.corp.intel.com> <23f1e835-5dbb-055b-3768-f361311a9387@FreeBSD.org> <02874ECE860811409154E81DA85FBB5896931470@ORSMSX121.amr.corp.intel.com> <80ba676b-1b26-5384-b7ef-0d853988616d@FreeBSD.org> In-Reply-To: <80ba676b-1b26-5384-b7ef-0d853988616d@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTNhODcxNjItZTk2Yy00OTUyLTkzYWEtMWVlZDRhOTM3NjJhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiK2RiREZsczVYYUJFa1pFbzFKRWZKTXI1bXhidkRGdmlxNUdhaXIxUzNnS0lINWtRbUhcLzdZWjBDRXZrdTdraWUifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Rspamd-Queue-Id: 46vR0m5Szjz3PVr X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=intel.com; spf=pass (mx1.freebsd.org: domain of jacob.e.keller@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=jacob.e.keller@intel.com X-Spamd-Result: default: False [-9.98 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:192.55.52.115/32]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[intel.com,none]; IP_SCORE(-3.78)[ip: (-9.91), ipnet: 192.55.52.0/24(-4.96), asn: 4983(-3.96), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4983, ipnet:192.55.52.0/24, country:US]; RCVD_IN_DNSWL_HI(-0.50)[115.52.55.192.list.dnswl.org : 127.0.9.3]; WHITELIST_SPF_DKIM(-3.00)[intel.com:s:+] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 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, 17 Oct 2019 23:57:14 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIEJhbGR3aW4gPGpoYkBG cmVlQlNELm9yZz4NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTkgNDozNCBQTQ0K PiBUbzogS2VsbGVyLCBKYWNvYiBFIDxqYWNvYi5lLmtlbGxlckBpbnRlbC5jb20+OyBmcmVlYnNk LW5ldEBmcmVlYnNkLm9yZw0KPiBDYzogc2h1cmRAbGxudy5jb207IEpveW5lciwgRXJpYyA8ZXJp Yy5qb3luZXJAaW50ZWwuY29tPg0KPiBTdWJqZWN0OiBSZTogcGFuaWMgb24gaW52YWxpZCBpZnAg cG9pbnRlciBpbiBpZmxpYiBkcml2ZXJzDQo+IA0KPiBPbiAxMC8xNy8xOSA0OjIyIFBNLCBLZWxs ZXIsIEphY29iIEUgd3JvdGU6DQo+ID4gSG1tLi4gbm93IHRoYXQgSSBsb29rIGF0IHRoYXQgbW9y ZSBjbG9zZWx5IEkgdGhpbmsgaXQncyBhIHNlcGFyYXRlIGlzc3VlLg0KPiANCj4gVGhpcyBtYXkg anVzdCBiZSB0aGUgcmN2aWYgaXNzdWUgd2hlcmUgd2UgZG9uJ3QgcmVmZXJlbmNlIGNvdW50IHRo ZSBpZnAgd2UNCj4gc3RvcmUgaW4gcmN2aWYgaW4gbWJ1ZnM/ICBUaGF0IHdhcyBteSByZWFjdGlv biB0byB5b3VyIGZpcnN0IGUtbWFpbCBleGNlcHQNCj4gdGhhdCB5b3Ugc2FpZCBpdCB3YXNuJ3Qg cmVwcm9kdWNpYmxlIG9uIHNvbWUgb3RoZXIgZHJpdmVycy4gIEkgd29uZGVyIGlmDQo+IG90aGVy IGRyaXZlcnMgd291bGQgYWxzbyBwcm92b2tlIHRoaXMgaWYgeW91IGp1c3QgcmFuIHRoZW0gaW4g YSBkZXRhY2gvYXR0YWNoDQo+IGxvb3AgbG9uZyBlbm91Z2guDQo+IA0KDQpUaGlzIGlzIGFsbW9z dCBjZXJ0YWlubHkgdGhlIHJjdmlmIGlzc3VlIGJhc2VkIG9uIHdoZXJlIGl0IHBhbmljcy4NCg0K SSBuZXZlciBzYXcgdGhpcyBwYW5pYyBiZWZvcmUuIEkgJ3ZlIGFsc28gb25seSByZXByb2R1Y2Vk IGl0IG9uIGEga2VybmVsIHdpdGggSU5WQVJJQU5UUyBhbmQgbWVtZ3VhcmQgc2V0IHRvIGlmbmV0 Lg0KDQpUaGFua3MsDQpKYWtlDQoNCg== From owner-freebsd-net@freebsd.org Fri Oct 18 05:51:10 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2113B167266; Fri, 18 Oct 2019 05:51:10 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "anubis.delphij.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vZs84tvMz4BBm; Fri, 18 Oct 2019 05:51:08 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from p51.home.us.delphij.net (unknown [IPv6:2601:646:8600:d04a:e670:b8ff:fe5c:4e69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 140634A2BE; Thu, 17 Oct 2019 22:51:01 -0700 (PDT) Reply-To: d@delphij.net To: freebsd-net , freebsd-current@freebsd.org From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= mQINBFuSR4oBEACvvEgwRIHs6IcSP/yaDtySF78Ji3rP29qdiQsxhMsOtvtffdbS56VApIWO UFb3/iN2gA8HwLvrmjijN0HEoLVX7na1WARmxRYzQMtApsZIUTtx7hnUYlsi2F5odZa6CDW9 a954DLRzYxiUwYDcu5Zjl9bglK1H8e/N9uC0Vuigr4teWfh86brzOyf819QzwFVYfMIK4ihw QGwMvTzbyVuCFy+LENkmcVYni70oQy6rZ5ktSuYbuOFvu7inRRfhSWPHziV7k+bW88sJ7xhv lBlegcnhkSudWX2M8tZ3MO1PJOcyys0CJlsBY5Weiog2lIPi05h/E9pZ9mc1Vud17iqDaL6w RaggOUhuPfDGCdO5ro82W4BZGeQMRnRF5Ntk+t2ShIH4nn3xRLV0E5nziCiKlgiMqOrz/ZTL QTVbHrCuiwD+fSK14y0oHbkOLYTYLlgh1JbwfY2Ty7elOYiWzyeJ7sJh2dF91NSEneWIOys3 mBpuvtU3nSzzTvAB48VV+Nbg1CpIOgNlPjj7uhIum/Z/VjUaJEyaLpTIRh0MVJVcbP7hXSqZ NA35EEZZVnWEOYdycm4CmEdeNPWkrAf2Ya77iR5VLGypwMlsUMQPh+sKVWDD38M8stFGBBNm d01Hi74Bsq5hKan654dOqMt5eYklrVj0ucMzFQtus7oE502UswARAQABtBxYaW4gTEkgPGRl bHBoaWpAZGVscGhpai5uZXQ+iQJUBBMBCgA+FiEEceNg5NEMZIki80nQQHl/fJX0g08FAluS R/YCGwMFCQmuhAAFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQQHl/fJX0g0+2Og//bWpE F2V5/M5l6YW1T8oLcT9rIOH6oq9M0LMNRgFeiNNnilGIeeIgtOGBRueG4CZiZAvsRPJkrO70 1R2SrdkCIvwGUzUAxx1NfBWb+vgm4fgkW/MotGonceM5v0qfSKKXasWvDctkK28aG+IoQzmi FjXNW4+ju4zeQFYwD4ZDWqw9MqO0hVb24uW3dxtQhbfmOLgJ/PEDMQaFuANbW1c+iR0BQA3D Go/EeMY4kpN8on6Aqt/S/4JVltudfQ9OXdjQsC7netSaB9K3mHGt9aKAAB7RzlRY00DKkYS/ /eQwLzGPmK7yX13M68mMDjBs6mIR8t/E1S5OdBNhHRPNPlEbwugR4KaiCsN5yqzJoSV99fKY z2VyxjWPaG8yhHE+jmKUgIBKTfFUQEfkriQR4EASoeJ+soaMTiFDBij1Zw5n3ndLRFMB1ZCl fZLER36mAgW4m4kP83TWnDiJLxOxSOxifV8HpTFjff902H85cybg9KMwrfPDr6W19GGk5Vo1 fkza5krRMGbKWb7+74Evusi0ZxJLIOFwp5Y8eVqUMZaAD3f1ZX1M3pgXOp20QgAy+2KvMHij rLa4q+tMGRzYYD1BnFVSVdXAX5VOoTmHBcDz67DkuRwk2Byp1sgd407oEOmSwrNJlKS0TPCm xUJ2fdSQF+1/MMSRfee49vtMvz7cOrC5Ag0EW5JHigEQANiBmIFAfRNH3nzYNWC0yC+tfx3z sUwAsH1VaBM/cTib+yKtbBOSIlXWjJZWX3MHwoI/1LeGghB2mxkkX1L0pJ/vj1eXNR+sFZ32 0pYcl61Fxg/5fioG4QDTM4i3i7NR5PxDnc6UVaynSlII93DedRhZ1ROtdn4vyMgzsDiqhbL7 BthDOt5KxjqdRk4qRPSw7BovEqZLOcG5IJtf/zZUzRbM7SBljEbOAfekDGx1Br+RrYSD7/Ef Pwwzou9T8315IpBpIHyQF/dZNk3iFiB9Ed5CA71ZRYV5YoLWE9lL0j9kxOLQ5vHnX3mVq7QZ Bc7nzwZ6UhQgYmrG5+RWvuiPpGwvDRIsugJUGXucYkAQh5kuNblmkwpv6u9rNMjCNbzAylOa qdogra5EW+RUSbRz0b4iIr8nnZeAlh7BihCe7JjOwbDjoBEEEtSfVc4hD/LENqpcYVrChphf aOLB9YIXhnVDTVvMc9OklWT/81HzAaDQqOQCzEfY92199Ct9/CwRoQ2OpO8TO5+8A7b9Nb33 nmxMn09mb48ruRacMrfHxCWbgU4w9SEfbip4GcS5wGG6yTC+hw55Iwnnwus40NrJ0GEr8a4r cdsLbkvlyoNHB8ZGgyJ4aFCQ1V4qE1BnlTk7Z8BYBUkJM1odPSkVvHpCnMUjVpJ3hEOC+73Z YH1dh7lZABEBAAGJAjwEGAEKACYWIQRx42Dk0QxkiSLzSdBAeX98lfSDTwUCW5JHigIbDAUJ Ca6EAAAKCRBAeX98lfSDTz8DEACMh3poeUb+gWNF4RWFZuLteZVo0+E1JLYXQkmtrRBLXviP +Qy0pXyFAVxLM4hNIBoIDYfK9BcwrBYf7AwSKrH0GiNwFpgHCkbZd6qoZy2gB+adTnCpVCTJ KJetsH/8awkrChJWMK0ckGf3EeWMPvawG7kW7FBz70NYEZ0pOMiaEZNVtzD3wwbYWUiDFYth 83XGglOExg+1ShTW5XjQPRrdyJAO+aUW4o3lVjfyUJXMgI4rmhMiLVm06GuNrbpKIF0s+4Vd jQAjhrDQjfoXi9CkfsA/cONseuHNv1JGj3RqHiqHJq1dbrpodXp925zGDAnUGxCOBPoFopAH gVzR89GTut059GpwqsddZmU6y7rqifuam/ekJ+QRwc16vgt7pHqCrTY8WPxRZr2UpFU1wlTo COdeiFep1gq1F9jzFjJnoMaAdmC6k7bgAA+RQusOgIhJL0jIej7DoAHxmxFFCfRy+lDtpXwF gQ8HMvzHI65QWmQnMo7s6SQH/ZH5s1yR6SJq8+3lDz+dCuT42qJVqIPVvxd10LW0FNN+t7HF eLadU6ekSgD13/EYMYXlvNHkw7dAItSDxIzgRyykLz0bCU9xwNWoS4Z43+ifF9anJ+uR0ltW El1j++h6ZrD3LLuCgJIt1so0m49GzdcSpOI7LCwMlacyvafiEyjUn+tSNDsnfw== Organization: The FreeBSD Project Subject: in6_mcast: in6_joingroup attempts to acquire IN6_MULTI_LOCK when sleeping prohibited Message-ID: <51c89593-a34b-46f8-bb4b-d1793ce6d1ae@delphij.net> Date: Thu, 17 Oct 2019 22:50:54 -0700 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OFr6YL2so5qjQgyO6vj1aS3sQAFcMdUT1" X-Rspamd-Queue-Id: 46vZs84tvMz4BBm X-Spamd-Bar: ------- X-Spamd-Result: default: False [-7.47 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; HAS_REPLYTO(0.00)[d@delphij.net]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DKIM_TRACE(0.00)[delphij.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(-2.37)[ip: (-9.88), ipnet: 64.62.128.0/18(1.51), asn: 6939(-3.41), country: US(-0.05)]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 05:51:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OFr6YL2so5qjQgyO6vj1aS3sQAFcMdUT1 Content-Type: multipart/mixed; boundary="eDZYHAvp7PvqvfeHmUszNYVsJ5LoydURo"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: freebsd-net , freebsd-current@freebsd.org Message-ID: <51c89593-a34b-46f8-bb4b-d1793ce6d1ae@delphij.net> Subject: in6_mcast: in6_joingroup attempts to acquire IN6_MULTI_LOCK when sleeping prohibited --eDZYHAvp7PvqvfeHmUszNYVsJ5LoydURo Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I have seen this on boot of my laptop. It appears that in6_joingroup() was called in netisr_dispatch_src codepath, and it tried to acquire IN6_MULTI_LOCK(), which happened to sleep because we failed to acquire the sx, thus triggered the panic. =3D=3D=3D panic: sleepq_add: td 0xfffff8000ecd6000 to sleep on wchan 0xffffffff81dedfe0 with sleeping prohibited #1 0xffffffff80bbff90 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:479 #2 0xffffffff80bc03e6 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:908 #3 0xffffffff80bc0143 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:835 #4 0xffffffff80c1a2bf in sleepq_add (wchan=3D0xffffffff81dedfe0, lock=3D= 0x0, wmesg=3D0xffffffff8110f331 "in6_multi_sx", flags=3D3, queue=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:318 #5 0xffffffff80bc9ce4 in _sx_xlock_hard (sx=3D0xffffffff81dedfe0, x=3D18446735277856440320, opts=3D, file=3D, line=3D) at /usr/src/sys/kern/kern_sx.c:841 #6 0xffffffff80bc983f in _sx_xlock (sx=3D0xffffffff81dedfe0, opts=3D0, file=3D0xffffffff8113a568 "/usr/src/sys/netinet6/in6_mcast.c", line=3D= 1185) at /usr/src/sys/kern/kern_sx.c:325 #7 0xffffffff80e17dd1 in in6_joingroup (ifp=3D0xfffff80003b99800, mcaddr=3D0xfffffe00e1612e58, imf=3D, pinm=3D0xfffff80019e17300, delay=3D2) at /usr/src/sys/netinet6/in6_mcast.c:1185 #8 0xffffffff80e0fa72 in in6_update_ifa (ifp=3D0xfffff80003b99800, ifra=3D, ia=3D, flags=3D) at /usr/src/sys/netinet6/in6.c:752 #9 0xffffffff80e374c5 in nd6_ra_input (m=3D0xfffff800191d4a00, off=3D, icmp6len=3D) at /usr/src/sys/netinet6/nd6_rtr.c:2274 #10 0xffffffff80e096d5 in icmp6_input (mp=3D, offp=3D0xfffffe00e161335c, proto=3D) at /usr/src/sys/netinet6/icmp6.c:767 #11 0xffffffff80e22dff in ip6_input (m=3D0xfffff800191d4a00) at /usr/src/sys/netinet6/ip6_input.c:963 #12 0xffffffff80ceff11 in netisr_dispatch_src (proto=3D6, source=3D0, m=3D0xfffff800191d4a00) at /usr/src/sys/net/netisr.c:1127 #13 0xffffffff80cd399e in ether_demux (ifp=3D0xfffff80003b99800, m=3D) at /usr/src/sys/net/if_ethersubr.c:916 #14 0xffffffff80cd4f88 in ether_nh_input (m=3D) at /usr/src/sys/net/if_ethersubr.c:705 #15 0xffffffff80ceff11 in netisr_dispatch_src (proto=3D5, source=3D0, m=3D0xfffff800191d4a00) at /usr/src/sys/net/netisr.c:1127 #16 0xffffffff80cd3e8d in ether_input (ifp=3D0xfffff8000397a800, m=3D0x0)= at /usr/src/sys/net/if_ethersubr.c:824 #17 0xffffffff80d429f0 in sta_input (ni=3D, m=3D0xfffff800191d4a00, rxs=3D, rssi=3D, nf=3D) at /usr/src/sys/net80211/ieee80211_sta.c:891 #18 0xffffffff80d1ec2a in ieee80211_input_mimo (ni=3D0xfffffe0106c66000, m=3D0xfffff800191d4a00) at /usr/src/sys/net80211/ieee80211_input.c:10= 1 #19 0xffffffff848e55a2 in iwm_mvm_rx_rx_mpdu (sc=3D0xfffffe00e2c00000, m=3D0xfffff800191d4a00, offset=3D, stolen=3D) at /usr/src/sys/dev/iwm/if_iwm.c:3245= #20 0xffffffff848e3fee in iwm_intr (arg=3D) at /usr/src/sys/dev/iwm/if_iwm.c:5151 --eDZYHAvp7PvqvfeHmUszNYVsJ5LoydURo-- --OFr6YL2so5qjQgyO6vj1aS3sQAFcMdUT1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.17 (FreeBSD) iQIzBAEBCgAdFiEEceNg5NEMZIki80nQQHl/fJX0g08FAl2pUsQACgkQQHl/fJX0 g0+lxw/+LOegOl2SbY654sqOk2YAetgj3KUlDN8wyQ/xko23Z/zC86Ivjs9dTSQB R56FWF3i1aZRtxlr5U4Vz8i0TNO1zP+IqtvXf1K1nc3Bp9hK7IAzE9LqlhNc1A13 zxsWNWMy9FK6XG10I3lf8YNYEJjJWHRsgCjq7jPjXypwnQ2+KT1H7c1zBzk/zaac GYxemhbo+B7T9zo+YNe1krhLBdnV1BvGNX7uweJCL/hSKkVdGJGdeT2Mm/etPwqI PYEjxp+Wsf1hjCOLMOnMVluOYOv4ZLhhkl9fabchbMrkBfZ+FnktUGjIXmGFHKg7 PeZoLX2gEJw9NWq+//bguByC1f5JpQ6TNPcvCUFuXjcftHfn2h0ehVoGLz1lWuXe s/JcPRZw6idPLCXgqU0ikapjNo3+jPEeyBnhgbriRd1H5cYIgjKava6Glu2Kr0Os iRZmwQi5383MT1aNk96bWZnS9DI1TJBn1ucP6NQOYqYBiDQLs1gfn3im9sG4LNd8 7Bb6ZjyIBT0zr555UF6ka0tBjlwpeE3iQvLK/Z33MILrQ50LSnXrG8ZFLWqiB9xT 21xUOXgnvrQLnc5/adiUNR2b95LIqAMi2rFhVStSOq8DvyQXd4ruIdZTX4XaCdNt gtrm8ZORiyVTwAw5ya1OCsnyiCcYer0C4Vd0Mu5DZH9oH1U2XCM= =6vOo -----END PGP SIGNATURE----- --OFr6YL2so5qjQgyO6vj1aS3sQAFcMdUT1-- From owner-freebsd-net@freebsd.org Fri Oct 18 12:57:22 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9BADF1501FE for ; Fri, 18 Oct 2019 12:57:22 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vmJx5Cmxz4XcN for ; Fri, 18 Oct 2019 12:57:21 +0000 (UTC) (envelope-from devgs@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Cc:To :Subject:From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=Zx7RZ/0YdTpglQGsaRiTbZ9nDlzxAbIvKkU4h+z0ESU=; b=n twNMGFhGwpr2NsDWS+Y1EvpMEWVS/aZlemtCp7yJIMbKeqKhXkklMOQRBfGwziKKCXXz61M9toJmd tPDwROC2DSWPyWjZUTUugyK4ViSqIbISxgdbnzYZMIH1Z+qg/r13X9vrVuq0mtgSaSHOgx6MjDXto v0m+5VhFZHnRvfdg=; Received: from [10.10.10.39] (helo=frv39.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1iLRof-0004Sc-Gc for freebsd-net@freebsd.org; Fri, 18 Oct 2019 15:57:13 +0300 Date: Fri, 18 Oct 2019 15:57:13 +0300 From: Paul Subject: Network anomalies after update from 11.2 STABLE to 12.1 STABLE To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Received: from devgs@ukr.net by frv39.fwdcdn.com; Fri, 18 Oct 2019 15:57:13 +0300 Message-Id: <1571398510.796520000.8iwbi4pd@frv39.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 46vmJx5Cmxz4XcN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=n twNMGF; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of devgs@ukr.net designates 212.42.77.199 as permitted sender) smtp.mailfrom=devgs@ukr.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24]; FREEMAIL_FROM(0.00)[ukr.net]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; IP_SCORE(0.00)[ipnet: 212.42.77.0/24(-4.77), asn: 8856(-3.85), country: UA(0.08)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 12:57:22 -0000 Our current version is: FreeBSD 11.2-STABLE #0 r340725 New version that we have problems with: FreeBSD 12.1-STABLE #5 r352893 After update to new version we have started to observe an incredible number of errors in HTTP requests in between various services in our system. This problem appeared on all the servers that were upgraded, and seems to not be specific to concrete network card: we use different models, all are affected. During various tests, we observed a lot of spontaneous TCP stream abortions, including at the establishment stage (SYN) in cases that were 100% issue free on 11.2-STABLE. Concrete test cases will be shown below. We also want to highlight that, on numerous occasions, we have observed random, huge ACK indices in a first response to a SYN packet, instead of 1, as expected. This forces client to abort connection via RST. On the fist glance it looks like races in the kernel, because problem disappears when: * we use `dev.ixl.0.iflib.override_nrxqs=1` and `dev.ixl.0.iflib.override_ntxqs=1` * we use `dev.ixl.0.iflib.override_nrxqs=0` and `dev.ixl.0.iflib.override_ntxqs=0`, but don't issue concurrent TCP streams These are some debug log messages, emitted by 12.1-STABLE: Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16304 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16326 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16402 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16652 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16686 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:18562 to [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, no action Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:18918 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19331 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, no action Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19489 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, no action Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:17705 to [10.10.10.92]:80; syncache_timer: Response timeout, retransmitting (1) SYN|ACK Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:18066 to [10.10.10.92]:80; syncache_timer: Response timeout, retransmitting (1) SYN|ACK Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:18066 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:17705 to [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Our SYN|ACK was rejected, connection attempt aborted by remote endpoint Here, 10.10.10.92 runs 12.1-STABLE, while 10.10.10.39 is a client that runs 11.2-STABLE. In our test case we use nginx and wrk , with a minimal config, where nginx always returns error page 404. nginx is on the 12.1-STABLE, while wrk is on 11.2-STABLE. We run wrk like so: wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing and often see errors like these: Socket errors: connect 12, read 4, write 4, timeout 0 If we reverse the test, by switching two servers places, ie 12.1-STABLE becomes a client and issues requests via wrk, we see no problems at all. Same is true between two between two 11.2-STABLE machines. It seems like issue appears only when the same local port is used for multiple connections on 12.1-STABLE. Currently this is possible only when 12.1-STABLE is a server and accepts connections on port, say 80, as in our case. To confirm, this we made another test. We've configured nginx to listen on 10 different ports, 80 through 89, and then launched 10 different wrk processes, each using only one concurrent connection, meaning that we will have only 10 TCP streams, each having its own unique port on the 12.1-STABLE's side: for I in {0..9}; do wrk -c 1 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:8${I}/missing & ; done Socket errors stopped appearing. We ran this test many many times, errors just don't appear. Though, whenever we repeat a previous test, using a single port: wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing errors start appearing again and again: Socket errors: connect 8, read 14, write 9, timeout 0 We've tested different drivers with the same outcome: em driver: em0@pci0:10:0:0: class=0x020000 card=0x000015d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' ixl driver: ixl0@pci0:4:0:0: class=0x020000 card=0x00078086 chip=0x15728086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Controller X710 for 10GbE SFP+' Even the driver from ports (/usr/ports/net/intel-ixl-kmod): ixl-1.11.9 Help with this matter would be really appreciated. Best regards, -Paul From owner-freebsd-net@freebsd.org Fri Oct 18 13:51:57 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B0F81513ED for ; Fri, 18 Oct 2019 13:51:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46vnWx2Crmz4b79 for ; Fri, 18 Oct 2019 13:51:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 466B71513EC; Fri, 18 Oct 2019 13:51:57 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 462EA1513EB for ; Fri, 18 Oct 2019 13:51:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vnWx18bXz4b78 for ; Fri, 18 Oct 2019 13:51:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0C6DC9E27 for ; Fri, 18 Oct 2019 13:51:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9IDpuAW051845 for ; Fri, 18 Oct 2019 13:51:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9IDpuWw051844 for net@FreeBSD.org; Fri, 18 Oct 2019 13:51:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240685] netgraph/ng_vlan_rotate: IEEE 802.1ad VLAN manipulation netgraph node type (new type) Date: Fri, 18 Oct 2019 13:51:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: lutz@donnerhacke.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete 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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 13:51:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240685 lutz@donnerhacke.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207625|0 |1 is obsolete| | --- Comment #5 from lutz@donnerhacke.de --- Comment on attachment 207625 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D207625 Patch for netgraph/ng_vlan_rotate module Overcome by https://reviews.freebsd.org/D22076 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Oct 18 13:52:22 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 202511515DA for ; Fri, 18 Oct 2019 13:52:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46vnXQ06Hdz4bCy for ; Fri, 18 Oct 2019 13:52:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 03C121515D9; Fri, 18 Oct 2019 13:52:22 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 038CB1515D8 for ; Fri, 18 Oct 2019 13:52:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46vnXP6Nzsz4bCw for ; Fri, 18 Oct 2019 13:52:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C06049E50 for ; Fri, 18 Oct 2019 13:52:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9IDqLqd053027 for ; Fri, 18 Oct 2019 13:52:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9IDqLIl053026 for net@FreeBSD.org; Fri, 18 Oct 2019 13:52:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240685] netgraph/ng_vlan_rotate: IEEE 802.1ad VLAN manipulation netgraph node type (new type) Date: Fri, 18 Oct 2019 13:52:21 +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: 12.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: lutz@donnerhacke.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete 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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 13:52:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240685 lutz@donnerhacke.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207732|0 |1 is obsolete| | --- Comment #6 from lutz@donnerhacke.de --- Comment on attachment 207732 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D207732 Updated patch for share/man/man4/ng_vlan_rotate.4 Overcome by https://reviews.freebsd.org/D22076 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Oct 19 06:39:14 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 448A015AD3A; Sat, 19 Oct 2019 06:39:14 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46wCt82S0Lz3Lyr; Sat, 19 Oct 2019 06:39:11 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from [172.20.10.4] (ip-109-40-1-210.web.vodafone.de [109.40.1.210]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 29FEB721E281A; Sat, 19 Oct 2019 08:39:07 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Network anomalies after update from 11.2 STABLE to 12.1 STABLE From: Michael Tuexen In-Reply-To: <1571398510.796520000.8iwbi4pd@frv39.fwdcdn.com> Date: Sat, 19 Oct 2019 08:39:06 +0200 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <626DDA83-4B56-4E77-8C7F-28BC950EBF63@lurchi.franken.de> References: <1571398510.796520000.8iwbi4pd@frv39.fwdcdn.com> To: Paul X-Mailer: Apple Mail (2.3594.4.19) X-Spam-Status: No, score=-1.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, NUMERIC_HTTP_ADDR,WEIRD_PORT autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 46wCt82S0Lz3Lyr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of michael.tuexen@lurchi.franken.de has no SPF policy when checking 2001:638:a02:a001:20e:cff:fe4a:feaa) smtp.mailfrom=michael.tuexen@lurchi.franken.de X-Spamd-Result: default: False [-0.85 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[210.1.40.109.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[franken.de]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.99)[-0.990,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.46)[ip: (-4.64), ipnet: 2001:638::/32(2.26), asn: 680(0.11), country: DE(-0.01)]; NEURAL_HAM_MEDIUM(-0.70)[-0.704,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[ukr.net]; RCVD_IN_DNSWL_LOW(-0.10)[a.a.e.f.a.4.e.f.f.f.c.0.e.0.2.0.1.0.0.a.2.0.a.0.8.3.6.0.1.0.0.2.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 06:39:14 -0000 > On 18. Oct 2019, at 14:57, Paul wrote: >=20 > Our current version is: >=20 > FreeBSD 11.2-STABLE #0 r340725 >=20 > New version that we have problems with: >=20 > FreeBSD 12.1-STABLE #5 r352893 >=20 >=20 > After update to new version we have started to observe an incredible = number of=20 > errors in HTTP requests in between various services in our system. = This problem > appeared on all the servers that were upgraded, and seems to not be = specific to > concrete network card: we use different models, all are affected. >=20 > During various tests, we observed a lot of spontaneous TCP stream = abortions,=20 > including at the establishment stage (SYN) in cases that were 100% = issue free > on 11.2-STABLE. Concrete test cases will be shown below. >=20 > We also want to highlight that, on numerous occasions, we have = observed random, > huge ACK indices in a first response to a SYN packet, instead of 1, as = expected. > This forces client to abort connection via RST. >=20 > On the fist glance it looks like races in the kernel, because problem = disappears when: > * we use `dev.ixl.0.iflib.override_nrxqs=3D1` and = `dev.ixl.0.iflib.override_ntxqs=3D1` > * we use `dev.ixl.0.iflib.override_nrxqs=3D0` and = `dev.ixl.0.iflib.override_ntxqs=3D0`, but don't issue concurrent TCP = streams >=20 > These are some debug log messages, emitted by 12.1-STABLE: >=20 > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16304 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16326 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16402 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16652 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16686 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:18562 to = [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, = no action > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:18918 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19331 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to = [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, = no action > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19489 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to = [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, = no action > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:17705 to = [10.10.10.92]:80; syncache_timer: Response timeout, retransmitting (1) = SYN|ACK > Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:18066 to = [10.10.10.92]:80; syncache_timer: Response timeout, retransmitting (1) = SYN|ACK > Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:18066 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Our SYN|ACK was = rejected, connection attempt aborted by remote endpoint > Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:17705 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Our SYN|ACK was = rejected, connection attempt aborted by remote endpoint >=20 > Here, 10.10.10.92 runs 12.1-STABLE, while 10.10.10.39 is a client that = runs 11.2-STABLE. >=20 >=20 > In our test case we use nginx and wrk , with a minimal config, where = nginx always returns=20 > error page 404. nginx is on the 12.1-STABLE, while wrk is on = 11.2-STABLE. >=20 > We run wrk like so: >=20 > wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency = http://10.10.10.92:80/missing >=20 > and often see errors like these: >=20 > Socket errors: connect 12, read 4, write 4, timeout 0 >=20 > If we reverse the test, by switching two servers places, ie = 12.1-STABLE becomes a client and=20 > issues requests via wrk, we see no problems at all. Same is true = between two between two > 11.2-STABLE machines. >=20 >=20 > It seems like issue appears only when the same local port is used for = multiple connections=20 > on 12.1-STABLE. Currently this is possible only when 12.1-STABLE is a = server and accepts=20 > connections on port, say 80, as in our case. To confirm, this we made = another test. We've=20 > configured nginx to listen on 10 different ports, 80 through 89, and = then launched 10=20 > different wrk processes, each using only one concurrent connection, = meaning that we will=20 > have only 10 TCP streams, each having its own unique port on the = 12.1-STABLE's side: >=20 > for I in {0..9}; do wrk -c 1 --header "Connection: close" -d 10 -t = 1 --latency http://10.10.10.92:8${I}/missing & ; done >=20 > Socket errors stopped appearing. We ran this test many many times, = errors just don't appear. >=20 > Though, whenever we repeat a previous test, using a single port: >=20 > wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency = http://10.10.10.92:80/missing >=20 > errors start appearing again and again: >=20 > Socket errors: connect 8, read 14, write 9, timeout 0 >=20 >=20 > We've tested different drivers with the same outcome: >=20 > em driver: > em0@pci0:10:0:0: class=3D0x020000 card=3D0x000015d9 = chip=3D0x10d38086 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82574L Gigabit Network Connection' >=20 > ixl driver: > ixl0@pci0:4:0:0: class=3D0x020000 card=3D0x00078086 = chip=3D0x15728086 rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Ethernet Controller X710 for 10GbE SFP+' >=20 > Even the driver from ports (/usr/ports/net/intel-ixl-kmod): ixl-1.11.9 >=20 >=20 > Help with this matter would be really appreciated. I would like to reproduce this locally. Could you send me (privately) the config of nginx such that I can setup = two machines? Are your client/server physical machines or virtual machines? Are there = any middleboxes (NAT/Firewall/whatever) involved? One thing (no idea if it is relevant or not): Could you set sudo sysctl -w net.inet.tcp.ts_offset_per_conn=3D0 on the 12.1 machine and test and report if it helps? Best regards Michael >=20 > Best regards, > -Paul >=20 > _______________________________________________ > 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 Sat Oct 19 06:41:52 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D829D15B022; Sat, 19 Oct 2019 06:41:52 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46wCxD3F7cz3MGL; Sat, 19 Oct 2019 06:41:52 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [172.20.10.4] (ip-109-40-1-210.web.vodafone.de [109.40.1.210]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id BC028721E280C; Sat, 19 Oct 2019 08:41:47 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Network anomalies after update from 11.2 STABLE to 12.1 STABLE From: Michael Tuexen In-Reply-To: <1571398510.796520000.8iwbi4pd@frv39.fwdcdn.com> Date: Sat, 19 Oct 2019 08:41:46 +0200 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1571398510.796520000.8iwbi4pd@frv39.fwdcdn.com> To: Paul X-Mailer: Apple Mail (2.3594.4.19) X-Spam-Status: No, score=-1.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, NUMERIC_HTTP_ADDR,WEIRD_PORT autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 46wCxD3F7cz3MGL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.74 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.75)[-0.745,0]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 06:41:52 -0000 > On 18. Oct 2019, at 14:57, Paul wrote: >=20 > Our current version is: >=20 > FreeBSD 11.2-STABLE #0 r340725 >=20 > New version that we have problems with: >=20 > FreeBSD 12.1-STABLE #5 r352893 >=20 >=20 > After update to new version we have started to observe an incredible = number of=20 > errors in HTTP requests in between various services in our system. = This problem > appeared on all the servers that were upgraded, and seems to not be = specific to > concrete network card: we use different models, all are affected. >=20 > During various tests, we observed a lot of spontaneous TCP stream = abortions,=20 > including at the establishment stage (SYN) in cases that were 100% = issue free > on 11.2-STABLE. Concrete test cases will be shown below. >=20 > We also want to highlight that, on numerous occasions, we have = observed random, > huge ACK indices in a first response to a SYN packet, instead of 1, as = expected. > This forces client to abort connection via RST. >=20 > On the fist glance it looks like races in the kernel, because problem = disappears when: > * we use `dev.ixl.0.iflib.override_nrxqs=3D1` and = `dev.ixl.0.iflib.override_ntxqs=3D1` > * we use `dev.ixl.0.iflib.override_nrxqs=3D0` and = `dev.ixl.0.iflib.override_ntxqs=3D0`, but don't issue concurrent TCP = streams >=20 > These are some debug log messages, emitted by 12.1-STABLE: >=20 > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16304 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16326 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16402 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16652 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:16686 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:18562 to = [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, = no action > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:18918 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19331 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to = [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, = no action > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19340 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19489 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to = [10.10.10.92]:80 tcpflags 0x4; tcp_do_segment: Timestamp missing, = no action > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:01 test kernel: TCP: [10.10.10.39]:19580 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Spurious RST = without matching syncache entry (possibly syncookie only), segment = ignored > Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:17705 to = [10.10.10.92]:80; syncache_timer: Response timeout, retransmitting (1) = SYN|ACK > Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:18066 to = [10.10.10.92]:80; syncache_timer: Response timeout, retransmitting (1) = SYN|ACK > Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:18066 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Our SYN|ACK was = rejected, connection attempt aborted by remote endpoint > Oct 18 14:59:02 test kernel: TCP: [10.10.10.39]:17705 to = [10.10.10.92]:80 tcpflags 0x4; syncache_chkrst: Our SYN|ACK was = rejected, connection attempt aborted by remote endpoint >=20 > Here, 10.10.10.92 runs 12.1-STABLE, while 10.10.10.39 is a client that = runs 11.2-STABLE. >=20 >=20 > In our test case we use nginx and wrk , with a minimal config, where = nginx always returns=20 > error page 404. nginx is on the 12.1-STABLE, while wrk is on = 11.2-STABLE. >=20 > We run wrk like so: >=20 > wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency = http://10.10.10.92:80/missing >=20 > and often see errors like these: >=20 > Socket errors: connect 12, read 4, write 4, timeout 0 >=20 > If we reverse the test, by switching two servers places, ie = 12.1-STABLE becomes a client and=20 > issues requests via wrk, we see no problems at all. Same is true = between two between two > 11.2-STABLE machines. >=20 >=20 > It seems like issue appears only when the same local port is used for = multiple connections=20 > on 12.1-STABLE. Currently this is possible only when 12.1-STABLE is a = server and accepts=20 > connections on port, say 80, as in our case. To confirm, this we made = another test. We've=20 > configured nginx to listen on 10 different ports, 80 through 89, and = then launched 10=20 > different wrk processes, each using only one concurrent connection, = meaning that we will=20 > have only 10 TCP streams, each having its own unique port on the = 12.1-STABLE's side: >=20 > for I in {0..9}; do wrk -c 1 --header "Connection: close" -d 10 -t 1 = --latency http://10.10.10.92:8${I}/missing & ; done >=20 > Socket errors stopped appearing. We ran this test many many times, = errors just don't appear. >=20 > Though, whenever we repeat a previous test, using a single port: >=20 > wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency = http://10.10.10.92:80/missing >=20 > errors start appearing again and again: >=20 > Socket errors: connect 8, read 14, write 9, timeout 0 >=20 >=20 > We've tested different drivers with the same outcome: >=20 > em driver: > em0@pci0:10:0:0: class=3D0x020000 card=3D0x000015d9 = chip=3D0x10d38086 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82574L Gigabit Network Connection' >=20 > ixl driver: > ixl0@pci0:4:0:0: class=3D0x020000 card=3D0x00078086 = chip=3D0x15728086 rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Ethernet Controller X710 for 10GbE SFP+' >=20 > Even the driver from ports (/usr/ports/net/intel-ixl-kmod): ixl-1.11.9 >=20 >=20 > Help with this matter would be really appreciated. I would like to reproduce this locally. Could you send me (privately) the config of nginx such that I can setup = two machines? Are your client/server physical machines or virtual machines? Are there = any middleboxes (NAT/Firewall/whatever) involved? One thing (no idea if it is relevant or not): Could you set sudo sysctl -w net.inet.tcp.ts_offset_per_conn=3D0 on the 12.1 machine and test and report if it helps? Best regards Michael >=20 > Best regards, > -Paul >=20 > _______________________________________________ > 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 Sat Oct 19 11:35:33 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 42EDF16171B for ; Sat, 19 Oct 2019 11:35:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46wLS514S2z47f3 for ; Sat, 19 Oct 2019 11:35:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2097616171A; Sat, 19 Oct 2019 11:35:33 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 205D3161718 for ; Sat, 19 Oct 2019 11:35:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46wLS506Wsz47f2 for ; Sat, 19 Oct 2019 11:35:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D87F921D27 for ; Sat, 19 Oct 2019 11:35:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9JBZWWR061956 for ; Sat, 19 Oct 2019 11:35:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9JBZW2L061955 for net@FreeBSD.org; Sat, 19 Oct 2019 11:35:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 241162] Panic in closefp() triggered by nginx (uwsgi with sendfile(2) enabled) Date: Sat, 19 Oct 2019 11:35:32 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: amdmi3@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 11:35:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241162 --- Comment #7 from Dmitry Marakasov --- 12.1-RC1 also panics > Could you attach the nginx / uwsgi configurations, as an attachment That'd be quite heavy, as nginx here serves 10 sites with a wide tree of included configs. I'll try to minimize it. Reproducing is not quite easy to= o - it happens on production every several hours, not even sure which request l= eads to it. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Oct 19 16:09:29 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA8CD1501A6 for ; Sat, 19 Oct 2019 16:09:29 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from frv190.fwdcdn.com (frv190.fwdcdn.com [212.42.77.190]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46wSX86Qtkz4Ngv for ; Sat, 19 Oct 2019 16:09:28 +0000 (UTC) (envelope-from devgs@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Type:MIME-Version:Message-Id:Cc:To:Subject:From:Date:Sender: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=JON/9xKyVPBm8Y00LpL8wHxWH75ZHFo/KDtYa5UG/tA=; b=n o7lW8O9TbpnY+mfdDVTb+TON8y+Mm66DAUMtO4/G3oddnkMiRwalIZ98J1Fd5rsjCYrnO8/RUqKXy h1ke2FrjgtaCLuTgxula0JnZASslMDFKoY2+49JDuyjNi3lObFnHbK2KHg8mvsFggpIY2Yd2PFMph 6u/B6HxnBtWWV7Is=; Received: from [10.10.10.39] (helo=frv39.fwdcdn.com) by frv190.fwdcdn.com with smtp ID 1iLrI8-0006LJ-DD for freebsd-net@freebsd.org; Sat, 19 Oct 2019 19:09:20 +0300 Date: Sat, 19 Oct 2019 19:09:20 +0300 From: Paul Subject: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE To: michael.tuexen@lurchi.franken.de, freebsd-net@freebsd.org, freebsd-stable@freebsd.org Received: from devgs@ukr.net by frv39.fwdcdn.com; Sat, 19 Oct 2019 19:09:20 +0300 Message-Id: <1571499556.409350000.a1ewtyar@frv39.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 X-Rspamd-Queue-Id: 46wSX86Qtkz4Ngv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=n o7lW8O; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of devgs@ukr.net designates 212.42.77.190 as permitted sender) smtp.mailfrom=devgs@ukr.net X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24]; FREEMAIL_FROM(0.00)[ukr.net]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; IP_SCORE(0.00)[ipnet: 212.42.77.0/24(-4.81), asn: 8856(-3.87), country: UA(0.08)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 16:09:30 -0000 Hi Michael, Thank you, for taking your time! We use physical machines. We don not have any special `pf` rules. Both sides ran `pfctl -d` before testing. `nginx` config is primitive, no secrets there: ------------------------------------------------------------------- user www; worker_processes auto; error_log /var/log/nginx/error.log warn; events { worker_connections 81920; kqueue_changes 4096; use kqueue; } http { include mime.types; default_type application/octet-stream; sendfile off; keepalive_timeout 65; tcp_nopush on; tcp_nodelay on; # Logging log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $request_length $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_real_ip" "$realip_remote_addr" "$request_completion" "$request_time" ' '"$request_body"'; access_log /var/log/nginx/access.log main; server { listen 80 default; server_name localhost _; location / { return 404; } } } ------------------------------------------------------------------- `wrk` is compiled with a default configuration. We test like this: `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` Also, it seems that our issue, and the one described in this thread, are identical: https://lists.freebsd.org/pipermail/freebsd-net/2019-June/053667.html We both have the Intel network cards, BTW. Our network cards are these: em0 at pci0:10:0:0: class=0x020000 card=0x000015d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' ixl0 at pci0:4:0:0: class=0x020000 card=0x00078086 chip=0x15728086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Controller X710 for 10GbE SFP+' ============================== Additional info: During the tests, we have bonded two interfaces into a lagg: ixl0: flags=8843 metric 0 mtu 1500 options=c500b8 ether 3c:fd:fe:aa:60:20 media: Ethernet autoselect (10Gbase-SR ) status: active nd6 options=29 ixl1: flags=8843 metric 0 mtu 1500 options=c500b8 ether 3c:fd:fe:aa:60:20 hwaddr 3c:fd:fe:aa:60:21 media: Ethernet autoselect (10Gbase-SR ) status: active nd6 options=29 lagg0: flags=8843 metric 0 mtu 1500 options=c500b8 ether 3c:fd:fe:aa:60:20 inet 10.10.10.92 netmask 0xffff0000 broadcast 10.10.255.255 laggproto failover lagghash l2,l3,l4 laggport: ixl0 flags=5 laggport: ixl1 flags=0<> groups: lagg media: Ethernet autoselect status: active nd6 options=29 using this config: ifconfig_ixl0="up -lro -tso -rxcsum -txcsum" (tried different options - got the same outcome) ifconfig_ixl1="up -lro -tso -rxcsum -txcsum" ifconfig_lagg0="laggproto failover laggport ixl0 laggport ixl1 10.10.10.92/24" We have randomly picked `ixl0` and restricted number of RX/TX queues to 1: /boot/loader.conf : dev.ixl.0.iflib.override_ntxqs=1 dev.ixl.0.iflib.override_nrxqs=1 leaving `ixl1` with a default number, matching number of cores (6). ixl0: mem 0xf8800000-0xf8ffffff,0xf9808000-0xf980ffff irq 40 at device 0.0 on pci4 ixl0: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 ixl0: PF-ID[0]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C ixl0: Using 1024 TX descriptors and 1024 RX descriptors ixl0: Using 1 RX queues 1 TX queues ixl0: Using MSI-X interrupts with 2 vectors ixl0: Ethernet address: 3c:fd:fe:aa:60:20 ixl0: Allocating 1 queues for PF LAN VSI; 1 queues active ixl0: PCI Express Bus: Speed 8.0GT/s Width x4 ixl0: SR-IOV ready ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 ixl1: mem 0xf8000000-0xf87fffff,0xf9800000-0xf9807fff irq 40 at device 0.1 on pci4 ixl1: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 ixl1: PF-ID[1]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C ixl1: Using 1024 TX descriptors and 1024 RX descriptors ixl1: Using 6 RX queues 6 TX queues ixl1: Using MSI-X interrupts with 7 vectors ixl1: Ethernet address: 3c:fd:fe:aa:60:21 ixl1: Allocating 8 queues for PF LAN VSI; 6 queues active ixl1: PCI Express Bus: Speed 8.0GT/s Width x4 ixl1: SR-IOV ready ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 This allowed us easy switch between different configurations without the need to reboot, by simply shutting down one interface or the other: `ifconfig XXX down` When testing `ixl0` that runs only a single queue: ixl0: Using 1 RX queues 1 TX queues ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 we've got these results: `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` Running 10s test @ http://10.10.10.92:80/missing 1 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 281.31us 297.74us 22.66ms 99.70% Req/Sec 19.91k 2.79k 21.25k 97.59% Latency Distribution 50% 266.00us 75% 309.00us 90% 374.00us 99% 490.00us 164440 requests in 10.02s, 47.52MB read Socket errors: read 0, write 0, timeout 0 Non-2xx or 3xx responses: 164440 Requests/sec: 16412.09 Transfer/sec: 4.74MB When testing `ixl1` that runs 6 queues: ixl1: Using 6 RX queues 6 TX queues ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 we've got these results: `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` Running 10s test @ http://10.10.10.92:80/missing 1 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 216.16us 71.97us 511.00us 47.56% Req/Sec 4.34k 2.76k 15.44k 83.17% Latency Distribution 50% 216.00us 75% 276.00us 90% 312.00us 99% 365.00us 43616 requests in 10.10s, 12.60MB read Socket errors: connect 0, read 24, write 8, timeout 0 Non-2xx or 3xx responses: 43616 Requests/sec: 4318.26 Transfer/sec: 1.25MB Do note, that, not only multiple queues cause issues they also dramatically decrease the performance of the network. Using `sysctl -w net.inet.tcp.ts_offset_per_conn=0` didn't help at all. Best regards, -Paul From owner-freebsd-net@freebsd.org Sat Oct 19 16:24:42 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C5848150AAB; Sat, 19 Oct 2019 16:24:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670089.outbound.protection.outlook.com [40.107.67.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46wSsj1tgRz4PQn; Sat, 19 Oct 2019 16:24:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YlbsuPP6MAK89kPftkQR7+nbjOnHbGvl2T1gMrv5ZfULWVhY1cpmfiqbDMGEeWABljUAygZHA3w8rO6wLd1ZVWGXnCRZ0PM10tGuuaC+L9TKvcmNBX0mMvOwGBsKNuyNPxTUUtQt5YSaVaiCCZgMkoWN/X3j2JudSNrBCkpZ9rRbRLgVZz0uYtWgwr9Uqrtxa7u2/NHFn6UtESg/7DXZpNy+64vrYTs8n2LievhlNGEwrhbxJyj8IiV7bkGRzxr/Ik8x/Q2OHtM/jkzWcw9FY7eT93FxHUn7U6zVQPSJCpG0Xe7qjDS/x/qCwUlKZxBBLfzx5eujDk5lq3E6mE6Jpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nmDu2kTrZ/KZjgSAP/EI6XzLFuwxFtA05QPIF91BrgQ=; b=X6CyavNKzJRTKxDONZevhKe+MSIu5p9xx8HY5Tp0kl5mBAxn/xOxqo7zgocdCRGc09pkzc4G59fLVSug9eXrkJRcGzwkQdS/iM1oCin1BrHv8xBMnw8Qa7NTS6Ot7XxvwwM4iJtWpjSRbQPIFFfXU+py0KMo+eacLnaaG3XegHDJXpj6ogDYINysIGDC5n/vbjcdois4Ja3PIGLTYKNb5m96SPMI3A522ND3Lo5DrVUJAGwgL63ScwEE0LNHLN6tDNzSjz1a5NA52cnNH0uCqOk/80ZU1GgRYOyrNvgdsx6/OKQX6v9dNPzu74SvyQQipBuwJrshvQq3PjBFkooPgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM (52.132.66.144) by YQBPR0101MB0754.CANPRD01.PROD.OUTLOOK.COM (52.132.73.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Sat, 19 Oct 2019 16:24:38 +0000 Received: from YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM ([fe80::9051:db7:40f3:2ba3]) by YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM ([fe80::9051:db7:40f3:2ba3%7]) with mapi id 15.20.2347.028; Sat, 19 Oct 2019 16:24:38 +0000 From: Rick Macklem To: Paul , "michael.tuexen@lurchi.franken.de" , "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE Thread-Topic: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE Thread-Index: AQHVhpeb/qQpao8VP0Wq+sk7OrrSy6diJbjH Date: Sat, 19 Oct 2019 16:24:38 +0000 Message-ID: References: <1571499556.409350000.a1ewtyar@frv39.fwdcdn.com> In-Reply-To: <1571499556.409350000.a1ewtyar@frv39.fwdcdn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27b834bb-216c-42f1-9ac6-08d754b0d6b1 x-ms-traffictypediagnostic: YQBPR0101MB0754: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3631; x-forefront-prvs: 01952C6E96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6019001)(346002)(136003)(39850400004)(396003)(366004)(376002)(51234002)(189003)(199004)(256004)(110136005)(76116006)(99286004)(478600001)(86362001)(14454004)(966005)(14444005)(305945005)(7696005)(8936002)(476003)(2501003)(2420400007)(76176011)(11346002)(53546011)(15650500001)(446003)(102836004)(6506007)(52536014)(186003)(81166006)(81156014)(6306002)(8676002)(46003)(6246003)(55016002)(6436002)(25786009)(2906002)(66946007)(316002)(66476007)(2201001)(71190400001)(64756008)(66556008)(786003)(66446008)(71200400001)(74316002)(486006)(33656002)(7110500001)(9686003)(5660300002)(229853002)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR0101MB0754; H:YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mXvfZLPTclq2Mao7G2rP9zD/VpNiUDG8m4ZhFbkJhZRemA3c8pzz+gyu0dgloYvv6/gQThg0Q0Ig3Zglbj5cxuPb2AYTDJGCf8iojSpZx7L3Ztn/mcQA+s0NIyQAzCP9eI+56Ja+JRmntzQ+qZuCNOgVXbj95RzxxXoeMkETjYR+TkLKOB1vDNd80gNegWK3mkNqhX6WF24eM1flMCUYsxYmMheXIZEKDmijA+EbJn+3Tfv+OPVjNxyfPXpDsN1lo61j6QSLhW/Ex+ltKWyn6rQhhSP8vln1A4j2LS8LcJVLNzqr/iQlpJK6z+Gk6Yp0uj4tu/jo+OSycw2c+eelU0mYCEW7zHQLzcdmvUk6MllBra9gbB40/C0IVU3QPLqcJ1I5Ekx+BdOq9QJIi+IJO7+eVSHWxdLUnEhTg8fHf9FOjzHp3ds4U8nM+5N5GK0iNmDvO59E9YXQDYY2+QOFjA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 27b834bb-216c-42f1-9ac6-08d754b0d6b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2019 16:24:38.8266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Re0lB8T9uWkb9SmCHtV7fAmHj4uA451AxB2XXrMWD/JyGY/uAulYZPmfh8+KBy4YAY2kmaBwtr4vGi04Rs2qBQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB0754 X-Rspamd-Queue-Id: 46wSsj1tgRz4PQn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.89 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.63 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[89.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.33)[ipnet: 40.64.0.0/10(-3.92), asn: 8075(-2.68), country: US(-0.05)]; FREEMAIL_TO(0.00)[ukr.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 16:24:42 -0000 Btw, I once ran into a situation where "smart networking" was injecting RSTs into a TCP stream. The packet captures at the client and server machines were identical, except for the RSTs and the problem went away when I connected the two machines with a cable, bypassing the network. Might be worth a try, if you can do it? Good luck with it, rick ________________________________________ From: owner-freebsd-net@freebsd.org on beha= lf of Paul Sent: Saturday, October 19, 2019 12:09 PM To: michael.tuexen@lurchi.franken.de; freebsd-net@freebsd.org; freebsd-stab= le@freebsd.org Subject: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STA= BLE Hi Michael, Thank you, for taking your time! We use physical machines. We don not have any special `pf` rules. Both sides ran `pfctl -d` before testing. `nginx` config is primitive, no secrets there: ------------------------------------------------------------------- user www; worker_processes auto; error_log /var/log/nginx/error.log warn; events { worker_connections 81920; kqueue_changes 4096; use kqueue; } http { include mime.types; default_type application/octet-stream; sendfile off; keepalive_timeout 65; tcp_nopush on; tcp_nodelay on; # Logging log_format main '$remote_addr - $remote_user [$time_local] = "$request" ' '$status $request_length $body_bytes_sent "= $http_referer" ' '"$http_user_agent" "$http_x_real_ip" "$rea= lip_remote_addr" "$request_completion" "$request_time" ' '"$request_body"'; access_log /var/log/nginx/access.log main; server { listen 80 default; server_name localhost _; location / { return 404; } } } ------------------------------------------------------------------- `wrk` is compiled with a default configuration. We test like this: `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.1= 0.92:80/missing` Also, it seems that our issue, and the one described in this thread, are id= entical: https://lists.freebsd.org/pipermail/freebsd-net/2019-June/053667.html We both have the Intel network cards, BTW. Our network cards are these: em0 at pci0:10:0:0: class=3D0x020000 card=3D0x000015d9 chip=3D0x10d3= 8086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82574L Gigabit Network Connection' ixl0 at pci0:4:0:0: class=3D0x020000 card=3D0x00078086 chip=3D0x1572= 8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Ethernet Controller X710 for 10GbE SFP+' =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Additional info: During the tests, we have bonded two interfaces into a lagg: ixl0: flags=3D8843 metric 0 mtu 150= 0 options=3Dc500b8 ether 3c:fd:fe:aa:60:20 media: Ethernet autoselect (10Gbase-SR ) status: active nd6 options=3D29 ixl1: flags=3D8843 metric 0 mtu 150= 0 options=3Dc500b8 ether 3c:fd:fe:aa:60:20 hwaddr 3c:fd:fe:aa:60:21 media: Ethernet autoselect (10Gbase-SR ) status: active nd6 options=3D29 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3Dc500b8 ether 3c:fd:fe:aa:60:20 inet 10.10.10.92 netmask 0xffff0000 broadcast 10.10.255.255 laggproto failover lagghash l2,l3,l4 laggport: ixl0 flags=3D5 laggport: ixl1 flags=3D0<> groups: lagg media: Ethernet autoselect status: active nd6 options=3D29 using this config: ifconfig_ixl0=3D"up -lro -tso -rxcsum -txcsum" (tried different option= s - got the same outcome) ifconfig_ixl1=3D"up -lro -tso -rxcsum -txcsum" ifconfig_lagg0=3D"laggproto failover laggport ixl0 laggport ixl1 10.10.= 10.92/24" We have randomly picked `ixl0` and restricted number of RX/TX queues to 1: /boot/loader.conf : dev.ixl.0.iflib.override_ntxqs=3D1 dev.ixl.0.iflib.override_nrxqs=3D1 leaving `ixl1` with a default number, matching number of cores (6). ixl0: mem = 0xf8800000-0xf8ffffff,0xf9808000-0xf980ffff irq 40 at device 0.0 on pci4 ixl0: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 ixl0: PF-ID[0]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C ixl0: Using 1024 TX descriptors and 1024 RX descriptors ixl0: Using 1 RX queues 1 TX queues ixl0: Using MSI-X interrupts with 2 vectors ixl0: Ethernet address: 3c:fd:fe:aa:60:20 ixl0: Allocating 1 queues for PF LAN VSI; 1 queues active ixl0: PCI Express Bus: Speed 8.0GT/s Width x4 ixl0: SR-IOV ready ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 ixl1: mem = 0xf8000000-0xf87fffff,0xf9800000-0xf9807fff irq 40 at device 0.1 on pci4 ixl1: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 ixl1: PF-ID[1]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C ixl1: Using 1024 TX descriptors and 1024 RX descriptors ixl1: Using 6 RX queues 6 TX queues ixl1: Using MSI-X interrupts with 7 vectors ixl1: Ethernet address: 3c:fd:fe:aa:60:21 ixl1: Allocating 8 queues for PF LAN VSI; 6 queues active ixl1: PCI Express Bus: Speed 8.0GT/s Width x4 ixl1: SR-IOV ready ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 This allowed us easy switch between different configurations without the need to reboot, by simply shutting down one interface or the other: `ifconfig XXX down` When testing `ixl0` that runs only a single queue: ixl0: Using 1 RX queues 1 TX queues ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 we've got these results: `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.1= 0.92:80/missing` Running 10s test @ http://10.10.10.92:80/missing 1 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 281.31us 297.74us 22.66ms 99.70% Req/Sec 19.91k 2.79k 21.25k 97.59% Latency Distribution 50% 266.00us 75% 309.00us 90% 374.00us 99% 490.00us 164440 requests in 10.02s, 47.52MB read Socket errors: read 0, write 0, timeout 0 Non-2xx or 3xx responses: 164440 Requests/sec: 16412.09 Transfer/sec: 4.74MB When testing `ixl1` that runs 6 queues: ixl1: Using 6 RX queues 6 TX queues ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 we've got these results: `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.1= 0.92:80/missing` Running 10s test @ http://10.10.10.92:80/missing 1 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 216.16us 71.97us 511.00us 47.56% Req/Sec 4.34k 2.76k 15.44k 83.17% Latency Distribution 50% 216.00us 75% 276.00us 90% 312.00us 99% 365.00us 43616 requests in 10.10s, 12.60MB read Socket errors: connect 0, read 24, write 8, timeout 0 Non-2xx or 3xx responses: 43616 Requests/sec: 4318.26 Transfer/sec: 1.25MB Do note, that, not only multiple queues cause issues they also dramatically decrease the performance of the network. Using `sysctl -w net.inet.tcp.ts_offset_per_conn=3D0` didn't help at all. Best regards, -Paul _______________________________________________ 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 Sat Oct 19 16:35:28 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 40E6B151268; Sat, 19 Oct 2019 16:35:28 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46wT665C13z4Px4; Sat, 19 Oct 2019 16:35:26 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from [IPv6:2a02:8109:1140:c3d:e070:ad51:e71e:6446] (unknown [IPv6:2a02:8109:1140:c3d:e070:ad51:e71e:6446]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 84F2C721E281A; Sat, 19 Oct 2019 18:35:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Network anomalies after update from 11.2 STABLE to 12.1 STABLE From: Michael Tuexen In-Reply-To: <1571499556.409350000.a1ewtyar@frv39.fwdcdn.com> Date: Sat, 19 Oct 2019 18:35:20 +0200 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1571499556.409350000.a1ewtyar@frv39.fwdcdn.com> To: Paul X-Mailer: Apple Mail (2.3594.4.19) X-Spam-Status: No, score=-1.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, NUMERIC_HTTP_ADDR autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 46wT665C13z4Px4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of michael.tuexen@lurchi.franken.de has no SPF policy when checking 2001:638:a02:a001:20e:cff:fe4a:feaa) smtp.mailfrom=michael.tuexen@lurchi.franken.de X-Spamd-Result: default: False [-0.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.70)[-0.700,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[franken.de]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.99)[-0.988,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.42)[ip: (-4.45), ipnet: 2001:638::/32(2.25), asn: 680(0.11), country: DE(-0.01)]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[ukr.net]; RCVD_IN_DNSWL_LOW(-0.10)[a.a.e.f.a.4.e.f.f.f.c.0.e.0.2.0.1.0.0.a.2.0.a.0.8.3.6.0.1.0.0.2.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 16:35:28 -0000 > On 19. Oct 2019, at 18:09, Paul wrote: >=20 > Hi Michael, >=20 > Thank you, for taking your time! >=20 > We use physical machines. We don not have any special `pf` rules.=20 > Both sides ran `pfctl -d` before testing. Hi Paul, OK. How are the physical machines connected to each other? What happens when you don't use a lagg interface, but the physical ones? (Trying to localise the problem...) Best regards Michael >=20 >=20 > `nginx` config is primitive, no secrets there: >=20 > ------------------------------------------------------------------- > user www; > worker_processes auto; >=20 > error_log /var/log/nginx/error.log warn; >=20 > events { > worker_connections 81920; > kqueue_changes 4096; > use kqueue; > } >=20 > http { > include mime.types; > default_type application/octet-stream; >=20 > sendfile off; > keepalive_timeout 65; > tcp_nopush on; > tcp_nodelay on; >=20 > # Logging > log_format main '$remote_addr - $remote_user = [$time_local] "$request" ' > '$status $request_length = $body_bytes_sent "$http_referer" ' > '"$http_user_agent" "$http_x_real_ip" = "$realip_remote_addr" "$request_completion" "$request_time" ' > '"$request_body"'; >=20 > access_log /var/log/nginx/access.log main; >=20 > server { > listen 80 default; >=20 > server_name localhost _; >=20 > location / { > return 404; > } > } > } > ------------------------------------------------------------------- >=20 >=20 > `wrk` is compiled with a default configuration. We test like this: >=20 > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency = http://10.10.10.92:80/missing` >=20 >=20 > Also, it seems that our issue, and the one described in this thread, = are identical: >=20 > = https://lists.freebsd.org/pipermail/freebsd-net/2019-June/053667.html >=20 > We both have the Intel network cards, BTW. Our network cards are = these: >=20 > em0 at pci0:10:0:0: class=3D0x020000 card=3D0x000015d9 = chip=3D0x10d38086 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82574L Gigabit Network Connection' >=20 > ixl0 at pci0:4:0:0: class=3D0x020000 card=3D0x00078086 = chip=3D0x15728086 rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Ethernet Controller X710 for 10GbE SFP+' >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > Additional info: >=20 > During the tests, we have bonded two interfaces into a lagg: >=20 > ixl0: flags=3D8843 metric 0 = mtu 1500 > = options=3Dc500b8 > ether 3c:fd:fe:aa:60:20 > media: Ethernet autoselect (10Gbase-SR ) > status: active > nd6 options=3D29 > ixl1: flags=3D8843 metric 0 = mtu 1500 > = options=3Dc500b8 > ether 3c:fd:fe:aa:60:20 > hwaddr 3c:fd:fe:aa:60:21 > media: Ethernet autoselect (10Gbase-SR ) > status: active > nd6 options=3D29 >=20 >=20 > lagg0: flags=3D8843 metric 0 = mtu 1500 > = options=3Dc500b8 > ether 3c:fd:fe:aa:60:20 > inet 10.10.10.92 netmask 0xffff0000 broadcast 10.10.255.255 > laggproto failover lagghash l2,l3,l4 > laggport: ixl0 flags=3D5 > laggport: ixl1 flags=3D0<> > groups: lagg > media: Ethernet autoselect > status: active > nd6 options=3D29 >=20 > using this config: >=20 > ifconfig_ixl0=3D"up -lro -tso -rxcsum -txcsum" (tried different = options - got the same outcome) > ifconfig_ixl1=3D"up -lro -tso -rxcsum -txcsum" > ifconfig_lagg0=3D"laggproto failover laggport ixl0 laggport ixl1 = 10.10.10.92/24" >=20 >=20 > We have randomly picked `ixl0` and restricted number of RX/TX queues = to 1: > /boot/loader.conf : > dev.ixl.0.iflib.override_ntxqs=3D1 > dev.ixl.0.iflib.override_nrxqs=3D1 >=20 > leaving `ixl1` with a default number, matching number of cores (6). >=20 >=20 > ixl0: = mem 0xf8800000-0xf8ffffff,0xf9808000-0xf980ffff irq 40 at device 0.0 on = pci4 > ixl0: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 > ixl0: PF-ID[0]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C > ixl0: Using 1024 TX descriptors and 1024 RX descriptors > ixl0: Using 1 RX queues 1 TX queues > ixl0: Using MSI-X interrupts with 2 vectors > ixl0: Ethernet address: 3c:fd:fe:aa:60:20 > ixl0: Allocating 1 queues for PF LAN VSI; 1 queues active > ixl0: PCI Express Bus: Speed 8.0GT/s Width x4 > ixl0: SR-IOV ready > ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 > ixl1: = mem 0xf8000000-0xf87fffff,0xf9800000-0xf9807fff irq 40 at device 0.1 on = pci4 > ixl1: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 > ixl1: PF-ID[1]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C > ixl1: Using 1024 TX descriptors and 1024 RX descriptors > ixl1: Using 6 RX queues 6 TX queues > ixl1: Using MSI-X interrupts with 7 vectors > ixl1: Ethernet address: 3c:fd:fe:aa:60:21 > ixl1: Allocating 8 queues for PF LAN VSI; 6 queues active > ixl1: PCI Express Bus: Speed 8.0GT/s Width x4 > ixl1: SR-IOV ready > ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 >=20 >=20 > This allowed us easy switch between different configurations without > the need to reboot, by simply shutting down one interface or the = other: >=20 > `ifconfig XXX down` >=20 > When testing `ixl0` that runs only a single queue: > ixl0: Using 1 RX queues 1 TX queues > ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 >=20 > we've got these results: >=20 > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency = http://10.10.10.92:80/missing` > Running 10s test @ http://10.10.10.92:80/missing > 1 threads and 10 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 281.31us 297.74us 22.66ms 99.70% > Req/Sec 19.91k 2.79k 21.25k 97.59% > Latency Distribution > 50% 266.00us > 75% 309.00us > 90% 374.00us > 99% 490.00us > 164440 requests in 10.02s, 47.52MB read > Socket errors: read 0, write 0, timeout 0 > Non-2xx or 3xx responses: 164440 > Requests/sec: 16412.09 > Transfer/sec: 4.74MB >=20 >=20 > When testing `ixl1` that runs 6 queues: > ixl1: Using 6 RX queues 6 TX queues > ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 >=20 > we've got these results: >=20 > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency = http://10.10.10.92:80/missing` > Running 10s test @ http://10.10.10.92:80/missing > 1 threads and 10 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 216.16us 71.97us 511.00us 47.56% > Req/Sec 4.34k 2.76k 15.44k 83.17% > Latency Distribution > 50% 216.00us > 75% 276.00us > 90% 312.00us > 99% 365.00us > 43616 requests in 10.10s, 12.60MB read > Socket errors: connect 0, read 24, write 8, timeout 0 > Non-2xx or 3xx responses: 43616 > Requests/sec: 4318.26 > Transfer/sec: 1.25MB >=20 > Do note, that, not only multiple queues cause issues they also = dramatically =20 > decrease the performance of the network.=20 >=20 > Using `sysctl -w net.inet.tcp.ts_offset_per_conn=3D0` didn't help at = all. >=20 > Best regards, > -Paul >=20 >=20 From owner-freebsd-net@freebsd.org Sat Oct 19 17:23:30 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E56D41521F2 for ; Sat, 19 Oct 2019 17:23:30 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from frv190.fwdcdn.com (frv190.fwdcdn.com [212.42.77.190]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46wV9Z0GJXz4Rl2 for ; Sat, 19 Oct 2019 17:23:29 +0000 (UTC) (envelope-from devgs@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DvRKeAf5fANH4zVjuMX05802peHFxaHZejyCrlcodjw=; b=KOtlZIxw5/0mqWqqShIEI0ETDL 1wYdJky4xV2iUgmhnjzsxvO98+vDj13OG28QGZlfKBOT84NosEQ0I5JS2jRBZYIwHIWOLvIQbpCuS w3MKJyI3t2J9/O2YgTDnHAmb1MrIv+04eoGS7i/hvChpqWZvD9zJzaC+owPCbZNCXnFY=; Received: from [10.10.10.39] (helo=frv39.fwdcdn.com) by frv190.fwdcdn.com with smtp ID 1iLsRp-000EQo-RK for freebsd-net@freebsd.org; Sat, 19 Oct 2019 20:23:25 +0300 Date: Sat, 19 Oct 2019 20:23:25 +0300 From: Paul Subject: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE To: Michael Tuexen Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Received: from devgs@ukr.net by frv39.fwdcdn.com; Sat, 19 Oct 2019 20:23:25 +0300 In-Reply-To: References: <1571499556.409350000.a1ewtyar@frv39.fwdcdn.com> X-Reply-Action: reply Message-Id: <1571505335.800858000.sqrselsr@frv39.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 46wV9Z0GJXz4Rl2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=KOtlZIxw; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of devgs@ukr.net designates 212.42.77.190 as permitted sender) smtp.mailfrom=devgs@ukr.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24:c]; FREEMAIL_FROM(0.00)[ukr.net]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ipnet: 212.42.77.0/24(-4.82), asn: 8856(-3.87), country: UA(0.08)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; IP_SCORE_FREEMAIL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 17:23:31 -0000 19 October 2019, 19:35:24, by "Michael Tuexen" : > > On 19. Oct 2019, at 18:09, Paul wrote: > > > > Hi Michael, > > > > Thank you, for taking your time! > > > > We use physical machines. We don not have any special `pf` rules. > > Both sides ran `pfctl -d` before testing. > Hi Paul, > > OK. How are the physical machines connected to each other? We have tested different connections. The old, copper ethernet, cable, as well as optics connection with an identical outcome. Machines are connected through Juniper QFX5100. > > What happens when you don't use a lagg interface, but the physical ones? > > (Trying to localise the problem...) Same thing, lagg does not change anything. Originally, the problem was observed on a regular interface. We have tested a on different hardware. Results are consistently stable on 11.2-STABLE and consistently unstable on 12.1-STABLE. The only unchanged thing is the network card vendor, it's Intel. > > Best regards > Michael > > > > > > `nginx` config is primitive, no secrets there: > > > > ------------------------------------------------------------------- > > user www; > > worker_processes auto; > > > > error_log /var/log/nginx/error.log warn; > > > > events { > > worker_connections 81920; > > kqueue_changes 4096; > > use kqueue; > > } > > > > http { > > include mime.types; > > default_type application/octet-stream; > > > > sendfile off; > > keepalive_timeout 65; > > tcp_nopush on; > > tcp_nodelay on; > > > > # Logging > > log_format main '$remote_addr - $remote_user [$time_local] "$request" ' > > '$status $request_length $body_bytes_sent "$http_referer" ' > > '"$http_user_agent" "$http_x_real_ip" "$realip_remote_addr" "$request_completion" "$request_time" ' > > '"$request_body"'; > > > > access_log /var/log/nginx/access.log main; > > > > server { > > listen 80 default; > > > > server_name localhost _; > > > > location / { > > return 404; > > } > > } > > } > > ------------------------------------------------------------------- > > > > > > `wrk` is compiled with a default configuration. We test like this: > > > > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` > > > > > > Also, it seems that our issue, and the one described in this thread, are identical: > > > > https://lists.freebsd.org/pipermail/freebsd-net/2019-June/053667.html > > > > We both have the Intel network cards, BTW. Our network cards are these: > > > > em0 at pci0:10:0:0: class=0x020000 card=0x000015d9 chip=0x10d38086 rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82574L Gigabit Network Connection' > > > > ixl0 at pci0:4:0:0: class=0x020000 card=0x00078086 chip=0x15728086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Ethernet Controller X710 for 10GbE SFP+' > > > > > > ============================== > > > > Additional info: > > > > During the tests, we have bonded two interfaces into a lagg: > > > > ixl0: flags=8843 metric 0 mtu 1500 > > options=c500b8 > > ether 3c:fd:fe:aa:60:20 > > media: Ethernet autoselect (10Gbase-SR ) > > status: active > > nd6 options=29 > > ixl1: flags=8843 metric 0 mtu 1500 > > options=c500b8 > > ether 3c:fd:fe:aa:60:20 > > hwaddr 3c:fd:fe:aa:60:21 > > media: Ethernet autoselect (10Gbase-SR ) > > status: active > > nd6 options=29 > > > > > > lagg0: flags=8843 metric 0 mtu 1500 > > options=c500b8 > > ether 3c:fd:fe:aa:60:20 > > inet 10.10.10.92 netmask 0xffff0000 broadcast 10.10.255.255 > > laggproto failover lagghash l2,l3,l4 > > laggport: ixl0 flags=5 > > laggport: ixl1 flags=0<> > > groups: lagg > > media: Ethernet autoselect > > status: active > > nd6 options=29 > > > > using this config: > > > > ifconfig_ixl0="up -lro -tso -rxcsum -txcsum" (tried different options - got the same outcome) > > ifconfig_ixl1="up -lro -tso -rxcsum -txcsum" > > ifconfig_lagg0="laggproto failover laggport ixl0 laggport ixl1 10.10.10.92/24" > > > > > > We have randomly picked `ixl0` and restricted number of RX/TX queues to 1: > > /boot/loader.conf : > > dev.ixl.0.iflib.override_ntxqs=1 > > dev.ixl.0.iflib.override_nrxqs=1 > > > > leaving `ixl1` with a default number, matching number of cores (6). > > > > > > ixl0: mem 0xf8800000-0xf8ffffff,0xf9808000-0xf980ffff irq 40 at device 0.0 on pci4 > > ixl0: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 > > ixl0: PF-ID[0]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C > > ixl0: Using 1024 TX descriptors and 1024 RX descriptors > > ixl0: Using 1 RX queues 1 TX queues > > ixl0: Using MSI-X interrupts with 2 vectors > > ixl0: Ethernet address: 3c:fd:fe:aa:60:20 > > ixl0: Allocating 1 queues for PF LAN VSI; 1 queues active > > ixl0: PCI Express Bus: Speed 8.0GT/s Width x4 > > ixl0: SR-IOV ready > > ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 > > ixl1: mem 0xf8000000-0xf87fffff,0xf9800000-0xf9807fff irq 40 at device 0.1 on pci4 > > ixl1: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 > > ixl1: PF-ID[1]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C > > ixl1: Using 1024 TX descriptors and 1024 RX descriptors > > ixl1: Using 6 RX queues 6 TX queues > > ixl1: Using MSI-X interrupts with 7 vectors > > ixl1: Ethernet address: 3c:fd:fe:aa:60:21 > > ixl1: Allocating 8 queues for PF LAN VSI; 6 queues active > > ixl1: PCI Express Bus: Speed 8.0GT/s Width x4 > > ixl1: SR-IOV ready > > ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 > > > > > > This allowed us easy switch between different configurations without > > the need to reboot, by simply shutting down one interface or the other: > > > > `ifconfig XXX down` > > > > When testing `ixl0` that runs only a single queue: > > ixl0: Using 1 RX queues 1 TX queues > > ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 > > > > we've got these results: > > > > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` > > Running 10s test @ http://10.10.10.92:80/missing > > 1 threads and 10 connections > > Thread Stats Avg Stdev Max +/- Stdev > > Latency 281.31us 297.74us 22.66ms 99.70% > > Req/Sec 19.91k 2.79k 21.25k 97.59% > > Latency Distribution > > 50% 266.00us > > 75% 309.00us > > 90% 374.00us > > 99% 490.00us > > 164440 requests in 10.02s, 47.52MB read > > Socket errors: read 0, write 0, timeout 0 > > Non-2xx or 3xx responses: 164440 > > Requests/sec: 16412.09 > > Transfer/sec: 4.74MB > > > > > > When testing `ixl1` that runs 6 queues: > > ixl1: Using 6 RX queues 6 TX queues > > ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 > > > > we've got these results: > > > > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` > > Running 10s test @ http://10.10.10.92:80/missing > > 1 threads and 10 connections > > Thread Stats Avg Stdev Max +/- Stdev > > Latency 216.16us 71.97us 511.00us 47.56% > > Req/Sec 4.34k 2.76k 15.44k 83.17% > > Latency Distribution > > 50% 216.00us > > 75% 276.00us > > 90% 312.00us > > 99% 365.00us > > 43616 requests in 10.10s, 12.60MB read > > Socket errors: connect 0, read 24, write 8, timeout 0 > > Non-2xx or 3xx responses: 43616 > > Requests/sec: 4318.26 > > Transfer/sec: 1.25MB > > > > Do note, that, not only multiple queues cause issues they also dramatically > > decrease the performance of the network. > > > > Using `sysctl -w net.inet.tcp.ts_offset_per_conn=0` didn't help at all. > > > > Best regards, > > -Paul > > > > > > From owner-freebsd-net@freebsd.org Sat Oct 19 17:32:33 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6CB491525BE for ; Sat, 19 Oct 2019 17:32:33 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46wVN011fGz4SDK for ; Sat, 19 Oct 2019 17:32:31 +0000 (UTC) (envelope-from devgs@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bScw/jFGWndC5VwaWImR8YFAx/txUP5TIuTknSYFxN0=; b=nnFwlRattPk02qR9bbd7evuCMS QO4mxTeY7Cm/0v9hgA8PNO4f+2De1h2jo/TRnY1NGzKLq9jlxON4B0Z/uCqRy3P3BgKfTLUsU2HkN 7FYXRmFkkwoOhCey4lt2TeG4eEnCaeizwvhVAv+UC8TYifjXg8EvShGc/Y/DUzGHNDdw=; Received: from [10.10.10.39] (helo=frv39.fwdcdn.com) by frv196.fwdcdn.com with smtp ID 1iLsaS-000IRu-Ny for freebsd-net@freebsd.org; Sat, 19 Oct 2019 20:32:20 +0300 Date: Sat, 19 Oct 2019 20:32:20 +0300 From: Paul Subject: Re[2]: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE To: Rick Macklem Cc: =?us-ascii?q?michael=2Etuexen=40lurchi=2Efranken=2Ede?= , =?us-ascii?q?freebsd-net=40freebsd=2Eorg?= , =?us-ascii?q?freebsd-stable=40freebsd=2Eorg?= Received: from devgs@ukr.net by frv39.fwdcdn.com; Sat, 19 Oct 2019 20:32:20 +0300 In-Reply-To: References: <1571499556.409350000.a1ewtyar@frv39.fwdcdn.com> X-Reply-Action: reply Message-Id: <1571505850.986841000.zen2nmth@frv39.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 46wVN011fGz4SDK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=nnFwlRat; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of devgs@ukr.net designates 212.42.77.196 as permitted sender) smtp.mailfrom=devgs@ukr.net X-Spamd-Result: default: False [-2.80 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24:c]; FREEMAIL_FROM(0.00)[ukr.net]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ipnet: 212.42.77.0/24(-4.84), asn: 8856(-3.88), country: UA(0.08)]; CC_EXCESS_QP(1.20)[]; TO_DN_SOME(0.00)[]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 17:32:33 -0000 Hi Rick, RST is only one part of a syndrome. Apart from it, we have a ton of different other issues. For example: a lot (50+) of ACK and [FIN, ACK] re-transmissions in cases where they are definitely not needed, as seen in tspdump, unless the packets that we see in the dump are not actually processed by the kernel(?), therefore leading to re-transmissions? It definitely has something to do with races, because issue completely disappears when only single queue is enabled. In other cases, we have observed that 12.1-STABLE has sent FIN, but then, when sending the ACK it didn't actually increment SEQ, as if those two packets FIN an ACK were sent concurrently, though ACK was dispatched later. Also, I want to focus on a weird behavior, as I wrote in the original post: issue also disappears if, multiple TCP streams each use different DST port. It's as if it has anything to do with sharing a port. 19 October 2019, 19:24:43, by "Rick Macklem" : > Btw, I once ran into a situation where "smart networking" was injecting > RSTs into a TCP stream. The packet captures at the client and server > machines were identical, except for the RSTs and the problem went away > when I connected the two machines with a cable, bypassing the network. > Might be worth a try, if you can do it? > > Good luck with it, rick > > ________________________________________ > From: owner-freebsd-net@freebsd.org on behalf of Paul > Sent: Saturday, October 19, 2019 12:09 PM > To: michael.tuexen@lurchi.franken.de; freebsd-net@freebsd.org; freebsd-stable@freebsd.org > Subject: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE > > Hi Michael, > > Thank you, for taking your time! > > We use physical machines. We don not have any special `pf` rules. > Both sides ran `pfctl -d` before testing. > > > `nginx` config is primitive, no secrets there: > > ------------------------------------------------------------------- > user www; > worker_processes auto; > > error_log /var/log/nginx/error.log warn; > > events { > worker_connections 81920; > kqueue_changes 4096; > use kqueue; > } > > http { > include mime.types; > default_type application/octet-stream; > > sendfile off; > keepalive_timeout 65; > tcp_nopush on; > tcp_nodelay on; > > # Logging > log_format main '$remote_addr - $remote_user [$time_local] "$request" ' > '$status $request_length $body_bytes_sent "$http_referer" ' > '"$http_user_agent" "$http_x_real_ip" "$realip_remote_addr" "$request_completion" "$request_time" ' > '"$request_body"'; > > access_log /var/log/nginx/access.log main; > > server { > listen 80 default; > > server_name localhost _; > > location / { > return 404; > } > } > } > ------------------------------------------------------------------- > > > `wrk` is compiled with a default configuration. We test like this: > > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` > > > Also, it seems that our issue, and the one described in this thread, are identical: > > https://lists.freebsd.org/pipermail/freebsd-net/2019-June/053667.html > > We both have the Intel network cards, BTW. Our network cards are these: > > em0 at pci0:10:0:0: class=0x020000 card=0x000015d9 chip=0x10d38086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82574L Gigabit Network Connection' > > ixl0 at pci0:4:0:0: class=0x020000 card=0x00078086 chip=0x15728086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Ethernet Controller X710 for 10GbE SFP+' > > > ============================== > > Additional info: > > During the tests, we have bonded two interfaces into a lagg: > > ixl0: flags=8843 metric 0 mtu 1500 > options=c500b8 > ether 3c:fd:fe:aa:60:20 > media: Ethernet autoselect (10Gbase-SR ) > status: active > nd6 options=29 > ixl1: flags=8843 metric 0 mtu 1500 > options=c500b8 > ether 3c:fd:fe:aa:60:20 > hwaddr 3c:fd:fe:aa:60:21 > media: Ethernet autoselect (10Gbase-SR ) > status: active > nd6 options=29 > > > lagg0: flags=8843 metric 0 mtu 1500 > options=c500b8 > ether 3c:fd:fe:aa:60:20 > inet 10.10.10.92 netmask 0xffff0000 broadcast 10.10.255.255 > laggproto failover lagghash l2,l3,l4 > laggport: ixl0 flags=5 > laggport: ixl1 flags=0<> > groups: lagg > media: Ethernet autoselect > status: active > nd6 options=29 > > using this config: > > ifconfig_ixl0="up -lro -tso -rxcsum -txcsum" (tried different options - got the same outcome) > ifconfig_ixl1="up -lro -tso -rxcsum -txcsum" > ifconfig_lagg0="laggproto failover laggport ixl0 laggport ixl1 10.10.10.92/24" > > > We have randomly picked `ixl0` and restricted number of RX/TX queues to 1: > /boot/loader.conf : > dev.ixl.0.iflib.override_ntxqs=1 > dev.ixl.0.iflib.override_nrxqs=1 > > leaving `ixl1` with a default number, matching number of cores (6). > > > ixl0: mem 0xf8800000-0xf8ffffff,0xf9808000-0xf980ffff irq 40 at device 0.0 on pci4 > ixl0: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 > ixl0: PF-ID[0]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C > ixl0: Using 1024 TX descriptors and 1024 RX descriptors > ixl0: Using 1 RX queues 1 TX queues > ixl0: Using MSI-X interrupts with 2 vectors > ixl0: Ethernet address: 3c:fd:fe:aa:60:20 > ixl0: Allocating 1 queues for PF LAN VSI; 1 queues active > ixl0: PCI Express Bus: Speed 8.0GT/s Width x4 > ixl0: SR-IOV ready > ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 > ixl1: mem 0xf8000000-0xf87fffff,0xf9800000-0xf9807fff irq 40 at device 0.1 on pci4 > ixl1: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002927 oem 1.261.0 > ixl1: PF-ID[1]: VFs 64, MSI-X 129, VF MSI-X 5, QPs 768, I2C > ixl1: Using 1024 TX descriptors and 1024 RX descriptors > ixl1: Using 6 RX queues 6 TX queues > ixl1: Using MSI-X interrupts with 7 vectors > ixl1: Ethernet address: 3c:fd:fe:aa:60:21 > ixl1: Allocating 8 queues for PF LAN VSI; 6 queues active > ixl1: PCI Express Bus: Speed 8.0GT/s Width x4 > ixl1: SR-IOV ready > ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 > > > This allowed us easy switch between different configurations without > the need to reboot, by simply shutting down one interface or the other: > > `ifconfig XXX down` > > When testing `ixl0` that runs only a single queue: > ixl0: Using 1 RX queues 1 TX queues > ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 > > we've got these results: > > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` > Running 10s test @ http://10.10.10.92:80/missing > 1 threads and 10 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 281.31us 297.74us 22.66ms 99.70% > Req/Sec 19.91k 2.79k 21.25k 97.59% > Latency Distribution > 50% 266.00us > 75% 309.00us > 90% 374.00us > 99% 490.00us > 164440 requests in 10.02s, 47.52MB read > Socket errors: read 0, write 0, timeout 0 > Non-2xx or 3xx responses: 164440 > Requests/sec: 16412.09 > Transfer/sec: 4.74MB > > > When testing `ixl1` that runs 6 queues: > ixl1: Using 6 RX queues 6 TX queues > ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 > > we've got these results: > > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` > Running 10s test @ http://10.10.10.92:80/missing > 1 threads and 10 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 216.16us 71.97us 511.00us 47.56% > Req/Sec 4.34k 2.76k 15.44k 83.17% > Latency Distribution > 50% 216.00us > 75% 276.00us > 90% 312.00us > 99% 365.00us > 43616 requests in 10.10s, 12.60MB read > Socket errors: connect 0, read 24, write 8, timeout 0 > Non-2xx or 3xx responses: 43616 > Requests/sec: 4318.26 > Transfer/sec: 1.25MB > > Do note, that, not only multiple queues cause issues they also dramatically > decrease the performance of the network. > > Using `sysctl -w net.inet.tcp.ts_offset_per_conn=0` didn't help at all. > > Best regards, > -Paul > > _______________________________________________ > 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" >