Null pointer dereference on zfs 0.6.4.1-2 and Debian 8 #3678
Labels
Component: ZVOL
ZFS Volumes
Milestone
Comments
|
Update: this may have something to do with trying to write to a zvol that is marked read only. ssh otherserver "zfs send -v tank/fish@snap" | zfs recv -Fduv tank The last zfs recv hangs in D state and dmesg shows the Null Pointer Dereference error. It may also depend on the size of the zvol. |
|
Yes, it definitely does sound like there some kind of race here but after a brief inspection it's not obvious. Clearly one of these fields was NULL, but an offset of 0x50 doesn't make sense for any of the members. We'll need to dig deeper. |
|
It's somewhere that is running all the time though, since once that happens (the error message), zvols cannot be created, destroyed or opened. That is, if a process (virtual machine in my case) was accessing a zvol it continues to be able to access it, but starting new VMs, stopping VMs or even running dd to/from a zvol gets stuck in D state. This continues until I hard reboot the server (running reboot from CLI gets stuck). Creating/destroying regular datasets work normally as far as I noticed. |
|
This happens also on zfs 0.6.5.1-4. stack dump of a stuck "zfs create -V 1G home/test/testzvol" process |
|
@behlendorf The 0x50 is in |
|
I got a different error message this time: This may or may not (I was not able to reproduce it at will, so it may be a coincidence) have something to do with creating a snapshot of a zvol, dd'ing it to a remote server and then creating a new zvol. |
|
Hello, Here's proposed patch: |
|
Hi, I think I've got the exact same backtraces four times when exporting my pool (simply 'zpool export pool'). Maybe it'll help that it occurred during export. My versions: |
nedbass
pushed a commit
that referenced
this issue
Mar 23, 2016
zfsonlinux issue #2217 - zvol minor operations: check snapdev property before traversing snapshots of a dataset zfsonlinux issue #3681 - lock order inversion between zvol_open() and dsl_pool_sync()...zvol_rename_minors() Create a per-pool zvol taskq for asynchronous zvol tasks. There are a few key design decisions to be aware of. * Each taskq must be single threaded to ensure tasks are always processed in the order in which they were dispatched. * There is a taskq per-pool in order to keep the pools independent. This way if one pool is suspended it will not impact another. * The preferred location to dispatch a zvol minor task is a sync task. In this context there is easy access to the spa_t and minimal error handling is required because the sync task must succeed. Support for asynchronous zvol minor operations address issue #3681. Signed-off-by: Boris Protopopov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #2217 Closes #3678 Closes #3681
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, I saw that the system in my previous issue was not the latest version, so I updated, now I got this:
The pool has a single raidz1 vdev with 3 SSDs.
modinfo zfs | grep version
modinfo spl | grep version
cat /etc/debian_version
The text was updated successfully, but these errors were encountered: