fs: check for opcode support before starting operation

[tahmid-23]

Motivation

io_uring exposes additional opcodes with successive kernel versions. Ideally, we can tell which opcodes are supported, so we can know whether to use the io_uring version or the threadpool version of an asynchronous function.

This functionality is exposed through io_uring's probing feature, which lists the supported opcodes. This is introduced in kernel 5.6. We fallback to attempting any opcode if probing support is not available.

All of the currently used opcodes (openat, read, write) were introduced before probing support in io_uring, so this is unnecessary for the current functionality. However, future additions can benefit from this check.

(Technically, #7799 and #7800 would benefit from this, although running on kernel [5.6, 5.10) is likely rare. But, other opcodes like mkdirat are not available on 5.10, which is an LTS.)

I bumped the io-uring crate to 0.7.11 to expose get_opcode, since it is tokio_unstable.

[Darksonn]

It's not clear that this is the correct approach. Perhaps we should simply treat such cases as not supporting io_uring, or hardcode the list opcodes that are present on 5.10, which I understand is the only supported Linux kernel version without IOURING_REGISTER_PROBE?

[tahmid-23]

If probing support isn't present, then none of the currently used opcodes will work (and I assume none of the future opcodes either). So let's go with the first option (5.6+).

[Darksonn]

Thanks.

[vrtgs]

I feel like having to lock a lock when running check_and_init, makes the whole using atomics pointless in my humble opinion

[Darksonn]

That's a good point. Does is_opcode_supported take &mut self?

[tahmid-23]

no, just &self / it needs to have been initialized.
It's not immediately obvious to me how to avoid a lock though. It needs an &mut Probe to store into, which is currently in the UringContext.
we could use something like an ArcSwap<Probe> in Handle, but that would require the arc-swap crate.

[Darksonn]

I guess we can probe the opcodes that Tokio cares about and store an AtomicU32 bitmap of the results.

Either way we should open an issue to remove the lock.