Linux: update and add missing AF_XDP API

[arctic-alpaca]

Description

This PR adds missing structs/constants from the if_xdp.h header and updates the xdp_umem_reg struct. Due to the added field in xdp_umem_reg, this is a breaking change from the 0.2 branch.

Ideally, I would like to include all the changes in the 0.2 branch. Would it be possible to add a xdp_umem_reg_v3 to not break the current xdp_umem_reg?
If not, how would deprecating a struct to change it work? Just add a deprecation notice, wait for X amount of time, add the field?

Sources

AF_XDP documentation: https://docs.kernel.org/networking/af_xdp.html
Header file: https://github.com/torvalds/linux/blob/v6.11/include/uapi/linux/if_xdp.h

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

I could not test the the changes locally due to the error described in #3865 (comment)

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

Thanks for the PR, I'm taking a look at this. Where is xsk_tx_metadata_completion defined? I can't seem to find it anywhere.

Ideally, I would like to include all the changes in the 0.2 branch. Would it be possible to add a xdp_umem_reg_v3 to not break the current xdp_umem_reg?

The kernel removed the old interface because it was buggy, right? If the kernel made the decision to do a breaking change here then I think we can just do the same.

[arctic-alpaca]

I'm taking a look at this.

Thank you!

Where is xsk_tx_metadata_completion defined?

xsk_tx_metadata_completion and xsk_tx_metadata_request are the two possible variants of the anonymous union in xsk_tx_metadata.

The kernel removed the old interface because it was buggy, right?

Correct, the issue was initially reported here with the fix removing the xdp_umem_reg_v2 struct. The current situation is either the new (xdp_umem_reg) struct is used or the kernel falls back to using xdp_umem_reg_v1, which silently ignores the flags field (source). Silently ignoring the flags field being a breaking change in the kernel.

[bors]

☔ The latest upstream changes (presumably #4018) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #4092) made this pull request unmergeable. Please resolve the merge conflicts.

[tgross35]

Everything added here is uapi right? It should probably go in src/unix/linux_like/linux/mod.rs rather than duplicating into gnu and musl. (The existing xdp types could probably move as well? Not in this PR though.)

[arctic-alpaca]

Everything added here is uapi right?

Yes.

The existing xdp types could probably move as well?

I think so, I wasn't sure where to put them when I initially added them. I'll create a PR after this one is merged to move the rest too.

[tgross35]

I did a bit of looking and it seems like rustix is about the only consumer of the specific type that would break. I asked about possible fallout here bytecodealliance/rustix#1221, if they say they can work around us breaking things then that is much easier than figuring out the best mitigation here.

In any case we can get this merged to main, left a comment about deduplicating gnu and musl.

@rustbot author

[arctic-alpaca]

Everything that was added in this PR (besides the field addition) is moved to src/unix/linux_like/linux/mod.rs now.

@rustbot review

[tgross35]

Thanks for moving things. I'll merge this now but hold off for a few more days on the backport to hear back from rustix (I am leaning toward just doing the backport, we can't reasonably do a major release in every case where the API we bind breaks).