Fix zvol_open() lock inversion

[behlendorf]

Motivation and Context

While investigating the cause of issue #12849 I was able to reproduce
this deadlock by running the rsend tests repeatedly. There's a decent
chance this explains the occasional hangs in the Ubuntu 20.04 CI.

Description

When restructuring the zvol_open() logic for the Linux 5.13 kernel
a lock inversion was accidentally introduced. In the updated code
the spa_namespace_lock is now taken before the zv_suspend_lock
allowing the following scenario to occur:

    down_read <=== waiting for zv_suspend_lock
    zvol_open <=== holds spa_namespace_lock
    __blkdev_get
    blkdev_get_by_dev
    blkdev_open
    ...

     mutex_lock <== waiting for spa_namespace_lock
     spa_open_common
     spa_open
     dsl_pool_hold
     dmu_objset_hold_flags
     dmu_objset_hold
     dsl_prop_get
     dsl_prop_get_integer
     zvol_create_minor
     dmu_recv_end
     zfs_ioc_recv_impl <=== holds zv_suspend_lock via zvol_suspend()
     zfs_ioc_recv
     ...

This commit resolves the issue by moving the acquisition of the
spa_namespace_lock back to after the zv_suspend_lock which restores
the original ordering.

Additionally, as part of this change the error exit paths were
simplified where possible.

NOTE: The Linux code was modeled after the current FreeBSD code
which which is why I wasn't concerned with changing the ordering.
It sure looks to me like it is possible to hit this on FreeBSD, but I've
seen no reports of it happening. Someone more familiar with FreeBSD
should take a close look at the deadlock to see if it is possible.

How Has This Been Tested?

Locally by running the rsend tests in a loop. As expected after
correcting the lock ordering no deadlock have been observed.
Pending full results from the CI testing.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[behlendorf]

From the test results this did resolve the deadlock. The other failures here are unrelated. That said, I'm going to run it through the GitHub actions builders again just to be sure.

[ghost]

I am thinking whether it would make sense to apply similar changes to the FreeBSD zvol open code, or is the locking only different on Linux for some reason?

[behlendorf]

From my reading of the code I don't see why this couldn't occur on FreeBSD as well. That said, it's been this way in the OpenZFS FreeBSD platform code since it was added so if it can happen it's thankfully very unlikely. I think it would be a good idea to make the same logical change on the FreeBSD side. I just didn't want to tackle that in this PR since it was addressing a regression introduced by a prior Linux specific commit.

On Linux I was able to hit this eventually by running the rsend test group in a loop since it includes tests which send/recv volumes. You might be able to make it more likely to hit by adding a delay for testing.

[numinit]

Could this happen on 2.1.2? I've seen these failures on a raw recv on both 2.0.x and 2.1.x:

https://www.reddit.com/r/zfs/comments/rkuf7i/comment/hpcj7v9/