From owner-freebsd-net@freebsd.org Tue Feb 18 19:37:13 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 577392441DD for ; Tue, 18 Feb 2020 19:37:13 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48MWMX1Spdz4Vbc; Tue, 18 Feb 2020 19:37:11 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id 01IJb8j0040173 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 18 Feb 2020 11:37:08 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id 01IJb8Zx040172; Tue, 18 Feb 2020 11:37:08 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 18 Feb 2020 11:37:08 -0800 From: Gleb Smirnoff To: Kristof Provost Cc: freebsd-net Subject: Re: vtnet IFF_NEEDSEPOCH? Message-ID: <20200218193708.GH5741@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 48MWMX1Spdz4Vbc X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 19:37:13 -0000 On Tue, Feb 18, 2020 at 10:52:09AM +0100, Kristof Provost wrote: K> Hi, K> K> I’ve been playing around with a risc-v qemu image, and run into this panic K> with vtnet: K> K> DHCPDISCOVER on vtnet0 to 255.255.255.255 port 67 interval 5 K> panic: Assertion in_epoch(net_epoch_preempt) failed at K> /usr/src/sys/net/netisr.c:1093 K> cpuid = 0 K> time = 1581981733 K> KDB: stack backtrace: K> db_trace_self() at db_trace_self K> db_fetch_ksymtab() at db_fetch_ksymtab+0x12a K> kdb_backtrace() at kdb_backtrace+0x2c K> vpanic() at vpanic+0x144 K> panic() at panic+0x26 K> netisr_dispatch_src() at netisr_dispatch_src+0x3c0 K> netisr_dispatch() at netisr_dispatch+0x10 K> ether_ifattach() at ether_ifattach+0x2fa K> vtmmio_attach() at vtmmio_attach+0x490c K> vtmmio_attach() at vtmmio_attach+0x4624 K> vtmmio_attach() at vtmmio_attach+0x544a K> virtqueue_intr() at virtqueue_intr+0xc K> vtmmio_attach() at vtmmio_attach+0x2008 K> db_dump_intr_event() at db_dump_intr_event+0x730 K> fork_exit() at fork_exit+0x68 K> fork_trampoline() at fork_trampoline+0xa K> KDB: enter: panic K> [ thread pid 12 tid 100023 ] K> Stopped at kdb_enter+0x44: sd zero,0(a0) K> db> K> K> It seems pretty clear that the vtmmio path doesn’t enter epoch before it K> runs the vtnet_attach() code. K> On the other hand, I run vtnet CURRENT guests in bhyve, and don’t see this K> panic. In that case it lives on top of PCI rather than mmio, but I don’t K> see why/where that’d enter epoch. The transition from ether_ifattach to netisr_dispatch looks strange. Is that something run trough EVENTHANDLER_INVOKE? Can you please print in kgdb? > list *ether_ifattach+0x2fa -- Gleb Smirnoff