dmu_redact.c does not call bqueue_destroy

[lundman]

Signed-off-by: Jorgen Lundman [email protected]

Ensure all calls to bqueue_init() has a corresponding call to bqueue_destroy().

Sorry about the new PR, after deforking there was no way to make the old PR see new commits.

Motivation and Context

Leaking resources, avoiding panics.

Description

Weirdest fluke of things here, the bqueue structure would not call bqueue_destroy() which means the mutex members inside are never mutex_destroy()ed either. Memory is freed and later on re-used, in my case, but entirely unrelated memory, however, by chance the new memory use happened to have a mutex in the same offset, and would then panic due to mutex already initialised.

I had to guess a bit on the locations of the bqueue_destroy() calls, so hopefully I got it right.

How Has This Been Tested?

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.

[lundman]

Ah sorry, when I used your suggestion in GH, it added a commit without Signed-off-by. Totally missed it :)

[behlendorf]

@pcd1193182 would you mind reviewing this small change.