feat(socket): decode (SOL_SOCKET, SO_MARK) cmsg into SoMark(u32)#2785
Conversation
|
CI partially failing on clippy complaints seems unrelated to my changes. |
Add a `ControlMessageOwned::SoMark(u32)` variant and a matching arm in `ControlMessageOwned::decode_from`, modeled on the existing `RxqOvfl(u32)` arm a few lines above. Receivers that have enabled `SO_RCVMARK` (Linux 5.19+, kernel commit `6fd1d51cfa253b5ee7dae18d7cf1df830e9b6137`) get an `(SOL_SOCKET, SO_MARK)` ancillary message on every datagram carrying the kernel-set `skb->mark`; without this arm the cmsg falls through to the catch-all `Unknown` variant and forces a per-recv `Vec<u8>` allocation to copy four bytes. `SO_MARK` is in `libc` for `linux_android` and `fuchsia`, but `SO_RCVMARK` (the option that actually causes the kernel to deliver the cmsg on receive) is Linux/Android-only, so the new arm is gated `#[cfg(linux_android)]`. Omitting `fuchsia` seems like the defensive choice.
SteveLauC
force-pushed
the
feat/cmsg-so-mark-decode
branch
from
3d33ad8 to
46bc4db
Compare
I rebased your branch to fix the CI failures. |
SteveLauC
left a comment
SteveLauC
left a comment
There was a problem hiding this comment.
Let me know if you think this requires additional tests. I validated that behavior locally.
Yeah, a set-get test would be needed. In order to do that, we should also implement the socket option SO_RCVMARK (pub struct RcvMark).
|
Use
Use |
libc only exposes `SO_RCVMARK` under `unix/linux_like/linux/arch/*`, not under `unix/linux_like/android/`, so the previous `linux_android` gating broke the Android build with `cannot find value SO_RCVMARK in crate libc`. Narrow the `RcvMark` sockopt, the `ControlMessageOwned::SoMark(u32)` variant, the matching `decode_from` arm, and the `test_recvmsg_so_mark` integration test to `target_os = "linux"` to match what `libc` actually offers (and what the existing send-side `Mark` sockopt is gated on).
|
31 Looks like this constant is not defined for android in the libc crate: https://github.com/search?q=repo%3Arust-lang%2Flibc%20SO_RCVMARK&type=code |
|
You're fast :-). Yep, only scoped it now to Linux. Now it's symmetrical. |
2 participants
What does this PR do
Add a
ControlMessageOwned::SoMark(u32)variant and a matching arm inControlMessageOwned::decode_from, modeled on the existingRxqOvfl(u32)arm a few lines above. Receivers that have enabledSO_RCVMARK(Linux 5.19+, kernel commit6fd1d51cfa253b5ee7dae18d7cf1df830e9b6137) get an(SOL_SOCKET, SO_MARK)ancillary message on every datagram carrying the kernel-setskb->mark; without this arm the cmsg falls through to the catch-allUnknownvariant and forces a per-recvVec<u8>allocation to copy four bytes.SO_MARKis inlibcforlinux_androidandfuchsia, butSO_RCVMARK(the option that actually causes the kernel to deliver the cmsg on receive) is Linux/Android-only, so the new arm is gated#[cfg(linux_android)]. Omittingfuchsiaseems like the defensive choice.Let me know if you think this requires additional tests. I validated that behavior locally.
Checklist:
CONTRIBUTING.mdnecessary tests andrustdoc comments