Skip to content
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

Don't cleanup prematurely #619

Merged
merged 3 commits into from
Feb 13, 2024
Merged

Don't cleanup prematurely #619

merged 3 commits into from
Feb 13, 2024

Conversation

grcevski
Copy link
Contributor

Fixing number of places where we used the unsafe delete after use pattern.

@codecov-commenter
Copy link

codecov-commenter commented Feb 12, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (e263f8e) 79.41% compared to head (0e52151) 44.57%.

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #619       +/-   ##
===========================================
- Coverage   79.41%   44.57%   -34.84%     
===========================================
  Files          70       68        -2     
  Lines        5989     5817      -172     
===========================================
- Hits         4756     2593     -2163     
- Misses       1005     3071     +2066     
+ Partials      228      153       -75     
Flag Coverage Δ
integration-test ?
unittests 44.57% <ø> (-0.04%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -13,15 +13,15 @@ char __license[] SEC("license") = "Dual MIT/GPL";

// Temporary tracking of accept arguments
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__uint(type, BPF_MAP_TYPE_LRU_HASH);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed some of these because kretprobes may not fire, so we can't be sure we'll clean-up these maps.

@@ -550,6 +553,7 @@ int uprobe_hpack_Encoder_WriteField(struct pt_regs *ctx) {

if (val_len <= 0) {
bpf_dbg_printk("Encoded traceparent value too large or empty");
bpf_map_delete_elem(&ongoing_grpc_header_writes, &goroutine_addr);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was simply missed cleanup

@@ -203,7 +203,7 @@ int uprobe_WriteHeader(struct pt_regs *ctx) {

#ifndef NO_HEADER_PROPAGATION
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__uint(type, BPF_MAP_TYPE_LRU_HASH);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No guaratee this will be cleaned up, making an LRU.

@@ -379,6 +380,8 @@ int uprobe_writeSubset(struct pt_regs *ctx) {
bpf_probe_write_user((void *)(io_writer_addr + io_writer_n_pos), &len, sizeof(len));
}

done:
bpf_map_delete_elem(&header_req_map, &header_addr);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another missed cleanup

Copy link
Contributor

@mariomac mariomac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

Copy link
Contributor

@marctc marctc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious about the usage of goto instead of functions, is this a common pattern in eBPF programs or it's just to simplify things? Is this fixing #618?

@grcevski
Copy link
Contributor Author

I'm curious about the usage of goto instead of functions, is this a common pattern in eBPF programs or it's just to simplify things? Is this fixing #618?

Yeah, it's sort of common in eBPF. Each program is always individual single function and when we use functions we'd have to put __always_inline so that the verifier likes it. The only way to call in terms of a function call is to use bpf_tail_call.

So I think you are right, we could've made the cleanup a function and "call it", but then we'd have to make individual cleanup function for each probe, I thought this was simpler, but maybe I'm not considering some approach. If you have a cleaner code in mind, please shout :).

@grcevski grcevski merged commit 13d3dd4 into grafana:main Feb 13, 2024
4 checks passed
@grcevski
Copy link
Contributor Author

Is this fixing #618?

I hope it will. I'll ask on the issue if they can try with our main branch now once this is built.

@myhro
Copy link
Contributor

myhro commented Feb 13, 2024

Hi Nikola,

(...) when we use functions we'd have to put __always_inline so that the verifier likes it.

Is this a limitation of the way bpf2go works? I'm not sure if/how it uses libbpf under the hood, but __always_inline should only be required on older kernels (< 4.16/< 5.5). For the ones Beyla is targeting (>= 5.8), function calls should work without inlining.

@grcevski
Copy link
Contributor Author

Oh maybe it's not needed anymore, I just keep using it by habbit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants