From owner-freebsd-net@freebsd.org Wed Jul 22 20:43:20 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 678AD360384; Wed, 22 Jul 2020 20:43:20 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BBnVH3jjhz4kYJ; Wed, 22 Jul 2020 20:43:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7F6538D4A161; Wed, 22 Jul 2020 20:43:10 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0A6ACE707BD; Wed, 22 Jul 2020 20:43:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id V7G1p1hKwsis; Wed, 22 Jul 2020 20:43:08 +0000 (UTC) Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:5ca3:9f20:8345:9910]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 2473EE707BC; Wed, 22 Jul 2020 20:43:07 +0000 (UTC) From: "Bjoern A. Zeeb" To: "John-Mark Gurney" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: somewhat reproducable vimage panic Date: Wed, 22 Jul 2020 20:43:06 +0000 X-Mailer: MailMate (2.0BETAr6146) Message-ID: <6C149617-55BB-4A87-B993-195E5E133790@lists.zabbadoz.net> In-Reply-To: <20200722193443.GG4213@funkthat.com> References: <20200721091654.GC4213@funkthat.com> <20200721113153.42d83119@x23> <20200721202323.GE4213@funkthat.com> <38F5A3A6-B578-4BA4-8F69-C248163CB6E0@libassi.se> <20200722060514.GF4213@funkthat.com> <20200722193443.GG4213@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4BBnVH3jjhz4kYJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.96)[-0.962]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_LONG(-0.98)[-0.983]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.25)[-0.254]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 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, 22 Jul 2020 20:43:20 -0000 On 22 Jul 2020, at 19:34, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Tue, Jul 21, 2020 at 23:05 > -0700: >> Peter Libassi wrote this message on Wed, Jul 22, 2020 at 06:54 +0200: >>> Is this related to >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 >>> and >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 >>> >> >> Definitely not 234985.. I'm using ue interfaces, and so they don't >> get destroyed while the jail is going away... >> >> I don't think it's 238326 either. This is 100% reliable and it's in >> the IP multicast code.. It looks like in_multi isn't holding an >> interface or address lock waiting for things to free up... > > Did a little more poking, and it looks like the vnet is free'd before > the ifnet is free'd causing this problem: > (kgdb) print inm->inm_ifp[0].if_refcount > $5 = 1 > (kgdb) print inm->inm_ifp[0].if_vnet[0] > $6 = {vnet_le = {le_next = 0xdeadc0dedeadc0de, le_prev = > 0xdeadc0dedeadc0de}, > vnet_magic_n = 3735929054, vnet_ifcnt = 3735929054, > vnet_sockcnt = 3735929054, vnet_state = 3735929054, > vnet_data_mem = 0xdeadc0dedeadc0de, vnet_data_base = > 16045693110842147038, > vnet_shutdown = 222} > > So the multicast code is fine, it holds and releases a reference to > ifnet.. > > The issue is that the reference to the ifnet doesn't involve a > reference to the vnet/prison. Does it need to? The ifnet cannot go away while something holds a reference to it, right? Sounds more like the teardown order is wrong (again)? There should be no more multicast when IP etc. is gone. That means MC doesn’t properly cleanup itself. I guess I should go back now and re-read your original problem statement on how you trigger this.. /bz