Unexpected behaviour of IORING_OP_CONNECT

[ghost]

The following program makes an attempt to connect to 0.0.0.0:8080 using both io_uring and plain old libc. I expect the returned values to be identical. However, they are not. In case of io_uring the returned value is -111. In case of libc it is -1 (as it should be according to documentation). I would like to get an explanation of that behaviour.

fn main() {
    libc_connect(); io_uring_connect();
}

const ADDR: libc::sockaddr_in = libc::sockaddr_in {
    sin_family: libc::AF_INET as libc::sa_family_t,
    sin_addr: libc::in_addr { s_addr: u32::from_ne_bytes([0, 0, 0, 0]) },
    sin_port: 8080,
    sin_zero: [0; 8]
};

fn libc_connect() {
    unsafe {
        let socket = libc::socket(libc::AF_INET, libc::SOCK_STREAM | libc::SOCK_CLOEXEC, 0);

        println!("libc connect: {}", libc::connect(socket, &ADDR as *const _ as *const libc::sockaddr, std::mem::size_of::<libc::sockaddr_in>() as libc::socklen_t));

        libc::close(socket);
    }
}

fn io_uring_connect() {
    use io_uring::IoUring;
    use io_uring::opcode::Connect;
    use io_uring::types::Fd;

    unsafe {
        let mut io_uring = IoUring::new(2).unwrap();

        let socket = libc::socket(libc::AF_INET, libc::SOCK_STREAM | libc::SOCK_CLOEXEC, 0);

        io_uring.submission()
            .push(&Connect::new(Fd(socket), &ADDR as *const _ as *const libc::sockaddr, std::mem::size_of::<libc::sockaddr_in>() as libc::socklen_t).build())
            .unwrap();

        io_uring.submit_and_wait(1).unwrap();

        println!("io_uring connect: {}", io_uring.completion().next().unwrap().result());

        libc::close(socket);
    }
}

[DylanZA]

from man connect(2):
If the connection or binding succeeds, zero is returned. On
error, -1 is returned, and errno is set to indicate the error.

You should look at errno to get the actual error code.

io_uring just returns the error code in the completion

(I assume - I have not run this rust code)

[ghost]

The issue is that io_uring's connect returns -111 (and no errno is set) whereas libc's connect returns -1. I am asking why.

[ghost]

I modified the code to run io_uring's connect before libc's connect and print the errno. Here's the output:

io_uring connect: -111
errno: Success (os error 0)
libc connect: -1
errno: Connection refused (os error 111)

[ammarfaizi2]

The issue is that io_uring's connect returns -111 (and no errno is set) whereas libc's connect returns -1. I am asking why.

First, you need to know that:

1. errno is a libc feature.

2. liburing and io_uring don't use errno.

3. liburing and io_uring are independent of libc.

Even if we did use libc, it doesn't make sense to put the error code of the
submission to the errno variable anyway, since you can have many CQEs at a
time. But errno can only contain a single value. You should naturally realize
that when you understand the io_uring design.

What io_uring does when your submission results in error is:
It returns the error code in cqe->res as a negative value.

Side note:
In the kernel, we reserve -4095 to -1 as error code for return value.
(see also: IS_ERR macro).

In other words, if a syscall returns a value x and x holds true for the
following condition:
-4095 <= x && x <= -1
it means the syscall returns error.

In your case -111 means -ECONNREFUSED (Connection Refused).

[ghost]

The issue is that io_uring's connect returns -111 (and no errno is set) whereas libc's connect returns -1. I am asking why.

First, you need to know that:

1. errno is a libc feature.
2. liburing and io_uring don't use errno.
3. liburing and io_uring are independent of libc.

Even if we did use libc, it doesn't make sense to put the error code of the submission to the errno variable anyway, since you can have many CQEs at a time. But errno can only contain a single value. You should naturally realize that when you understand the io_uring design.

What io_uring does when your submission results in error is: It returns the error code in cqe->res as a negative value.

Side note: In the kernel, we reserve -4095 to -1 as error code for return value. (see also: IS_ERR macro).

In other words, if a syscall returns a value x and x holds true for the following condition: -4095 <= x && x <= -1 it means the syscall returns error.

In your case -111 means -ECONNREFUSED (Connection Refused).

Thanks for the clarification. I suggest you document that so that people don’t get confused.

[axboe]

Thanks for the clarification. I suggest you document that so that people don’t get confused.

You're kidding, right? It's literally even in the io_uring_prep_connect(3) man page. You just didn't read the documentation.

[ghost]

What is io_uring_prep_connect even for? I'm not using that. No offense, but error handling should be documented in a dedicated page (libc has that in every single page), not in some random one. Also I had not the easiest time searching for the list of all supported opcodes. Again, you should have a dedicated page for that.

[ghost]

Oh, it's a liburing method. I'm not using liburing. The reason though is that I can't use part of it's API from Rust (see rust-lang/rust-bindgen#592).

[axboe]

It literally is documented in prep handlers for opcodes, and in the io_uring.7 general man page, and in the io_uring_enter.2 man page. Of course an async API doesn't use errno for per-IO error codes, that would make zero sense and be unusable in practice. Ask yourself, what would errno mean in this context? Which request would it be for?

Maybe it's a language thing, but you are coming off as rude and demanding. If you have changes you think would make sense, please do send changes to make the project better. Nobody here works for you.

[axboe]

Oh, it's a liburing method

You are literally creating a discussion on the liburing github. Yes, it's a liburing thing.