-
Notifications
You must be signed in to change notification settings - Fork 550
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
rbd: prevent calling rbdVolume.Destroy() after an error #4564
base: devel
Are you sure you want to change the base?
Conversation
It seems possible that the .Destroy() function is called on a nil pointer. This would cause a panic in the node-plugin. Depending on how far GenVolFromVolID() comes, the returned rbdVolume can be connected. If an error occurs, the rbdVolume should not be connected at all, so call the .Destroy() function in those cases too. Fixes: ceph#4562 Signed-off-by: Niels de Vos <[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.
@nixpanic sadly we dont have any CI for RDR workflow, we need to test this code manually to ensure nothing breaks
defer func() { | ||
if err != nil { | ||
vol.Destroy() | ||
} | ||
}() |
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.
in case of err the volume is already destroyed above, do we need to destroy it again? if yes , can you please add check check for vol !=nil
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.
generateVolumeFromVolumeID()
should now only return a connected volume if no error occurred. But it is possible that this function itself detects an error below. In that case, the .Destroy()
function should be called too.
Destroying a volume that is already destroyed is fine, extra checks for that just make the code more complex.
if vol != nil { | ||
vol.Destroy() | ||
} |
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.
when will we hit this one? In case of error we are already doing the Destory and in case of non-nil error case the vol is returned at line 1197
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.
It is not clear to me if this can be hit, better destroy something that could have been at line 1194.
If the vol
was connected, and generateVolumeFromMapping()
overwrites that variable, the 1st vol
would leak and no .Destroy()
would be done on it.
/test ci/centos/mini-e2e-helm/k8s-1.29 |
Failed with a panic:
|
It seems possible that the .Destroy() function is called on a nil
pointer. This would cause a panic in the node-plugin.
Depending on how far GenVolFromVolID() comes, the returned rbdVolume can
be connected. If an error occurs, the rbdVolume should not be connected
at all, so call the .Destroy() function in those cases too.
Fixes: #4562