-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Always perform bounds-checking in metaslab_free_concrete #17136
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
Conversation
The vd->vdev_ms access can overflow due to on-disk corruption, not just due to programming bugs. So it makes sense to check its boundaries even in production builds. Sponsored by: ConnectWise Signed-off-by: Alan Somers <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no objections, but wonder if this is the earliest place we can catch the corruption.
This slightly echoes with #17094. |
I hope there's a better place to catch it. I plan to keep working on the problem. But in the meantime I think this change is correct. Maybe after #17094 there will be a better way to handle it. |
The vd->vdev_ms access can overflow due to on-disk corruption, not just due to programming bugs. So it makes sense to check its boundaries even in production builds. Sponsored by: ConnectWise Reviewed by: Alek Pinchuk <[email protected]> Reviewed-by: Tony Hutter <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Alan Somers <[email protected]> Closes openzfs#17136
The vd->vdev_ms access can overflow due to on-disk corruption, not just due to programming bugs. So it makes sense to check its boundaries even in production builds. Sponsored by: ConnectWise Reviewed by: Alek Pinchuk <[email protected]> Reviewed-by: Tony Hutter <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Alan Somers <[email protected]> Closes openzfs#17136
The vd->vdev_ms access can overflow due to on-disk corruption, not just due to programming bugs. So it makes sense to check its boundaries even in production builds. Sponsored by: ConnectWise Reviewed by: Alek Pinchuk <[email protected]> Reviewed-by: Tony Hutter <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Alan Somers <[email protected]> Closes openzfs#17136
The vd->vdev_ms access can overflow due to on-disk corruption, not just due to programming bugs. So it makes sense to check its boundaries even in production builds. Sponsored by: ConnectWise Reviewed by: Alek Pinchuk <[email protected]> Reviewed-by: Tony Hutter <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Alan Somers <[email protected]> Closes openzfs#17136
The vd->vdev_ms access can overflow due to on-disk corruption, not just due to programming bugs. So it makes sense to check its boundaries even in production builds.
Sponsored by: ConnectWise
Signed-off-by: Alan Somers [email protected]
Motivation and Context
Prevents an out-of-bounds memory access due to on-disk corruption. The out of bounds access usually results in a page fault, but its effects are unpredictable. Better to cleanly panic instead. The original corruption was probably caused by the same underlying cause as #16626, combined with inadequate sanity checking of the block pointers.
Description
Changes in existing ASSERT into a VERIFY
How Has This Been Tested?
Ran the ZFS test suite on FreeBSD
Types of changes
Checklist:
Signed-off-by
.