Erroneous socket connect pass?

Erroneous socket connect pass?

[Weber, Eugene F Jr CIV (USA)]

Hi,

Thanks for creating liburing. Great stuff.

I **may** have found a bug. I would expect a socket connect using io_uring to fail as it does using connect() if the port is not setup to listen. In the simple test case attached it does not. If this is pilot error, please let me know what I'm doing wrong, or why my expectation is incorrect. Version information is in the code header. Please let me know if any additional information is needed.

Thanks,

Gene


//
// Simple program to demonstrate erroneous connect pass.
//
// liburing Version: 2.2
// Linux 5.13.0-1025-aws #27~20.04.1-Ubuntu
// g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
// g++ -Wall -O3 -o cnct_test cnct_test.cpp -luring
//
#include <stdlib.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <sys/socket.h>
#include <cstring>
#include <linux/time_types.h>
#include <liburing.h>
#define PORT 8080
#define ADDRESS "127.0.0.1"

int main(int argc, char const* argv[]) {
    int sock = 0;
    struct sockaddr_in serv_addr;
    memset(&serv_addr, 0, sizeof(serv_addr));

    if (argc != 2) {
        fprintf(stderr, "\nUsage: %s test_number(1 or 2)\n\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    if ((sock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
        perror("Create socket failed");
        exit(EXIT_FAILURE);
    }

    serv_addr.sin_family = AF_INET;
    serv_addr.sin_port = htons(PORT);

    if (inet_pton(AF_INET, ADDRESS, &serv_addr.sin_addr) <= 0) {
        perror("Invalid address/ Address not supported");
        exit(EXIT_FAILURE);
    }

    if (*argv[1] == '1') {
        fprintf(stdout, "\nTesting that connect() fails if port isn't listening.\n");
        if (connect(sock, (struct sockaddr*)&serv_addr, sizeof(serv_addr)) < 0) {
            perror("Connect failed");
            exit(EXIT_FAILURE);
        }
    }

    if (*argv[1] == '2') {
        fprintf(stdout, "\nTesting that connect using io_uring fails if port isn't listening.\n");
        int job_info = 42; // The meaning of life.
        struct __kernel_timespec cnct_wait;
        cnct_wait.tv_sec = 15;
        struct io_uring_cqe *cqe;

        struct io_uring io_uring_sq;
        int rtrn_val = io_uring_queue_init(256, &io_uring_sq, 0);
        if (rtrn_val < 0) {
            fprintf(stderr, "io_uring_queue_init failed: %d", -rtrn_val);
            exit (EXIT_FAILURE);
        }
        struct io_uring_sqe *sqe = io_uring_get_sqe(&io_uring_sq);

        io_uring_prep_connect(sqe, sock, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
        io_uring_sqe_set_data(sqe, &job_info);

        rtrn_val = io_uring_submit(&io_uring_sq);
        if (rtrn_val < 0) {
            fprintf(stderr, "io_uring_submit failed: %d", -rtrn_val);
            exit (EXIT_FAILURE);
        }

        rtrn_val = io_uring_wait_cqe_timeout(&io_uring_sq, &cqe, &cnct_wait);
        //Same result: rtrn_val = io_uring_wait_cqe(&io_uring_sq, &cqe);
        if (rtrn_val < 0) {
            fprintf(stderr, "io_uring_wait_cqe failed: %d", -rtrn_val);
            exit (EXIT_FAILURE);
        }
        fprintf(stdout, "Why doesn't io_uring_wait_cqe_timeout fail or timeout?\n\n");
    }

    return 0;
}

Re: Erroneous socket connect pass?

[Jens Axboe]

On 5/27/22 8:29 AM, Weber, Eugene F Jr CIV (USA) wrote:
> 
> Hi,
> 
> Thanks for creating liburing. Great stuff.
> 
> I **may** have found a bug. I would expect a socket connect using
> io_uring to fail as it does using connect() if the port is not setup
> to listen. In the simple test case attached it does not. If this is
> pilot error, please let me know what I'm doing wrong, or why my
> expectation is incorrect. Version information is in the code header.
> Please let me know if any additional information is needed.

The return value of io_uring_wait_cqe and related functions isn't the
completion result. It's simply if we succeeded in waiting for one or
more events. It could never be the completion result, because consider
what happens if you have multiple requests in flight.

You need to look at cqe->res for the completion result of the request.

-- 
Jens Axboe