-
Notifications
You must be signed in to change notification settings - Fork 120
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
test_udp_recvmsg_multishot_trunc
fails
#277
Comments
@SUPERCILEX are you interested in checking this out? It changes in newer kernels. |
What kernel version is this on? And do the |
@SUPERCILEX Sorry for the delay. Here is my linux version:
And yes every single one of those assertions failed for me. |
Ah sorry one of them does not fail, specifically 0 => {
let msg = msg.unwrap();
if !msg.is_payload_truncated() {
println!("Payload is not truncated")
}
if !msg.is_name_data_truncated() {
println!("Name is not truncated")
}
if !msg.payload_data().is_empty() {
println!("Payload data is not empty")
}
if 4 >= msg.incoming_name_len() {
println!("Payload name length is >= 4")
}
if DATA.len() != msg.incoming_payload_len() as usize {
println!("Payload len is {}", msg.incoming_payload_len());
}
assert_eq!(4, msg.name_data().len());
} Gives this output:
|
That just seems so broken to me. Can you try dbg printing the header here: Line 415 in 501ee78 |
@SUPERCILEX Output when commenting out the entire
|
Hmmm, that all zero pattern is deeply suspicious. I wonder if we're using the wrong buffer somehow? Can you throw in this for loop below
My guess is that one of the buffers will be filled in, but |
I added a
|
I had actually not read what the actual test was doing until just now, so I now have a few questions about this test. for (index, buf) in buffers.iter_mut().enumerate() {
let provide_bufs_e = io_uring::opcode::ProvideBuffers::new(
(**buf).as_mut_ptr(),
buf.len() as i32,
1,
BUF_GROUP,
index as u16,
)
.build()
.user_data(11)
.into();
unsafe { ring.submission().push(&provide_bufs_e)? };
ring.submitter().submit_and_wait(1)?;
let cqes: Vec<io_uring::cqueue::Entry> = ring.completion().map(Into::into).collect();
assert_eq!(cqes.len(), 1);
assert_eq!(cqes[0].user_data(), 11);
assert_eq!(cqes[0].result(), 0);
assert_eq!(cqes[0].flags(), 0);
} Man pages for The specific thing I have a question about is the |
Huh, yeah maybe that's it though I thought it was supposed to be fine. You could try adding the index to the buf group and see if that fixes it. Also you can print |
Hey, can you try #284 and see if it fixes it for you? If so, I was just being a dumdum and the kernel is returning sendmsg responses out of order which I wasn't expecting. |
Sorry for the delay, I've added a comment directly on the PR. |
Closed by #284 |
On my machine, this test fails. I'm running the most recent version of Arch Linux.
If I comment out each assertion one by one, every single assertion gets tripped.
Code is located here.
Some potentially helpful error output:
The text was updated successfully, but these errors were encountered: