[Bug 296637] zfs create -V <bla> -o volmode=dev panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296637

            Bug ID: 296637
           Summary: zfs create -V <bla> -o volmode=dev panic
           Product: Base System
           Version: 15.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: [email protected]
          Reporter: [email protected]

I have been playing around with vm-bhyve, and managed to panic my 15.1p1 host a
handful of times in an hour:

    Fatal trap 12: page fault while in kernel mode
    cpuid = 43; apic id = 39
    fault virtual address   = 0x50
    fault code              = supervisor read data, page not present
    instruction pointer     = 0x20:0xffffffff825c449f
    stack pointer           = 0x28:0xfffffe0167208d10
    frame pointer           = 0x28:0xfffffe0167208d50
    code segment            = base 0x0, limit 0xfffff, type 0x1b
                            = DPL 0, pres 1, long 1, def32 0, gran 1
    processor eflags        = interrupt enabled, resume, IOPL = 0
    current process         = 13 (g_event)
    rdi: 0000000000000000 rsi: fffff8010a710780 rdx: fffff8010471b780
    rcx: 0000000000000080  r8: 0000000000000000  r9: 0000000000000fff
    rax: 0000000000000000 rbx: fffff801058cf690 rbp: fffffe0167208d50
    r10: 0000000000000000 r11: 0000000000000000 r12: fffff80105785100
    r13: 0000000000000000 r14: 0000000000000001 r15: fffff801058cf400
    trap number             = 12
    panic: page fault
    cpuid = 43
    time = 1783592574
    KDB: stack backtrace:
    #0 0xffffffff80bd678d at kdb_backtrace+0x5d
    #1 0xffffffff80b872f6 at vpanic+0x136
    #2 0xffffffff80b871b3 at panic+0x43
    #3 0xffffffff81098fcd at trap_pfault+0x37d
    #4 0xffffffff8106f188 at calltrap+0x8
    #5 0xffffffff80abfc37 at g_access+0x1b7
    #6 0xffffffff80ac1e39 at g_label_taste+0x119
    #7 0xffffffff80ac046a at g_new_provider_event+0x8a
    #8 0xffffffff80abb67e at g_run_events+0x11e
    #9 0xffffffff80b3d74b at fork_exit+0x7b
    #10 0xffffffff810701ae at fork_trampoline+0xe


vm-bhyve does (in vm-zfs):

    zfs create ${_opt} ${_size} -o volmode=dev ${_user_opts} "${_name}"

I have not been able to provoke the panic after I removed the '-o volmode=dev'
argument.

As far as I can tell, the zvol is created, geom testing commences, then
zfs_ioc_create applies the volmode=dev property, and that yanks something out
from under the feet of the ongoing tasting.

It may only be this one property which is a problem, but overall, it would be
much better and more efficient to only offer the zvol to GEOM after
zfs_ioc_create() has applied all the properties, rather than go through the
vdev_geom_attrchanged() song&dance needlessly.

-- 
You are receiving this mail because:
You are the assignee for the bug.