Prepare release 0.26.3 #2105
Merged
Prepare release 0.26.3 #2105
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1925: fix: send ETH_P_ALL in htons format r=asomers a=tzneal Co-authored-by: Todd Neal <toddneal@protonmail.com>
2041: Set the length of a socket address when calling `recvmsg` on Linux r=asomers a=JarredAllen # Background I think I've found a bug with `recvmsg` on Linux where it doesn't set the length of a received socket address. I found this while working with unix datagram sockets with path `struct sockaddr_un` addresses, but I think this applies to any variable-length socket address type. At present, the `sun_len` field of `UnixAddr` on Linux shows up as 0 whenever I call `recvmsg`. I think it's reading uninitialized memory (afaict the `recvmsg` function never initializes it before we call `MaybeUninit::assume_init`), though it's possible that it's being zero-initialized somewhere that I missed. Either way, this isn't the correct behavior, which should set it to the length of the `struct sockaddr_un` contents (or whatever other type of socket). # Changes I changed the `recvmsg` function to construct the returned socket address from the `struct sockaddr` and length returned by the libc `recvmsg` call (using the `from_raw` function the trait provides). Since the trait is sealed so downstream crates can't implement it, I believe this shouldn't be a breaking change. # Validation I've tested that my code (which failed due to this bug) now works. I also added a new test case which tests that we construct `UnixAddr`s correctly in the `recvmsg` function, which passes locally for me and fails if I cherry-pick it onto the current `master`. I've also checked that `cargo test` and `cargo clippy` both still pass on `aarch64-apple-darwin` and on `aarch64-unknown-linux-musl` targets (the two targets I develop for/have access to). Hopefully your CI will confirm that everything else still works. Co-authored-by: Jarred Allen <jarred@moveparallel.com> Co-authored-by: Jarred Allen <jarredallen73@gmail.com>
2061: For invalid IP address conversions with future Rust versions r=asomers a=asomers Rust's standard library no longer guarantees that Ipv4Addr and Ipv6Addr are wrappers around the C types (though for now at least, they are identical on all platforms I'm aware of). So do the conversions explicitly instead of transmuting. Fixes nix-rust#2053 Co-authored-by: Alan Somers <asomers@gmail.com>
Fix an incorrect lifetime in the return value of recvmsg
2033: remove unused mut from two variable declarations in sys/socket/mod.rs r=asomers a=inglorion
This addresses diagnostics like:
error: variable does not need to be mutable
--> src/sys/socket/mod.rs:1537:13
|
1537 | let mut p = &mut mmsghdr.msg_hdr;
Co-authored-by: Bob Haarman <inglorion@google.com>
This is a direct commit to the r0.26 branch, because the offending code has been removed in master.
2086: Clippy cleanup r=asomers a=asomers Clippy found some const-correctness issues in internal APIs, but nothing user-facing. Co-authored-by: Alan Somers <asomers@gmail.com>
2027: Update to bitflags 2.2.1. r=asomers a=qwandor This is a new major version and requires some code changes. 2057: Haiku: `speed_t` is defined as `u8` for 32 and 64 bit systems r=asomers a=nielx This fixes the build on 32 bit Haiku systems. Co-authored-by: Andrew Walbran <qwandor@google.com> Co-authored-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
2076: Clippy cleanup r=asomers a=asomers Co-authored-by: Alan Somers <asomers@gmail.com>
2043: Clippy cleanup: r=asomers a=asomers fix the new clippy::non_minimal_cfg lint Co-authored-by: Alan Somers <asomers@gmail.com>
Clippy cleanup: noop_method_call
2052: Fix CI with the latest rustup r=asomers a=asomers Co-authored-by: Alan Somers <asomers@gmail.com> Co-authored-by: Ben Kimock <kimockb@gmail.com>
2022: Quiet Clippy::manual_slice_size_calculation lints r=asomers a=asomers Co-authored-by: Alan Somers <asomers@gmail.com>
use --locked with cargo install so it won't pull in a version of addr2line that is too new for our MSRV.
We mainly provide VsockAddr, so let's try to test well that VsockAddr mapping to libc::sockaddr_vm is correct. Let's remove all interactions with the socket, since vsock may or may not be available in the environment. Testing socket(), bind(), listen(), connect(), etc. caused unexpected failures, and it's out of scope of this crate. So let's simplify the vsock test focussing on VsockAddr. This should work also on graviton, so let's try to re-enable it. Fixes nix-rust#1934 Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
It's failing in CI, and we don't yet know why. Possibly the cloud provider just turned on seccomp. Issue nix-rust#2060
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most just a bunch of cherry-picks from master, for bug fixes and Clippy stuff.