From owner-freebsd-net@freebsd.org Sun Dec 6 01:22:17 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45FD9A40955 for ; Sun, 6 Dec 2015 01:22:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2852D1958 for ; Sun, 6 Dec 2015 01:22:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB61MHrt054915 for ; Sun, 6 Dec 2015 01:22:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204340] [panic] nfsd, em, msix, fatal trap 9 Date: Sun, 06 Dec 2015 01:22:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: IntelNetworking, crash, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rmacklem@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9- mfc-stable10? X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Dec 2015 01:22:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #16 from Rick Macklem --- The patch that fixes this has been committed to head as r291150 and stable/10 as r291869. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Sun Dec 6 01:22:49 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14DDCA409D3 for ; Sun, 6 Dec 2015 01:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0142D1A80 for ; Sun, 6 Dec 2015 01:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB61Mm95055679 for ; Sun, 6 Dec 2015 01:22:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204340] [panic] nfsd, em, msix, fatal trap 9 Date: Sun, 06 Dec 2015 01:22: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: 10.2-RELEASE X-Bugzilla-Keywords: IntelNetworking, crash, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rmacklem@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9- mfc-stable10+ X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Dec 2015 01:22:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable10? |mfc-stable10+ -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Sun Dec 6 16:21:37 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E2529A013B for ; Sun, 6 Dec 2015 16:21:37 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0856D12CA for ; Sun, 6 Dec 2015 16:21:36 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from moby.local ([91.140.51.43]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mh5h7-1Zsdc62ry5-00MLoI; Sun, 06 Dec 2015 17:20:55 +0100 Subject: Re: etherip (or gif) tunnel blues To: Eugene Grosbein , FreeBSD Net References: <5660DC8B.1090309@gmx.com> <5661AAC0.4000308@grosbein.net> From: Nikos Vassiliadis Message-ID: <5664604A.2030908@gmx.com> Date: Sun, 6 Dec 2015 18:20:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5661AAC0.4000308@grosbein.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TH8fhWIkKfc8b7CgpkDtmGfqY0yMpERDfLO1M1NCZtU6NtUYjIg rfDXQmpFk1gaAcG1SiXCWTfp/ncSZs056WXgGgoaEFmeUB1OzZz8qzP3cdY37DQXdXIZgQu sTYj+ZSFH9R5N4FyexivyumdpjJ5z7knBciFK8ajwtwykCexaV/iX3WpTlak7ntCdvLWs+D Cgq7Fs2Vhkrv2tWiOOFbw== X-UI-Out-Filterresults: notjunk:1;V01:K0:uRaEIEcg1zI=:Qw7Ol2QBl+FHDkhu71r89Z OfOg/3avOek0nQXg8Vuj7oWuoJ9jbNQxNio35iCKmY4yKVPkMdVRjDihKzu4LleLjeH1nd1Yo ue3MB0mXKDXPsx3TFWKQ+9zcOkpkFSg23X4KkNMZEVFKwgfH9xgjeIdeWrh2HzjMqrz+cxgrP SJ30tsg3O/ehNE3OsjPmgS9W1+VHoInLH2vDpsj9kANtIHm0dfr/EulSlnxPfrjyWk9Kfz1+6 0wGZluFAe5G7x+3R0YGErIW42J0FT/miQ9etBnyVUkmGcGPOE7NKWScKXx76iqCTJ4mvI3fBV ByxSbW/VZdmOG7X3j2h/yUIakaQhfbEtXJtl/koYuNAkm8zvjJLPd5TiK6qWLPgz7B4zUjeow eQmyTsoQqjg2BgEMIAiVdHLaxypw/Sjw1uLUH0XOwZ3It+A6OVfU52kWko7W1ry9tRl91U9Qz yXTZGlp3DG0lPmlwvadO8DHQxXkpcLHQw6eMyytYcjmW2of3yyLTRZq0qyPMcFLZ/f7beq7iy 6MJOo1ydH8vAvkUoE2LQAsTH5kDbe/VYB0CUpfPlwtRJyPm5VQOWu8isr0uv3gzaUMphgO1Du HB6mjDYpTOZAv1eB+dBtVlbuKkxWJiv+WaXIATCW8CqoF3sWttk2LMTVXei2zl5oK+EIM9UFF xdtrV4vRyHfWhPE7dkWPEEQPO/unAselnd1m11NGC4OZzKHouB3EQGgF3E+QkXSeYpxJDBI3Z UnYkPRkHFrLv9WKL8aUCBBGQN9jJZK+EcFF2NbrIxFNEPOHWSn1m0tceFboVDUC3QpuwkM/eF Uewz6kf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Dec 2015 16:21:37 -0000 On 12/04/15 17:01, Eugene Grosbein wrote: > You should show output of ifconfig for your gif and bridge interfaces > and obtain tcpdump output for them at sending and receiving side. Thanks Eugene. After carefully examining tcpdumps it seems that the network infrastructure of my provider is the cause of the problem. ETHERIP behaves as it should:) Nikos From owner-freebsd-net@freebsd.org Mon Dec 7 15:20:59 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B88129A0EF8 for ; Mon, 7 Dec 2015 15:20:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8C101774 for ; Mon, 7 Dec 2015 15:20:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB7FKxQ5070191 for ; Mon, 7 Dec 2015 15:20:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203630] [Hyper-V] [nat] [tcp] 10.2 NAT bug in TCP stack or hyperv netsvc driver Date: Mon, 07 Dec 2015 15:20:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: onyx@netfusion.fr X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emulation@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Dec 2015 15:20:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630 --- Comment #18 from Eddy --- Hi Wei, Is the patch merged to stable branch? Thank you. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Mon Dec 7 16:29:23 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F6A39C1007 for ; Mon, 7 Dec 2015 16:29:23 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8C671645; Mon, 7 Dec 2015 16:29:22 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by wmww144 with SMTP id w144so147645563wmw.1; Mon, 07 Dec 2015 08:29:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=zpa+HDuHM2KrQK0T2JstPD/wYffmZYZiXSjwa3+WMio=; b=Xz82llzvDQ4WTORW/3w3SCvpp+3Z/OFqHCB1XaRQL2gC5e0idS/FAItyBj8jozNe3U wp3TtPDBMvLO4vU1XLuICiZj4KLUacqUvkkO3wn5kLq18LG7xXR7pMR9yO9j3rZLRVkx uPZI6E9XVNVWdkXmNc0HDno4H8CQpueaBJ+p0v8wvsmcNFeaWvVhYh99d2kVqy4Reu3N zF5p6qIFI4MumuxWyWROJXjwTMP79zJaCHqAPGyO9HT0xJEbiz22xOZAJNRg2TM3o5Kq OT0FmUZiC2Ripih9cRjJGukfh7dtyoXhK1fBl0wqX+wD7GlfO4agZ3ignZ2oTHyoE5Pp vp4Q== X-Received: by 10.194.6.40 with SMTP id x8mr33443614wjx.50.1449502610199; Mon, 07 Dec 2015 07:36:50 -0800 (PST) Received: from FRI2JCHARBON-M1.local ([217.30.88.7]) by smtp.googlemail.com with ESMTPSA id uz5sm25741313wjc.8.2015.12.07.07.36.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Dec 2015 07:36:49 -0800 (PST) Subject: Re: TCP stack lock contention with short-lived connections To: k simon , freebsd-net@freebsd.org References: <537F39DF.1090900@verisign.com> <537FB51D.2060401@verisign.com> <53861209.2000306@verisign.com> <53880525.6000203@gmail.com> From: Julien Charbon X-Enigmail-Draft-Status: N1110 Message-ID: <5665A78E.3090401@freebsd.org> Date: Mon, 7 Dec 2015 16:36:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <53880525.6000203@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FkvFx3Q7o6N1sDBE46uxD8pxFoMSO0bwE" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Dec 2015 16:29:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FkvFx3Q7o6N1sDBE46uxD8pxFoMSO0bwE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 30/05/14 06:12, k simon wrote: > Does any plan commit and MFC to the 10-stable ? I got a bit of interest of having the performance improvements for short-lived TCP connections in 10-stable. Just to share the current status to a wider audience: - I maintain a stack of our TCP performance related patches for 10.2-RELENG here: https://github.com/verisign/freebsd/commits/10.2/tcp-scale - All these performance patches are in 11-CURRENT since (at least) August 2015. - If these patches are indeed quite stable, I would prefer to have other traffic/real life examples where these changes also improve performances (in top of our specific DNS over TCP traffic) before starting to MFC in 10-stable. - Currently all (few) concerned users I am aware of are happily using 11-CURRENT. Of course, all these improvements will be available by default in 11.0.0 anyway. -- Julien --FkvFx3Q7o6N1sDBE46uxD8pxFoMSO0bwE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWZaeUAAoJEKVlQ5Je6dhxXasH/iQefxycNBShEpD0h61mbotm zQDU4TN1pB3XE/6IWSgiAnSEm+ssyA4vfzrTI3+ceMhTcsT685IPIpBKLF5fARqI G9IZ7jCuglqNk/yQrAJWRPMGiF8bHvq4Vk7sh7AymUFD05U9gQNlP/YAoS/jPhQS 1RblQZEl4lWX300mgeXRY90l6KgOao1zGZ5e4sPZ2QXP4w8T8FpWq0kEg7NkTP5M 4SAsWj22U/YLiaFfmRM1VapiVz6Gz/ltdnczopwrhfWitnkp27/iqafIuq4lYDwL emQTxrxtSJJ4ZYPu3IFuiQwBK3D3FRANIddvhDPfIIOsx/596p90ttrrdaK/0XI= =STNt -----END PGP SIGNATURE----- --FkvFx3Q7o6N1sDBE46uxD8pxFoMSO0bwE-- From owner-freebsd-net@freebsd.org Mon Dec 7 17:59:33 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87A159B93D2 for ; Mon, 7 Dec 2015 17:59:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 650991DBA for ; Mon, 7 Dec 2015 17:59:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB7HxXbU043205 for ; Mon, 7 Dec 2015 17:59:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205083] bce: impossible to configure working bridge interface Date: Mon, 07 Dec 2015 17:59:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Dec 2015 17:59:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205083 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|bce bridge |bce: impossible to | |configure working bridge | |interface Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Dec 7 21:24:27 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FBF99C1A5B for ; Mon, 7 Dec 2015 21:24:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 908AD1D0B for ; Mon, 7 Dec 2015 21:24:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB7LORkK075815 for ; Mon, 7 Dec 2015 21:24:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200221] em0 watchdog timeout under load Date: Mon, 07 Dec 2015 21:24:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.heider@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: sbruno@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Dec 2015 21:24:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200221 Andre changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |a.heider@gmail.com --- Comment #23 from Andre --- I'm seeing the same issue on the very same hardware as Julien on current releng/10.2. Currently using this /etc/rc.conf workaround: ifconfig_em0="DHCP -tso -vlanhwtso" -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Tue Dec 8 01:27:30 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF0499D382A for ; Tue, 8 Dec 2015 01:27:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF75F1767 for ; Tue, 8 Dec 2015 01:27:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB81RUiu037751 for ; Tue, 8 Dec 2015 01:27:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203630] [Hyper-V] [nat] [tcp] 10.2 NAT bug in TCP stack or hyperv netsvc driver Date: Tue, 08 Dec 2015 01:27:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: weh@microsoft.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emulation@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Dec 2015 01:27:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630 --- Comment #19 from Wei Hu --- (In reply to Eddy from comment #18) Not yet. I will try to do it this week. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Tue Dec 8 01:30:05 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34F7B9D3A8D for ; Tue, 8 Dec 2015 01:30:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 251BD1A49 for ; Tue, 8 Dec 2015 01:30:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB81U53A041216 for ; Tue, 8 Dec 2015 01:30:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203630] [Hyper-V] [nat] [tcp] 10.2 NAT bug in TCP stack or hyperv netsvc driver Date: Tue, 08 Dec 2015 01:30:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emulation@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Dec 2015 01:30:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #20 from Kubilay Kocak --- (In reply to Eddy from comment #18) @Eddy / Wei When commits logs contain a line containing "PR: [, ], it will be referenced as a comment against those issue id's. Also, committers will set the mfc-stable* flag to + when done/committed, or to - with a comment as to why an MFC to that branch is not necessary/invalid. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Tue Dec 8 05:39:06 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3AFD9D3C84 for ; Tue, 8 Dec 2015 05:39:06 +0000 (UTC) (envelope-from j@scre.ws) Received: from nitrology.com (nitrology.com [69.28.133.242]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC6C106B; Tue, 8 Dec 2015 05:39:06 +0000 (UTC) (envelope-from j@scre.ws) Received: by nitrology.com (Postfix, from userid 80) id 724139CC9F; Mon, 7 Dec 2015 22:32:41 -0700 (MST) To: freebsd-net@freebsd.org Subject: Multiple cores/race conditions in IPv6 RA X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 07 Dec 2015 22:32:41 -0700 From: Jason Cc: sbruno@freebsd.org, kevin.bowling@kev009.com, hiren@strugglingcoder.info Message-ID: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> X-Sender: j@scre.ws User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Dec 2015 05:39:06 -0000 Hi, It appears the IPv6 router advertisement code paths were written fairly lockless, assuming you would never process multiples concurrently. We are seeing multiple page faults in various places processing the messages and modifying the routing table. We have multiple L3 devices and multiple v6 blocks broadcasting these messages to hardware with dual uplinks in the same VLAN, which I believe is making us susceptible to this. Though I believe the dual uplink is all that's required for this, as it can be seen in configurations with a single v6 block. We are running stable/10 @ r285800, and it doesn't appear anything relevant has changed since then. Our other widely deployed version is 8.3-RELEASE, which does not see this issue. Upon bumping a machine from 8.3 -> 10 we can see it start to exhibit this behavior. The only change I see that might be relevant is r243148, but these cores are relatively rare, so testing is tough without a considerable deployment. So basically I'm hoping someone with a trained eye can send us in the right direction before we go down that road. Every backtrace looks pretty much like this, with the location in nd6_rtr differing: panic: page fault #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff8075fa07 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xffffffff8075fe05 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xffffffff8075fc93 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xffffffff80acdf9b in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:851 #5 0xffffffff80ace29d in trap_pfault (frame=0xfffffe0f959b0ff0, usermode=) at /usr/src/sys/amd64/amd64/trap.c:674 #6 0xffffffff80acd93a in trap (frame=0xfffffe0f959b0ff0) at /usr/src/sys/amd64/amd64/trap.c:440 #7 0xffffffff80ab3932 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #8 0xffffffff808a5550 in nd6_ra_input (m=, off=, icmp6len=) at /usr/src/sys/netinet6/nd6_rtr.c:739 #9 0xffffffff8087f31f in icmp6_input (mp=, offp=0xfffffe0f959b167c, proto=) at /usr/src/sys/netinet6/icmp6.c:808 #10 0xffffffff808949fc in ip6_input (m=0xfffff8002e743200) at /usr/src/sys/netinet6/ip6_input.c:1019 #11 0xffffffff80832f02 in netisr_dispatch_src (proto=, source=, m=0x1) at /usr/src/sys/net/netisr.c:976 #12 0xffffffff8082a226 in ether_demux (ifp=, m=0xfffff8002e743200) at /usr/src/sys/net/if_ethersubr.c:851 #13 0xffffffff8082aece in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:646 #14 0xffffffff80832f02 in netisr_dispatch_src (proto=, source=, m=0x1) at /usr/src/sys/net/netisr.c:976 I'll link to GH for the various relevant bits, because I know everyone can agree it's the superior RCS. It appears to be that most of these are caused by the dr struct being freed by concurrent processing: https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L578 https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L654 https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L728 https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L739 https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L800 https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L1312 Thanks for any assistance, Jason From owner-freebsd-net@freebsd.org Tue Dec 8 10:10:36 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 469269D4909 for ; Tue, 8 Dec 2015 10:10:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 384FB1339 for ; Tue, 8 Dec 2015 10:10:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB8AAax6090331 for ; Tue, 8 Dec 2015 10:10:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205083] bce: impossible to configure working bridge interface Date: Tue, 08 Dec 2015 10:10:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ludovit.koren@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Dec 2015 10:10:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205083 --- Comment #1 from Ludovit Koren --- Hi, I am sorry, I just chcecked at networking staff, they configured port security on the switch without let me know. Now, after port security off, it is working... Sorry for any inconvience. Regards, lk -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 8 11:46:18 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07A319D4139 for ; Tue, 8 Dec 2015 11:46:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECF4514ED for ; Tue, 8 Dec 2015 11:46:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB8BkHPJ016652 for ; Tue, 8 Dec 2015 11:46:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205083] bce: impossible to configure working bridge interface Date: Tue, 08 Dec 2015 11:46:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Dec 2015 11:46:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205083 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Not A Bug --- Comment #2 from Kubilay Kocak --- @Ludovit Thank you for reporting back -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 8 18:14:06 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7ED859D3C9B for ; Tue, 8 Dec 2015 18:14:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6FB3019AE for ; Tue, 8 Dec 2015 18:14:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB8IE6EL054753 for ; Tue, 8 Dec 2015 18:14:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205144] [patch] make rsh(1) compatible with recent Cisco IOS versions Date: Tue, 08 Dec 2015 18:14:06 +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: 10.2-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@grosbein.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Dec 2015 18:14:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205144 eugen@grosbein.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Tue Dec 8 23:29:38 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7AFC9D4D6F for ; Tue, 8 Dec 2015 23:29:38 +0000 (UTC) (envelope-from j@nitrology.com) Received: from nitrology.com (nitrology.com [69.28.133.242]) by mx1.freebsd.org (Postfix) with ESMTP id C9AEB1861; Tue, 8 Dec 2015 23:29:38 +0000 (UTC) (envelope-from j@nitrology.com) Received: by nitrology.com (Postfix, from userid 80) id 1C94C9CC9F; Tue, 8 Dec 2015 16:29:38 -0700 (MST) To: freebsd-net@freebsd.org Subject: Re: Multiple cores/race conditions in IPv6 RA X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Dec 2015 16:29:38 -0700 From: Jason Wolfe Cc: kevin.bowling@kev009.com, hiren@strugglingcoder.info, sbruno@freebsd.org, gnn@freebsd.org In-Reply-To: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> Message-ID: X-Sender: j@nitrology.com User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Dec 2015 23:29:39 -0000 I believe I've found a way to reproduce this, simply an rtsol against 2 interfaces in isolated loops, which elicits a broadcasted RA. I am able to deadlock the system fairly quickly, which finally results in a core after __rw_wunlock_hard steps in. We have seen this deadlock in one other case, but the code path prior is the same as most of the others, so hopefully it's keeping me on the right track. I tested backing out r243148 without success. load: 51.27 cmd: rtsol 7678 [*Giant] 832.44r 0.00u 0.00s 0% 1868k (prior to core) https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L654 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff807ada7c stack pointer = 0x28:0xfffffe201edcff60 frame pointer = 0x28:0xfffffe201edcff90 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 12 (irq279: ix0:que 1) trap number = 12 panic: page fault cpuid = 1 (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff8075fa07 in kern_reboot (howto=16644) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xffffffff8075fe05 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xffffffff8075fc93 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xffffffff80ace3cb in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:851 #5 0xffffffff80ace6cd in trap_pfault (frame=0xfffffe201edcfeb0, usermode=) at /usr/src/sys/amd64/amd64/trap.c:674 #6 0xffffffff80acdd6a in trap (frame=0xfffffe201edcfeb0) at /usr/src/sys/amd64/amd64/trap.c:440 #7 0xffffffff80ab3d62 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #8 0xffffffff807ada7c in turnstile_broadcast (ts=0x0, queue=1) at /usr/src/sys/kern/subr_turnstile.c:838 #9 0xffffffff8075e080 in __rw_wunlock_hard (c=0xfffffe1f29f2f3f8, tid=1, file=0x1
, line=1) at /usr/src/sys/kern/kern_rwlock.c:988 #10 0xffffffff808a7136 in defrouter_select () at /usr/src/sys/netinet6/nd6_rtr.c:654 #11 0xffffffff808a5a58 in nd6_ra_input (m=, off=, icmp6len=) at /usr/src/sys/netinet6/nd6_rtr.c:804 #12 0xffffffff8087f31f in icmp6_input (mp=, offp=0xfffffe201edd064c, proto=) at /usr/src/sys/netinet6/icmp6.c:808 #13 0xffffffff80894adc in ip6_input (m=0xfffff8038cab7000) at /usr/src/sys/netinet6/ip6_input.c:1019 #14 0xffffffff80832f02 in netisr_dispatch_src (proto=, source=, m=0x10) at /usr/src/sys/net/netisr.c:976 #15 0xffffffff8082a226 in ether_demux (ifp=, m=0xfffff8038cab7000) at /usr/src/sys/net/if_ethersubr.c:851 #16 0xffffffff8082aece in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:646 #17 0xffffffff80832f02 in netisr_dispatch_src (proto=, source=, m=0x10) at /usr/src/sys/net/netisr.c:976 #18 0xffffffff804c7e89 in ixgbe_rxeof (que=0xfffff8011680d470) at /usr/src/sys/dev/ixgbe/ix_txrx.c:1681 #19 0xffffffff804c1e0a in ixgbe_msix_que (arg=0xfffff8011680d470) at /usr/src/sys/dev/ixgbe/if_ix.c:1391 #20 0xffffffff8072ff9b in intr_event_execute_handlers (p=, ie=0xfffff80116806600) at /usr/src/sys/kern/kern_intr.c:1264 #21 0xffffffff80730936 in ithread_loop (arg=0xfffff8011681e480) at /usr/src/sys/kern/kern_intr.c:1277 #22 0xffffffff8072dbba in fork_exit (callout=0xffffffff807308a0 , arg=0xfffff8011681e480, frame=0xfffffe201edd0ac0) at /usr/src/sys/kern/kern_fork.c:1018 #23 0xffffffff80ab429e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #24 0x0000000000000000 in ?? () (kgdb) frame 10 #10 0xffffffff808a7136 in defrouter_select () at /usr/src/sys/netinet6/nd6_rtr.c:654 654 IF_AFDATA_UNLOCK(dr->ifp); (kgdb) list 649 if (selected_dr == NULL && 650 (ln = nd6_lookup(&dr->rtaddr, 0, dr->ifp)) && 651 ND6_IS_LLINFO_PROBREACH(ln)) { 652 selected_dr = dr; 653 } 654 IF_AFDATA_UNLOCK(dr->ifp); 655 if (ln != NULL) { 656 LLE_RUNLOCK(ln); 657 ln = NULL; 658 } (kgdb) print *dr Cannot access memory at address 0xa00000001 (kgdb) print dr->ifp Cannot access memory at address 0xa00000031 Thanks again, Jason On 2015-12-07 22:32, Jason wrote: > Hi, > > It appears the IPv6 router advertisement code paths were written > fairly lockless, assuming you would never process multiples > concurrently. We are seeing multiple page faults in various places > processing the messages and modifying the routing table. We have > multiple L3 devices and multiple v6 blocks broadcasting these messages > to hardware with dual uplinks in the same VLAN, which I believe is > making us susceptible to this. Though I believe the dual uplink is > all that's required for this, as it can be seen in configurations with > a single v6 block. > > We are running stable/10 @ r285800, and it doesn't appear anything > relevant has changed since then. Our other widely deployed version is > 8.3-RELEASE, which does not see this issue. Upon bumping a machine > from 8.3 -> 10 we can see it start to exhibit this behavior. The only > change I see that might be relevant is r243148, but these cores are > relatively rare, so testing is tough without a considerable > deployment. So basically I'm hoping someone with a trained eye can > send us in the right direction before we go down that road. > > Every backtrace looks pretty much like this, with the location in > nd6_rtr differing: > > panic: page fault > #0 doadump (textdump=1) at pcpu.h:219 > #1 0xffffffff8075fa07 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:451 > #2 0xffffffff8075fe05 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:758 > #3 0xffffffff8075fc93 in panic (fmt=0x0) at > /usr/src/sys/kern/kern_shutdown.c:687 > #4 0xffffffff80acdf9b in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:851 > #5 0xffffffff80ace29d in trap_pfault (frame=0xfffffe0f959b0ff0, > usermode=) at /usr/src/sys/amd64/amd64/trap.c:674 > #6 0xffffffff80acd93a in trap (frame=0xfffffe0f959b0ff0) at > /usr/src/sys/amd64/amd64/trap.c:440 > #7 0xffffffff80ab3932 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #8 0xffffffff808a5550 in nd6_ra_input (m=, > off=, icmp6len=) > at /usr/src/sys/netinet6/nd6_rtr.c:739 > #9 0xffffffff8087f31f in icmp6_input (mp=, > offp=0xfffffe0f959b167c, proto=) > at /usr/src/sys/netinet6/icmp6.c:808 > #10 0xffffffff808949fc in ip6_input (m=0xfffff8002e743200) at > /usr/src/sys/netinet6/ip6_input.c:1019 > #11 0xffffffff80832f02 in netisr_dispatch_src (proto= out>, source=, m=0x1) > at /usr/src/sys/net/netisr.c:976 > #12 0xffffffff8082a226 in ether_demux (ifp=, > m=0xfffff8002e743200) at /usr/src/sys/net/if_ethersubr.c:851 > #13 0xffffffff8082aece in ether_nh_input (m=) at > /usr/src/sys/net/if_ethersubr.c:646 > #14 0xffffffff80832f02 in netisr_dispatch_src (proto= out>, source=, m=0x1) > at /usr/src/sys/net/netisr.c:976 > > I'll link to GH for the various relevant bits, because I know everyone > can agree it's the superior RCS. It appears to be that most of these > are caused by the dr struct being freed by concurrent processing: > > https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L578 > https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L654 > https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L728 > https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L739 > https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L800 > https://github.com/freebsd/freebsd/blob/e5ee1c2b414851b17663cb491e2f2317a0af9bda/sys/netinet6/nd6_rtr.c#L1312 > > Thanks for any assistance, > Jason > _______________________________________________ > 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 Dec 9 02:11:13 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CCDD9D4F68; Wed, 9 Dec 2015 02:11:13 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E827155F; Wed, 9 Dec 2015 02:11:12 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 47A23CAC3C; Tue, 8 Dec 2015 18:11:06 -0800 (PST) Date: Tue, 8 Dec 2015 18:11:06 -0800 From: hiren panchasara To: Slawa Olhovchenkov Cc: freebsd-stable@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: TCP regression between 288167 and 291456 Message-ID: <20151209021106.GG89422@strugglingcoder.info> References: <20151203152422.GB70867@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+QwZB9vYiNIzNXIj" Content-Disposition: inline In-Reply-To: <20151203152422.GB70867@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 02:11:13 -0000 --+QwZB9vYiNIzNXIj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable + net@ On 12/03/15 at 06:24P, Slawa Olhovchenkov wrote: > After upgrading STABLE to r291456 I am see bunch of sockets in > TIME_WAIT state. In normal situation I am expect about 30k-50k such > sockets. Now I am see all of net.inet.tcp.maxtcptw (440k currently). > Setting net.inet.tcp.msl to low value don't reduce this sockets. >=20 > I am see socket in TIME_WAIT state during 30 minutes. > Perhapsh in this state socket may be for ever Does updating to latest stable/10 help? I see there were other fixes that went in after r291456. (I am not 100% if that'll help but worth trying.) I've added -net to get more relevant eyes on the problem. Cheers, Hiren --+QwZB9vYiNIzNXIj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWZ422XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lNsIH/Rj9c5wWAE9zIaRSkr0Qpfea uqIbihAcll29wS4lUdX9497PuPXi3WpYlxVDXgn02wfTJXInNiDylPiPyBgyx8fV dpom9Xcl12CRkh6b9SsNn4WucMoxdJxVjLjSOva8ysor0pEEn/mJfc50X8uljQOS 78JVYefoSlyCkMau1P4mHtInITDTYD6Q+36EsOT0SYohMHM2Wuxgb0j07IhWZrhj 2xl2W3AfSrsVIS+lTLDFTr0Q/keSPpBlS8Gmk/O4ba/ouPz+b+0MlsghSmvuXequ cwxRKFDO9TaYqnPKxhAyPgZtPKIh/EI4wpvUvtWQNdqhuutzdhck4tqpcYeAEf4= =s3yH -----END PGP SIGNATURE----- --+QwZB9vYiNIzNXIj-- From owner-freebsd-net@freebsd.org Wed Dec 9 08:46:01 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44DCA9D3B50 for ; Wed, 9 Dec 2015 08:46:01 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36F351CF8; Wed, 9 Dec 2015 08:46:01 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 3C06F66514; Wed, 9 Dec 2015 08:45:58 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: Multiple cores/race conditions in IPv6 RA To: Jason , freebsd-net@freebsd.org References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> Cc: kevin.bowling@kev009.com, hiren@strugglingcoder.info, Mark Johnston From: "Andrey V. Elsukov" Message-ID: <5667EA3A.8050200@FreeBSD.org> Date: Wed, 9 Dec 2015 11:45:46 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CA3LqJI7WbNHHaADAAf5o3jSFhroLgeMh" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 08:46:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CA3LqJI7WbNHHaADAAf5o3jSFhroLgeMh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08.12.15 08:32, Jason wrote: > Hi, >=20 > It appears the IPv6 router advertisement code paths were written fairly= > lockless, assuming you would never process multiples concurrently. We > are seeing multiple page faults in various places processing the > messages and modifying the routing table. We have multiple L3 devices > and multiple v6 blocks broadcasting these messages to hardware with dua= l > uplinks in the same VLAN, which I believe is making us susceptible to > this. Though I believe the dual uplink is all that's required for this= , > as it can be seen in configurations with a single v6 block. >=20 > We are running stable/10 @ r285800, and it doesn't appear anything > relevant has changed since then. Our other widely deployed version is > 8.3-RELEASE, which does not see this issue. Upon bumping a machine fro= m > 8.3 -> 10 we can see it start to exhibit this behavior. The only chang= e > I see that might be relevant is r243148, but these cores are relatively= > rare, so testing is tough without a considerable deployment. So > basically I'm hoping someone with a trained eye can send us in the righ= t > direction before we go down that road. Hi, some time ago Mark Johnston has published there the patch related to this problem: https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html= Maybe Mark has something to say about it. --=20 WBR, Andrey V. Elsukov --CA3LqJI7WbNHHaADAAf5o3jSFhroLgeMh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWZ+o6AAoJEAHF6gQQyKF6pvgH/iD6n22BzWnTli+pnOc4GkyV UqHl5cnNb6qpZBHJ57zjw4sPubjkog1GaoTDKqMFmXkJ1YjWaMvAQ1XXmdH3Yz4b SV9tOuQUqasI+Pd6d/0u9DwJdnHV17BtvauBr9Ld9u4zL3kEaUpLIY6hIzobRFUv /YKq3mIr5KzrCKwGu6YGcV3Jyiqx8MLOIj07kovllGYMhIe0aaCU034ydIWOlTGR bvuRCXh2eJKMvj+rCozYxOCIfTPZY8gA9tKgu9CwNvfRA9XMdMEiCgnt7NPC0RQV ecmeH6/BU+GpnuNpxjSnKlIW73ipdRFo6bd3/7O7SDXWooU7T407iV2ndzz9hKw= =ZXQo -----END PGP SIGNATURE----- --CA3LqJI7WbNHHaADAAf5o3jSFhroLgeMh-- From owner-freebsd-net@freebsd.org Wed Dec 9 08:54:39 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D400B9D43D2 for ; Wed, 9 Dec 2015 08:54:39 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB51E1328; Wed, 9 Dec 2015 08:54:39 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by pfnn128 with SMTP id n128so26868482pfn.0; Wed, 09 Dec 2015 00:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=80zRfT0B3vVI03sw6o6f2f38rQmhA+u0py3LR1F9cUE=; b=k0qcUNTcpqtvApe75DVO9RFG0XUmvcQ6xQNUhynP3td7W1oA278TEoeuYPiDIdDOeo fe+uR8J8NjuQmc9cyWapOHHXi+iD52UPvVO/wjhEc0nOrQJfTxIDpujLddmDzlLBhZzv JYviHspLUq0YxkzaOshJolSg5oNqJYWaFgd07yWXi5Jfj2jy1HaMdalrBjO6udmKUuaV XuPldgO68xwP1q+OcLmy5l+vfMHQx1FOvT5suGnl4jNyiw0FZDhjy4OJAs1GqlVtz9cg sL/gJPHr/Zok76OD+J9eluloqasQsZM4gxvGMowZjs1oe2ApNXNYZzIYYngZzKn7XFPR E+iw== X-Received: by 10.98.80.22 with SMTP id e22mr11363420pfb.34.1449651279283; Wed, 09 Dec 2015 00:54:39 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b01::2? (2001-44b8-31ae-7b01-0000-0000-0000-0002.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01::2]) by smtp.gmail.com with ESMTPSA id 82sm9807817pfn.76.2015.12.09.00.54.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Dec 2015 00:54:38 -0800 (PST) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: Multiple cores/race conditions in IPv6 RA References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> <5667EA3A.8050200@FreeBSD.org> To: "Andrey V. Elsukov" , Jason , freebsd-net@freebsd.org Cc: Mark Johnston , kevin.bowling@kev009.com, hiren@strugglingcoder.info, "freebsd-net@freebsd.org" From: Kubilay Kocak Message-ID: <5667EC45.2050808@FreeBSD.org> Date: Wed, 9 Dec 2015 19:54:29 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: <5667EA3A.8050200@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 08:54:39 -0000 On 9/12/2015 7:45 PM, Andrey V. Elsukov wrote: > On 08.12.15 08:32, Jason wrote: >> Hi, >> >> It appears the IPv6 router advertisement code paths were written fairly >> lockless, assuming you would never process multiples concurrently. We >> are seeing multiple page faults in various places processing the >> messages and modifying the routing table. We have multiple L3 devices >> and multiple v6 blocks broadcasting these messages to hardware with dual >> uplinks in the same VLAN, which I believe is making us susceptible to >> this. Though I believe the dual uplink is all that's required for this, >> as it can be seen in configurations with a single v6 block. >> >> We are running stable/10 @ r285800, and it doesn't appear anything >> relevant has changed since then. Our other widely deployed version is >> 8.3-RELEASE, which does not see this issue. Upon bumping a machine from >> 8.3 -> 10 we can see it start to exhibit this behavior. The only change >> I see that might be relevant is r243148, but these cores are relatively >> rare, so testing is tough without a considerable deployment. So >> basically I'm hoping someone with a trained eye can send us in the right >> direction before we go down that road. > > Hi, > > some time ago Mark Johnston has published there the patch related to > this problem: > https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html > > Maybe Mark has something to say about it. > Is it worth creating an issue report to track/resolve this, with 10.3 coming up? ./koobs From owner-freebsd-net@freebsd.org Wed Dec 9 08:59:13 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 932CA9D479E for ; Wed, 9 Dec 2015 08:59:13 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62D4615CE; Wed, 9 Dec 2015 08:59:13 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 44B1B65528; Wed, 9 Dec 2015 08:59:08 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: Multiple cores/race conditions in IPv6 RA To: koobs@FreeBSD.org, Jason , freebsd-net@freebsd.org References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> <5667EA3A.8050200@FreeBSD.org> <5667EC45.2050808@FreeBSD.org> Cc: Mark Johnston , kevin.bowling@kev009.com, hiren@strugglingcoder.info From: "Andrey V. Elsukov" Message-ID: <5667ED4C.90405@FreeBSD.org> Date: Wed, 9 Dec 2015 11:58:52 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5667EC45.2050808@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kRFFvfu3ParsxmU90NJ290M3TDaTPLbpv" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 08:59:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kRFFvfu3ParsxmU90NJ290M3TDaTPLbpv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09.12.15 11:54, Kubilay Kocak wrote: >> some time ago Mark Johnston has published there the patch related to >> this problem: >> https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.h= tml >> >> Maybe Mark has something to say about it. >> >=20 > Is it worth creating an issue report to track/resolve this, with 10.3 > coming up? This problem exists since 4.x-5.x, so, I don't think that creating a report will automatically resolve it :) --=20 WBR, Andrey V. Elsukov --kRFFvfu3ParsxmU90NJ290M3TDaTPLbpv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWZ+1MAAoJEAHF6gQQyKF63N0H/2rq0Zb2cCPmNY3t5bM/sWZh /0vURWCbsKTR9Jkes8uV6SF2Qj+FgJzdj3n69VnjzDPuy4lSJaDm6GTh9DpWRwuA GrTDR5txYyqKJpUzWI8Xf9UZtYKMggNcrmAM+pUDAnmsOmf/zPoHl2WP0PZ/xKh6 1DbbRex3ZDntVeguUZrPjCYMt6iysNP5L0rViyg1cIyFxWyqwy3UWebFtFqR8MJk 9WTlVdvdTLd3hk4F2AsdzV+RLfAyCa/cdfdAQ1ljRlyZxrrdYCpB3c7C1PkwWSwd kPgVtBOrTuHnq9IwoWCG0X1jqXeg9sjrT0e96VDEtfUzifO/scNtcviz7vfaKGM= =4rjC -----END PGP SIGNATURE----- --kRFFvfu3ParsxmU90NJ290M3TDaTPLbpv-- From owner-freebsd-net@freebsd.org Wed Dec 9 10:02:58 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D14579D5C3B for ; Wed, 9 Dec 2015 10:02:58 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6BC01C44; Wed, 9 Dec 2015 10:02:58 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by pacwq6 with SMTP id wq6so27467093pac.1; Wed, 09 Dec 2015 02:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ATs/QYSLrIh0HYRIE2g60aGMXHMO1ej9DhTQsLEuHY0=; b=j/z26oTmsLHYhG7Ev4/rY4q+BclNl83rTDlEdu9ppbNyRhDuXKUFdc3KQJ46LIXBz2 5RVKPMA61GdtZtH1WR2PQvSC8jSWme4jxgSHKUqzlLcSYU3v/yNrpfiNFBRSY9AraM9t Q5M6RXWuipoQ94NmATl64v73gawBPzfMTIGYDYAeaBWeyexjUCOXmgWVnWZ8Hx7kigFI 67wgYIJuz7a+rPhG+old3/1katvhwq0/i8W1mwFoBW8XBu32EPp04kQewnvq2kAytP99 ctxrcAdkgVOqI6sUcI+LB7Gt9wE+dtFPJaLbdbNERxJ3oDORexwufgxKLddJNUIAUuMC sm4A== X-Received: by 10.66.219.228 with SMTP id pr4mr6370155pac.99.1449655378271; Wed, 09 Dec 2015 02:02:58 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b01:e88a:629d:a199:b333? (2001-44b8-31ae-7b01-e88a-629d-a199-b333.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:e88a:629d:a199:b333]) by smtp.gmail.com with ESMTPSA id dz6sm10529960pab.19.2015.12.09.02.02.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Dec 2015 02:02:57 -0800 (PST) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: Multiple cores/race conditions in IPv6 RA References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> <5667EA3A.8050200@FreeBSD.org> <5667EC45.2050808@FreeBSD.org> <5667ED4C.90405@FreeBSD.org> To: "Andrey V. Elsukov" , Jason , freebsd-net@freebsd.org Cc: Mark Johnston , kevin.bowling@kev009.com, hiren@strugglingcoder.info From: Kubilay Kocak Message-ID: <5667FC48.5090507@FreeBSD.org> Date: Wed, 9 Dec 2015 21:02:48 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: <5667ED4C.90405@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 10:02:58 -0000 On 9/12/2015 7:58 PM, Andrey V. Elsukov wrote: > On 09.12.15 11:54, Kubilay Kocak wrote: >>> some time ago Mark Johnston has published there the patch related to >>> this problem: >>> https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html >>> >>> Maybe Mark has something to say about it. >>> >> >> Is it worth creating an issue report to track/resolve this, with 10.3 >> coming up? > > This problem exists since 4.x-5.x, so, I don't think that creating a > report will automatically resolve it :) > Not automatically no. But perhaps never being tracked has contributed to its non-resolution? From owner-freebsd-net@freebsd.org Wed Dec 9 14:11:46 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C970D9D58F0 for ; Wed, 9 Dec 2015 14:11:46 +0000 (UTC) (envelope-from ken@pcbsd.org) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B421F1810 for ; Wed, 9 Dec 2015 14:11:46 +0000 (UTC) (envelope-from ken@pcbsd.org) X-ASG-Debug-ID: 1449670304-08ca042abd06970002-QdxwpM Received: from [192.168.1.130] (24-151-177-78.dhcp.kgpt.tn.charter.com [24.151.177.78]) by barracuda.ixsystems.com with ESMTP id 4gggmiTvoADdeZpM (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 09 Dec 2015 06:11:45 -0800 (PST) X-Barracuda-Envelope-From: ken@pcbsd.org X-Barracuda-AUTH-User: ken@pcbsd.org X-Barracuda-Apparent-Source-IP: 24.151.177.78 To: freebsd-net@freebsd.org From: Ken Moore Subject: IPv6 Address as text (C) Message-ID: <5668369F.9020309@pcbsd.org> X-ASG-Orig-Subj: IPv6 Address as text (C) Date: Wed, 9 Dec 2015 09:11:43 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 24-151-177-78.dhcp.kgpt.tn.charter.com[24.151.177.78] X-Barracuda-Start-Time: 1449670304 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.25106 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 14:11:47 -0000 Note: Please CC me on replies - I am not subscribed to this list. I am having a bit of trouble getting an accurate string representation of the current IPv6 address for a given device using the C system libraries and was wondering of somebody with more experience than me might be able to spot the error... Background: I have been working on a couple simple C/C++/Qt functions to return printable forms of the current ipv4 and ipv6 addresses assigned to a particular device, and while the ipv4 function works fine the ipv6 address is consistently wrong and almost always the same string - making me think it is converting some internal error code to a string ("::XXe2:ffff:ff7f:0" where the "X"s are the only two characters which ever change). The two functions are nearly identical, and I think the error probably comes from needing to use inet_ntop() for the ipv6 address because there is no ipv6-compatible version of the inet_ntoa() function. Do you have any thoughts or ideas about where the error might be coming from or a better way to read off the ipv6 address as a string? Here are the two functions: Note: "name" is the QString of the device name (wlan0, re0, other...), and is an internal variable for the overall "NetDevice" class [code] //Fetch the IPv4 address and return it as a QString QString NetDevice::ipAsString(){ struct ifreq ifr; memset(&ifr, 0, sizeof(struct ifreq)); strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); int s = socket(PF_INET, SOCK_DGRAM, 0); ioctl(s, SIOCGIFADDR, &ifr); struct in_addr in = ((sockaddr_in *) &ifr.ifr_addr)->sin_addr; return QString( inet_ntoa(in) ); } //Fetch the IPv6 address and return it as a QString QString NetDevice::ipv6AsString(){ struct ifreq ifr; memset(&ifr, 0, sizeof(struct ifreq)); strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); int s = socket(PF_INET6, SOCK_DGRAM, 0); ioctl(s, SIOCGIFADDR, &ifr); struct in6_addr in = ((sockaddr_in6 *) &ifr.ifr_addr)->sin6_addr; char straddr[INET6_ADDRSTRLEN]; inet_ntop(AF_INET6, &in, straddr, sizeof(straddr)); return QString( inet_ntop(AF_INET6, &in, straddr, sizeof(straddr)) ); } [/code] Thanks! Any input is appreciated! -- ~~ Ken Moore ~~ PC-BSD/iXsystems From owner-freebsd-net@freebsd.org Wed Dec 9 14:35:49 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 647119D52D6 for ; Wed, 9 Dec 2015 14:35:49 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ED141645 for ; Wed, 9 Dec 2015 14:35:48 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from alph.d.allbsd.org (p1141-ipbf2205funabasi.chiba.ocn.ne.jp [114.148.196.141]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.9) with ESMTP id tB9EZP9A038307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/C=XX/ST=Some-state/L=Some-city/O=Some-org/CN=alph.allbsd.org", Issuer "/C=XX/ST=Some-state/L=Some-city/O=Some-org/CN=alph.allbsd.org"); Wed, 9 Dec 2015 23:35:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id tB9EZN3K059602; Wed, 9 Dec 2015 23:35:24 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 09 Dec 2015 23:35:15 +0900 (JST) Message-Id: <20151209.233515.1592617248580059512.hrs@allbsd.org> To: ken@pcbsd.org Cc: freebsd-net@freebsd.org Subject: Re: IPv6 Address as text (C) From: Hiroki Sato In-Reply-To: <5668369F.9020309@pcbsd.org> References: <5668369F.9020309@pcbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Dec__9_23_35_15_2015_181)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.6 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [133.31.130.32]); Wed, 09 Dec 2015 23:35:40 +0900 (JST) X-Spam-Status: No, score=-94.5 required=13.0 tests=CONTENT_TYPE_PRESENT, RCVD_IN_AHBL, RCVD_IN_AHBL_PROXY, RCVD_IN_AHBL_SPAM, RCVD_IN_PBL, RCVD_IN_RP_RNBL, USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gatekeeper.allbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 14:35:49 -0000 ----Security_Multipart(Wed_Dec__9_23_35_15_2015_181)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Moore wrote in <5668369F.9020309@pcbsd.org>: ke> Note: Please CC me on replies - I am not subscribed to this list. ke> ke> I am having a bit of trouble getting an accurate string representation ke> of the current IPv6 address for a given device using the C system ke> libraries and was wondering of somebody with more experience than me ke> might be able to spot the error... ke> ke> Background: ke> I have been working on a couple simple C/C++/Qt functions to return ke> printable forms of the current ipv4 and ipv6 addresses assigned to a ke> particular device, and while the ipv4 function works fine the ipv6 ke> address is consistently wrong and almost always the same string - ke> making me think it is converting some internal error code to a string ke> ("::XXe2:ffff:ff7f:0" where the "X"s are the only two characters which ke> ever change). ke> ke> The two functions are nearly identical, and I think the error probably ke> comes from needing to use inet_ntop() for the ipv6 address because ke> there is no ipv6-compatible version of the inet_ntoa() function. ke> Do you have any thoughts or ideas about where the error might be ke> coming from or a better way to read off the ipv6 address as a string? ke> ke> Here are the two functions: ke> Note: "name" is the QString of the device name (wlan0, re0, other...), ke> and is an internal variable for the overall "NetDevice" class ke> [code] ke> //Fetch the IPv4 address and return it as a QString ke> QString NetDevice::ipAsString(){ ke> struct ifreq ifr; ke> memset(&ifr, 0, sizeof(struct ifreq)); ke> ke> strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); ke> int s = socket(PF_INET, SOCK_DGRAM, 0); ke> ke> ioctl(s, SIOCGIFADDR, &ifr); ke> struct in_addr in = ((sockaddr_in *) &ifr.ifr_addr)->sin_addr; ke> ke> return QString( inet_ntoa(in) ); ke> } ke> ke> //Fetch the IPv6 address and return it as a QString ke> QString NetDevice::ipv6AsString(){ ke> struct ifreq ifr; ke> memset(&ifr, 0, sizeof(struct ifreq)); ke> ke> strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); ke> int s = socket(PF_INET6, SOCK_DGRAM, 0); ke> ke> ioctl(s, SIOCGIFADDR, &ifr); Should this be SIOCGIFADDR_IN6 here? You should check the error code. Anyway, you should use getnameinfo() for IPv4 and IPv6 instead of inet_ntop() and inet_ntoa() for this purpose. It is an address family independent API which accepts struct sockaddr directly like this: ---- struct sockaddr *sa; /* input */ char hbuf[NI_MAXHOST]; int error; error = getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), NULL, 0, NI_NUMERICHOST); if (error) { errx(1, "getnameinfo: %s", gai_strerror(error)); /* NOTREACHED */ } printf("host=%s\n", hbuf); ---- See getnameinfo(3) for more details. -- Hiroki ----Security_Multipart(Wed_Dec__9_23_35_15_2015_181)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlZoPCMACgkQTyzT2CeTzy017QCgg0p18C2ZOOd5fyAbWJ0WKzOo DwkAnAm4cZlrHuFM/V8IYm9zGtCazqrC =04D0 -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Dec__9_23_35_15_2015_181)---- From owner-freebsd-net@freebsd.org Wed Dec 9 15:25:43 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A1299D472E for ; Wed, 9 Dec 2015 15:25:43 +0000 (UTC) (envelope-from ken@pcbsd.org) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 437C01058 for ; Wed, 9 Dec 2015 15:25:42 +0000 (UTC) (envelope-from ken@pcbsd.org) X-ASG-Debug-ID: 1449674740-08ca042abc06d30002-QdxwpM Received: from [192.168.1.130] (24-151-177-78.dhcp.kgpt.tn.charter.com [24.151.177.78]) by barracuda.ixsystems.com with ESMTP id uuGFbyYNuaNCKqpw (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 09 Dec 2015 07:25:41 -0800 (PST) X-Barracuda-Envelope-From: ken@pcbsd.org X-Barracuda-AUTH-User: ken@pcbsd.org X-Barracuda-Apparent-Source-IP: 24.151.177.78 Subject: Re: IPv6 Address as text (C) To: Hiroki Sato X-ASG-Orig-Subj: Re: IPv6 Address as text (C) References: <5668369F.9020309@pcbsd.org> <20151209.233515.1592617248580059512.hrs@allbsd.org> Cc: freebsd-net@freebsd.org From: Ken Moore Message-ID: <566847F3.7060900@pcbsd.org> Date: Wed, 9 Dec 2015 10:25:39 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151209.233515.1592617248580059512.hrs@allbsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 24-151-177-78.dhcp.kgpt.tn.charter.com[24.151.177.78] X-Barracuda-Start-Time: 1449674740 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.25107 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 15:25:43 -0000 On 12/09/2015 09:35, Hiroki Sato wrote: > Ken Moore wrote > in <5668369F.9020309@pcbsd.org>: > > ke> Note: Please CC me on replies - I am not subscribed to this list. > ke> > ke> I am having a bit of trouble getting an accurate string representation > ke> of the current IPv6 address for a given device using the C system > ke> libraries and was wondering of somebody with more experience than me > ke> might be able to spot the error... > ke> > ke> Background: > ke> I have been working on a couple simple C/C++/Qt functions to return > ke> printable forms of the current ipv4 and ipv6 addresses assigned to a > ke> particular device, and while the ipv4 function works fine the ipv6 > ke> address is consistently wrong and almost always the same string - > ke> making me think it is converting some internal error code to a string > ke> ("::XXe2:ffff:ff7f:0" where the "X"s are the only two characters which > ke> ever change). > ke> > ke> The two functions are nearly identical, and I think the error probably > ke> comes from needing to use inet_ntop() for the ipv6 address because > ke> there is no ipv6-compatible version of the inet_ntoa() function. > ke> Do you have any thoughts or ideas about where the error might be > ke> coming from or a better way to read off the ipv6 address as a string? > ke> > ke> Here are the two functions: > ke> Note: "name" is the QString of the device name (wlan0, re0, other...), > ke> and is an internal variable for the overall "NetDevice" class > ke> [code] > ke> //Fetch the IPv4 address and return it as a QString > ke> QString NetDevice::ipAsString(){ > ke> struct ifreq ifr; > ke> memset(&ifr, 0, sizeof(struct ifreq)); > ke> > ke> strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); > ke> int s = socket(PF_INET, SOCK_DGRAM, 0); > ke> > ke> ioctl(s, SIOCGIFADDR, &ifr); > ke> struct in_addr in = ((sockaddr_in *) &ifr.ifr_addr)->sin_addr; > ke> > ke> return QString( inet_ntoa(in) ); > ke> } > ke> > ke> //Fetch the IPv6 address and return it as a QString > ke> QString NetDevice::ipv6AsString(){ > ke> struct ifreq ifr; > ke> memset(&ifr, 0, sizeof(struct ifreq)); > ke> > ke> strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); > ke> int s = socket(PF_INET6, SOCK_DGRAM, 0); > ke> > ke> ioctl(s, SIOCGIFADDR, &ifr); > > Should this be SIOCGIFADDR_IN6 here? You should check the error > code. There does not appear to be any *_IN6 definitions in any of the /usr/include/[sys, net, netinet]/* include files (sys/sockio.h appears to hold the defines needed - nothing ipv6 related though). > Anyway, you should use getnameinfo() for IPv4 and IPv6 instead of > inet_ntop() and inet_ntoa() for this purpose. It is an address > family independent API which accepts struct sockaddr directly like > this: > > ---- > struct sockaddr *sa; /* input */ > char hbuf[NI_MAXHOST]; > int error; > > error = getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), NULL, > 0, NI_NUMERICHOST); > if (error) { > errx(1, "getnameinfo: %s", gai_strerror(error)); > /* NOTREACHED */ > } > printf("host=%s\n", hbuf); > ---- > > See getnameinfo(3) for more details. > > -- Hiroki So I adjusted the function to use getnameinfo() as you recommended: and the reported error is "ai_family not supported". [code] QString NetDevice::ipv6AsString(){ struct ifreq ifr; memset(&ifr, 0, sizeof(struct ifreq)); strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); int s = socket(PF_INET6, SOCK_DGRAM, 0); ioctl(s, SIOCGIFADDR, &ifr); sockaddr *in = (&ifr.ifr_addr); char straddr[INET6_ADDRSTRLEN]; int err = getnameinfo(in, in->sa_len, straddr, sizeof(straddr),NULL, 0, NI_NUMERICHOST); if(err){ return QString(gai_strerror(err)); } else{ return QString(straddr); } } [/code] -- ~~ Ken Moore ~~ PC-BSD/iXsystems From owner-freebsd-net@freebsd.org Wed Dec 9 16:14:13 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE2319D5C6C for ; Wed, 9 Dec 2015 16:14:13 +0000 (UTC) (envelope-from ken@pcbsd.org) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D62611BEB for ; Wed, 9 Dec 2015 16:14:13 +0000 (UTC) (envelope-from ken@pcbsd.org) X-ASG-Debug-ID: 1449677651-08ca042abc06db0002-QdxwpM Received: from [192.168.1.130] (24-151-177-78.dhcp.kgpt.tn.charter.com [24.151.177.78]) by barracuda.ixsystems.com with ESMTP id XjY1NGOCdhnaDde7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 09 Dec 2015 08:14:12 -0800 (PST) X-Barracuda-Envelope-From: ken@pcbsd.org X-Barracuda-AUTH-User: ken@pcbsd.org X-Barracuda-Apparent-Source-IP: 24.151.177.78 Subject: Re: IPv6 Address as text (C) To: Hiroki Sato X-ASG-Orig-Subj: Re: IPv6 Address as text (C) References: <5668369F.9020309@pcbsd.org> <20151209.233515.1592617248580059512.hrs@allbsd.org> Cc: freebsd-net@freebsd.org From: Ken Moore Message-ID: <56685352.60206@pcbsd.org> Date: Wed, 9 Dec 2015 11:14:10 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151209.233515.1592617248580059512.hrs@allbsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 24-151-177-78.dhcp.kgpt.tn.charter.com[24.151.177.78] X-Barracuda-Start-Time: 1449677651 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.25109 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 16:14:14 -0000 On 12/09/2015 09:35, Hiroki Sato wrote: > Ken Moore wrote > in <5668369F.9020309@pcbsd.org>: > > ke> Note: Please CC me on replies - I am not subscribed to this list. > ke> > ke> I am having a bit of trouble getting an accurate string representation > ke> of the current IPv6 address for a given device using the C system > ke> libraries and was wondering of somebody with more experience than me > ke> might be able to spot the error... > ke> > ke> Background: > ke> I have been working on a couple simple C/C++/Qt functions to return > ke> printable forms of the current ipv4 and ipv6 addresses assigned to a > ke> particular device, and while the ipv4 function works fine the ipv6 > ke> address is consistently wrong and almost always the same string - > ke> making me think it is converting some internal error code to a string > ke> ("::XXe2:ffff:ff7f:0" where the "X"s are the only two characters which > ke> ever change). > ke> > ke> The two functions are nearly identical, and I think the error probably > ke> comes from needing to use inet_ntop() for the ipv6 address because > ke> there is no ipv6-compatible version of the inet_ntoa() function. > ke> Do you have any thoughts or ideas about where the error might be > ke> coming from or a better way to read off the ipv6 address as a string? > ke> > ke> Here are the two functions: > ke> Note: "name" is the QString of the device name (wlan0, re0, other...), > ke> and is an internal variable for the overall "NetDevice" class > ke> [code] > ke> //Fetch the IPv4 address and return it as a QString > ke> QString NetDevice::ipAsString(){ > ke> struct ifreq ifr; > ke> memset(&ifr, 0, sizeof(struct ifreq)); > ke> > ke> strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); > ke> int s = socket(PF_INET, SOCK_DGRAM, 0); > ke> > ke> ioctl(s, SIOCGIFADDR, &ifr); > ke> struct in_addr in = ((sockaddr_in *) &ifr.ifr_addr)->sin_addr; > ke> > ke> return QString( inet_ntoa(in) ); > ke> } > ke> > ke> //Fetch the IPv6 address and return it as a QString > ke> QString NetDevice::ipv6AsString(){ > ke> struct ifreq ifr; > ke> memset(&ifr, 0, sizeof(struct ifreq)); > ke> > ke> strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); > ke> int s = socket(PF_INET6, SOCK_DGRAM, 0); > ke> > ke> ioctl(s, SIOCGIFADDR, &ifr); > > Should this be SIOCGIFADDR_IN6 here? You should check the error > code. > > Anyway, you should use getnameinfo() for IPv4 and IPv6 instead of > inet_ntop() and inet_ntoa() for this purpose. It is an address > family independent API which accepts struct sockaddr directly like > this: > > ---- > struct sockaddr *sa; /* input */ > char hbuf[NI_MAXHOST]; > int error; > > error = getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), NULL, > 0, NI_NUMERICHOST); > if (error) { > errx(1, "getnameinfo: %s", gai_strerror(error)); > /* NOTREACHED */ > } > printf("host=%s\n", hbuf); > ---- > > See getnameinfo(3) for more details. > > -- Hiroki Quick Followup with additional debugging: The errors appear to explicitly involve the sockaddr[_in6] to string conversion routine: I looked at how ifconfig does this same thing (lines 209-214 in af_inet6.c) and adjusted my routine to match and I still get the same errors: [code] QString NetDevice::ipv6AsString(){ struct ifreq ifr; memset(&ifr, 0, sizeof(struct ifreq)); strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); int s = socket(PF_INET6, SOCK_DGRAM, 0); if(s<0){ return "Error creating socket"; } int err = ioctl(s, SIOCGIFADDR, &ifr); if(err<0){ return (QString("Error with ioctl: ")+QString::number(err)); } struct sockaddr_in6 *in = (struct sockaddr_in6 *)(&ifr.ifr_addr); char straddr[INET6_ADDRSTRLEN]; err = getnameinfo((struct sockaddr *)in, in->sin6_len, straddr, sizeof(straddr),NULL, 0, NI_NUMERICHOST); if(err){ qDebug() << "getnameinfo error:" << gai_strerror(err); //Fall back on ntop instead inet_ntop(AF_INET6, &in->sin6_addr, straddr, sizeof(straddr)); } return QString(straddr); } [/code] This returns: getnameinfo error: ai_family not supported ::6a00:0:0:0 Which obviously does not match what ifconfig returns as the ipv6 address for the device. Any other ideas? -- ~~ Ken Moore ~~ PC-BSD/iXsystems From owner-freebsd-net@freebsd.org Wed Dec 9 16:31:48 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76F559D4972 for ; Wed, 9 Dec 2015 16:31:48 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3ECDC1515 for ; Wed, 9 Dec 2015 16:31:47 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1a6heT-00078Q-Ok for freebsd-net@freebsd.org; Wed, 09 Dec 2015 17:31:38 +0100 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Dec 2015 17:31:37 +0100 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Dec 2015 17:31:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Subject: Re: IPv6 Address as text (C) Date: Wed, 9 Dec 2015 08:31:31 -0800 Lines: 102 Message-ID: <56685763.5080506@gmail.com> References: <5668369F.9020309@pcbsd.org> <20151209.233515.1592617248580059512.hrs@allbsd.org> <566847F3.7060900@pcbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org Cc: ken@pcbsd.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <566847F3.7060900@pcbsd.org> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 16:31:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/9/15 7:25 AM, Ken Moore wrote: > On 12/09/2015 09:35, Hiroki Sato wrote: >> Ken Moore wrote in <5668369F.9020309@pcbsd.org>: >> >> ke> Note: Please CC me on replies - I am not subscribed to this >> list. ke> ke> I am having a bit of trouble getting an accurate >> string representation ke> of the current IPv6 address for a given >> device using the C system ke> libraries and was wondering of >> somebody with more experience than me ke> might be able to spot >> the error... ke> ke> Background: ke> I have been working on a >> couple simple C/C++/Qt functions to return ke> printable forms of >> the current ipv4 and ipv6 addresses assigned to a ke> particular >> device, and while the ipv4 function works fine the ipv6 ke> >> address is consistently wrong and almost always the same string >> - ke> making me think it is converting some internal error code >> to a string ke> ("::XXe2:ffff:ff7f:0" where the "X"s are the only >> two characters which ke> ever change). ke> ke> The two functions >> are nearly identical, and I think the error probably ke> comes >> from needing to use inet_ntop() for the ipv6 address because ke> >> there is no ipv6-compatible version of the inet_ntoa() function. >> ke> Do you have any thoughts or ideas about where the error might >> be ke> coming from or a better way to read off the ipv6 address >> as a string? ke> ke> Here are the two functions: ke> Note: "name" >> is the QString of the device name (wlan0, re0, other...), ke> and >> is an internal variable for the overall "NetDevice" class ke> >> [code] ke> //Fetch the IPv4 address and return it as a QString >> ke> QString NetDevice::ipAsString(){ ke> struct ifreq ifr; ke> >> memset(&ifr, 0, sizeof(struct ifreq)); ke> ke> >> strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); ke> int s >> = socket(PF_INET, SOCK_DGRAM, 0); ke> ke> ioctl(s, >> SIOCGIFADDR, &ifr); ke> struct in_addr in = ((sockaddr_in *) >> &ifr.ifr_addr)->sin_addr; ke> ke> return QString( >> inet_ntoa(in) ); ke> } ke> ke> //Fetch the IPv6 address and >> return it as a QString ke> QString NetDevice::ipv6AsString(){ ke> >> struct ifreq ifr; ke> memset(&ifr, 0, sizeof(struct ifreq)); >> ke> ke> strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); >> ke> int s = socket(PF_INET6, SOCK_DGRAM, 0); ke> ke> >> ioctl(s, SIOCGIFADDR, &ifr); >> >> Should this be SIOCGIFADDR_IN6 here? You should check the error >> code. > There does not appear to be any *_IN6 definitions in any of the > /usr/include/[sys, net, netinet]/* include files (sys/sockio.h > appears to hold the defines needed - nothing ipv6 related though). > >> Anyway, you should use getnameinfo() for IPv4 and IPv6 instead >> of inet_ntop() and inet_ntoa() for this purpose. It is an >> address family independent API which accepts struct sockaddr >> directly like this: >> >> ---- struct sockaddr *sa; /* input */ char hbuf[NI_MAXHOST]; int >> error; >> >> error = getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), NULL, 0, >> NI_NUMERICHOST); if (error) { errx(1, "getnameinfo: %s", >> gai_strerror(error)); /* NOTREACHED */ } printf("host=%s\n", >> hbuf); ---- >> >> See getnameinfo(3) for more details. >> >> -- Hiroki > > So I adjusted the function to use getnameinfo() as you recommended: > and the reported error is "ai_family not supported". > > [code] QString NetDevice::ipv6AsString(){ struct ifreq ifr; > memset(&ifr, 0, sizeof(struct ifreq)); > > strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ); int s = > socket(PF_INET6, SOCK_DGRAM, 0); > > ioctl(s, SIOCGIFADDR, &ifr); sockaddr *in = (&ifr.ifr_addr); char > straddr[INET6_ADDRSTRLEN]; > > int err = getnameinfo(in, in->sa_len, straddr, > sizeof(straddr),NULL, 0, NI_NUMERICHOST); if(err){ return > QString(gai_strerror(err)); } else{ return QString(straddr); } } > [/code] > > ioctl() is probably not returning what you expect (and you're not checking for error). You should probably be using getifaddrs(3). Interfaces can contain lots of addresses and ipv6 enabled interfaces will always contain a link-local at least. You may need to determine the scope of the address as well and if you only want globally routeable addresses, use that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZoV2MACgkQrDN5kXnx8yazdgCgmaZEIa/zhTZ6+R7il3a7DPUO VY4AnR5lUlK8jbMSofduLYAK7G27aox7 =GtN9 -----END PGP SIGNATURE----- From owner-freebsd-net@freebsd.org Wed Dec 9 16:52:15 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91A7B9D5A6F for ; Wed, 9 Dec 2015 16:52:15 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward18h.cmail.yandex.net (forward18h.cmail.yandex.net [87.250.230.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1C1121E; Wed, 9 Dec 2015 16:52:14 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward18h.cmail.yandex.net (Yandex) with ESMTP id 66D1F207AE; Wed, 9 Dec 2015 19:52:05 +0300 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 52B4E17000E9; Wed, 9 Dec 2015 19:52:04 +0300 (MSK) Received: by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id tr8T2fJiAV-q3eGE4DB; Wed, 9 Dec 2015 19:52:03 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1449679923; bh=cwOc0astTtLSDHUFue8bVutvi5I8L5VhbkPt6Go0DdY=; h=Subject:To:References:Cc:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; b=VR4rIMfHNNO5jN0WFp/nxJ9Cryoo0pgd7L2HeiubIUC3r0dXRddFVWbUnH/2nCaVp 7Z7Ggp6HQbFssl3UmybVHtZEelnrjxJKYHeruDCuHIw64w+qhO2ptJ/32Yfi6s9M1d gsp/10H09af+nFRm1EN3G3FXQEvjwX9Y7/9UBMb0= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-ForeignMX: US Subject: Re: IPv6 Address as text (C) To: Ken Moore , Hiroki Sato References: <5668369F.9020309@pcbsd.org> <20151209.233515.1592617248580059512.hrs@allbsd.org> <566847F3.7060900@pcbsd.org> Cc: freebsd-net@freebsd.org From: "Andrey V. Elsukov" Message-ID: <56685C23.600@yandex.ru> Date: Wed, 9 Dec 2015 19:51:47 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <566847F3.7060900@pcbsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1bsEEwJBHPTohNj7ncfRsJ17QrMhGb6gw" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 16:52:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1bsEEwJBHPTohNj7ncfRsJ17QrMhGb6gw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09.12.15 18:25, Ken Moore wrote: Simple example: #include __FBSDID("$FreeBSD$"); #include #include #include #include #include #include #include #include int main(int argc, char **argv) { char buf[INET6_ADDRSTRLEN]; struct ifaddrs *ifap, *ifa; int error; if (getifaddrs(&ifap) !=3D 0) err(1, "getifaddrs"); for (ifa =3D ifap; ifa; ifa =3D ifa->ifa_next) if (ifa->ifa_addr->sa_family =3D=3D AF_INET6) { error =3D getnameinfo(ifa->ifa_addr, ifa->ifa_addr->sa_len, buf, sizeof(buf), NULL, 0, NI_NUMERICHOST); if (error !=3D 0) err(1, "%s", gai_strerror(error)); printf("%s\n", buf); } freeifaddrs(ifap); return (0); } --=20 WBR, Andrey V. Elsukov --1bsEEwJBHPTohNj7ncfRsJ17QrMhGb6gw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWaFwmAAoJEAHF6gQQyKF6+x0IALRhJeeoUOAjElj5vctkSv7H q10R82pc2w7c+5u+ZwsKkofgkpQIxDdTI6XmTMFDG4YJzVfSfBKpzFnEwghc3r5f sn78fEc0hk5mlBImAMiHVb3Uo+xeWkKLJxMIE1jvKF7gfI5SxVM6mMmoL7YLIy5S bqdU3Rk4jFIz6PjPA6M3gid+8qyvbc9GfFxsrzgCmAvrZPFeg7X/UHmC7BxJDSQl pRZDZFYPPeAN4ppW/lL6FZTWN6TAXMm85Anqp/iCIJXQXKAKDFCJAw8kSdKUptMZ HS6lAXm/FITXRAzVVBGP7/UoasV/E+t/7y4yCI/4kKH1imRZHGPSOANBFJevBT4= =uVxP -----END PGP SIGNATURE----- --1bsEEwJBHPTohNj7ncfRsJ17QrMhGb6gw-- From owner-freebsd-net@freebsd.org Wed Dec 9 17:26:19 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C5959D4116 for ; Wed, 9 Dec 2015 17:26:19 +0000 (UTC) (envelope-from ken@pcbsd.org) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66ED31382 for ; Wed, 9 Dec 2015 17:26:19 +0000 (UTC) (envelope-from ken@pcbsd.org) X-ASG-Debug-ID: 1449681976-08ca042abd06a80002-QdxwpM Received: from [192.168.1.130] (24-151-177-78.dhcp.kgpt.tn.charter.com [24.151.177.78]) by barracuda.ixsystems.com with ESMTP id Sj8SG6FUrvXu21nv (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 09 Dec 2015 09:26:17 -0800 (PST) X-Barracuda-Envelope-From: ken@pcbsd.org X-Barracuda-AUTH-User: ken@pcbsd.org X-Barracuda-Apparent-Source-IP: 24.151.177.78 Subject: Re: IPv6 Address as text (C) To: "Andrey V. Elsukov" , Hiroki Sato X-ASG-Orig-Subj: Re: IPv6 Address as text (C) References: <5668369F.9020309@pcbsd.org> <20151209.233515.1592617248580059512.hrs@allbsd.org> <566847F3.7060900@pcbsd.org> <56685C23.600@yandex.ru> Cc: freebsd-net@freebsd.org From: Ken Moore Message-ID: <56686438.8000109@pcbsd.org> Date: Wed, 9 Dec 2015 12:26:16 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56685C23.600@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 24-151-177-78.dhcp.kgpt.tn.charter.com[24.151.177.78] X-Barracuda-Start-Time: 1449681977 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.25110 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 17:26:19 -0000 On 12/09/2015 11:51, Andrey V. Elsukov wrote: > On 09.12.15 18:25, Ken Moore wrote: > > Simple example: > > #include > __FBSDID("$FreeBSD$"); > > #include > #include > #include > > #include > #include > #include > #include > #include > > int > main(int argc, char **argv) > { > char buf[INET6_ADDRSTRLEN]; > struct ifaddrs *ifap, *ifa; > int error; > > if (getifaddrs(&ifap) != 0) > err(1, "getifaddrs"); > for (ifa = ifap; ifa; ifa = ifa->ifa_next) > if (ifa->ifa_addr->sa_family == AF_INET6) { > error = getnameinfo(ifa->ifa_addr, > ifa->ifa_addr->sa_len, buf, sizeof(buf), > NULL, 0, NI_NUMERICHOST); > if (error != 0) > err(1, "%s", gai_strerror(error)); > printf("%s\n", buf); > } > freeifaddrs(ifap); > return (0); > } > Thanks! Using getifaddrs() to fetch the pre-existing socket address did the trick. Here is the final form of the function which works (although I am sure I can clean it up a bit still...): [code] QString NetDevice::ipv6AsString(){ //Get the sockaddr for the device struct sockaddr *sadd = 0; struct ifaddrs *addrs; if( 0!=getifaddrs( &addrs ) ){ qDebug() << "Could not get addrs"; return ""; } while(sadd==0 && addrs!=0){ if( QString(addrs->ifa_name)==name && addrs->ifa_addr->sa_family==AF_INET6){ //Found device (with IPv6 address) sadd = addrs->ifa_addr; break; }else{ //Move to the next device addrs = addrs->ifa_next; } } free(addrs); if(sadd==0){ qDebug() << "No socket address found"; return ""; } //Now get the IPv6 address in string form char straddr[INET6_ADDRSTRLEN]; int err = getnameinfo(sadd, sadd->sa_len, straddr, sizeof(straddr),NULL, 0, NI_NUMERICHOST); if(err!=0){ qDebug() << "getnameinfo error:" << gai_strerror(err); return ""; }else{ return QString(straddr); } } [/code] Thanks everybody! -- ~~ Ken Moore ~~ PC-BSD/iXsystems From owner-freebsd-net@freebsd.org Wed Dec 9 19:18:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66EA39D6026 for ; Wed, 9 Dec 2015 19:18:22 +0000 (UTC) (envelope-from evidence@nitrology.com) Received: from nitrology.com (nitrology.com [69.28.133.242]) by mx1.freebsd.org (Postfix) with ESMTP id 575F31ED6; Wed, 9 Dec 2015 19:18:22 +0000 (UTC) (envelope-from evidence@nitrology.com) Received: by nitrology.com (Postfix, from userid 1001) id EB9799CC9F; Wed, 9 Dec 2015 12:18:15 -0700 (MST) Date: Wed, 9 Dec 2015 12:18:15 -0700 From: Jason Wolfe To: Kubilay Kocak Cc: "Andrey V. Elsukov" , freebsd-net@freebsd.org, Mark Johnston , kevin.bowling@kev009.com, hiren@strugglingcoder.info Subject: Re: Multiple cores/race conditions in IPv6 RA Message-ID: <20151209191815.GA56497@nitrology.com> References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> <5667EA3A.8050200@FreeBSD.org> <5667EC45.2050808@FreeBSD.org> <5667ED4C.90405@FreeBSD.org> <5667FC48.5090507@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5667FC48.5090507@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 19:18:22 -0000 Word around town is Kubilay Kocak leaked this on Wed, Dec 09, 2015 at 09:02:48PM +1100: > On 9/12/2015 7:58 PM, Andrey V. Elsukov wrote: > > On 09.12.15 11:54, Kubilay Kocak wrote: > >>> some time ago Mark Johnston has published there the patch related to > >>> this problem: > >>> https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html > >>> > >>> Maybe Mark has something to say about it. > >>> > >> > >> Is it worth creating an issue report to track/resolve this, with 10.3 > >> coming up? > > > > This problem exists since 4.x-5.x, so, I don't think that creating a > > report will automatically resolve it :) > > > > Not automatically no. But perhaps never being tracked has contributed to > its non-resolution? Andrey/Kubilay, Thanks for the responses. I was actually able to grab 2 patches from markj that we are currently testing. The first is actually in Phab, maybe we can bribe markj to pick it back up :) https://reviews.freebsd.org/D2254 The second one actually gets into the NDP code and is similar to the one posted on the mailing list that you linked. It's a few months newer from May of 2013: https://people.freebsd.org/~markj/patches/ndp-locking.diff Initial testing is going well, I'll report back once we have more conclusive results. It appears based various threads and reviews that the issues are a bit nebulous as there are many locking issues in this code. Thank you to markj and others for going after the hot spots, and I've created a bug report to track the overall progress of this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205165 Also, I don't believe these issues have been present for too long. I see the entry deletion bug reported on 4.X/5.X, and that seems to be more related to the ndp binary itself. Our 8.3-RELEASE installs did not exhibit the race conditions in the kernel code. Thanks again! Jason From owner-freebsd-net@freebsd.org Wed Dec 9 23:01:28 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F5E59D6D1F for ; Wed, 9 Dec 2015 23:01:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8137D1220 for ; Wed, 9 Dec 2015 23:01:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB9N1SeV043378 for ; Wed, 9 Dec 2015 23:01:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200379] SCTP stack is not FIB aware Date: Wed, 09 Dec 2015 23:01:28 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tuexen@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 23:01:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #20 from Craig Rodrigues --- Sorry for the late feedback. I can confirm that you fixed the problem. This was a very weird and convoluted corner case. Thank you so much for digging into this and fixing it!! -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Wed Dec 9 23:35:52 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EDF19D65EB for ; Wed, 9 Dec 2015 23:35:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F47D18B3 for ; Wed, 9 Dec 2015 23:35:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB9NZqpo026464 for ; Wed, 9 Dec 2015 23:35:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205169] 10.2-RELEASE panic on boot if autobridge with wlan0 (iwn) Date: Wed, 09 Dec 2015 23:35:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 23:35:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205169 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Wed Dec 9 23:36:33 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BFBF9D6729 for ; Wed, 9 Dec 2015 23:36:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C8181C5B for ; Wed, 9 Dec 2015 23:36:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB9NaXY9027444 for ; Wed, 9 Dec 2015 23:36:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205165] [ip6] [panic] Multiple race conditions in the V6 list manipulation Date: Wed, 09 Dec 2015 23:36:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 23:36:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205165 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Wed Dec 9 23:36:49 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51FC19D67A8 for ; Wed, 9 Dec 2015 23:36:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 429091D66 for ; Wed, 9 Dec 2015 23:36:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB9Nanh3027811 for ; Wed, 9 Dec 2015 23:36:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205164] BPF gives EIO with sendmsg() where write > pagesize Date: Wed, 09 Dec 2015 23:36:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Dec 2015 23:36:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 10 00:38:42 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA31F9D56A4 for ; Thu, 10 Dec 2015 00:38:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A69B1079 for ; Thu, 10 Dec 2015 00:38:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBA0cgIS025096 for ; Thu, 10 Dec 2015 00:38:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205164] BPF gives EIO with sendmsg() where write > pagesize Date: Thu, 10 Dec 2015 00:38:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: abasterfield@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 00:38:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164 --- Comment #1 from Andrew Basterfield --- https://github.com/OpenAoE/vblade/issues/7 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 10 02:27:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A12EE9D67D3 for ; Thu, 10 Dec 2015 02:27:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90CB61AE0 for ; Thu, 10 Dec 2015 02:27:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBA2RM0F034319 for ; Thu, 10 Dec 2015 02:27:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205165] [ip6] [panic] Multiple race conditions in the V6 list manipulation Date: Thu, 10 Dec 2015 02:27:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: keywords flagtypes.name bug_file_loc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 02:27:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205165 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |crash, needs-qa, patch Flags| |mfc-stable9?, mfc-stable10? URL| |https://reviews.freebsd.org | |/D2254 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 10 02:29:02 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64B9F9D68AE for ; Thu, 10 Dec 2015 02:29:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5464B1BE0 for ; Thu, 10 Dec 2015 02:29:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBA2T2su079382 for ; Thu, 10 Dec 2015 02:29:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205169] 10.2-RELEASE panic on boot if autobridge with wlan0 (iwn) Date: Thu, 10 Dec 2015 02:29:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: keywords flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 02:29:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205169 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |crash, needs-patch, | |needs-qa Flags| |mfc-stable9?, mfc-stable10? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 10 15:11:28 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE7AD9D6F15; Thu, 10 Dec 2015 15:11:27 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 9BCC010AA; Thu, 10 Dec 2015 15:11:27 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 88AD61FE023; Thu, 10 Dec 2015 16:11:18 +0100 (CET) Subject: Re: panic in arptimer in r289937 To: "Alexander V. Chernikov" , Adrian Chadd References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> Cc: FreeBSD Net , freebsd-current , Randall Stewart From: Hans Petter Selasky Message-ID: <56699683.5030203@selasky.org> Date: Thu, 10 Dec 2015 16:13:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5661EF10.8060300@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 15:11:28 -0000 Hi, Here is the backtrace for a reproducable panic seen with arptimer(): > #0 doadump (textdump=0) at pcpu.h:221 > #1 0xffffffff80385afb in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/img/freebsd/sys/ddb/db_command.c:533 > #2 0xffffffff803858ee in db_command (cmd_table=0x0) at /usr/img/freebsd/sys/ddb/db_command.c:440 > #3 0xffffffff80385684 in db_command_loop () at /usr/img/freebsd/sys/ddb/db_command.c:493 > #4 0xffffffff8038818b in db_trap (type=, code=0) at /usr/img/freebsd/sys/ddb/db_main.c:251 > #5 0xffffffff80ae0973 in kdb_trap (type=12, code=0, tf=) at /usr/img/freebsd/sys/kern/subr_kdb.c:654 > #6 0xffffffff80f276f1 in trap_fatal (frame=0xfffffe00f59f4950, eva=) at /usr/img/freebsd/sys/amd64/amd64/trap.c:829 > #7 0xffffffff80f27924 in trap_pfault (frame=0xfffffe00f59f4950, usermode=) at /usr/img/freebsd/sys/amd64/amd64/trap.c:684 > #8 0xffffffff80f270de in trap (frame=0xfffffe00f59f4950) at /usr/img/freebsd/sys/amd64/amd64/trap.c:435 > #9 0xffffffff80f0a347 in calltrap () at /usr/img/freebsd/sys/amd64/amd64/exception.S:234 > #10 0xffffffff80be9e3d in arptimer (arg=0xfffff8011d0fda00) at atomic.h:184 > #11 0xffffffff80ab54f1 in softclock_call_cc (c=0xfffff8011d0fdaa8, cc=0xffffffff81ccd600, direct=) > at /usr/img/freebsd/sys/kern/kern_timeout.c:832 > #12 0xffffffff80ab5814 in softclock (arg=0xffffffff81ccd600) at /usr/img/freebsd/sys/kern/kern_timeout.c:921 > #13 0xffffffff80a5d7f6 in intr_event_execute_handlers (p=, ie=0xfffff80003998b00) at /usr/img/freebsd/sys/kern/kern_intr.c:1262 > #14 0xffffffff80a5de06 in ithread_loop (arg=0xfffff8000396cde0) at /usr/img/freebsd/sys/kern/kern_intr.c:1275 > #15 0xffffffff80a5a87c in fork_exit (callout=0xffffffff80a5dd60 , arg=0xfffff8000396cde0, frame=0xfffffe00f59f4c00) > at /usr/img/freebsd/sys/kern/kern_fork.c:1011 > #16 0xffffffff80f0a87e in fork_trampoline () at /usr/img/freebsd/sys/amd64/amd64/exception.S:609 > #17 0x0000000000000000 in ?? () (kgdb) print ((struct llentry *)arg)[0] $5 = { lle_next = { le_next = 0x0, le_prev = 0xfffff80069b5fa98 }, r_l3addr = { addr4 = { s_addr = 1563742475 }, addr6 = { __u6_addr = { __u6_addr8 = 0xfffff8011d0fda10 "\vοΏ½4]", __u6_addr16 = 0xfffff8011d0fda10, __u6_addr32 = 0xfffff8011d0fda10 } } }, ll_addr = { mac_aligned = 121984137371108, mac16 = 0xfffff8011d0fda20, mac8 = 0xfffff8011d0fda20 "οΏ½\035-οΏ½οΏ½n" }, r_flags = 1, r_skip_req = 1, spare1 = 0, lle_tbl = 0xfffff80005653300, lle_head = 0xfffff80069b5fa98, lle_free = 0xffffffff80bf2270 , la_hold = 0x0, la_numheld = 0, la_expire = 12422, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 2, ln_router = 0, ln_ntick = 0, lle_refcnt = 1, lle_chain = { le_next = 0x0, le_prev = 0x0 }, lle_timer = { c_links = { le = { le_next = 0x0, le_prev = 0xffffffff81ccd718 }, sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0xffffffff81ccd718 } }, c_time = 53354272998546, c_precision = 268435437, c_arg = 0xfffff8011d0fda00, c_func = 0xffffffff80be9950 , c_lock = 0x0, c_flags = 16, c_cpu = 0 }, lle_lock = { lock_object = { lo_name = 0xffffffff8144abf0 "lle", lo_flags = 90374144, lo_data = 0, lo_witness = 0x0 }, rw_lock = 1 }, req_mtx = { lock_object = { lo_name = 0xffffffff8144abf4 "lle req", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0 }, mtx_lock = 4 } } (kgdb) print /x ((struct llentry *)arg)->lle_tbl[0] $6 = { llt_link = { sle_next = 0xfffff8004be51900 }, llt_af = 0x1d243aa0, llt_hsize = 0xfffff801, lle_head = 0xfffff800053e5330, llt_ifp = 0xd04, llt_lookup = 0x0, llt_alloc_entry = 0xfffffe0001a472f0, llt_delete_entry = 0xfffff800504a5100, llt_prefix_free = 0xfffff800503d8c88, llt_dump_entry = 0x0, llt_hash = 0x0, llt_match_prefix = 0x0, llt_free_entry = 0x0, llt_foreach_entry = 0x0, llt_link_entry = 0x0, llt_unlink_entry = 0x38e425e, llt_fill_sa_entry = 0x0, llt_free_tbl = 0xfffff8011d243ab0 } It appears arptimer() was called after lltable_unlink_entry() was called, because la_flags does not have the LLE_LINKED bit set, which can happen!! If arptimer() is firing exactly when we call lltable_unlink_entry(), then arptimer() will refer to freed memory. Does the following patch make sense? > Index: netinet/if_ether.c > =================================================================== > --- netinet/if_ether.c (revision 291256) > +++ netinet/if_ether.c (working copy) > @@ -185,7 +185,13 @@ > LLE_WUNLOCK(lle); > return; > } > - ifp = lle->lle_tbl->llt_ifp; > + if (lle->la_flags & LLE_LINKED) { > + ifp = lle->lle_tbl->llt_ifp; > + } else { > + /* XXX RACE entry has been freed */ > + llentry_free(lle); > + return; > + } > CURVNET_SET(ifp->if_vnet); > > if ((lle->la_flags & LLE_DELETED) == 0) { If you need more information from the dump, let me know. --HPS From owner-freebsd-net@freebsd.org Thu Dec 10 15:19:21 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8020F9D74CE for ; Thu, 10 Dec 2015 15:19:21 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5166818D5 for ; Thu, 10 Dec 2015 15:19:21 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pabur14 with SMTP id ur14so49212330pab.0 for ; Thu, 10 Dec 2015 07:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uAXgjMBQMvSBiF56K5cDrS8ficVXXJ7eBLT2JwhSFGs=; b=eVUE3qKnUEdYyN46BSh6O/AiMWzI8iGhAMxXbZUcfZeFeB/kOcFKszPpN40LCpUcii aVcKjEKgm9eP1jBxU3uQ2jUiVNqME41lvk+qRLnIBhoa58RGPb6RjwsNOgB65/lW92yp OCeJYFpSEavojogRt+2fBTppvBGwAG9597jD4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uAXgjMBQMvSBiF56K5cDrS8ficVXXJ7eBLT2JwhSFGs=; b=Xdeptdfize6AMcgVGaqcL0r98AvluU57vBMbAIl7M+rS0ob/5jks4163qb+tl4rx8V ELUgvkdew8nz1zI0Drkxg4hnevX8u1ylaUi5lMWy+ICSp3XoQ4cNQ7md1QHrIvekUyrV +f8kFWy5oIxC/QnIBcZJxEVuKsy2kckEiUGa9/GvLHQ1w4MMDP+7W4qdJmxcX0v7OoUg wti3LPUyIv5h99B9+riSayCBjccLLcYaS8elhjhFahELvkpG1mJ2Y3TKvTKkknDg0/iM TvOMZ9lpT2BcSy5FJHtiA/mXmfEw1nMPe+blWytS/TjevOuo+3vd2BalAyrd7OvKq1T7 THtA== X-Gm-Message-State: ALoCoQl7VlUt8unlJDvRT5X4qevkj/LlRpR30aNH5lwUhWLbpP61/djRFDjq/UEr7t9yKjkiumb/4sp4tKUh4Rcq0R8KvVQXBQ== X-Received: by 10.66.254.234 with SMTP id al10mr17371925pad.87.1449760760835; Thu, 10 Dec 2015 07:19:20 -0800 (PST) Received: from ?IPv6:2607:fb10:16:208:6441:e815:1de9:889c? ([2607:fb10:16:208:6441:e815:1de9:889c]) by smtp.gmail.com with ESMTPSA id xz6sm12185043pab.42.2015.12.10.07.19.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 07:19:19 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic in arptimer in r289937 From: Randall Stewart In-Reply-To: <5661EAAF.1010906@selasky.org> Date: Thu, 10 Dec 2015 07:19:17 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current Message-Id: <2CB15013-69DC-491E-A9AD-45CA95D37AE9@netflix.com> References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 15:19:21 -0000 Hans: Though it would not hurt to add your patch, its not possible for callout_reset() to return anything but 1 or 0. Only callout_stop(), callout_drain(), callout_async_drain() can return = -1. So I don=92t think that this will fix it. R On Dec 4, 2015, at 11:34 AM, Hans Petter Selasky = wrote: >>>> . -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-net@freebsd.org Thu Dec 10 15:26:00 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BD279D791B for ; Thu, 10 Dec 2015 15:26:00 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB551D97 for ; Thu, 10 Dec 2015 15:26:00 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pacdm15 with SMTP id dm15so49256929pac.3 for ; Thu, 10 Dec 2015 07:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=FTTHQyrkWI+EYCu+3oZ9tUhE3sqlQ6eQqVGGmHxbE2I=; b=aeXSkM29eIqqVhuGS75Mh2WBDulordAHYyyjZz+l9Zna9eS/RXA6HieOJpyzGnebiN mzgYKU90GVU/r6ZAfg8XNZf4Punj2XciFshkihVoz8DNox2w6HO9YmJOIoUutEVTKos1 vnMwdWuIPQHPf+K96bThdD0TXkdGl8Cokc8o8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FTTHQyrkWI+EYCu+3oZ9tUhE3sqlQ6eQqVGGmHxbE2I=; b=SUc8N98InlERO/OkHTS7HLN9ta5GMOf0VCXcngCR/lygXsOr6NpirpfWlnwsj52xnU xnbq0IKaqT1EXvm1pZCu0IoUpF7qSEmRC/zKHcqZPmfvCZXrmTDBvXV7P42+VbZq3sPC /MzioCg5HCReQuIp8ZCco6077kYz2tsGLoQqk6B6HSGVQxc5ikBwgn1fNB5e5UOZq8y7 jc/JNEhICw5QRPkO+RwCCDBxkkgreJdGBtEH9rmBGlOl/sec+wTzy6iPGMRDlrTFyqu6 gRdSICQUZsNgwJ1pXz8WQd5FVUhRFZl52QtGIpkiw8VjaFgv8IZxq+Ibska0Lejy4HIg pqyw== X-Gm-Message-State: ALoCoQmdU3TTBVU6VZW0YuWYQeh5/yG5vIJlU0SxiA6DH8s98iDP7vy13RzlMM4ldd1PtWuF+mbe/IVd5xUeT030dhMcySzcIA== X-Received: by 10.67.5.40 with SMTP id cj8mr17202864pad.98.1449761159705; Thu, 10 Dec 2015 07:25:59 -0800 (PST) Received: from [10.16.208.207] ([69.53.232.0]) by smtp.gmail.com with ESMTPSA id sg4sm19599472pac.48.2015.12.10.07.25.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 07:25:58 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic in arptimer in r289937 From: Randall Stewart In-Reply-To: <5661EF10.8060300@selasky.org> Date: Thu, 10 Dec 2015 07:25:56 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current Message-Id: <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 15:26:00 -0000 For callout_stop/drain you get -1 =3D=3D Callout as already gone off or is not running (usually the = latter) else the caller iks not using locking properly or did not lock and check the = active() value (which would have returned not active so no stop would have been needed); 0 =3D=3D we could not stop the callout, it was in process.. 1 =3D=3D it was stopped successfully=20 For callout_reset() you get 0 =3D=3D it was started 1 =3D=3D it was restarted. There is no -1 since it is either started or restarted never left in a = not-running state... R On Dec 4, 2015, at 11:52 AM, Hans Petter Selasky = wrote: > On 12/04/15 20:34, Hans Petter Selasky wrote: >> Hi Adrian, >>=20 >> On 10/31/15 16:01, Alexander V. Chernikov wrote: >>>=20 >>>=20 >>> 31.10.2015, 16:46, "Adrian Chadd" : >>>> On 31 October 2015 at 09:34, Alexander V. Chernikov >>>> wrote: >>>>> 31.10.2015, 05:32, "Adrian Chadd" : >>>>>> Hiya, >>>>>>=20 >>>>>> Here's a panic from arptimer: >>>>> Hi Adrian, >>>>>=20 >>>>> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) >>>>> which happens after LLE_WUNLOCK(). >>>>> So, it looks like (pre-cached) ifp had been freed before locking >>>>> ifdata. >>>>> Do you have any more details on that? (e.g. was some interface >>>>> detached at that moment, is it reproducible, etc..) >>>>>=20 >>>>> =46rom a quick glance, potential use-after-free has been possible >>>>> for quite a long time, but I wonder why it hasn't been observed = before. >>>>> Probably lltable_free() changes might have triggered that. >>>>>=20 >>>>> I'll take a deeper look on that and reply. >>>>=20 >>=20 >> Observed on an idle box with projects/hps_head too: >>=20 >>> panic: bogus refcnt 0 on lle 0xfffff8016508ca00 >>> cpuid =3D 7 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe03e4e8c7e0 >>> vpanic() at vpanic+0x182/frame 0xfffffe03e4e8c860 >>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe03e4e8c8d0 >>> llentry_free() at llentry_free+0x136/frame 0xfffffe03e4e8c900 >>> arptimer() at arptimer+0x20e/frame 0xfffffe03e4e8c950 >>> softclock_call_cc() at softclock_call_cc+0x170/frame = 0xfffffe03e4e8c9c0 >>> softclock() at softclock+0x47/frame 0xfffffe03e4e8c9e0 >>> intr_event_execute_handlers() at >>> intr_event_execute_handlers+0x96/frame 0xfffffe03e4e8ca20 >>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe03e4e8ca70 >>> fork_exit() at fork_exit+0x84/frame 0xfffffe03e4e8cab0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe03e4e8cab0 >>> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- >>=20 >> Looks like callout_reset() must be examined too, and was missed by: >>=20 >> https://svnweb.freebsd.org/changeset/base/290805 >>=20 >> Can you try the attached patch? >>=20 >> Randall: Can you fix this ASAP? >>=20 >> --HPS >>=20 >=20 > Hi, >=20 > Randall: >=20 > I see for 11-current, callout_reset() doesn't return -1 when the = callout is stopped like with callout_stop(). Is this a bug or a feature? = Why can't the callout_reset() and callout_stop() functions use the same = return values? >=20 > In nd6_llinfo_settimer_locked() the return value of both = callout_reset() and callout_stop() is checked for positive values, but = not in the other places mentioned by my patch. >=20 > --HPS -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-net@freebsd.org Thu Dec 10 15:33:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5D589D7E93; Thu, 10 Dec 2015 15:33:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 8C9541294; Thu, 10 Dec 2015 15:33:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2C6B01FE023; Thu, 10 Dec 2015 16:33:20 +0100 (CET) Subject: Re: panic in arptimer in r289937 To: Randall Stewart References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current From: Hans Petter Selasky Message-ID: <56699BAD.9090208@selasky.org> Date: Thu, 10 Dec 2015 16:35:09 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 15:33:22 -0000 On 12/10/15 16:25, Randall Stewart wrote: > For callout_stop/drain you get > > -1 == Callout as already gone off or is not running (usually the latter) else the caller iks > not using locking properly or did not lock and check the active() value (which would have returned not active so no stop > would have been needed); > 0 == we could not stop the callout, it was in process.. > 1 == it was stopped successfully > > > For callout_reset() you get > > 0 == it was started > 1 == it was restarted. > > There is no -1 since it is either started or restarted never left in a not-running state... > Hi, Correct, though if the return values would be the same, it might simplify the callout API and manual page a bit: /* return values for all callout_xxx() functions */ #define CALLOUT_RET_DRAINING 0 /* callout cannot be stopped, need drain */ #define CALLOUT_RET_CANCELLED 1 /* callout was successfully stopped */ #define CALLOUT_RET_STOPPED -1 /* callout was already stopped */ Then callout_reset() would return -1, if it was started from the stopped state. --HPS From owner-freebsd-net@freebsd.org Thu Dec 10 15:35:47 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD2F29D50A9 for ; Thu, 10 Dec 2015 15:35:47 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D6B91537 for ; Thu, 10 Dec 2015 15:35:47 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pfbg73 with SMTP id g73so50848545pfb.1 for ; Thu, 10 Dec 2015 07:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QpbrlU7/zpaHCEIPG7lrq/sXHtnSjTwnW8qIaM/QsFk=; b=oFxKkkPaI3V8Pc4oq/o07kCCE54osSIeJgrH4+d5JjQMm5Nj+xVMwCc/k81/EiNA9i iPnwanWgTOue4ZRK17qKnCAHZInSlfMXT7RxxYNzFRlU+qA0eQDqS4XErc157e2erP8N JfWzB6AsJ16i8uvksFS/aRaBpNED9aaOJkYEs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=QpbrlU7/zpaHCEIPG7lrq/sXHtnSjTwnW8qIaM/QsFk=; b=bXZA/K463dnlyPDUT2qE8KyOzeOrEYv6qyKh+LRCsQlXvlNkS2xLTxGO6sczBUCTN6 4h05mxtSSNigQeATx0OeuMkHo6VzVRKodAJ6SJgCTJ83uf14lJnrLESIkLPFkXAzJPDY aBt+JEOK/NfRpbKevHrlFj8vAN4aXzAvsDTW9yR/Qy48SFOrgKBt3ujBbRFSMTTICLpb s+4O8lf4CfI4du9KUdQVFaDXfPmYf3IWZrHgHiGjnQZ7MidMewAF0HeBCw10bP/twUnY JEwXIeZJ2djZQwE3WbTHt3aT4Y2YMukUeE51SRoMS454Zo9ah/nEOw5c4YeERpA5gQo/ E6Cg== X-Gm-Message-State: ALoCoQkGuXTlxgg/huVbBX39bkckX+QMXDteirdR2eQEymtecNSgJslsQyvh44OaepLQd9B6mL3f1Nq96OEUYFnWx8JgXAtAig== X-Received: by 10.98.7.129 with SMTP id 1mr7773816pfh.70.1449761747194; Thu, 10 Dec 2015 07:35:47 -0800 (PST) Received: from lgml-rrs-2.corp.netflix.com ([69.53.232.0]) by smtp.gmail.com with ESMTPSA id e14sm17226630pap.24.2015.12.10.07.35.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 07:35:46 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic in arptimer in r289937 From: Randall Stewart In-Reply-To: <56699BAD.9090208@selasky.org> Date: Thu, 10 Dec 2015 07:35:44 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current Message-Id: <0D974796-6166-48DB-BB66-72236E0B50AF@netflix.com> References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> <56699BAD.9090208@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 15:35:47 -0000 If you did that it would change the KPI a bit meaning lots of thrashing in the code. And on top of that you now would no longer return 0.. You would get 1 it was restarted or -1 it was not running but is now = started. Makes no sense to me sorry.. R On Dec 10, 2015, at 7:35 AM, Hans Petter Selasky = wrote: > On 12/10/15 16:25, Randall Stewart wrote: >> For callout_stop/drain you get >>=20 >> -1 =3D=3D Callout as already gone off or is not running (usually the = latter) else the caller iks >> not using locking properly or did not lock and check the = active() value (which would have returned not active so no stop >> would have been needed); >> 0 =3D=3D we could not stop the callout, it was in process.. >> 1 =3D=3D it was stopped successfully >>=20 >>=20 >> For callout_reset() you get >>=20 >> 0 =3D=3D it was started >> 1 =3D=3D it was restarted. >>=20 >> There is no -1 since it is either started or restarted never left in = a not-running state... >>=20 >=20 > Hi, >=20 > Correct, though if the return values would be the same, it might = simplify the callout API and manual page a bit: >=20 > /* return values for all callout_xxx() functions */ > #define CALLOUT_RET_DRAINING 0 /* callout cannot be stopped, need = drain */ > #define CALLOUT_RET_CANCELLED 1 /* callout was successfully stopped = */ > #define CALLOUT_RET_STOPPED -1 /* callout was already stopped */ >=20 > Then callout_reset() would return -1, if it was started from the = stopped state. >=20 > --HPS -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-net@freebsd.org Thu Dec 10 15:40:32 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66C0B9D53E4; Thu, 10 Dec 2015 15:40:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 2E87517A2; Thu, 10 Dec 2015 15:40:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 02B6A1FE023; Thu, 10 Dec 2015 16:40:29 +0100 (CET) Subject: Re: panic in arptimer in r289937 To: Randall Stewart References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> <56699BAD.9090208@selasky.org> <0D974796-6166-48DB-BB66-72236E0B50AF@netflix.com> Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current From: Hans Petter Selasky Message-ID: <56699D5B.8070102@selasky.org> Date: Thu, 10 Dec 2015 16:42:19 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0D974796-6166-48DB-BB66-72236E0B50AF@netflix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 15:40:32 -0000 On 12/10/15 16:35, Randall Stewart wrote: > If you did that it would change the KPI a bit meaning lots > of thrashing in the code. > Hi, There are only 5 consumers of the callout_reset() return code in the FreeBSD 11-current kernel from what I can see: grep -r "= callout_reset" sys/ | wc -l 5 Two of these are already using > 0 checks. --HPS From owner-freebsd-net@freebsd.org Thu Dec 10 15:58:13 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF79D9D6103 for ; Thu, 10 Dec 2015 15:58:13 +0000 (UTC) (envelope-from jmc@cs.rit.edu) Received: from pony-express.cs.rit.edu (pony-express.cs.rit.edu [129.21.30.24]) (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 538CD1135 for ; Thu, 10 Dec 2015 15:58:13 +0000 (UTC) (envelope-from jmc@cs.rit.edu) Received: (qmail 23611 invoked by uid 56003); 10 Dec 2015 15:58:12 -0000 Received: from 129.21.36.151 by pony-express (envelope-from , uid 20003) with qmail-scanner-1.25st (spamassassin: 3.3.2. perlscan: 1.25st. Clear:RC:1(129.21.36.151):SA:0(-1.0/4.5):. Processed in 0.517875 secs); 10 Dec 2015 15:58:12 -0000 X-Spam-Status: No, hits=-1.0 required=4.5 X-Spam-Report: SA TESTS -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Received: from starfury.cs.rit.edu (HELO starfury) (129.21.36.151) by mailhost.cs.rit.edu with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Dec 2015 15:58:11 -0000 Date: Thu, 10 Dec 2015 10:58:11 -0500 (EST) From: James Craig To: freebsd-net@freebsd.org Subject: Netgroups in FreeBSD10 Message-ID: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 15:58:13 -0000 Hey all! I am migrating some of our services to freeBSD, and in the process of this, I have discovered something that seems odd to me; netgroups don't seem to work as expected. I am trying to set up a machine that will eventually be a file server (running 10.2-RELEASE) and getent netgroup doesn't return anything, even if it is a valid name. We have been using openldap, and on the old solaris server, I was able to query netgroups for information, and use netgroups to limit some access to NFS. getent passwd, and other lookups seem to work fine. I had truss running on the ldap server, and when I try to getent netgroup there is no action. So I ran a truss on the getent on the FreeBSD machine, and sifting through the system calls the system will only search the file /etc/netgroup (which is empty), despite that my /etc/nsswitch.conf looks like this: group: files ldap hosts: files dns networks: files ldap netgroup: ldap passwd: files ldap shells: files services: compat services_compat: files protocols: files rpc: files If I put a netgroup into /etc/netgroup, it will find that one group. My only work-arround is to run a cronjob that does an ldapsearch (which works) for my netgroups and compiles it into the netgroup file every hour or so. This seems like something is missing. From what I have been able to read, it might be that netgroups are not really well supported at all. Is that true? Help will be greatly appreciated, as this could impact other ways I have always used netgroups... Thank you! james craig -- James Craig, Department of Computer Science, RIT 102 Lomb Memorial Drive, Rochester, NY 14623 mailto:jmc@cs.rit.edu, voice: (585) 475-5254 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information. From owner-freebsd-net@freebsd.org Thu Dec 10 16:23:38 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75A189D74B2 for ; Thu, 10 Dec 2015 16:23:38 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mx143.netapp.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52EF81282 for ; Thu, 10 Dec 2015 16:23:37 +0000 (UTC) (envelope-from lars@netapp.com) X-IronPort-AV: E=Sophos;i="5.20,408,1444719600"; d="asc'?scan'208";a="84121130" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx143-out.netapp.com with ESMTP; 10 Dec 2015 08:18:31 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 10 Dec 2015 08:18:31 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::942f:e59f:f84a:7191%21]) with mapi id 15.00.1130.005; Thu, 10 Dec 2015 08:18:31 -0800 From: "Eggert, Lars" To: "Pieper, Jeffrey E" CC: Kevin Oberman , Daniel Engberg , "freebsd-net@freebsd.org" Subject: Re: ixl 40G bad performance? Thread-Topic: ixl 40G bad performance? Thread-Index: AQHRDva+ZO+9KY7om02T8EKrgQTcE559lvyAgABhmICAAFavAIAACEoAgAARDQCAABmYAIBGsssA Date: Thu, 10 Dec 2015 16:18:30 +0000 Message-ID: References: <5aae0ee63c44627223d5d179f1901d00@pyret.net> <0E4C2D93-FBAF-48CB-A704-499ABFC892B9@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2A8A@ORSMSX111.amr.corp.intel.com> <99E53825-99F8-4E82-A710-6BC07B123F77@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2D52@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_F348DDF7-77DE-4388-8A43-01DE983F8350"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 16:23:38 -0000 --Apple-Mail=_F348DDF7-77DE-4388-8A43-01DE983F8350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2015-10-26, at 18:40, Eggert, Lars wrote: > On 2015-10-26, at 17:08, Pieper, Jeffrey E = wrote: >> As a caveat, this was using default netperf message sizes. >=20 > I get the same ~3 Gb/s with the default netperf sizes and driver = 1.4.5. Now there is version 1.4.8 on the Intel website, but it doesn't change = things for me. > When you tcpdump during the run, do you see TSO/LRO in effect, i.e., = do you see "segments" > 32K in the trace? I still see no TSO/LRO in effect when tcpdump'ing on the receiver; note = how all the packets are 1448 bytes: tcpdump: verbose output suppressed, use -v or -vv for full protocol = decode listening on ixl0, link-type EN10MB (Ethernet), capture size 262144 = bytes 17:02:42.328782 IP 10.0.4.1.21507 > 10.0.4.2.12865: Flags [S], seq = 15244366, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 478099 = ecr 0], length 0 17:02:42.328808 IP 10.0.4.2.12865 > 10.0.4.1.21507: Flags [S.], seq = 1819579546, ack 15244367, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 3553932482 ecr 478099], length 0 17:02:42.328842 IP 10.0.4.1.21507 > 10.0.4.2.12865: Flags [.], ack 1, = win 1040, options [nop,nop,TS val 478099 ecr 3553932482], length 0 17:02:42.329804 IP 10.0.4.1.21507 > 10.0.4.2.12865: Flags [P.], seq = 1:657, ack 1, win 1040, options [nop,nop,TS val 478100 ecr 3553932482], = length 656 17:02:42.331671 IP 10.0.4.2.12865 > 10.0.4.1.21507: Flags [P.], seq = 1:657, ack 657, win 1040, options [nop,nop,TS val 3553932485 ecr = 478100], length 656 17:02:42.331717 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [S], seq = 1387798477, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 478102 ecr 0], length 0 17:02:42.331729 IP 10.0.4.2.30216 > 10.0.4.1.10449: Flags [S.], seq = 4085135109, ack 1387798478, win 65535, options [mss 1460,nop,wscale = 6,sackOK,TS val 2829000022 ecr 478102], length 0 17:02:42.331781 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], ack 1, = win 1040, options [nop,nop,TS val 478102 ecr 2829000022], length 0 17:02:42.331796 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq = 1:1449, ack 1, win 1040, options [nop,nop,TS val 478102 ecr 2829000022], = length 1448 17:02:42.331800 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq = 1449:2897, ack 1, win 1040, options [nop,nop,TS val 478102 ecr = 2829000022], length 1448 17:02:42.331807 IP 10.0.4.2.30216 > 10.0.4.1.10449: Flags [.], ack 2897, = win 1018, options [nop,nop,TS val 2829000023 ecr 478102], length 0 17:02:42.331809 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq = 2897:4345, ack 1, win 1040, options [nop,nop,TS val 478102 ecr = 2829000022], length 1448 17:02:42.331813 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq = 4345:5793, ack 1, win 1040, options [nop,nop,TS val 478102 ecr = 2829000022], length 1448 17:02:42.331817 IP 10.0.4.2.30216 > 10.0.4.1.10449: Flags [.], ack 5793, = win 1018, options [nop,nop,TS val 2829000023 ecr 478102], length 0 17:02:42.331818 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq = 5793:7241, ack 1, win 1040, options [nop,nop,TS val 478102 ecr = 2829000022], length 1448 17:02:42.331821 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq = 7241:8689, ack 1, win 1040, options [nop,nop,TS val 478102 ecr = 2829000022], length 1448 17:02:42.331825 IP 10.0.4.2.30216 > 10.0.4.1.10449: Flags [.], ack 8689, = win 1018, options [nop,nop,TS val 2829000023 ecr 478102], length 0 17:02:42.331826 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq = 8689:10137, ack 1, win 1040, options [nop,nop,TS val 478102 ecr = 2829000022], length 1448 17:02:42.331829 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq = 10137:11585, ack 1, win 1040, options [nop,nop,TS val 478102 ecr = 2829000022], length 1448 ... Doing the same trace over 10G ix interfaces shows most segments in the = 8-32K range, indicating that TSO/LRO are in use (and results in 9.9G = throughput). Lars --Apple-Mail=_F348DDF7-77DE-4388-8A43-01DE983F8350 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJWaaXVAAoJEFS1wwm/cMFX40sP/jfIYTvgeHj9V3NvdkSE9dC/ dtcjwPMzi6zz9nfcjC2LWmqpeeRu0AbKG/luo3jF0n1lg6j+1G5PxnenvSAfZPsP 8aavCT1xzXf9gevBRD2XKrptbcR4weTmLMuvf/r0GGgeDlYLCpkWXVK1QOrbYl9M OUUsl+Z/2YiRD2+u2NxWk4+YZOqyiLyuCvDSbNtK0U0A4Cm8StAQMI8wbn18N8HD tEzA0wW1GOh8ByRKwCUuzcGkDVJtVAz4lt/0BZhNoWBKXOBQcJNbnCODSn3vjMrh kwe5+87X385jTD1LQsO+7YfUx5RfUW+XOmpVmTGNGRQO6KLH5zPCVU54s6hkGoGs Sz65aPLW5nJY7fP5o22LdxaLz41MrwAbEbQgdBgiQDzCy/M5unsdvDblwRpKo02Y V5NZNSNv6Q8mZnc+iEFT818cDWakQ3TrX8tRtvMYKmnGdgOqf4vrXMLlmBKEJbcO JIeJPFNLPsWL/Ly0ztcjKUPOLFusUsxqhGRclPRUkaYWyTTN1UPvqxmU9Z+l6nYu KfldgW3ZDgAmWQy4XJV3wzN7pQ7hLpyUgA7lnk/AUsZ+dfEKWEmJuJ67T/6GczsZ XwD2PVYxim/V9rkd5t3AHHiCt7JZMMeLGoMytRWKBMR/j7dnxRDXHELKavFnJ4LH vNtS+06NjxyaSrmuO4ue =YDe4 -----END PGP SIGNATURE----- --Apple-Mail=_F348DDF7-77DE-4388-8A43-01DE983F8350-- From owner-freebsd-net@freebsd.org Thu Dec 10 18:29:21 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 043B29D7934 for ; Thu, 10 Dec 2015 18:29:21 +0000 (UTC) (envelope-from dennix.pearson@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C306C17F0 for ; Thu, 10 Dec 2015 18:29:20 +0000 (UTC) (envelope-from dennix.pearson@gmail.com) Received: by iofh3 with SMTP id h3so8917498iof.3 for ; Thu, 10 Dec 2015 10:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Oai9mh2biU3svXg7mRALAx5gxxMN35jv9KEZ+tA7rJs=; b=NkHrtFXJ/yggHrRiUYupI04hvHaXI+tDdG3IxHgiBZ9Opxb1+5ZSBTPbffEL3+Oh7O VNW5a+hYPZ/u2VT2tIGNRrVgANRRtKuuHesB5IP+z/Pyjmaks10qasmM83dGsXecO+os +7pFSZWIRVJSbx7xpYn6NnhVEu5ReVHjjsb9LZh+wvg+tEowZ37b8bWomyI5FDf57pDb lwXqkWYznwrrO8L8xiYwO33ajAwzupzlsQVKnjbuBrwbV7O86ijW6ilQ5eNR7dLVNAQV Swi7T1b7hstIML+S96NhLFjsPwhqxsLKkWF4YtYy42hOzZ/QA6+lqR9E/hjhNnT5tfiT HHeg== MIME-Version: 1.0 X-Received: by 10.107.135.94 with SMTP id j91mr12924026iod.54.1449772160256; Thu, 10 Dec 2015 10:29:20 -0800 (PST) Received: by 10.79.27.149 with HTTP; Thu, 10 Dec 2015 10:29:20 -0800 (PST) In-Reply-To: References: <5aae0ee63c44627223d5d179f1901d00@pyret.net> <0E4C2D93-FBAF-48CB-A704-499ABFC892B9@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2A8A@ORSMSX111.amr.corp.intel.com> <99E53825-99F8-4E82-A710-6BC07B123F77@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2D52@ORSMSX111.amr.corp.intel.com> Date: Thu, 10 Dec 2015 16:29:20 -0200 Message-ID: Subject: Re: ixl 40G bad performance? From: Denis Pearson To: "Eggert, Lars" Cc: "Pieper, Jeffrey E" , Kevin Oberman , Daniel Engberg , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 18:29:21 -0000 On Thu, Dec 10, 2015 at 2:18 PM, Eggert, Lars wrote: > On 2015-10-26, at 18:40, Eggert, Lars wrote: > > On 2015-10-26, at 17:08, Pieper, Jeffrey E > wrote: > >> As a caveat, this was using default netperf message sizes. > > > > I get the same ~3 Gb/s with the default netperf sizes and driver 1.4.5. > > Now there is version 1.4.8 on the Intel website, but it doesn't change > things for me. > I had the opportunity to see similar numbers and behavior while using XL710 1.4.3 as of FreeBSD r291085 while in DPDK poll mode, but driver 1.2.8 as of r292035 was providing expected numbers. While removing rxcsum/txcsum did not provide differences, fully removing RSS + disabling rx/cxsum support provided better numbers. However now with driver 1.4.8 and the same set of hardware setup, except for a different transceiver, I can get 36Gbps/24Mpps with no further tweaks, so if you can replace your transceiver, shall be a different test as a starting point. > > > When you tcpdump during the run, do you see TSO/LRO in effect, i.e., do > you see "segments" > 32K in the trace? > > I still see no TSO/LRO in effect when tcpdump'ing on the receiver; note > how all the packets are 1448 bytes: > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ixl0, link-type EN10MB (Ethernet), capture size 262144 bytes > 17:02:42.328782 IP 10.0.4.1.21507 > 10.0.4.2.12865: Flags [S], seq > 15244366, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 478099 > ecr 0], length 0 > 17:02:42.328808 IP 10.0.4.2.12865 > 10.0.4.1.21507: Flags [S.], seq > 1819579546, ack 15244367, win 65535, options [mss 1460,nop,wscale > 6,sackOK,TS val 3553932482 ecr 478099], length 0 > 17:02:42.328842 IP 10.0.4.1.21507 > 10.0.4.2.12865: Flags [.], ack 1, win > 1040, options [nop,nop,TS val 478099 ecr 3553932482], length 0 > 17:02:42.329804 IP 10.0.4.1.21507 > 10.0.4.2.12865: Flags [P.], seq 1:657, > ack 1, win 1040, options [nop,nop,TS val 478100 ecr 3553932482], length 656 > 17:02:42.331671 IP 10.0.4.2.12865 > 10.0.4.1.21507: Flags [P.], seq 1:657, > ack 657, win 1040, options [nop,nop,TS val 3553932485 ecr 478100], length > 656 > 17:02:42.331717 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [S], seq > 1387798477, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 478102 > ecr 0], length 0 > 17:02:42.331729 IP 10.0.4.2.30216 > 10.0.4.1.10449: Flags [S.], seq > 4085135109, ack 1387798478, win 65535, options [mss 1460,nop,wscale > 6,sackOK,TS val 2829000022 ecr 478102], length 0 > 17:02:42.331781 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], ack 1, win > 1040, options [nop,nop,TS val 478102 ecr 2829000022], length 0 > 17:02:42.331796 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq 1:1449, > ack 1, win 1040, options [nop,nop,TS val 478102 ecr 2829000022], length 1448 > 17:02:42.331800 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq > 1449:2897, ack 1, win 1040, options [nop,nop,TS val 478102 ecr 2829000022], > length 1448 > 17:02:42.331807 IP 10.0.4.2.30216 > 10.0.4.1.10449: Flags [.], ack 2897, > win 1018, options [nop,nop,TS val 2829000023 ecr 478102], length 0 > 17:02:42.331809 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq > 2897:4345, ack 1, win 1040, options [nop,nop,TS val 478102 ecr 2829000022], > length 1448 > 17:02:42.331813 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq > 4345:5793, ack 1, win 1040, options [nop,nop,TS val 478102 ecr 2829000022], > length 1448 > 17:02:42.331817 IP 10.0.4.2.30216 > 10.0.4.1.10449: Flags [.], ack 5793, > win 1018, options [nop,nop,TS val 2829000023 ecr 478102], length 0 > 17:02:42.331818 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq > 5793:7241, ack 1, win 1040, options [nop,nop,TS val 478102 ecr 2829000022], > length 1448 > 17:02:42.331821 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq > 7241:8689, ack 1, win 1040, options [nop,nop,TS val 478102 ecr 2829000022], > length 1448 > 17:02:42.331825 IP 10.0.4.2.30216 > 10.0.4.1.10449: Flags [.], ack 8689, > win 1018, options [nop,nop,TS val 2829000023 ecr 478102], length 0 > 17:02:42.331826 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq > 8689:10137, ack 1, win 1040, options [nop,nop,TS val 478102 ecr > 2829000022], length 1448 > 17:02:42.331829 IP 10.0.4.1.10449 > 10.0.4.2.30216: Flags [.], seq > 10137:11585, ack 1, win 1040, options [nop,nop,TS val 478102 ecr > 2829000022], length 1448 > ... > > Doing the same trace over 10G ix interfaces shows most segments in the > 8-32K range, indicating that TSO/LRO are in use (and results in 9.9G > throughput). > > Lars > From owner-freebsd-net@freebsd.org Thu Dec 10 18:33:59 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0463D9D7DDE for ; Thu, 10 Dec 2015 18:33:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6F011DAE for ; Thu, 10 Dec 2015 18:33:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBAIXwCq014680 for ; Thu, 10 Dec 2015 18:33:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205165] [ip6] [panic] Multiple race conditions in the V6 list manipulation Date: Thu, 10 Dec 2015 18:33:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: sbruno@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 18:33:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205165 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |sbruno@FreeBSD.org --- Comment #2 from Sean Bruno --- I'm keeping an eye on this for work, so I'll be the assignee. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 10 18:40:03 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 979539D63C4 for ; Thu, 10 Dec 2015 18:40:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63A911242 for ; Thu, 10 Dec 2015 18:40:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofh3 with SMTP id h3so102244588iof.3 for ; Thu, 10 Dec 2015 10:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8STRfGfC47mO1xoUZTji8u0F7Ou0suCTPrQYtkR76RY=; b=zpFk2iTgf4Q05vWs/hXCKrgD8OicgBgjsQo3nKkOdTi1jnRXxHoXOIf8CSD3+K9fAm MaZrTpbyLXDkIjiFGMfLrTh8THrUkgHUl0rUGkHXsErshaWQ70N1TcYYicx8hczlBHlv wGMJw5H8MQg8CQ1h1FYGsq16FLzj2Hq+5Oc6m8JfJ2u6EgQ9Ruf6ezFL+9+yYod1ovFu n8WtTMHeVm9664Gs/vI4uixOQMI/UVI8+mMKL6Cpr82yKo+WU52f8MgdJA+C3u0DtwHf 92sTo8vbHK3oTIgGHE49mDfJgBc+CIQDiaaW1BrxRJeqHYsAzzrItSwu1nGdwMOME9/d LRQA== MIME-Version: 1.0 X-Received: by 10.107.11.147 with SMTP id 19mr12394735iol.165.1449772802868; Thu, 10 Dec 2015 10:40:02 -0800 (PST) Received: by 10.36.121.202 with HTTP; Thu, 10 Dec 2015 10:40:02 -0800 (PST) In-Reply-To: References: <5aae0ee63c44627223d5d179f1901d00@pyret.net> <0E4C2D93-FBAF-48CB-A704-499ABFC892B9@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2A8A@ORSMSX111.amr.corp.intel.com> <99E53825-99F8-4E82-A710-6BC07B123F77@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2D52@ORSMSX111.amr.corp.intel.com> Date: Thu, 10 Dec 2015 10:40:02 -0800 Message-ID: Subject: Re: ixl 40G bad performance? From: Adrian Chadd To: Denis Pearson Cc: "Eggert, Lars" , "Pieper, Jeffrey E" , Kevin Oberman , Daniel Engberg , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 18:40:03 -0000 On 10 December 2015 at 10:29, Denis Pearson wrote: > On Thu, Dec 10, 2015 at 2:18 PM, Eggert, Lars wrote: > >> On 2015-10-26, at 18:40, Eggert, Lars wrote: >> > On 2015-10-26, at 17:08, Pieper, Jeffrey E >> wrote: >> >> As a caveat, this was using default netperf message sizes. >> > >> > I get the same ~3 Gb/s with the default netperf sizes and driver 1.4.5. >> >> Now there is version 1.4.8 on the Intel website, but it doesn't change >> things for me. >> > > I had the opportunity to see similar numbers and behavior while using XL710 > 1.4.3 as of FreeBSD r291085 while in DPDK poll mode, but driver 1.2.8 as of > r292035 was providing expected numbers. While removing rxcsum/txcsum did > not provide differences, fully removing RSS + disabling rx/cxsum support > provided better numbers. Can someone debug this a bit more? (My kit with ixl NICs in it is still not up and available. :( ) Device RSS, even without kernel RSS enabled, shouldn't cause a massive performance drop. If it is then something else odd is going on. Do you have a diff where you removed things? -adrian > However now with driver 1.4.8 and the same set of hardware setup, except > for a different transceiver, I can get 36Gbps/24Mpps with no further > tweaks, so if you can replace your transceiver, shall be a different test > as a starting point. From owner-freebsd-net@freebsd.org Thu Dec 10 18:48:28 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 701DF9D6B6F for ; Thu, 10 Dec 2015 18:48:28 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB9FB1B06 for ; Thu, 10 Dec 2015 18:48:27 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by lffu14 with SMTP id u14so63355995lff.1 for ; Thu, 10 Dec 2015 10:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FvEMUncJsyyPzzZPg4apo6aH3DV69Hdf3yHPidDXZV0=; b=B8zD9dquaA0PI49eGtoJSxTlu5agohLTLf3XavHsMxG9pknLShtLYqfGIlohfOhns2 IZafpCFpZkqqND/4BLWOmNlq0gbQCAddMSSewiJy+eYbNjQwoEGNFHKBJZXHLAbgiPr1 K0CWeqCwcnbvDR67y/9SHvMHNutES8lpAZ33LX5RN2zPATXyf8eLene4Yda8VBTYc5TC rPb90jQxS+hlx/3UKBmBfpO9bS2Dy+bZeLYd8UGE/XMSYY6M63vaenhfZNgPyt5lnP2K Rxc/6fnZcEqJuOKv8QwkIixKTYUMNpJKfIrbaMmzGuWnESfCUr6mSlSshQ56TAOUsX5T yQCg== MIME-Version: 1.0 X-Received: by 10.25.4.208 with SMTP id 199mr5903702lfe.96.1449773306075; Thu, 10 Dec 2015 10:48:26 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.97.100 with HTTP; Thu, 10 Dec 2015 10:48:26 -0800 (PST) In-Reply-To: References: <5aae0ee63c44627223d5d179f1901d00@pyret.net> <0E4C2D93-FBAF-48CB-A704-499ABFC892B9@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2A8A@ORSMSX111.amr.corp.intel.com> <99E53825-99F8-4E82-A710-6BC07B123F77@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2D52@ORSMSX111.amr.corp.intel.com> Date: Thu, 10 Dec 2015 10:48:26 -0800 X-Google-Sender-Auth: QH2RcnCI9LcjPgoFF9zKh1cFKQs Message-ID: Subject: Re: ixl 40G bad performance? From: Luigi Rizzo To: Adrian Chadd Cc: Denis Pearson , "Pieper, Jeffrey E" , Kevin Oberman , Daniel Engberg , "Eggert, Lars" , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 18:48:28 -0000 On Thu, Dec 10, 2015 at 10:40 AM, Adrian Chadd wrote: > On 10 December 2015 at 10:29, Denis Pearson wrote: >> On Thu, Dec 10, 2015 at 2:18 PM, Eggert, Lars wrote: >> >>> On 2015-10-26, at 18:40, Eggert, Lars wrote: >>> > On 2015-10-26, at 17:08, Pieper, Jeffrey E >>> wrote: >>> >> As a caveat, this was using default netperf message sizes. >>> > >>> > I get the same ~3 Gb/s with the default netperf sizes and driver 1.4.5. >>> >>> Now there is version 1.4.8 on the Intel website, but it doesn't change >>> things for me. >>> >> >> I had the opportunity to see similar numbers and behavior while using XL710 >> 1.4.3 as of FreeBSD r291085 while in DPDK poll mode, but driver 1.2.8 as of >> r292035 was providing expected numbers. While removing rxcsum/txcsum did >> not provide differences, fully removing RSS + disabling rx/cxsum support >> provided better numbers. > > Can someone debug this a bit more? (My kit with ixl NICs in it is > still not up and available. :( ) > > Device RSS, even without kernel RSS enabled, shouldn't cause a massive > performance drop. If it is then something else odd is going on. I am not sure whether we are digressing (Lars' complaint was about poor bulk throughput, now i see DPDK and high packet rates mentioned so i feel obliged to pitch in!) but a related piece of info: last spring, with netmap and i40e on linux (don't remember which driver/firmware), we saw that enabling FlowDirector killed the pps throughput (from 32 down to 18 Mpps). FlowDirector is a device feature which was probably affecting ordinary processing on the NIC, either because of bugs or because of consuming controller resources. The same may be possibly happening with other device features. cheers luigi > > Do you have a diff where you removed things? > > > -adrian > >> However now with driver 1.4.8 and the same set of hardware setup, except >> for a different transceiver, I can get 36Gbps/24Mpps with no further >> tweaks, so if you can replace your transceiver, shall be a different test >> as a starting point. > _______________________________________________ > 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" -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Thu Dec 10 19:04:50 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 694D19D5A60 for ; Thu, 10 Dec 2015 19:04:50 +0000 (UTC) (envelope-from h.rezaee@ideatech.io) Received: from mail.ideatech.io (mail.ideatech.io [104.131.120.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB52126D for ; Thu, 10 Dec 2015 19:04:49 +0000 (UTC) (envelope-from h.rezaee@ideatech.io) Received: from hadi-pc.my.domain (unknown [5.106.69.153]) by mail.ideatech.io (Postfix) with ESMTPSA id 202F71125B2 for ; Thu, 10 Dec 2015 13:55:27 -0500 (EST) To: freebsd-net@freebsd.org From: Hadi Rezaee Subject: problem with tcpdump/netmap X-Enigmail-Draft-Status: N1110 Message-ID: <5669D94A.6010505@ideatech.io> Date: Thu, 10 Dec 2015 23:28:02 +0330 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 19:04:50 -0000 Hey there, I rebuild my box (FreeBSD 10.2R amd64) with netmap support. Just to check if everything going well, I connected my laptop to another machine in same ip range. The problem is when I issue "tcpdump -i netmap:re0" command to capture packets, I see different results but all of them will fail eventually .. for example: 1) the capturing will start successfully , I'll see some output on screen and after seconds capturing will stop and the interface will lose the IP address! 2) the capturing will start successfully , nothing will printed on screen ... but the interface keep the IP address along with NETMAP flag and at the end the stat will be: 0 packets captured 1904 packets received by filter 0 packets dropped by kernel please note than when i use tcpdump normally (without netmap), the capturing process just run successfully ... Thanks, Hadi From owner-freebsd-net@freebsd.org Thu Dec 10 19:42:35 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EC729D7889 for ; Thu, 10 Dec 2015 19:42:35 +0000 (UTC) (envelope-from dennix.pearson@gmail.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 185CF17A0 for ; Thu, 10 Dec 2015 19:42:35 +0000 (UTC) (envelope-from dennix.pearson@gmail.com) Received: by ioo197 with SMTP id 197so9097718ioo.1 for ; Thu, 10 Dec 2015 11:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=02aY70kvHI8MFAhyPSy/oWseFFaqcnoxc+NNTtzTD6E=; b=N4HvCIF6IoCsTCY5renxSYF6oE+zUP2Z0nSPVrzGw00ReM1nBMcbowTMN+F78lUcEb Nc3MN5nELtZ+GaYATBs83YGBrWc3NdV5KS4JaK/h3NNf/rD9nhE+2SNJjxx1Uuyb443r vkHXr3Yw3kPDedXweo9DI52SjtyoCfjKF9iiakCrz/BOhGkciPqXFLmGE1caU1iPkoro kHAyhvvz+HhtI0nskeLQEUZMKrNd6M8wcqTbcHrT4iGdFI+WiUMaW9oZoGabTpBt01I2 A8x+9reTMzo6FQexhxj8X1kdF4bmMtp0Lefr7aQdgLOufF09Gf4VsftUDnlnnV4JGhOA bE/Q== MIME-Version: 1.0 X-Received: by 10.107.156.195 with SMTP id f186mr24188ioe.54.1449776554354; Thu, 10 Dec 2015 11:42:34 -0800 (PST) Received: by 10.79.27.149 with HTTP; Thu, 10 Dec 2015 11:42:34 -0800 (PST) In-Reply-To: References: <5aae0ee63c44627223d5d179f1901d00@pyret.net> <0E4C2D93-FBAF-48CB-A704-499ABFC892B9@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2A8A@ORSMSX111.amr.corp.intel.com> <99E53825-99F8-4E82-A710-6BC07B123F77@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2D52@ORSMSX111.amr.corp.intel.com> Date: Thu, 10 Dec 2015 17:42:34 -0200 Message-ID: Subject: Re: ixl 40G bad performance? From: Denis Pearson To: Adrian Chadd Cc: "Eggert, Lars" , "Pieper, Jeffrey E" , Kevin Oberman , Daniel Engberg , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 19:42:35 -0000 On Thu, Dec 10, 2015 at 4:40 PM, Adrian Chadd wrote: > On 10 December 2015 at 10:29, Denis Pearson > wrote: > > On Thu, Dec 10, 2015 at 2:18 PM, Eggert, Lars wrote: > > > >> On 2015-10-26, at 18:40, Eggert, Lars wrote: > >> > On 2015-10-26, at 17:08, Pieper, Jeffrey E < > jeffrey.e.pieper@intel.com> > >> wrote: > >> >> As a caveat, this was using default netperf message sizes. > >> > > >> > I get the same ~3 Gb/s with the default netperf sizes and driver > 1.4.5. > >> > >> Now there is version 1.4.8 on the Intel website, but it doesn't change > >> things for me. > >> > > > > I had the opportunity to see similar numbers and behavior while using > XL710 > > 1.4.3 as of FreeBSD r291085 while in DPDK poll mode, but driver 1.2.8 as > of > > r292035 was providing expected numbers. While removing rxcsum/txcsum did > > not provide differences, fully removing RSS + disabling rx/cxsum support > > provided better numbers. > > Can someone debug this a bit more? (My kit with ixl NICs in it is > still not up and available. :( ) > > Device RSS, even without kernel RSS enabled, shouldn't cause a massive > performance drop. If it is then something else odd is going on. > Do you have a diff where you removed things? > I can probably find out a snapshot with the code at the time and extract a diff, yes. I just don't know how it worths wasting the time when the problem is not reproducible on the current 1.4.8 driver which will hopefully get into -CURRENT (if it's not already there?). And it's much more specific, the performance drop happened on dpdk poll mode, not the usual kernel operation so a simple diff only pointing out the changes for the driver to actually build and run without rss will still require a testlab and different ways to generate traffic. This is why I suggested a transceiver change or replug first. Anyway RSS performance dropping problem is far from a FreeBSD specific problem, while researching I could find the exact same complaints on Windows users starting from windows 8 while having RSS@4 or RSS@16 or RSS completely disabled, some times with acceptable results only when it was disabled (despiste the fact that MiniportInterruptDPC was using a whole CPU when RSS was off results were still better). So I guess this is just a side effect of when it's just good to have NIC features turned off. The reason, I'm not an engineer to answer, but I would guess it's related to other NIC features also doing something with the packet or any sort of errors netstat or driver status may not tell. I was able to see the problem even with low pps rates and big packet sizes, as well as avg pkt size of 768bytes so I don't think it's any sort of card resource starvation. I can manage to have the whole lab up and running by the weekend if you want to investigate and compare, just ping me off list. > > -adrian > > > However now with driver 1.4.8 and the same set of hardware setup, except > > for a different transceiver, I can get 36Gbps/24Mpps with no further > > tweaks, so if you can replace your transceiver, shall be a different test > > as a starting point. > From owner-freebsd-net@freebsd.org Thu Dec 10 20:00:31 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C7DC9D67E7 for ; Thu, 10 Dec 2015 20:00:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F05BD10A1; Thu, 10 Dec 2015 20:00:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by qgec40 with SMTP id c40so159210862qge.2; Thu, 10 Dec 2015 12:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=1hb2JLIk9vV9dROoDNElctLks8yjauiCv945aU0RUpE=; b=rxtsklU7BDmH4Zv/UmQTR6n5zYlv9HGBa6dNm+Y7/WmRR22MbriEtLcv9iDSQsS/QU oEoLBUbYTUYL+oNj6IybgrsZVc8HmZnSv/uS1EJd3Qq13YuVMLROZ2o+d1HHIu0EJbSE 3NJC/5YSG7sbN7PEmZGITBRWVoDDxuJ4TaSu4BTsmdREY5++D1KdMKY2d8imCO6nfQ/7 fIjQmnboTj3pDUysgbVc30hgnevQelEotRATIAdSkgIy4jGjioj/551s3QKN0ygEmFwH 5FldjmpHUYF44iFPCdCPJHMjvW0G4jHoN97xPq8Wl76ZvJMxK667fcggNFmUG+G5qG78 bKcw== X-Received: by 10.55.76.16 with SMTP id z16mr17726196qka.83.1449777626019; Thu, 10 Dec 2015 12:00:26 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by smtp.gmail.com with ESMTPSA id e134sm6653616qhc.49.2015.12.10.12.00.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Dec 2015 12:00:25 -0800 (PST) Sender: Mark Johnston Date: Thu, 10 Dec 2015 12:02:15 -0800 From: Mark Johnston To: "Andrey V. Elsukov" Cc: Jason , freebsd-net@freebsd.org, kevin.bowling@kev009.com, hiren@strugglingcoder.info Subject: Re: Multiple cores/race conditions in IPv6 RA Message-ID: <20151210200215.GB34692@wkstn-mjohnston.west.isilon.com> References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> <5667EA3A.8050200@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5667EA3A.8050200@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 20:00:31 -0000 On Wed, Dec 09, 2015 at 11:45:46AM +0300, Andrey V. Elsukov wrote: > On 08.12.15 08:32, Jason wrote: > > Hi, > > > > It appears the IPv6 router advertisement code paths were written fairly > > lockless, assuming you would never process multiples concurrently. We > > are seeing multiple page faults in various places processing the > > messages and modifying the routing table. We have multiple L3 devices > > and multiple v6 blocks broadcasting these messages to hardware with dual > > uplinks in the same VLAN, which I believe is making us susceptible to > > this. Though I believe the dual uplink is all that's required for this, > > as it can be seen in configurations with a single v6 block. > > > > We are running stable/10 @ r285800, and it doesn't appear anything > > relevant has changed since then. Our other widely deployed version is > > 8.3-RELEASE, which does not see this issue. Upon bumping a machine from > > 8.3 -> 10 we can see it start to exhibit this behavior. The only change > > I see that might be relevant is r243148, but these cores are relatively > > rare, so testing is tough without a considerable deployment. So > > basically I'm hoping someone with a trained eye can send us in the right > > direction before we go down that road. > > Hi, > > some time ago Mark Johnston has published there the patch related to > this problem: > https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html > > Maybe Mark has something to say about it. I started trying to push this work in with D2254, which fixes some of the global IPv6 addr list locking. It turns out to be pretty tricky to lock both NDP and the global address list properly; the patch in my public directory fixes only some of the issues with NDP and is thus incomplete, which is why I'd been reluctant to push it in. I'll return to D2254 and try and make some further progress on this. From owner-freebsd-net@freebsd.org Thu Dec 10 20:14:32 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0618A9D7351 for ; Thu, 10 Dec 2015 20:14:32 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B955A18DE for ; Thu, 10 Dec 2015 20:14:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by qgea14 with SMTP id a14so161746919qge.0 for ; Thu, 10 Dec 2015 12:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=cRNAVUcirrE66ZNpaAOLsc+6AeAOdWd2lZGE3kNiZss=; b=YFoNrxEMuICPjxoVSURm22bI+N7idKGByEQ2OybgZmGKBH1Z/JYHVoCvUDtH1hUJa9 A2hdSlsKYV0MdUc1bLZQaFSo3RjAEoF5q9C2hWa7Kwp2/zrQJj4zz/od81Isloh1E+ey FhpCqMEjZ8Xa6thmG6uh9sbs+IY8SGD+qqy0TLTOVrvxf6FEkVsVp3XVhjKVaOBLoV4R MGY4Q/MQ81JV6xhIycv1NsyPTLWWGdJJ31zDbelWxeCApzR54UkwfjwUBf+ZGhHDkgac 3dcOCrWBu7WmoWmu/XZV3JBxbgKbMRwhD5vmb9DFFOM+qSu4Y0ku8JGHMHuCxvDG9RIF W0hw== X-Received: by 10.140.194.136 with SMTP id p130mr9525511qha.76.1449778468772; Thu, 10 Dec 2015 12:14:28 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by smtp.gmail.com with ESMTPSA id d69sm6706205qkb.45.2015.12.10.12.14.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Dec 2015 12:14:28 -0800 (PST) Sender: Mark Johnston Date: Thu, 10 Dec 2015 12:16:21 -0800 From: Mark Johnston To: James Craig Cc: freebsd-net@freebsd.org Subject: Re: Netgroups in FreeBSD10 Message-ID: <20151210201621.GC34692@wkstn-mjohnston.west.isilon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 20:14:32 -0000 On Thu, Dec 10, 2015 at 10:58:11AM -0500, James Craig wrote: > > > Hey all! > > I am migrating some of our services to freeBSD, and in the process of this, > I have discovered something that seems odd to me; netgroups don't seem to work > as expected. > > I am trying to set up a machine that will eventually be a file server > (running 10.2-RELEASE) and getent netgroup doesn't return anything, > even if it is a valid name. > > We have been using openldap, and on the old solaris server, I was able to > query netgroups for information, and use netgroups to limit some access to NFS. > > getent passwd, and other lookups seem to work fine. > > > I had truss running on the ldap server, and when I try to > getent netgroup there is no action. So I ran a truss on the getent on > the FreeBSD machine, and sifting through the system calls the system will only > search the file /etc/netgroup (which is empty), despite that > my /etc/nsswitch.conf looks like this: Unfortunately, the NSS documentation is wrong: the netgroup database isn't implemented. The netgroup NSS methods always read /etc/netgroup and ignore the sources configured in /etc/nsswitch.conf. I have a libc patch (missing man page updates) that fixes this: https://people.freebsd.org/~markj/patches/netgroup_nss.diff It also adds a getnetgrent_r() implementation. If you're able to rebuild libc in your environment, this patch should fix the problem you're encountering - please let me know if it doesn't! From owner-freebsd-net@freebsd.org Thu Dec 10 20:26:48 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29E6E9D7BE9 for ; Thu, 10 Dec 2015 20:26:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E97D61F05 for ; Thu, 10 Dec 2015 20:26:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22f.google.com with SMTP id su19so24385379igc.0 for ; Thu, 10 Dec 2015 12:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gysf+ERZa+/Qak3rnmaOGkrf9nycJAxYGVeHD397cUc=; b=siwUyg7GeFeK8TfubJic/wnkNxI0HjRvijgBq7CHz9ApkO9S+5gPFcBp/GaddkPjw9 IMrBkuaSyVigJSFlj5TZGuvAJRo0xuFjOSnCjScCqAO64BF+G+S5c/EYFG3YARZB23G3 mHbUcbVxijHPhQFKzd9R4CKb4tch7AINhplZTJSMQ7eM/ZvByGX1ctOFu4TT2UFqbmba 3RA9/TbOiO2us0gy2x1SjrnK/jXSq7dCXakAsoLFqguLBrBp/Eugx+2+hpLwK8ZsCP7e WKU2P2EtDHohPZWkFiY5Md5e1n6zarLDUbDo2LCrd2kYy1yDGGRQatlCJMtMcz5C2a/T aBFQ== MIME-Version: 1.0 X-Received: by 10.50.136.226 with SMTP id qd2mr1073214igb.37.1449779207387; Thu, 10 Dec 2015 12:26:47 -0800 (PST) Received: by 10.36.121.202 with HTTP; Thu, 10 Dec 2015 12:26:47 -0800 (PST) In-Reply-To: References: <5aae0ee63c44627223d5d179f1901d00@pyret.net> <0E4C2D93-FBAF-48CB-A704-499ABFC892B9@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2A8A@ORSMSX111.amr.corp.intel.com> <99E53825-99F8-4E82-A710-6BC07B123F77@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2D52@ORSMSX111.amr.corp.intel.com> Date: Thu, 10 Dec 2015 12:26:47 -0800 Message-ID: Subject: Re: ixl 40G bad performance? From: Adrian Chadd To: Denis Pearson Cc: "Eggert, Lars" , "Pieper, Jeffrey E" , Kevin Oberman , Daniel Engberg , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 20:26:48 -0000 [snip] If RSS works fine on the latest driver then great. This was with single queue netperf, right? -a From owner-freebsd-net@freebsd.org Thu Dec 10 22:02:17 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5DF99D6C7B for ; Thu, 10 Dec 2015 22:02:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96D171E17 for ; Thu, 10 Dec 2015 22:02:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBAM2HjE026639 for ; Thu, 10 Dec 2015 22:02:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202484] vtnet drivers didn't support being use for multicast routing (MRT_ADD_VIF) Date: Thu, 10 Dec 2015 22:02:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: olivier@cochard.me X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Dec 2015 22:02:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202484 --- Comment #1 from olivier@cochard.me --- errno(2) translate error number 45 by a EOPNOTSUPP. And code in netinet/ip_mroute.c can return EOPNOTSUPP in 2 cases: if ((vifcp->vifc_flags & VIFF_TUNNEL) != 0) { CTR1(KTR_IPMF, "%s: tunnels are no longer supported", __func__); VIF_UNLOCK(); return EOPNOTSUPP; or } else { /* Make sure the interface supports multicast */ if ((ifp->if_flags & IFF_MULTICAST) == 0) { VIF_UNLOCK(); return EOPNOTSUPP; But a vtnet interface seems to correctly set IFF_MULTICAST because dev/virtio/network/if_vtnet.c includes: vtnet_setup_interface(struct vtnet_softc *sc) { ... ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ... } Then how to troubleshoot deeper this problem ? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Dec 11 02:13:53 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 236C79D7514 for ; Fri, 11 Dec 2015 02:13:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13D3A1504 for ; Fri, 11 Dec 2015 02:13:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBB2DqXS044032 for ; Fri, 11 Dec 2015 02:13:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205194] Changing MTU higher than 1500 on the interface pfsync0 causes panic Date: Fri, 11 Dec 2015 02:13:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 02:13:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205194 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Dec 11 07:25:57 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EBF49D6A1E for ; Fri, 11 Dec 2015 07:25:57 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mx141.netapp.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B00118B8 for ; Fri, 11 Dec 2015 07:25:56 +0000 (UTC) (envelope-from lars@netapp.com) X-IronPort-AV: E=Sophos;i="5.20,412,1444719600"; d="asc'?scan'208,217";a="87356335" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 10 Dec 2015 23:20:47 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 10 Dec 2015 23:20:47 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::942f:e59f:f84a:7191%21]) with mapi id 15.00.1130.005; Thu, 10 Dec 2015 23:20:47 -0800 From: "Eggert, Lars" To: Denis Pearson CC: Adrian Chadd , "Pieper, Jeffrey E" , Kevin Oberman , "Daniel Engberg" , "freebsd-net@freebsd.org" Subject: Re: ixl 40G bad performance? Thread-Topic: ixl 40G bad performance? Thread-Index: AQHRDva+ZO+9KY7om02T8EKrgQTcE559lvyAgABhmICAAFavAIAACEoAgAARDQCAABmYAIBGsssAgAAkkACAAAL9AIAAEXkAgADDEQA= Date: Fri, 11 Dec 2015 07:20:47 +0000 Message-ID: <72184809-0507-4927-BCA3-22ACC126FA50@netapp.com> References: <5aae0ee63c44627223d5d179f1901d00@pyret.net> <0E4C2D93-FBAF-48CB-A704-499ABFC892B9@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2A8A@ORSMSX111.amr.corp.intel.com> <99E53825-99F8-4E82-A710-6BC07B123F77@netapp.com> <2A35EA60C3C77D438915767F458D6568807F2D52@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_FAB4E4D4-EEAE-4D68-83E1-37F9E972C1BD"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 07:25:57 -0000 --Apple-Mail=_FAB4E4D4-EEAE-4D68-83E1-37F9E972C1BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2015-12-10, at 20:42, Denis Pearson wrote: > I can probably find out a snapshot with the code at the time and = extract a diff, yes. I just don't know how it worths wasting the time = when the problem is not reproducible on the current 1.4.8 driver which = will hopefully get into -CURRENT (if it's not already there?). per my last email, I do see the same issues with 1.4.8. This is with a single netperf TCP flow, no NIC parameter tuning and no = RSS or PCBGROUP in the kernel. > This is why I suggested a transceiver change or replug first. I will test this next week. (However, the same testbed booted into Linux = doesn't see these low netperf numbers.) It really smells like a TSO/LRO (=3D packet rate) issue. If I configure = jumbograms, performance jumps up as expected. Lars --Apple-Mail=_FAB4E4D4-EEAE-4D68-83E1-37F9E972C1BD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJWanlNAAoJEFS1wwm/cMFXkQoP/19pmIvjixR89hhSoirGzA2P 7/KsOmPqMlKuuohy0y4pGL6VgBfl1y0E2zsngfE0lkbFfcCUUgegq5p553hO1+vH adQF3UdOTm5fo1X6NOAWhkToIJf1T3X9N8KUhhZ3gy+eUV9nt1nCzA0E3kLdI68T 8eQCS/N1c13HEl1NCMi0Hri6yQJaAqmQHjp/vfMKaNtNYkn1cVlxealfqqSoVPY4 BgKBrTSAspETOKsd0SEZXubd43Apbg5av9V/BGuKF4gpO9EYVSemZFmBgXtGVEbs s+oyR1ROhWrOz2r4IG4uxQodI3WHhgSXc5GV0L+fSXxmM9iqchT8jAnvfXV3iDkQ I38zC3csNtuaMNVy99AjoWd2O1jDnBJQT7KMdZeufxjJqEGVgU49lsA3TEdh/6uL tC/xwNlaaxBo99ClBnXLOLrVAsmsLvTRzNx7QjjSMruUOFtxfbOhBvyfcVLcFeTv XoBcv6HTREd3HKrGgBr/xBJgc7qvZlAIedx9YFhtJ3yoaraWIYyBMexSLgiClABn tE7+sdgfa1VaIdfJGrVkt1GrUlOA78z/iOxvdi1JYD6H18ux4msY8CH54ATcViZd ZUTjj0j+/u8GdtS9+gWlL+o3EMbbiSFTbkignC02Ngn51Kb7R69/iOf4x/c4csSx e0AYBhcRjx9XAtzcjzpq =nCz1 -----END PGP SIGNATURE----- --Apple-Mail=_FAB4E4D4-EEAE-4D68-83E1-37F9E972C1BD-- From owner-freebsd-net@freebsd.org Fri Dec 11 08:18:55 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 906059D592C for ; Fri, 11 Dec 2015 08:18:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82E97157A for ; Fri, 11 Dec 2015 08:18:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBB8ItpL025678 for ; Fri, 11 Dec 2015 08:18:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202484] vtnet drivers didn't support being use for multicast routing (MRT_ADD_VIF) Date: Fri, 11 Dec 2015 08:18:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 08:18:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202484 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #2 from Andrey V. Elsukov --- (In reply to olivier from comment #1) > errno(2) translate error number 45 by a EOPNOTSUPP. > > And code in netinet/ip_mroute.c can return EOPNOTSUPP in 2 cases: You forgot about "return (error)" and "return (some_func())" :) I guess you receive this error from if_allmulti()->vtnet_ioctl(). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Dec 11 08:46:34 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28F999D7329 for ; Fri, 11 Dec 2015 08:46:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AF841A9E for ; Fri, 11 Dec 2015 08:46:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBB8kXeX083731 for ; Fri, 11 Dec 2015 08:46:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202484] vtnet drivers didn't support being use for multicast routing (MRT_ADD_VIF) Date: Fri, 11 Dec 2015 08:46:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: olivier@cochard.me X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 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.20 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, 11 Dec 2015 08:46:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202484 --- Comment #3 from olivier@cochard.me --- I=C2=A0beleive I've found the source of the problem in this message: https://lists.freebsd.org/pipermail/svn-src-head/2014-January/055007.html "It also does not handle multicast filter configuration when VTNET_FLAG_CTR= L_RX flag is not set. If vtnet(4) does not support multicast filter, it shouldn= 't announce IFF_MULTICAST. I wonder how vtnet(4) can work with carp(4) given that its multicast handling is ignored." If I understand correctly: Multicast support is totaly missing on the vtnet drivers ? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Dec 11 09:01:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 410D89D7EBD for ; Fri, 11 Dec 2015 09:01:22 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE2A1239; Fri, 11 Dec 2015 09:01:22 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id D77762D64; Fri, 11 Dec 2015 09:01:19 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: Multiple cores/race conditions in IPv6 RA To: Mark Johnston References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> <5667EA3A.8050200@FreeBSD.org> <20151210200215.GB34692@wkstn-mjohnston.west.isilon.com> Cc: freebsd-net@freebsd.org, Jason , kevin.bowling@kev009.com, hiren@strugglingcoder.info, Eugene Grosbein From: "Andrey V. Elsukov" X-Enigmail-Draft-Status: N1110 Message-ID: <566A90C9.8070301@FreeBSD.org> Date: Fri, 11 Dec 2015 12:00:57 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151210200215.GB34692@wkstn-mjohnston.west.isilon.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gsOM6WKoCPbE6uWEo9nrF68NClHXPHCDS" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 09:01:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gsOM6WKoCPbE6uWEo9nrF68NClHXPHCDS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10.12.15 23:02, Mark Johnston wrote: >> some time ago Mark Johnston has published there the patch related to >> this problem: >> https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.h= tml >> >> Maybe Mark has something to say about it. >=20 > I started trying to push this work in with D2254, which fixes some of > the global IPv6 addr list locking. It turns out to be pretty tricky > to lock both NDP and the global address list properly; the patch in my > public directory fixes only some of the issues with NDP and is thus > incomplete, which is why I'd been reluctant to push it in. >=20 > I'll return to D2254 and try and make some further progress on this. There was one report about panic, I think it is related to this problem too: http://www.grosbein.net/img/v6crash.png --=20 WBR, Andrey V. Elsukov --gsOM6WKoCPbE6uWEo9nrF68NClHXPHCDS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWapDJAAoJEAHF6gQQyKF67bIIALYFvXJMZLjP0L3PSxL7o2bM quiD/V+2ldgxMwIQFkGB25ab088wxjTHF9bwZzN5OX0DVfD0/hHvXkCe+DZ5VYI+ UCr94rDJvEo+AqXYxiqww1/uyzSiT3fUQPA28muRkcU6wMaRg8PW0hCuM551VXCy QD1F73VzjYivd5OsAZPBc40h1/KxT8GQ174LOowfQqUBzwrCaDKyerDo6+QqtaLb 7tlfXnv1zg5TpL+pb305smjXmC1Y2DGVeUTRKUJVVEDQ4FJQ83Qk8VLp+HQDImOr Cz6iVSdHWSeUBSSiMhOHJIXMJuWKRVGRMov5oa0vUGSHDOKl5kaBJwBnMMeoTKU= =7YmX -----END PGP SIGNATURE----- --gsOM6WKoCPbE6uWEo9nrF68NClHXPHCDS-- From owner-freebsd-net@freebsd.org Fri Dec 11 09:15:33 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1DB49D8792 for ; Fri, 11 Dec 2015 09:15:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF657199F; Fri, 11 Dec 2015 09:15:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B94251FE023; Fri, 11 Dec 2015 10:15:30 +0100 (CET) Subject: Race between arptimer() and lle removal [WAS: panic in arptimer in r289937] To: "Alexander V. Chernikov" , Adrian Chadd , "freebsd-net@freebsd.org" References: null <2739461446298483@web2h.yandex.ru> From: Hans Petter Selasky Message-ID: <566A94A1.60400@selasky.org> Date: Fri, 11 Dec 2015 10:17:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2739461446298483@web2h.yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 09:15:34 -0000 Hi, Pulling the nail out of the haystack hopefully. >> Any ideas on where next to look? Adrian: In your dump aswell I see: la_flags = 1 That means there was a race calling arptimer() and removing the "lle". Alexander: Can you comment on the following patch: > Index: netinet/if_ether.c > =================================================================== > --- netinet/if_ether.c (revision 291256) > +++ netinet/if_ether.c (working copy) > @@ -185,7 +185,13 @@ > LLE_WUNLOCK(lle); > return; > } > - ifp = lle->lle_tbl->llt_ifp; > + if (lle->la_flags & LLE_LINKED) { > + ifp = lle->lle_tbl->llt_ifp; > + } else { > + /* XXX RACE entry has been freed */ > + llentry_free(lle); > + return; > + } > CURVNET_SET(ifp->if_vnet); > > if ((lle->la_flags & LLE_DELETED) == 0) { We need a check in arptimer() that the lle is still linked before proceeding, in there from what I can see. Because the callback is not protected by a mutex, it is not atomically stopped by callout_stop(). --HPS From owner-freebsd-net@freebsd.org Fri Dec 11 10:13:01 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFBF89D83E8 for ; Fri, 11 Dec 2015 10:13:01 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward16o.cmail.yandex.net (forward16o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::1e6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BBEC1D1F; Fri, 11 Dec 2015 10:13:01 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web21o.yandex.ru (web21o.yandex.ru [IPv6:2a02:6b8:0:1a2d::5:121]) by forward16o.cmail.yandex.net (Yandex) with ESMTP id 96E7E20EF7; Fri, 11 Dec 2015 13:12:57 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web21o.yandex.ru (Yandex) with ESMTP id 86584401A3F; Fri, 11 Dec 2015 13:12:56 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1449828777; bh=2Gs0Q33K9LAJ4U7JSV3+GFk6m0W6RNcHf9SGaQ8Vbow=; h=From:To:In-Reply-To:References:Subject:Date; b=OFUofFPFfO2OmyyT+Rv36+MJWL2JXg3NKWYGigSFHMBgGJtU6Sg7SlQXkNxfcS6/5 fcfCcm+jf1y1CnkcNTmPhN1xfhDHql8lcA4OSI5k9CP5SAG8vJPLGd/fdlcxgZTPq1 fJHChI/PFk+QWlD9sED9N0Tm+Ukbus+2TQuFg/ZI= Received: by web21o.yandex.ru with HTTP; Fri, 11 Dec 2015 13:12:55 +0300 From: Alexander V. Chernikov To: Hans Petter Selasky , Adrian Chadd , "freebsd-net@freebsd.org" In-Reply-To: <566A94A1.60400@selasky.org> References: null <2739461446298483@web2h.yandex.ru> <566A94A1.60400@selasky.org> Subject: Re: Race between arptimer() and lle removal [WAS: panic in arptimer in r289937] MIME-Version: 1.0 Message-Id: <2850091449828775@web21o.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 11 Dec 2015 13:12:55 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 10:13:01 -0000 11.12.2015, 12:15, "Hans Petter Selasky" : > Hi, > > Pulling the nail out of the haystack hopefully. > >>> šAny ideas on where next to look? > > Adrian: In your dump aswell I see: > > la_flags = 1 > > That means there was a race calling arptimer() and removing the "lle". Yes. The interesting part here is why lle is removed. There are quite a few reasons: either interface address deleted or interface going down, or explicit delete request. That's why I asked Adrian about interface stuff (and haven't got a reply). > > Alexander: Can you comment on the following patch: > > š> Index: netinet/if_ether.c > š> =================================================================== > š> --- netinet/if_ether.c (revision 291256) > š> +++ netinet/if_ether.c (working copy) > š> @@ -185,7 +185,13 @@ > š> LLE_WUNLOCK(lle); > š> return; > š> } > š> - ifp = lle->lle_tbl->llt_ifp; > š> + if (lle->la_flags & LLE_LINKED) { > š> + ifp = lle->lle_tbl->llt_ifp; > š> + } else { > š> + /* XXX RACE entry has been freed */ > š> + llentry_free(lle); > š> + return; > š> + } > š> CURVNET_SET(ifp->if_vnet); > š> > š> if ((lle->la_flags & LLE_DELETED) == 0) { > > We need a check in arptimer() that the lle is still linked before Yes, I had exactly that approach in mind. (And nd6_llinfo_timer() needs the same fix). So, would you commit it or should I? > proceeding, in there from what I can see. Because the callback is not > protected by a mutex, it is not atomically stopped by callout_stop(). > > --HPS From owner-freebsd-net@freebsd.org Fri Dec 11 11:14:30 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E72029D81A9 for ; Fri, 11 Dec 2015 11:14:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 AEC761F8C; Fri, 11 Dec 2015 11:14:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 463D71FE023; Fri, 11 Dec 2015 12:14:26 +0100 (CET) Subject: Re: Race between arptimer() and lle removal [WAS: panic in arptimer in r289937] To: "Alexander V. Chernikov" , Adrian Chadd , "freebsd-net@freebsd.org" References: null <2739461446298483@web2h.yandex.ru> <566A94A1.60400@selasky.org> <2850091449828775@web21o.yandex.ru> From: Hans Petter Selasky Message-ID: <566AB081.8050100@selasky.org> Date: Fri, 11 Dec 2015 12:16:17 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2850091449828775@web21o.yandex.ru> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 11:14:30 -0000 On 12/11/15 11:12, Alexander V. Chernikov wrote: > 11.12.2015, 12:15, "Hans Petter Selasky" : >> Hi, >> >> Pulling the nail out of the haystack hopefully. >> >>>> Any ideas on where next to look? >> >> Adrian: In your dump aswell I see: >> >> la_flags = 1 >> >> That means there was a race calling arptimer() and removing the "lle". > Yes. The interesting part here is why lle is removed. There are quite a few reasons: either interface address deleted or interface going down, or explicit delete request. > That's why I asked Adrian about interface stuff (and haven't got a reply). >> >> Alexander: Can you comment on the following patch: >> >> > Index: netinet/if_ether.c >> > =================================================================== >> > --- netinet/if_ether.c (revision 291256) >> > +++ netinet/if_ether.c (working copy) >> > @@ -185,7 +185,13 @@ >> > LLE_WUNLOCK(lle); >> > return; >> > } >> > - ifp = lle->lle_tbl->llt_ifp; >> > + if (lle->la_flags & LLE_LINKED) { >> > + ifp = lle->lle_tbl->llt_ifp; >> > + } else { >> > + /* XXX RACE entry has been freed */ >> > + llentry_free(lle); >> > + return; >> > + } >> > CURVNET_SET(ifp->if_vnet); >> > >> > if ((lle->la_flags & LLE_DELETED) == 0) { >> >> We need a check in arptimer() that the lle is still linked before > Yes, I had exactly that approach in mind. (And nd6_llinfo_timer() needs the same fix). > So, would you commit it or should I? >> proceeding, in there from what I can see. Because the callback is not >> protected by a mutex, it is not atomically stopped by callout_stop(). Hi, Talking to Randall offlist, I see some more trouble. Let's get everything straight before making a fix. There is one more race I see: The start of the arptimer() callback looks like this: > static void > arptimer(void *arg) > { POINT0 > LLE_WLOCK(lle); > if (callout_pending(&lle->lle_timer)) { POINT1 > LLE_WUNLOCK(lle); > return; > } The code starting the callback looks like this: > LLE_ADDREF(la); > la->la_expire = time_uptime; > canceled = callout_reset(&la->lle_timer, hz * V_arpt_down, > arptimer, la); > if (canceled) > LLE_REMREF(la); Which can be written like this: > la->la_expire = time_uptime; > canceled = callout_reset(&la->lle_timer, hz * V_arpt_down, > arptimer, la); > if (canceled == 0) > LLE_ADDREF(la); In case we are at POINT0 in arptimer, callout_reset() will not be able to cancel the callout and will return 0. We should also drop one ref at POINT1, or rewrite the code a bit, which might need Randall's help in the callout subsystem area. --HPS From owner-freebsd-net@freebsd.org Fri Dec 11 12:10:44 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 396F49D6EBB for ; Fri, 11 Dec 2015 12:10:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 C09AF1D97; Fri, 11 Dec 2015 12:10:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E3C1A1FE023; Fri, 11 Dec 2015 13:10:40 +0100 (CET) Subject: Re: Race between arptimer() and lle removal [WAS: panic in arptimer in r289937] To: "Alexander V. Chernikov" , Adrian Chadd , "freebsd-net@freebsd.org" , Randall Stewart , Gleb Smirnoff References: null <2739461446298483@web2h.yandex.ru> <566A94A1.60400@selasky.org> <2850091449828775@web21o.yandex.ru> <566AB081.8050100@selasky.org> From: Hans Petter Selasky Message-ID: <566ABDAF.7060208@selasky.org> Date: Fri, 11 Dec 2015 13:12:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <566AB081.8050100@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 12:10:44 -0000 On 12/11/15 12:16, Hans Petter Selasky wrote: > On 12/11/15 11:12, Alexander V. Chernikov wrote: >> 11.12.2015, 12:15, "Hans Petter Selasky" : >>> Hi, >>> >>> Pulling the nail out of the haystack hopefully. >>> >>>>> Any ideas on where next to look? >>> >>> Adrian: In your dump aswell I see: >>> >>> la_flags = 1 >>> >>> That means there was a race calling arptimer() and removing the "lle". >> Yes. The interesting part here is why lle is removed. There are quite >> a few reasons: either interface address deleted or interface going >> down, or explicit delete request. >> That's why I asked Adrian about interface stuff (and haven't got a >> reply). >>> >>> Alexander: Can you comment on the following patch: >>> >>> > Index: netinet/if_ether.c >>> > =================================================================== >>> > --- netinet/if_ether.c (revision 291256) >>> > +++ netinet/if_ether.c (working copy) >>> > @@ -185,7 +185,13 @@ >>> > LLE_WUNLOCK(lle); >>> > return; >>> > } >>> > - ifp = lle->lle_tbl->llt_ifp; >>> > + if (lle->la_flags & LLE_LINKED) { >>> > + ifp = lle->lle_tbl->llt_ifp; >>> > + } else { >>> > + /* XXX RACE entry has been freed */ >>> > + llentry_free(lle); >>> > + return; >>> > + } >>> > CURVNET_SET(ifp->if_vnet); >>> > >>> > if ((lle->la_flags & LLE_DELETED) == 0) { >>> >>> We need a check in arptimer() that the lle is still linked before >> Yes, I had exactly that approach in mind. (And nd6_llinfo_timer() >> needs the same fix). >> So, would you commit it or should I? >>> proceeding, in there from what I can see. Because the callback is not >>> protected by a mutex, it is not atomically stopped by callout_stop(). > > Hi, > > Talking to Randall offlist, I see some more trouble. Let's get > everything straight before making a fix. There is one more race I see: > > The start of the arptimer() callback looks like this: > > > static void > > arptimer(void *arg) > > { > POINT0 > > LLE_WLOCK(lle); > > if (callout_pending(&lle->lle_timer)) { > POINT1 > > LLE_WUNLOCK(lle); > > return; > > } > > The code starting the callback looks like this: > > > LLE_ADDREF(la); > > la->la_expire = time_uptime; > > canceled = callout_reset(&la->lle_timer, hz * > V_arpt_down, > > arptimer, la); > > if (canceled) > > LLE_REMREF(la); > > Which can be written like this: > > > la->la_expire = time_uptime; > > canceled = callout_reset(&la->lle_timer, hz * V_arpt_down, > > arptimer, la); > > if (canceled == 0) > > LLE_ADDREF(la); > > In case we are at POINT0 in arptimer, callout_reset() will not be able > to cancel the callout and will return 0. We should also drop one ref at > POINT1, or rewrite the code a bit, which might need Randall's help in > the callout subsystem area. > Hi, Looking at the version history, I see Gleb Smirnoff and Randall, heavily involved with these code paths. Gleb and Randall, do you have any comments on the above findings? Gleb+Randall: Do you agree or disagree there is a race as pointed out above? Ways forward: 1) Revert r278472 (done by Randall) and fix r238990 (done by Gleb) to use the new callout_async_drain() instead of callout_stop() to avoid using the rm lock after free. 2) Use callout_stop() before callout_reset() and add a reference when the callout was not pending nor completing. We need to use callout_stop() in this case because callout_reset() only has two return values and cannot be used to distinguish the three callout states in use. 3) Modify callout_reset() to have three return values and fix the arptimer code to not leak references. --HPS From owner-freebsd-net@freebsd.org Fri Dec 11 15:16:55 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBC069D8EFA for ; Fri, 11 Dec 2015 15:16:54 +0000 (UTC) (envelope-from jmc@cs.rit.edu) Received: from pony-express.cs.rit.edu (pony-express.cs.rit.edu [129.21.30.24]) (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 7C63C12AA for ; Fri, 11 Dec 2015 15:16:53 +0000 (UTC) (envelope-from jmc@cs.rit.edu) Received: (qmail 27481 invoked by uid 56003); 11 Dec 2015 15:16:51 -0000 Received: from 129.21.36.151 by pony-express (envelope-from , uid 20003) with qmail-scanner-1.25st (spamassassin: 3.3.2. perlscan: 1.25st. Clear:RC:1(129.21.36.151):SA:0(-1.0/4.5):. Processed in 0.704388 secs); 11 Dec 2015 15:16:51 -0000 X-Spam-Status: No, hits=-1.0 required=4.5 X-Spam-Report: SA TESTS -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Received: from starfury.cs.rit.edu (HELO starfury) (129.21.36.151) by mailhost.cs.rit.edu with ESMTPS (DHE-RSA-AES256-SHA encrypted); 11 Dec 2015 15:16:51 -0000 Date: Fri, 11 Dec 2015 10:16:50 -0500 (EST) From: James Craig To: Mark Johnston cc: freebsd-net@freebsd.org Subject: Re: Netgroups in FreeBSD10 In-Reply-To: <20151210201621.GC34692@wkstn-mjohnston.west.isilon.com> Message-ID: References: <20151210201621.GC34692@wkstn-mjohnston.west.isilon.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 15:16:55 -0000 On Thu, 10 Dec 2015, Mark Johnston wrote: > On Thu, Dec 10, 2015 at 10:58:11AM -0500, James Craig wrote: >> >> >> Hey all! >> >> I am migrating some of our services to freeBSD, and in the process of this, >> I have discovered something that seems odd to me; netgroups don't seem to work >> as expected. >> >> I am trying to set up a machine that will eventually be a file server >> (running 10.2-RELEASE) and getent netgroup doesn't return anything, >> even if it is a valid name. >> >> We have been using openldap, and on the old solaris server, I was able to >> query netgroups for information, and use netgroups to limit some access to NFS. >> >> getent passwd, and other lookups seem to work fine. >> >> >> I had truss running on the ldap server, and when I try to >> getent netgroup there is no action. So I ran a truss on the getent on >> the FreeBSD machine, and sifting through the system calls the system will only >> search the file /etc/netgroup (which is empty), despite that >> my /etc/nsswitch.conf looks like this: > > Unfortunately, the NSS documentation is wrong: the netgroup database isn't > implemented. The netgroup NSS methods always read /etc/netgroup and > ignore the sources configured in /etc/nsswitch.conf. I am glad I wasn't screwing up; thanks for the insight. Since this note I have also discovered that trying to use netgroups in login.access fails because I am not using NIS -- regardless of the /etc/netgroup file being populated. Is this something that will get implemented? (where would I go to find out?) > I have a libc patch (missing man page updates) that fixes this: > https://people.freebsd.org/~markj/patches/netgroup_nss.diff > It also adds a getnetgrent_r() implementation. If you're able to rebuild > libc in your environment, this patch should fix the problem you're > encountering - please let me know if it doesn't! I'll be honest; I have never done that before, so I am not sure what it will take, or what the ramifications on the system would be. I can look into it. (pointers would be appreciated, if there are any) thank you! James Craig -- James Craig, Department of Computer Science, RIT 102 Lomb Memorial Drive, Rochester, NY 14623 mailto:jmc@cs.rit.edu, voice: (585) 475-5254 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information. From owner-freebsd-net@freebsd.org Fri Dec 11 19:13:59 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F3F39D72FF for ; Fri, 11 Dec 2015 19:13:59 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9B201CC0 for ; Fri, 11 Dec 2015 19:13:58 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pfbu66 with SMTP id u66so26603187pfb.3 for ; Fri, 11 Dec 2015 11:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tAg7DwvXSOt0qi/AUM8XXJYACJTj5sQNj4sZJhfnGEA=; b=KiVBYm0mUtUiPpt45f+wvBBMKw3tUSQEZr4mh+/6ED4+M6wDsEbohuRsudyIzVpBsr KWTWjg6CO9P0IN1fSvB809iV/GSIY6K0LN0N9YLPRtUf/LwAa8rFOcNKbVkjW4R7BNE4 S1a9bt8CacpIgsj95XESA4XsXJHFuS5ywYpxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=tAg7DwvXSOt0qi/AUM8XXJYACJTj5sQNj4sZJhfnGEA=; b=FoyiqLmjNzT5cnZMcYiZDLFTjtfJKFj46zd0IIGUZl2vCm4J7NadRy+d3I1f0vqxzk iHUxs/YgfZRh1z84/s1W2Jr1kK3eCThyVnXDRaixaQ2buzV4WeAMH3uDgLyaD+n7iFUh vuxuK2MFmv9jyDrOhb3YvYZ5FePafm/NURMWHosymDyVE66Aqqu9vcgO6ZtON95p6/X2 pxNG+8pHu2V4v5GJac8AbV/tKey6PtfbVhyYuVnbpGhpSIWwMYQ6GZ+ptSIZpjSnbAPD ly6EJRrEqsZkoRbgKyRxD7SyLSQwoxO1qqRU6Wv+cuzEC86v09rBYKddnX1EYuILwSWP qD/g== X-Gm-Message-State: ALoCoQln/aScAkjRKYDpjYdAuqxSZM+kqqyNDZs1ageiWlwChCXWsGtKAeMnQjjea+Uq/gU4m5ybhOM68T6et8jn54N8rLtCHA== X-Received: by 10.98.9.146 with SMTP id 18mr17452968pfj.13.1449861238254; Fri, 11 Dec 2015 11:13:58 -0800 (PST) Received: from lgml-rrs-2.corp.netflix.com ([69.53.232.0]) by smtp.gmail.com with ESMTPSA id 1sm26704755pfo.72.2015.12.11.11.13.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Dec 2015 11:13:56 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Race between arptimer() and lle removal [WAS: panic in arptimer in r289937] From: Randall Stewart In-Reply-To: <566ABDAF.7060208@selasky.org> Date: Fri, 11 Dec 2015 11:13:58 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , Gleb Smirnoff Message-Id: References: null <2739461446298483@web2h.yandex.ru> <566A94A1.60400@selasky.org> <2850091449828775@web21o.yandex.ru> <566AB081.8050100@selasky.org> <566ABDAF.7060208@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 19:13:59 -0000 Hans: I don=92t think you are getting a 1 back from the callout_reset()..=20 If the pending bit is set, you get a 1 back. But if you have a race = where the arp-timer is blocked on the lock (held by arp resolve) your going to have the pending bit off.. since before calling the function the callout code removes pending. Callout-reset() is going to return 0 here since it is running and cannot be stopped. That should make you *not* decrement your reference. The only time you get a 1 back (where you will decrement your reference) = is if the PENDING flag is set or if you are migrating and the current one = running. The ARP code does not migrate that I can see. Which means that once you start = running and block a return of 0 will be done by the callout system. Since you check the PENDING flag at the top of the callout, that would = get you=20 to return if its been reset. However I notice down in the arptimer code a unlock/lock/lock is done. = Now again the pending flag will be gone when that set of calls is made. So we = should be getting a zero return out of the callout_reset() code. Hmm. let me mull on this a bit.. any time there is a unlock/lock/lock that = could be a problem.. R On Dec 11, 2015, at 4:12 AM, Hans Petter Selasky = wrote: > On 12/11/15 12:16, Hans Petter Selasky wrote: >> On 12/11/15 11:12, Alexander V. Chernikov wrote: >>> 11.12.2015, 12:15, "Hans Petter Selasky" : >>>> Hi, >>>>=20 >>>> Pulling the nail out of the haystack hopefully. >>>>=20 >>>>>> Any ideas on where next to look? >>>>=20 >>>> Adrian: In your dump aswell I see: >>>>=20 >>>> la_flags =3D 1 >>>>=20 >>>> That means there was a race calling arptimer() and removing the = "lle". >>> Yes. The interesting part here is why lle is removed. There are = quite >>> a few reasons: either interface address deleted or interface going >>> down, or explicit delete request. >>> That's why I asked Adrian about interface stuff (and haven't got a >>> reply). >>>>=20 >>>> Alexander: Can you comment on the following patch: >>>>=20 >>>> > Index: netinet/if_ether.c >>>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > --- netinet/if_ether.c (revision 291256) >>>> > +++ netinet/if_ether.c (working copy) >>>> > @@ -185,7 +185,13 @@ >>>> > LLE_WUNLOCK(lle); >>>> > return; >>>> > } >>>> > - ifp =3D lle->lle_tbl->llt_ifp; >>>> > + if (lle->la_flags & LLE_LINKED) { >>>> > + ifp =3D lle->lle_tbl->llt_ifp; >>>> > + } else { >>>> > + /* XXX RACE entry has been freed */ >>>> > + llentry_free(lle); >>>> > + return; >>>> > + } >>>> > CURVNET_SET(ifp->if_vnet); >>>> > >>>> > if ((lle->la_flags & LLE_DELETED) =3D=3D 0) { >>>>=20 >>>> We need a check in arptimer() that the lle is still linked before >>> Yes, I had exactly that approach in mind. (And nd6_llinfo_timer() >>> needs the same fix). >>> So, would you commit it or should I? >>>> proceeding, in there from what I can see. Because the callback is = not >>>> protected by a mutex, it is not atomically stopped by = callout_stop(). >>=20 >> Hi, >>=20 >> Talking to Randall offlist, I see some more trouble. Let's get >> everything straight before making a fix. There is one more race I = see: >>=20 >> The start of the arptimer() callback looks like this: >>=20 >> > static void >> > arptimer(void *arg) >> > { >> POINT0 >> > LLE_WLOCK(lle); >> > if (callout_pending(&lle->lle_timer)) { >> POINT1 >> > LLE_WUNLOCK(lle); >> > return; >> > } >>=20 >> The code starting the callback looks like this: >>=20 >> > LLE_ADDREF(la); >> > la->la_expire =3D time_uptime; >> > canceled =3D callout_reset(&la->lle_timer, hz * >> V_arpt_down, >> > arptimer, la); >> > if (canceled) >> > LLE_REMREF(la); >>=20 >> Which can be written like this: >>=20 >> > la->la_expire =3D time_uptime; >> > canceled =3D callout_reset(&la->lle_timer, hz * V_arpt_down, >> > arptimer, la); >> > if (canceled =3D=3D 0) >> > LLE_ADDREF(la); >>=20 >> In case we are at POINT0 in arptimer, callout_reset() will not be = able >> to cancel the callout and will return 0. We should also drop one ref = at >> POINT1, or rewrite the code a bit, which might need Randall's help in >> the callout subsystem area. >>=20 >=20 > Hi, >=20 > Looking at the version history, I see Gleb Smirnoff and Randall, = heavily involved with these code paths. Gleb and Randall, do you have = any comments on the above findings? >=20 > Gleb+Randall: Do you agree or disagree there is a race as pointed out = above? >=20 > Ways forward: >=20 > 1) Revert r278472 (done by Randall) and fix r238990 (done by Gleb) to = use the new callout_async_drain() instead of callout_stop() to avoid = using the rm lock after free. >=20 > 2) Use callout_stop() before callout_reset() and add a reference when = the callout was not pending nor completing. We need to use = callout_stop() in this case because callout_reset() only has two return = values and cannot be used to distinguish the three callout states in = use. >=20 > 3) Modify callout_reset() to have three return values and fix the = arptimer code to not leak references. >=20 > --HPS -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-net@freebsd.org Fri Dec 11 19:37:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3809DA04697 for ; Fri, 11 Dec 2015 19:37:22 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC08B17A6 for ; Fri, 11 Dec 2015 19:37:21 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by qkck189 with SMTP id k189so18687527qkc.0 for ; Fri, 11 Dec 2015 11:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=goIZuW71ziqeUypKfspLccVXGZ9RJq8wnRpeeR3IWA8=; b=T82tN7NY3kuk8CVv7cJVKcnHIzmS6Ma4lidtGPuO86RKm6d4l7iC9CE1jMgNMAmCGb AbylORyavSZRPWg3/hZ206xud2vEsE1oEFXjCP42p6fvw0nak9jU7qpu22ZZP1dH1Bci mirlKuB02W//Uz6oB4+DmlcEsTf0QskZ8A5mV9BKos4a1aDrHVNMO+v+34AbIi8bRmDH S0F9kmhJMqDRoTi1dGp5X9J+w1b4+8vjniMzVML6rBjzfuGK1Jh44euH/idq6BcamBDA era3KZOWui69AHzQzJoGDdfYQvKlq7+wgl6MJEXKoVivQ0prb76M9fFo8Y/dXHyYmosB mZjQ== X-Received: by 10.55.78.82 with SMTP id c79mr25562465qkb.44.1449862640864; Fri, 11 Dec 2015 11:37:20 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by smtp.gmail.com with ESMTPSA id 9sm59144qhm.21.2015.12.11.11.37.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Dec 2015 11:37:20 -0800 (PST) Sender: Mark Johnston Date: Fri, 11 Dec 2015 11:39:15 -0800 From: Mark Johnston To: James Craig Cc: freebsd-net@freebsd.org Subject: Re: Netgroups in FreeBSD10 Message-ID: <20151211193915.GC98922@wkstn-mjohnston.west.isilon.com> References: <20151210201621.GC34692@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 19:37:22 -0000 On Fri, Dec 11, 2015 at 10:16:50AM -0500, James Craig wrote: > On Thu, 10 Dec 2015, Mark Johnston wrote: > > > On Thu, Dec 10, 2015 at 10:58:11AM -0500, James Craig wrote: > >> > >> > >> Hey all! > >> > >> I am migrating some of our services to freeBSD, and in the process of this, > >> I have discovered something that seems odd to me; netgroups don't seem to work > >> as expected. > >> > >> I am trying to set up a machine that will eventually be a file server > >> (running 10.2-RELEASE) and getent netgroup doesn't return anything, > >> even if it is a valid name. > >> > >> We have been using openldap, and on the old solaris server, I was able to > >> query netgroups for information, and use netgroups to limit some access to NFS. > >> > >> getent passwd, and other lookups seem to work fine. > >> > >> > >> I had truss running on the ldap server, and when I try to > >> getent netgroup there is no action. So I ran a truss on the getent on > >> the FreeBSD machine, and sifting through the system calls the system will only > >> search the file /etc/netgroup (which is empty), despite that > >> my /etc/nsswitch.conf looks like this: > > > > Unfortunately, the NSS documentation is wrong: the netgroup database isn't > > implemented. The netgroup NSS methods always read /etc/netgroup and > > ignore the sources configured in /etc/nsswitch.conf. > > I am glad I wasn't screwing up; thanks for the insight. > > Since this note I have also discovered that trying to use netgroups > in login.access fails because I am not using NIS -- regardless of > the /etc/netgroup file being populated. Yes, it looks like the system needs to belong to an NIS domain containing the specified netgroups in order for login.access support to work. > > Is this something that will get implemented? (where would I go to > find out?) It's not really clear what "this" is. :) If you want to be able to specify an NIS domain in login.access, some syntax for doing so would need to be proposed. A bugzilla PR would be the way to do so: https://bugs.freebsd.org You can search for existing PRs to see if something similar has already been submitted. > > > I have a libc patch (missing man page updates) that fixes this: > > https://people.freebsd.org/~markj/patches/netgroup_nss.diff > > It also adds a getnetgrent_r() implementation. If you're able to rebuild > > libc in your environment, this patch should fix the problem you're > > encountering - please let me know if it doesn't! > > I'll be honest; I have never done that before, so I am not sure > what it will take, or what the ramifications on the system would > be. > > I can look into it. (pointers would be appreciated, if there are any) I'll send some instructions in a separate mail. From owner-freebsd-net@freebsd.org Fri Dec 11 19:58:07 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EED09D77BC for ; Fri, 11 Dec 2015 19:58:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F80311BD for ; Fri, 11 Dec 2015 19:58:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBBJw6br087458 for ; Fri, 11 Dec 2015 19:58:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205194] Changing MTU higher than 1500 on the interface pfsync0 causes panic Date: Fri, 11 Dec 2015 19:58:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 19:58:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205194 --- Comment #1 from Kristof Provost --- I've had a quick look at this, and imagine my surprise when it turned out to not actually be a PF bug. Briefly, the pfsync interface doesn't have any ip6 data associated with it, while the netinet6 code assumes it to be present. We panic because of the call to nd6_setmtu(ifp); in the SIOCSIFMTU ioctl() handler. We just need to check if ip6 is active on the interface before we try to do anything with it. There's an open review in: https://reviews.freebsd.org/D4522 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Dec 11 23:26:34 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B3919D7C31 for ; Fri, 11 Dec 2015 23:26:34 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE90A17FC for ; Fri, 11 Dec 2015 23:26:33 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by padhk6 with SMTP id hk6so32272259pad.2 for ; Fri, 11 Dec 2015 15:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8TwPPowbt3sfq3u8xwNAibubJmu1iDNGbhaOCZ58I1s=; b=Ly4PVvQ+Hjrhc11PYVKwiMu0PeQ93JTuRrNQF2EPN+GLP2K+m/sN7LeRm+v5Oljm3B BmcvPNk1OSJA6GRIrYMo/x5LMAI96QfYhxu7UlXuc29CWHfjMyOPFGi2QB7Fw6tYq19h VDIVlu6P+9+rNldky16NjG6uQMMiSfFjXVxjc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8TwPPowbt3sfq3u8xwNAibubJmu1iDNGbhaOCZ58I1s=; b=RymojcRnFbf3XfUKTUbAnSM+6IVuI9yovl3kgMLhy5vSdGPy/q7PMjjyWIe48elgco xQo1d5qPlFnUxaaPMZEEBfMjvh1vxKJzglums2kS2ekfD50fYvOkp9YCMwx/aSaQEO9B EUWFgo7zvhG8K1JI8H2QKK6TX5ee19/ljSRFv0t5PzAUGe8cHC32ibWr9UkJxQbaiiyJ A9XFU4xevlVQxxnKKxLZi5+H9q43Rjqthvxgta10NeNp7alLNTFVDni2LQDXOIRGCLs5 xXRXH/ao0rVgdEC6vwJoJeBK3ceMA18bl9J9PJC3suiudI+AJFAL0NpAup8ZrbDHbEVU okuw== X-Gm-Message-State: ALoCoQmbKLqa0BcpPVtoKL0uvs/Y7pq5OrcK4fHHJKYlce8CYEzBivnTVojDr3VqPmeOBhq04RnLaWDxLlXQxFOhSL065lUlMA== X-Received: by 10.66.122.105 with SMTP id lr9mr29042238pab.8.1449876393190; Fri, 11 Dec 2015 15:26:33 -0800 (PST) Received: from [172.20.1.11] ([40.140.7.61]) by smtp.gmail.com with ESMTPSA id qy7sm27698577pab.37.2015.12.11.15.26.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Dec 2015 15:26:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Race between arptimer() and lle removal [WAS: panic in arptimer in r289937] From: Randall Stewart In-Reply-To: Date: Fri, 11 Dec 2015 15:26:29 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , Gleb Smirnoff Message-Id: <91332B46-8CD3-45C0-80D0-AAD29ADD2DE0@netflix.com> References: null <2739461446298483@web2h.yandex.ru> <566A94A1.60400@selasky.org> <2850091449828775@web21o.yandex.ru> <566AB081.8050100@selasky.org> <566ABDAF.7060208@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 11 Dec 2015 23:26:34 -0000 Hans: After talking with Gleb he tells me part of your test is to kldunload a = module. Now I think that is the source of the problem. Probably the cleanup code failed to stop the timer and did the remove.. = thus when the timer expires it blows up. This is not a callout issue.. I think you need to start looking at the = cleanup if you want to pursue this.=20 R On Dec 11, 2015, at 11:13 AM, Randall Stewart wrote: > Hans: >=20 > I don=92t think you are getting a 1 back from the callout_reset()..=20 >=20 > If the pending bit is set, you get a 1 back. But if you have a race = where > the arp-timer is blocked on the lock (held by arp resolve) your going = to > have the pending bit off.. since before calling the function the = callout > code removes pending. >=20 > Callout-reset() is going to return 0 here since it is running and = cannot > be stopped. That should make you *not* decrement your reference. >=20 > The only time you get a 1 back (where you will decrement your = reference) is if > the PENDING flag is set or if you are migrating and the current one = running. The ARP code > does not migrate that I can see. Which means that once you start = running > and block a return of 0 will be done by the callout system. >=20 > Since you check the PENDING flag at the top of the callout, that would = get you=20 > to return if its been reset. >=20 > However I notice down in the arptimer code a unlock/lock/lock is done. = Now again > the pending flag will be gone when that set of calls is made. So we = should > be getting a zero return out of the callout_reset() code. >=20 > Hmm. >=20 > let me mull on this a bit.. any time there is a unlock/lock/lock that = could be > a problem.. >=20 > R >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Dec 11, 2015, at 4:12 AM, Hans Petter Selasky = wrote: >=20 >> On 12/11/15 12:16, Hans Petter Selasky wrote: >>> On 12/11/15 11:12, Alexander V. Chernikov wrote: >>>> 11.12.2015, 12:15, "Hans Petter Selasky" : >>>>> Hi, >>>>>=20 >>>>> Pulling the nail out of the haystack hopefully. >>>>>=20 >>>>>>> Any ideas on where next to look? >>>>>=20 >>>>> Adrian: In your dump aswell I see: >>>>>=20 >>>>> la_flags =3D 1 >>>>>=20 >>>>> That means there was a race calling arptimer() and removing the = "lle". >>>> Yes. The interesting part here is why lle is removed. There are = quite >>>> a few reasons: either interface address deleted or interface going >>>> down, or explicit delete request. >>>> That's why I asked Adrian about interface stuff (and haven't got a >>>> reply). >>>>>=20 >>>>> Alexander: Can you comment on the following patch: >>>>>=20 >>>>> > Index: netinet/if_ether.c >>>>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> > --- netinet/if_ether.c (revision 291256) >>>>> > +++ netinet/if_ether.c (working copy) >>>>> > @@ -185,7 +185,13 @@ >>>>> > LLE_WUNLOCK(lle); >>>>> > return; >>>>> > } >>>>> > - ifp =3D lle->lle_tbl->llt_ifp; >>>>> > + if (lle->la_flags & LLE_LINKED) { >>>>> > + ifp =3D lle->lle_tbl->llt_ifp; >>>>> > + } else { >>>>> > + /* XXX RACE entry has been freed */ >>>>> > + llentry_free(lle); >>>>> > + return; >>>>> > + } >>>>> > CURVNET_SET(ifp->if_vnet); >>>>> > >>>>> > if ((lle->la_flags & LLE_DELETED) =3D=3D 0) { >>>>>=20 >>>>> We need a check in arptimer() that the lle is still linked before >>>> Yes, I had exactly that approach in mind. (And nd6_llinfo_timer() >>>> needs the same fix). >>>> So, would you commit it or should I? >>>>> proceeding, in there from what I can see. Because the callback is = not >>>>> protected by a mutex, it is not atomically stopped by = callout_stop(). >>>=20 >>> Hi, >>>=20 >>> Talking to Randall offlist, I see some more trouble. Let's get >>> everything straight before making a fix. There is one more race I = see: >>>=20 >>> The start of the arptimer() callback looks like this: >>>=20 >>> > static void >>> > arptimer(void *arg) >>> > { >>> POINT0 >>> > LLE_WLOCK(lle); >>> > if (callout_pending(&lle->lle_timer)) { >>> POINT1 >>> > LLE_WUNLOCK(lle); >>> > return; >>> > } >>>=20 >>> The code starting the callback looks like this: >>>=20 >>> > LLE_ADDREF(la); >>> > la->la_expire =3D time_uptime; >>> > canceled =3D callout_reset(&la->lle_timer, hz * >>> V_arpt_down, >>> > arptimer, la); >>> > if (canceled) >>> > LLE_REMREF(la); >>>=20 >>> Which can be written like this: >>>=20 >>> > la->la_expire =3D time_uptime; >>> > canceled =3D callout_reset(&la->lle_timer, hz * V_arpt_down, >>> > arptimer, la); >>> > if (canceled =3D=3D 0) >>> > LLE_ADDREF(la); >>>=20 >>> In case we are at POINT0 in arptimer, callout_reset() will not be = able >>> to cancel the callout and will return 0. We should also drop one ref = at >>> POINT1, or rewrite the code a bit, which might need Randall's help = in >>> the callout subsystem area. >>>=20 >>=20 >> Hi, >>=20 >> Looking at the version history, I see Gleb Smirnoff and Randall, = heavily involved with these code paths. Gleb and Randall, do you have = any comments on the above findings? >>=20 >> Gleb+Randall: Do you agree or disagree there is a race as pointed out = above? >>=20 >> Ways forward: >>=20 >> 1) Revert r278472 (done by Randall) and fix r238990 (done by Gleb) to = use the new callout_async_drain() instead of callout_stop() to avoid = using the rm lock after free. >>=20 >> 2) Use callout_stop() before callout_reset() and add a reference when = the callout was not pending nor completing. We need to use = callout_stop() in this case because callout_reset() only has two return = values and cannot be used to distinguish the three callout states in = use. >>=20 >> 3) Modify callout_reset() to have three return values and fix the = arptimer code to not leak references. >>=20 >> --HPS >=20 > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 >=20 >=20 >=20 >=20 >=20 -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-net@freebsd.org Sat Dec 12 07:57:28 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BE50A141A9 for ; Sat, 12 Dec 2015 07:57:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E2DE1958 for ; Sat, 12 Dec 2015 07:57:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBC7vRTg068112 for ; Sat, 12 Dec 2015 07:57:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205264] XOR logic error in ixgb(4) Date: Sat, 12 Dec 2015 07:57:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Dec 2015 07:57:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205264 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Keywords| |IntelNetworking -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sat Dec 12 10:12:31 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA04BA14AC4 for ; Sat, 12 Dec 2015 10:12:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 9DC691F73; Sat, 12 Dec 2015 10:12:30 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A76B61FE023; Sat, 12 Dec 2015 11:12:15 +0100 (CET) Subject: Re: Race between arptimer() and lle removal [WAS: panic in arptimer in r289937] To: Randall Stewart References: null <2739461446298483@web2h.yandex.ru> <566A94A1.60400@selasky.org> <2850091449828775@web21o.yandex.ru> <566AB081.8050100@selasky.org> <566ABDAF.7060208@selasky.org> <91332B46-8CD3-45C0-80D0-AAD29ADD2DE0@netflix.com> Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , Gleb Smirnoff From: Hans Petter Selasky Message-ID: <566BF36D.5060702@selasky.org> Date: Sat, 12 Dec 2015 11:14:05 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <91332B46-8CD3-45C0-80D0-AAD29ADD2DE0@netflix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Dec 2015 10:12:31 -0000 On 12/12/15 00:26, Randall Stewart wrote: > Hans: > > After talking with Gleb he tells me part of your test is to kldunload a module. > > Now I think that is the source of the problem. > > Probably the cleanup code failed to stop the timer and did the remove.. thus > when the timer expires it blows up. > > This is not a callout issue.. I think you need to start looking at the cleanup if you > want to pursue this. Randall: Our driver uses a pause of hz ticks to ensure resources are not used any more, which on a fast machine might give exactly hz ticks between ifattach and ifdetach. Is this a problem? What about tunX and tapX devices? In think the right way to ensure races go away is to use Glebs initial approach, because then there is no need to have a check for LLE_LINKED, hence the callback is protected by a mutex, and will be atomically stopped? And use callout_async_drain() when when freeing lle's. Like you write in your previous e-mail, the value of callout_pending() can change during the execution of the arptimer function, and even after the last unlock in arptimer. --HPS From owner-freebsd-net@freebsd.org Sat Dec 12 21:35:25 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E071A3EB32 for ; Sat, 12 Dec 2015 21:35:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EF4817BD for ; Sat, 12 Dec 2015 21:35:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBCLZOJl055304 for ; Sat, 12 Dec 2015 21:35:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 205264] XOR logic error in ixgb(4) Date: Sat, 12 Dec 2015 21:35:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: truckman@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Dec 2015 21:35:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205264 Don Lewis changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |truckman@FreeBSD.org --- Comment #1 from Don Lewis --- IFCAP_HWCSUM is defined as (IFCAP_RXCSUM | IFCAP_TXCSUM), so this code: case SIOCSIFCAP: IOCTL_DEBUGOUT("ioctl rcv'd: SIOCSIFCAP (Set Capabilities)"); mask = ifr->ifr_reqcap ^ ifp->if_capenable; [snip] if (mask & IFCAP_HWCSUM) { if (IFCAP_HWCSUM & ifp->if_capenable) ifp->if_capenable &= ~IFCAP_HWCSUM; else ifp->if_capenable |= IFCAP_HWCSUM; if (ifp->if_drv_flags & IFF_DRV_RUNNING) ixgb_init(adapter); } will set both bits even if the request only specifies one bit, and it will clear both bits even if the request only wants to clear one bit. Replacing the inner if/else block with this should fix the problem: ifp->if_capenable ^= (mask & IFCAP_HWCSUM); or alternatively: ifp->if_capenable = (ifr->ifr_reqcap & IFCAP_HWCSUM) | (ifp->if_capenable & ~IFCAP_HWCSUM); -- You are receiving this mail because: You are the assignee for the bug.