Null pointer dereference when writing then destroying a ZVOL

[dechamps]

Using latest master, there seems to be a race condition when destroying a ZVOL just after writing to it. With a bit of luck, it can sometimes be reproduced using the following commands in quick succession:

# zfs create -V 1g homez/test
# dd if=/dev/zero of=/dev/zvol/homez/test bs=1048576 count=100
# zfs destroy homez/test

The result:

BUG: unable to handle kernel NULL pointer dereference at 00000000000001d6
IP: [<ffffffff8115b5d0>] __blkdev_get+0x50/0x470
PGD 3a1d08067 PUD 23ebda067 PMD 0 
Oops: 0000 [#4] SMP 
CPU 0 
Modules linked in: zfs(P) zcommon(P) znvpair(P) zavl(P) zunicode(P) spl(O) [last unloaded: zfs]

Pid: 21183, comm: zvol_id Tainted: P      D    O 3.2.18-leclercng-std-ipv6-64 #2 Supermicro X8ST3/X8ST3
RIP: 0010:[<ffffffff8115b5d0>]  [<ffffffff8115b5d0>] __blkdev_get+0x50/0x470
RSP: 0018:ffff88030ebb1bb8  EFLAGS: 00010282
RAX: ffffffffffffff86 RBX: ffff88040ecb7b00 RCX: ffff8803fe2dbc80
RDX: ffffffffffffff86 RSI: ffff88030ebb1bd4 RDI: ffffffffa0227620
RBP: ffff88030ebb1c08 R08: ffff88030ebb1c64 R09: ffff88040f00e320
R10: ffff88030ebb1d04 R11: ffff88030ebb1d60 R12: ffffffffffffff86
R13: 0000000000000000 R14: ffff88040ecb7b18 R15: ffffffff8115bd20
FS:  00007f0be824f740(0000) GS:ffff88041fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000001d6 CR3: 000000014b2d2000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process zvol_id (pid: 21183, threadinfo ffff88030ebb0000, task ffff8802f2c2ed70)
Stack:
 ffff88030ebb1c64 0000001d00000000 ffff88030ebb1c48 000000000f010c00
 0000000000000000 ffff88040ecb7b00 0000000000000000 ffff88033d9d3100
 ffff8803c2054a30 ffffffff8115bd20 ffff88030ebb1c98 ffffffff8115ba3f
Call Trace:
 [<ffffffff8115bd20>] ? blkdev_get+0x330/0x330
 [<ffffffff8115ba3f>] blkdev_get+0x4f/0x330
 [<ffffffff8115bd20>] ? blkdev_get+0x330/0x330
 [<ffffffff8115ab80>] ? bdget+0x40/0x130
 [<ffffffff8115bd20>] ? blkdev_get+0x330/0x330
 [<ffffffff8115bd7d>] blkdev_open+0x5d/0x80
 [<ffffffff81129932>] __dentry_open+0x202/0x310
 [<ffffffff811365ee>] ? inode_permission+0x2e/0xe0
 [<ffffffff81129b41>] nameidata_to_filp+0x71/0x80
 [<ffffffff81139a6b>] do_last+0x1cb/0x7e0
 [<ffffffff8113a150>] path_openat+0xd0/0x3e0
 [<ffffffff81137c75>] ? user_path_at_empty+0x65/0xa0
 [<ffffffff8113a574>] do_filp_open+0x44/0xa0
 [<ffffffff811451bb>] ? alloc_fd+0x4b/0x140
 [<ffffffff811294d2>] do_sys_open+0x102/0x1e0
 [<ffffffff811295db>] sys_open+0x1b/0x20
 [<ffffffff81ae8d3b>] system_call_fastpath+0x16/0x1b
Code: c8 02 f6 45 bc 02 0f 45 f0 85 d2 75 0f 48 8b 7f 08 8b 57 44 85 d2 0f 85 fe 03 00 00 4c 8d 73 18 e9 d3 00 00 00 66 0f 1f 44 00 00 <48> 8b 80 50 02 00 00 4c 89 e7 4c 8b 78 58 e8 4d 09 3e 00 4c 89 
RIP  [<ffffffff8115b5d0>] __blkdev_get+0x50/0x470
 RSP <ffff88030ebb1bb8>
CR2: 00000000000001d6
---[ end trace 2f6e1bea6b9d225e ]---

Fortunately, the system seems to continue working just fine after this despite the null pointer dereference bug.

[behlendorf]

This looks like another race with udev we'll need to resolve.