- Notifications
You must be signed in to change notification settings - Fork1.8k
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Always perform bounds-checking in metaslab_free_concrete#17136
base:master
Are you sure you want to change the base?
Conversation
The vd->vdev_ms access can overflow due to on-disk corruption, not justdue to programming bugs. So it makes sense to check its boundaries evenin production builds.Sponsored by:ConnectWiseSigned-off-by:Alan Somers <asomers@gmail.com>
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
Signed-off-by:Alan Somersasomers@gmail.com
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.