summaryrefslogtreecommitdiffstats
path: root/include/sys/dsl_userhold.h
diff options
context:
space:
mode:
authorMatthew Ahrens <[email protected]>2017-04-14 12:52:43 -0700
committerBrian Behlendorf <[email protected]>2017-06-30 11:11:01 -0700
commitc6f6767eea2179689873efdad4929f73f7f2b10b (patch)
treee5c354f759bab04c2b86d08481511d88788fa84f /include/sys/dsl_userhold.h
parent817b1b6e7b6f9b8890a550c7c7efabdba41dd352 (diff)
OpenZFS 8377 - Panic in bookmark deletion
Authored by: Matthew Ahrens <[email protected]> Reviewed by: Paul Dagnelie <[email protected]> Reviewed by: Pavel Zakharov <[email protected]> Reviewed by: George Wilson <[email protected]> Approved by: Robert Mustacchi <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: George Melikov <[email protected]> Ported-by: Giuseppe Di Natale <[email protected]> The problem is that when dsl_bookmark_destroy_check() is executed from open context (the pre-check), it fills in dbda_success based on the existence of the bookmark. But the bookmark (or containing filesystem as in this case) can be destroyed before we get to syncing context. When we re-run dsl_bookmark_destroy_check() in syncing context, it will not add the deleted bookmark to dbda_success, intending for dsl_bookmark_destroy_sync() to not process it. But because the bookmark is still in dbda_success from the open-context call, we do try to destroy it. The fix is that dsl_bookmark_destroy_check() should not modify dbda_success when called from open context. OpenZFS-issue: https://www.illumos.org/issues/8377 OpenZFS-commit: https://github.com/openzfs/openzfs/commit/b0b6fe3 Closes #6286
Diffstat (limited to 'include/sys/dsl_userhold.h')
0 files changed, 0 insertions, 0 deletions