Bug 193949 - [zfs] panic on zvol resize
Summary: [zfs] panic on zvol resize
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-26 14:24 UTC by Christer
Modified: 2015-03-15 15:15 UTC (History)
3 users (show)

See Also:


Attachments
Panic summary (127.88 KB, text/plain)
2014-09-26 14:24 UTC, Christer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christer 2014-09-26 14:24:22 UTC
Created attachment 147693 [details]
Panic summary

+++ This bug was initially created as a clone of Bug #192085 +++

On current r268263 with WITNESS and INVARIANTS enabled, do:

# zfs create tank/zvol
# zfs set mountpoint=none tank/zvol
# zfs create -V100G tank/zvol/disk0
# zfs set volsize=200G tank/zvol/disk0

This panics as follows:
panic: solaris assert: !rrw_held(&dp->dp_config_rwlock, RW_READER), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c, line: 1120
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01217d54b0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe01217d5560
vpanic() at vpanic+0x126/frame 0xfffffe01217d55a0
panic() at panic+0x43/frame 0xfffffe01217d5600
assfail() at assfail+0x1d/frame 0xfffffe01217d5610
dsl_pool_hold() at dsl_pool_hold+0x67/frame 0xfffffe01217d5650
dmu_objset_hold() at dmu_objset_hold+0x21/frame 0xfffffe01217d5690
dsl_prop_get_integer() at dsl_prop_get_integer+0x28/frame 0xfffffe01217d56d0
zvol_set_volsize() at zvol_set_volsize+0x126/frame 0xfffffe01217d5760
zfs_prop_set_special() at zfs_prop_set_special+0x2e2/frame 0xfffffe01217d57f0
zfs_set_prop_nvlist() at zfs_set_prop_nvlist+0x23f/frame 0xfffffe01217d5880
zfs_ioc_set_prop() at zfs_ioc_set_prop+0x106/frame 0xfffffe01217d58e0
zfsdev_ioctl() at zfsdev_ioctl+0x6ee/frame 0xfffffe01217d5990
devfs_ioctl_f() at devfs_ioctl_f+0xfb/frame 0xfffffe01217d59f0
kern_ioctl() at kern_ioctl+0x22b/frame 0xfffffe01217d5a50
sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe01217d5aa0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe01217d5bb0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe01217d5bb0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019e89ba, rsp = 0x7fffffffb8c8, rbp = 0x7fffffffb940 ---


Additional information to the clone:

The following is run to cause the panic on an existing pool with default options
$ zfs create -V 81920 storage/vol
$ zfs set volsize=163840 storage/vol

Dump summary attached.

Source: bb5379e9a2f748abed4de69c61b20523c4d77ac7 from the stable/10 branch.
Comment 1 Marcus von Appen freebsd_committer freebsd_triage 2015-02-18 11:54:22 UTC
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Comment 2 Steven Hartland freebsd_committer freebsd_triage 2015-03-15 11:23:16 UTC
(In reply to Marcus von Appen from comment #1)
Please confirm your running stable/10 after r277483
Comment 3 Kristof Provost freebsd_committer freebsd_triage 2015-03-15 15:15:48 UTC
I've been unable to reproduce this on a stable/10 from February 10th, so yes, this looks like it's fixed.