Re: panic: No vop_need_inactive

From: Mateusz Guzik <mjguzik_at_gmail.com>
Date: Sun, 1 Sep 2019 15:19:25 +0200
This is fixed in https://svnweb.freebsd.org/base?view=revision&revision=351642

On 9/1/19, Guido Falsi <madpilot_at_freebsd.org> 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.
>
>
> 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
>
>
> Anyone can help?
>
>
> --
> Guido Falsi <madpilot_at_freebsd.org>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>


-- 
Mateusz Guzik <mjguzik gmail.com>
Received on Sun Sep 01 2019 - 11:19:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC