-
Notifications
You must be signed in to change notification settings - Fork 286
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
sys: add map_ids to bpf_prog_get_info_by_fd #747
Conversation
✅ Deploy Preview for aya-rs-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Allows the caller to pass a slice which the kernel will populate with map ids used by the program.
let mut attr = unsafe { mem::zeroed::<bpf_attr>() }; | ||
// info gets entirely populated by the kernel | ||
let info = MaybeUninit::zeroed(); | ||
let mut info = unsafe { mem::zeroed() }; |
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.
Can this stay as MaybeUninit::zeroed();
?
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.
How's that better? We'll need to immediately assume_init
so we can write to it.
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.
why not just call as_mut_ptr()
on info
in the init closure? Since we only need to assume_init in that one case
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.
We'd still need to assume_init later, before returning. What is the benefit of using MaybeUninit
here?
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.
Or just use as_mut_ptr() here and ONLY do unsafe code in that one case
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.
This doesn't make sense - look at the diff. Before the change, we had unsafe code on the return path.
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.
Writing through MaybeUninit::as_mut_ptr
is nasty:
Gets a mutable pointer to the contained value. Reading from this pointer or turning it into a reference is undefined behavior unless the MaybeUninit is initialized.
https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.as_mut_ptr
That means we can't turn it into a mutable reference because that's UB. Again, how is this better?
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.
Fair enough I guess there is no way to protect against the unsafe code here 👍 In the docs it says
This has the same effect as [MaybeUninit::zeroed().assume_init()](https://doc.rust-lang.org/std/mem/union.MaybeUninit.html#method.zeroed). It is useful for FFI sometimes, but should generally be avoided.
This is the "useful for FFI case" lol :)
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.
Yup.
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.
/LGTM
Allows the caller to pass a slice which the kernel will populate with
map ids used by the program.