Destroying a zvol: Thread overran stack, or stack corrupted

[vicksters]

Hello,

I am running 0.6.2 built from the 0.6.2-r3 gentoo ebuild.

I ran into an issue destroying a zvol used as a storage backend for a qemu VM. I issued the command and it seemed to be doing its thing at first, but then it got killed by the kernel. I had these messages in dmesg:

[77487.323302] PAX: please report this to [email protected]
[77487.323318] BUG: unable to handle kernel NULL pointer dereference
at (nil)
[77487.323347] IP: [] __wake_up_common+0x34/0xa0
[77487.323371] PGD 4e3eb8066
[77487.323379] Thread overran stack, or stack corrupted
[77487.323390] Oops: 0000 [#1] PREEMPT SMP
[77487.323404] Modules linked in: macvtap macvlan ipt_MASQUERADE
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_conntrack nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle
xt_tcpudp bridge stp llc ip6table_filter ip6_tables iptable_filter
ip_tables x_tables nfsd auth_rpcgss oid_registry nfs_acl ipv6 tun
kvm_amd kvm microcode mperf freq_table bnx2 ohci_pci processor
thermal_sys button xts gf128mul aes_x86_64 cbc libiscsi
scsi_transport_iscsi tg3 libphy ptp pps_core e1000 fuse zfs(PO)
zcommon(PO) znvpair(PO) zavl(PO) zunicode(PO) spl(O) nfs lockd sunrpc
jfs reiserfs btrfs zlib_deflate lzo_compress multipath linear raid10
raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq
async_tx raid1 raid0 dm_snapshot dm_crypt dm_mirror dm_region_hash
dm_log dm_mod hid_sunplus
[77487.323740] hid_sony led_class hid_samsung hid_pl hid_petalynx
hid_gyration sl811_hcd usbhid xhci_hcd ohci_hcd uhci_hcd usb_storage
ehci_pci ehci_hcd usbcore usb_common scsi_transport_fc scsi_tgt hpsa
cciss sg
[77487.323825] CPU: 7 PID: 8075 Comm: zfs Tainted: P O
3.11.7-hardened-r1 #5
[77487.323840] Hardware name: HP ProLiant DL585 G2 , BIOS A07 04/30/2010
[77487.323868] task: ffff880fa61ab2c0 ti: ffff880fa61ab728 task.ti:
ffff880fa61ab728
[77487.323897] RIP: 0010:[] []
__wake_up_common+0x34/0xa0
[77487.323932] RSP: 0018:ffff880dfc4b3c48 EFLAGS: 00010086
[77487.323959] RAX: 0000000000000000 RBX: ffff88101757d7d0 RCX: 0000000000000000
[77487.323986] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88101757d7d0
[77487.324013] RBP: ffff880dfc4b3c88 R08: 0000000000000000 R09: 0000000000000000
[77487.324041] R10: ffffffffffffffff R11: 0000000000000000 R12: ffff88101757d7d8
[77487.324069] R13: 8000000000000000 R14: ffff881022f78558 R15: 0000000000000003
[77487.324096] FS: 00000316398a4b80(0000) GS:ffff88107fae0000(0000)
knlGS:0000000000000000
[77487.324124] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[77487.324148] CR2: 0000000000000000 CR3: 0000000001578000 CR4: 00000000000006f0
[77487.324174] Stack:
[77487.324194] 0000000000000000 0000000000000000 ffff880dfc4b3c88
ffff88101757d7d0
[77487.324232] 0000000000000092 0000000000000000 ffff881022f78558
ffff88034728f500
[77487.324268] ffff880dfc4b3cc8 ffffffff8107a6be ffff881000000000
8000000000000003
[77487.324305] Call Trace:
[77487.324329] [] __wake_up+0x3e/0x60
[77487.324359] [] __blk_drain_queue+0x10b/0x140
[77487.324386] [] blk_cleanup_queue+0x81/0xf0
[77487.324438] [] zrl_is_locked+0xf7c/0x1a10 [zfs]
[77487.324471] [] zvol_remove_minor+0xa2/0x150 [zfs]
[77487.324507] [] zfs_unmount_snap+0x2e3/0x410 [zfs]
[77487.324540] [] ? zvol_fini+0x4550/0x2eaf5 [zfs]
[77487.324575] [] pool_status_check+0x193/0x2b0 [zfs]
[77487.324605] [] do_vfs_ioctl+0xaa/0x8a0
[77487.325852] [] SyS_ioctl+0x99/0xb0
[77487.325880] [] system_call_fastpath+0x18/0x1d
[77487.325909] [] ? pax_randomize_kstack+0x33/0x70
[77487.325934] Code: 41 56 41 55 49 bd 00 00 00 00 00 00 00 80 41 54
49 89 fc 53 48 83 ec 18 89 55 c8 89 4d cc 4c 89 45 c0 49 8b 44 24 08
49 83 c4 08 <4c> 8b 30 48 8d 78 e8 49 83 ee 18 49 39 c4 75 07 eb 3c 66
90 49
[77487.326151] RIP [] __wake_up_common+0x34/0xa0
[77487.326178] RSP
[77487.326206] CR2: 0000000000000000
[77487.326400] ---[ end trace 190b8d15a9227407 ]---
[77487.326446] note: zfs[8075] exited with preempt_count 2

My system was then left in a state where the zvol in question was unresponsive to any kind of command or manipulation. I had to reboot the machine to get it working again. It doesn't look like any data corruption occurred.

I managed to reproduce the issue. I realize that you may not have enough details to go on so please let me know what information you need.

Best regards,

Vicks~.

[behlendorf]

This issue was probably address by commit a168788 which was made post-0.6.2. There's just not enough in the above stack trace to say for certain.

[behlendorf]

Closing. All know stack overflow are believed to have been addressed.