panic: No vop_need_inactive

[Evilham]

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