The code does not compile due to this, which will be addressed shortly.

I missed that some offsets are dynamic and depend on size.

For check_add_overflow/struct_size/etc, I think we should ignore the possibility of overflows and just open-code the operations they do. First, we are a fuzzer and if we do more nonsense, nothing bad happens. Maybe the opposite: the more nonsense, the better! :)
Second, what matters for us is if we overflow the already allocated sizes for these rings, not the UINT64_MAX or whatever they check in the kernel before the allocation. And overflowing the smaller allocated sizes if much easier. So this check mostly does not do anything useful for us.

For the static offsets I was thinking about calling io_uring_create inside of syz_io_uring_submit and using the values it returns rather then hardcoding them in executor. These offsets may change across kernel versions. And just less logic in executor this way.
But let's think what's the best way to handle the dynamic offset first, because it may affect the best way to handle static offsets as well.

FTR, the array offset calculation in the kernel seems wrong to me:
https://lore.kernel.org/io-uring/[email protected]/T/#u

Yes, and for SMP and cache-line alignment, I think we should assume the kernel is SMP maybe with a comment about this assumption. First, non-SMP kernels are quite rare today (maybe only the smallest ARM boards), definitely not anything we care about right now. Second, figuring out if kernel was build as SMP or not may be tricky and can only be done dynamically.

The offsets calculation does not look too complex. I used test program for experimentation:
https://gist.githubusercontent.com/dvyukov/2fe31bfd154592f3840dc4676294b77e/raw/c42cb4a3da0a032b0f4d5e28b7f6f0526f43a36f/gistfile1.txt
It prints:

res=3 time=3745
sq: head=0 tail=64 ring_mask=256 ring_entries=264 array=4928
cq: head=128 tail=192 ring_mask=260 ring_entries=268 array=320
sq_entries=128 cq_entries=256
sq_array_off=4928

I see 2 options:

1. Either duplicate whole calculation in executor (what you do now). But then I think it's simpler to just hardcode all offsets as defines (we duplicate all of that logic, so there is little in doing something more complex).
   or 2. call io_uring_setup with size 1 to get static offsets and then calculate sq array offset manually (as my test program does).

Which one is better?... Hard to say 2 is less hard-coded things that duplicate kernel logic and can break in future (but still some), but 1 is simpler and faster...
Let's do 1 for now as simpler and faster, with some comment and just difines for offsets.

Codecov Report

Merging #1926 into master will increase coverage by 0.0%.
The diff coverage is 80.0%.

There are few remaining TODO's, please finalize it, and we will do final review passes.

One additional thing we need since this is a tricky subsystem and we use custom pseudo-syscalls is a test program.
These are stored in sys/linux/test/*
At least we need 1 successful scenario: create io_uring, submit 1 operation using syz_io_uring_submit, wait for completion, call syz_io_uring_complete, check that the operation has succeeded.
Checking that the operation was successful can be done either with syz_io_uring_complete result (if openat2 operation returns an fd), or by observing some side-effect of the operations (e.g. if we do a write to a pipe, we can then read from the pipe).
Check out other test programs for the use of AUTO, it's handy for specifying address and const values.
The test can be run with syz-execprog utility inside of a VM. Or using go install ./tools/syz-runtest && syz-runtest -config=manager.config -tests yourtestfilename.

One additional thing we need since this is a tricky subsystem and we use custom pseudo-syscalls is a test program.
These are stored in sys/linux/test/*
At least we need 1 successful scenario: create io_uring, submit 1 operation using syz_io_uring_submit, wait for completion, call syz_io_uring_complete, check that the operation has succeeded.
Checking that the operation was successful can be done either with syz_io_uring_complete result (if openat2 operation returns an fd), or by observing some side-effect of the operations (e.g. if we do a write to a pipe, we can then read from the pipe).
Check out other test programs for the use of AUTO, it's handy for specifying address and const values.
The test can be run with syz-execprog utility inside of a VM. Or using go install ./tools/syz-runtest && syz-runtest -config=manager.config -tests yourtestfilename.

OK, so we have syz_io_uring_complete return an fd in some cases.
A test that obtains that fd and then closes it would be an awesome demonstration of the power of the new descriptions.
And I usually also find lots of bugs in my descriptions when I run such tests :)

The test to test the new descriptions and the pseudo-calls now added, which indeed helped as I found a bug in one of the pseudo-calls' implementation.

While writing the mmap calls' arguments in the tests, something drew my attention.

In the current state of the descriptions, the length arg for the mmap$IORING_* is written in a very generic way [1].

On the other hand, if we want the fuzzer to be able to utilize the ring in full, we may want to compute the size for the memory region we want to map (as in here) and call the mmap with that size (as in here).

I cannot think of a way to achieve the exact computation without another pseudo-call. One approach might be to have syz_io_uring_setup(), which would wrap io_uring_setup() and do the mapping right after the setup inside the pseudo-call, and return us the ring_ptr. Another benefit of such approach might be that we can make io_cqring_offsets and io_sqring_offsets as out args of the new pseudo-call, and fill them once io_uring_setup() returns inside. This way, we might be able avoid hard-coding the offsets. This might complicate the things for syz_memcpy_off(), though..

Another approach might be to set lower&upper bounds for mmap$IORING_*'s length. The num of sq and cq ring entries are limited, thus, it is doable. This would be the fastest solution.

Thanks for your valuable reviews!

The last commit fixes the io_uring test and the linter warnings.

This should be ready for the final review passes @xairy