Fix double mutex_init bug in send code #10374
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Ah neat - I was set to drill down further to try to figure out where it goes wrong, but a PR is even better :) |
lundman
approved these changes
May 27, 2020
Codecov Report
@@ Coverage Diff @@
## master #10374 +/- ##
==========================================
+ Coverage 79.30% 79.53% +0.23%
==========================================
Files 391 391
Lines 123603 123604 +1
==========================================
+ Hits 98018 98305 +287
+ Misses 25585 25299 -286
Continue to review full report at Codecov.
|
behlendorf
approved these changes
May 27, 2020
behlendorf
added
Status: Accepted
|
Looks good, would you just mind fixing the style warning and rebasing this on master. |
|
@pcd1193182 I've love to get this merged if you can just address style issue and rebase. |
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
as-com
pushed a commit
to as-com/zfs
that referenced
this pull request
Jun 20, 2020
It was possible to cause a kernel panic in the send code by initializing an already-initialized mutex, if a record was created with type DATA, destroyed with a different type (bypassing the mutex_destroy call) and then re-allocated as a DATA record again. We tweak the logic to not change the type of a record once it has been created, avoiding the issue. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Jorgen Lundman <lundman@lundman.net> Signed-off-by: Paul Dagnelie <pcd@delphix.com> Closes openzfs#10374 (cherry picked from commit 99b281f)
jsai20
pushed a commit
to jsai20/zfs
that referenced
this pull request
Mar 30, 2021
It was possible to cause a kernel panic in the send code by initializing an already-initialized mutex, if a record was created with type DATA, destroyed with a different type (bypassing the mutex_destroy call) and then re-allocated as a DATA record again. We tweak the logic to not change the type of a record once it has been created, avoiding the issue. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Jorgen Lundman <lundman@lundman.net> Signed-off-by: Paul Dagnelie <pcd@delphix.com> Closes openzfs#10374
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Paul Dagnelie pcd@delphix.com
Motivation and Context
It was possible to cause a kernel panic in the send code by initializing an already-initialized mutex, if a record was created with type DATA, destroyed with a different type (bypassing the mutex_destroy call) and then re-allocated as a DATA record again.
Description
We tweak the logic to not change the type of a record once it has been created, avoiding the issue.
How Has This Been Tested?
Passes zfs test suite
Types of changes
Checklist:
Signed-off-by.