From owner-freebsd-fs@freebsd.org Sun Sep 1 13:30:49 2019 Return-Path: Delivered-To: freebsd-fs@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 92E47DA426 for ; Sun, 1 Sep 2019 13:30:49 +0000 (UTC) (envelope-from contact@evilham.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46LvHF1lzXz4K2t for ; Sun, 1 Sep 2019 13:30:49 +0000 (UTC) (envelope-from contact@evilham.com) Received: by mailman.nyi.freebsd.org (Postfix) id 38858DA425; Sun, 1 Sep 2019 13:30:49 +0000 (UTC) Delivered-To: fs@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 3835EDA423; Sun, 1 Sep 2019 13:30:49 +0000 (UTC) (envelope-from contact@evilham.com) Received: from yggdrasil.evilham.com (yggdrasil.evilham.com [IPv6:2a02:2770::216:3eff:fee1:cf9]) (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 46LvH91n0rz4K2g; Sun, 1 Sep 2019 13:30:44 +0000 (UTC) (envelope-from contact@evilham.com) Received: from yggdrasil.evilham.com (unknown [IPv6:2a0a:e5c1:121:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by yggdrasil.evilham.com (Postfix) with ESMTPSA id 46Lv8t2Cjpz3wpY; Sun, 1 Sep 2019 15:25:18 +0200 (CEST) From: Evilham To: Guido Falsi Cc: current@freebsd.org, fs@FreeBSD.org Subject: Re: panic: No vop_need_inactive References: <6d695bc6-37e3-e068-6620-dcd5616b2a5c@FreeBSD.org> In-reply-to: <6d695bc6-37e3-e068-6620-dcd5616b2a5c@FreeBSD.org> Date: Sun, 01 Sep 2019 15:25:14 +0200 Message-ID: <889667e1-9610-46c0-bd23-3e034f835d7f@yggdrasil.evilham.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Rspamd-Queue-Id: 46LvH91n0rz4K2g X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=evilham.com; spf=pass (mx1.freebsd.org: domain of contact@evilham.com designates 2a02:2770::216:3eff:fee1:cf9 as permitted sender) smtp.mailfrom=contact@evilham.com X-Spamd-Result: default: False [-5.43 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.66)[ipnet: 2a02:2770::/32(-4.69), asn: 196752(-3.64), country: NL(0.01)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; DMARC_POLICY_ALLOW(-0.50)[evilham.com,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:196752, ipnet:2a02:2770::/32, country:NL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 13:30:49 -0000 On dg., set. 01 2019, Guido Falsi wrote: > Hi, > > I'm experiencing a recurring panic I can trigger repeatably. > > The machine is: > > FreeBSD 13.0-CURRENT r351604 amd64 > > The panic looks ZFS related. This machine performs mainly > poudriere > builds. I also use portshaker to manage the ports tree. > > Portshaker works by downloading ports trees and overlays in > zfses, then > snapshots them, clones them placing the clones in the poudriere > namespace, then modifies the ports there applying the required > overlays. > > This happens to me any time I run poudriere and after the build > I run > portshaker to update the ports trees, when it tries to remove > the > snapshot of the freebsd base tree (which AFAIK is the base for > the clone > where poudriere works). > > I'm going to try to create a more clear and detailed use case, > removing > from the equation complex programs like poudriere and > portshaker. > Interesting! I was going to send a similar email a few hours ago to the current ML but decided to debug some more before that. I use poudriere to manage my ports tree with svn, I do use ZFS. I can trigger the panic by running poudriere bulk on e.g. finance/gnucash. Some more info that may be related: - This worked fine on a build from the 2nd week of August, after r350551 (a fix for AMD Ryzen laptops). - Since that build had an issue with bhyve (as mentioned on this list a few days ago), I upgraded last week which started triggering this issue with poudriere - It still happens with: # uname -v FreeBSD 13.0-CURRENT r351654+209e505321db-c262365(master) GENERIC Which is posterior to r351642 that was mentioned by Mateusz. > Here is the panic message: > > VNASSERT failed > 0xfffff800abfcbd20: tag zfs, type VDIR > usecount 0, writecount 0, refcount 1 mountedhere 0 > flags (VI_ACTIVE) > VI_LOCKed lock type zfs: UNLOCKED > name = portshaker-2019-09-01:11:04:20 > parent_id = 2 > id = 269 > panic: No vop_need_inactive(0xfffff800abfcbd20, > 0xfffffe00ba39b3f0) > cpuid = 2 > time = 1567342436 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00ba39b310 > vpanic() at vpanic+0x19d/frame 0xfffffe00ba39b360 > panic() at panic+0x43/frame 0xfffffe00ba39b3c0 > VOP_NEED_INACTIVE_APV() at VOP_NEED_INACTIVE_APV+0x8f/frame > 0xfffffe00ba39b3e0 > vputx() at vputx+0x1ae/frame 0xfffffe00ba39b440 > vfs_mount_destroy() at vfs_mount_destroy+0x14f/frame > 0xfffffe00ba39b470 > dounmount() at dounmount+0x7e8/frame 0xfffffe00ba39b4d0 > zfs_unmount_snap() at zfs_unmount_snap+0xbb/frame > 0xfffffe00ba39b4f0 > zfs_ioc_destroy_snaps() at zfs_ioc_destroy_snaps+0xb3/frame > 0xfffffe00ba39b540 > zfsdev_ioctl() at zfsdev_ioctl+0x54c/frame 0xfffffe00ba39b5e0 > devfs_ioctl() at devfs_ioctl+0xc9/frame 0xfffffe00ba39b630 > vn_ioctl() at vn_ioctl+0x13d/frame 0xfffffe00ba39b740 > devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfffffe00ba39b760 > kern_ioctl() at kern_ioctl+0x1e4/frame 0xfffffe00ba39b7c0 > sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe00ba39b890 > amd64_syscall() at amd64_syscall+0x284/frame 0xfffffe00ba39b9b0 > fast_syscall_common() at fast_syscall_common+0x101/frame > 0xfffffe00ba39b9b0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80049f2da, > rsp = > 0x7fffffffc948, rbp = 0x7fffffffc9c0 --- > KDB: enter: panic > FWIW: I am not 100% sure I it's the same panic, I am missing a cable ATM to get a full dump, but I do think they sound very similar. -- Evilham