-
Notifications
You must be signed in to change notification settings - Fork 451
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
Duplicate Enum value in bpf_map_type
#1060
Comments
As I see it, there are four possible solutions here:
My thoughts on those are:
To me option 2 seems to be the lesser evil as those strings are equivalent from C's perspective so it shouldn't matter which one is returned. However, I would keep the if an output a debug log message so people can figure out what is going on. However, I've got no clue about the context of the larger code base so I might be missing something here. Happy to hear some feedback :) |
So the point of the function is to generate a map, so that if we have a value, we can look-up what it means. That appears to be the only place it's used, and it is private, so the only public expose is through the So the real options open to us are:
I'm kind of ok with any of them. I tend to err on the side of barfing rather than deciding things for the user, but that may work out to be extremely inconvenient, in which case my second choice would just be to ignore duplicates and debug log for the user. I'll mock up a PR that would make the change... |
Commit
bpf: Implement cgroup storage available to non-cgroup-attached bpf progs
merged in Linux 6.2-rc1 introduced a duplicate enum value inenum bpf_map_type
.Currently Volatility throws an exception in that case, could we maybe handle it more gracefully, e.g., by making the mapping
int -> str | list[str]
orint -> list[str]
?The relevant code seems to be here and it looks like the problem was already anticipated ;)
https://github.com/volatilityfoundation/volatility3/blob/713b5f96dd218eea9c3fdb490a2436a474d22352/volatility3/framework/objects/__init__.py#L599C19-L599C19
The text was updated successfully, but these errors were encountered: