io_uring_prep_openat returns -2?

[CharlieTap]

I'm sure this is my own stupidity somehow but I'm receiving -2 for io_uring_prep_openat, whats quite exceptional is the same arguments given to standard open_at syscall works just fine. What does -2 represent?

To make sure I receiving the correct cqe (I was only sending one sqe anyway) I tagged it with user data also and it was certainly for the open_at sqe.

I'm passing the following, I figured it should work irrespective of the distro:

dirfd = -100
pathname = "/proc/version"
flags = 0
mode = 0

Printing the struct returns:

{ opcode: 18, flags: 0, ioprio: 0, fd: -100, off: 0, addr: 12694552, len: 384, user_data: 0, buf_index: 0, buf_group: 0, personality: 0, file_index: 0, splice_fd_in: 0, splice_flags: 0, splice_off_in: 12694552, accept_flags: 0, cancel_flags: 0, open_flags: 0, unlink_flags: 0, statx_flags: 0, timeout_flags: 0, rename_flags: 0, poll_events: 0, poll32_events: 0, fsync_flags: 0, sync_range_flags: 0, fadvise_advice: 0, msg_flags: 0, hardlink_flags: 0, rw_flags: 0, addr2: 0 }

Kernel version: 6.1.44-060144-generic

Features:

Feature	Enabled
Single MMap	true
No Drop	true
Submit Stable	true
RW Current Position	true
Current Personality	true
Fast Poll	true
Poll 32 Bits	true
SQ Poll Non Fixed	true
Enter Extended Argument	true
Native Workers	true
Resource Tags	true
CQE Skip	true
Linked File	true
Register Ring	false

[axboe]

-2 is -ENOENT, io_uring always returns -errno for failure cases.

Can you include a reproducer, please?

[axboe]

Tested this one:

static int test(void)
{
	struct io_uring_cqe *cqe;
	struct io_uring_sqe *sqe;
	struct io_uring ring;

	io_uring_queue_init(4, &ring, 0);

	sqe = io_uring_get_sqe(&ring);
	io_uring_prep_openat(sqe, -1, "/proc/version", O_RDONLY, 0);
	io_uring_submit(&ring);

	io_uring_wait_cqe(&ring, &cqe);
	printf("cqe res: %d\n", cqe->res);

	io_uring_queue_exit(&ring);
	return 0;
}

and it works fine on current kernels and 6.1-stable:

axboe@m1max-kvm ~> uname -r
6.1.46-00004-gc47db9ca937e
axboe@m1max-kvm ~> ./openat
cqe res: 4

[axboe]

Checked your struct dump and it looks weird. For example, what is 'addr'? And why is splice_off_in the same. And what's going on with len?

This is why I always ask for a reproducer, because most of the time it's a coding error and it saves the maintainers a lot of time in trying to reproduce an issue which seemingly works fine here.

[CharlieTap]

Hey @axboe, Apologies if this has cost you time, I created a discussion rather than an issue because I assumed the problem I'm having is almost certainly on my side and I needed some steer. I 'm working on this later tonight so I will update with my results.

I strongly suspect this this is an issue with passing the path over FFI, for more context I'm working on a library to expose liburing in a typesafe way using Kotlin. Whats particularly odd though is that I'm calling open_at (the sys call) over the same FFI with the exact same string and it works, so maybe its an issue with the Kotlin bindgen.

[axboe]

Gotcha, yes the ffi side is obviously a bit different and I'd be surprised if this isn't an issue with the bindings.

[CharlieTap]

So it transpires this is entirely a bindgen problem... but for anyone that stumbles in here from a Kotlin ecosystem in the future:

• Turn off string conversion in your def file i.e. noStringConversion = io_uring_prep_openat
• Manually turn your kotlin string into a c string and grab the pointer example.cstr.getPointer(scope) and obviously make sure the scopes lifetime extends until the cqe is received.

Thank you @axboe for the steer

[axboe]

Thanks for putting in these details! Will be helpful to others in the future.