Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix zpool on zvol deadlock #1220

Closed
wants to merge 1 commit into from
Closed

Conversation

maxximino
Copy link
Contributor

Commit 65d5608 fixes the lock inversion
between spa_namespace_lock and bdev->bd_mutex but only for the first
user of spa_namespace_lock: dmu_objset_own. Later spa_namespace_lock
gets acquired by dsl_prop_get_integer
(dsl_prop_get->dsl_dataset_hold->dsl_dir_open_spa->spa_open->spa_open_common)
without this "protection". By moving the mutex release after this
second use, even this acquisition of the lock is "protected" by the
ERESTARTSYS trick.

zfs create mypool/internalpool -V 40G; zpool create intpool /dev/mypool/internalpool
was consistently failing for me, and now is consistently working.

Commit 65d5608 fixes the lock inversion
between spa_namespace_lock and bdev->bd_mutex but only for the first
user of spa_namespace_lock: dmu_objset_own.  Later spa_namespace_lock
gets acquired by dsl_prop_get_integer
(dsl_prop_get->dsl_dataset_hold->dsl_dir_open_spa->spa_open->spa_open_common)
without this "protection".  By moving the mutex release after this
second use, even this acquisition of the lock is "protected" by the
ERESTARTSYS trick.

Author: Massimo Maggi <[email protected]>
@behlendorf
Copy link
Contributor

@maxximino Thank you, looks good.

babf3f9 Fix zpool on zvol deadlock

unya pushed a commit to unya/zfs that referenced this pull request Dec 13, 2013
Commit 65d5608 fixes the lock
inversion between spa_namespace_lock and bdev->bd_mutex but only
for the first user of spa_namespace_lock: dmu_objset_own().
Later spa_namespace_lock gets acquired by dsl_prop_get_integer()
though dsl_prop_get()->dsl_dataset_hold()->dsl_dir_open_spa()->
spa_open()->spa_open_common() without this "protection".  By
moving the mutex release after this second use, even this
acquisition of the lock is "protected" by the ERESTARTSYS trick.

Signed-off-by: Massimo Maggi <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes openzfs#1220
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants