diff options
author | Matthew Ahrens <[email protected]> | 2017-04-14 12:52:43 -0700 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2017-06-30 11:11:01 -0700 |
commit | c6f6767eea2179689873efdad4929f73f7f2b10b (patch) | |
tree | e5c354f759bab04c2b86d08481511d88788fa84f /include/sys/dsl_userhold.h | |
parent | 817b1b6e7b6f9b8890a550c7c7efabdba41dd352 (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