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

validateMaps fails for eBPF map without property 'value' #321

Closed
havefuncoding1 opened this issue Nov 16, 2023 · 1 comment
Closed

validateMaps fails for eBPF map without property 'value' #321

havefuncoding1 opened this issue Nov 16, 2023 · 1 comment

Comments

@havefuncoding1
Copy link

havefuncoding1 commented Nov 16, 2023

Almost all yaml files under examples point to eBPF maps with 'value' property defined. Here is an example from accept-latency:

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, (MAX_LATENCY_SLOT + 1) * MAX_PORTS);
    __type(key, struct socket_latency_key_t);
    __type(value, u64);
} accept_latency_seconds SEC(".maps");

One exception is that oomkill. Here is the map definition which has no 'value'. Instead, it is value_size.

struct {
    __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
    __uint(key_size, sizeof(u32));
    __uint(value_size, sizeof(u32));
} oom_kills_total SEC(".maps");

Running this example results in runtime failure

Error attaching exporter: error validating maps for config "oomkill": value size for map "oom_kills_total" is not expected 8 bytes (u64), it is 4 bytes

And this is caused by the check in validateMap. What would be the solution here? Is replacing 'fmt.Errorf' with a warning message reasonable? We can add a 'value' to the map, but per my understanding there shouldn't be a 'value' property for BPF_MAP_TYPE_PERF_EVENT_ARRAY. Here is reference from Nakryiko's blog. Thanks.

valueSize := m.ValueSize()
if valueSize != 8 {
	return fmt.Errorf("value size for map %q is not expected 8 bytes (u64), it is %d bytes", name, valueSize)
}
@bobrik
Copy link
Contributor

bobrik commented Nov 16, 2023

Thanks for the report. I opened #322 to both fix this and prevent it from breaking again.

@bobrik bobrik closed this as completed Nov 16, 2023
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

No branches or pull requests

2 participants