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
Use feature probes to detect kernel support for sockops #10941
Use feature probes to detect kernel support for sockops #10941
Conversation
This comment has been minimized.
This comment has been minimized.
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.
Thanks @soumynathan for taking care of this!
d29d73d
to
d5f3543
Compare
d5f3543
to
175f622
Compare
175f622
to
18085c1
Compare
test-me-please |
18085c1
to
cea62ad
Compare
4d16f3b
to
165d149
Compare
165d149
to
1c0d98c
Compare
1c0d98c
to
315ab0a
Compare
@soumynathan it seems a real failure:
|
daemon/cmd/daemon_main.go
Outdated
if option.Config.SockopsEnable { | ||
if h := probes.NewProbeManager().GetHelpers("sk_msg"); h != nil { | ||
if _, ok := h["bpf_msg_redirect_hash"]; ok { | ||
return 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.
The return nil
here might be the cause for the build error. Simply return
should work?
Note: Instead of having all the code of that function if the if option.Config.SockopsEnable
block, you could also return early if the option is not set and avoid indenting all the rest:
if !option.Config.SockopsEnable {
return
}
if h := probes.NewProbeManager()...
It usually makes the code a bit easier to read, I find.
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.
@qmonnet The probe still needs to be fixed anyway ;-)
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.
ok will fix it. @pchaigno is the probe fix that you mentioned above related to this patch or we need to handle it in a different PR>
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.
Related to this patch. Please see #10941 (comment) and #10941 (comment).
This patch probes the kernel for bpf sockops support and validates the user configuration for SockopsEnable. Fixes: cilium#10931 Signed-off-by: Swaminathan Vasudevan <svasudevan@suse.com>
315ab0a
to
57c625b
Compare
test-me-please |
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.
Thanks @soumynathan! LGTM!
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.
Looks good, thanks
k := probes.NewProbeManager().GetHelpers("sock_ops") | ||
h := probes.NewProbeManager().GetHelpers("sk_msg") |
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.
k := probes.NewProbeManager().GetHelpers("sock_ops") | |
h := probes.NewProbeManager().GetHelpers("sk_msg") | |
pm := probes.NewProbeManager() | |
k := pm.GetHelpers("sock_ops") | |
h := pm.GetHelpers("sk_msg") |
Not an issue because probe results are cached, but suggestion for next time: don't create more probe managers than necessary :)
This patch probes the kernel for bpf sockops support and validates
the user configuration for SockopsEnable.
Fixes: #10931
Signed-off-by: Swaminathan Vasudevan svasudevan@suse.com