The enumeration allows us to keep track of the last
io_uring_register(2) opcode available.
Behaviour and opcodes names don't change.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
This is fixed by upstream commit:
commit 68faa4727c0e2d7d255d9b97e754f2cda748f141
Author: Jens Axboe <axboe@kernel.dk>
Date: Tue Aug 25 12:27:50 2020 -0600
io_uring: don't use poll handler if file can't be nonblocking read/written
We're testing whether we first get some data, then a zero return on the
next one when it's closed. The buggy behavior was to arm a poll handler,
which isn't notified when the pipe is closed.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Guillem Jover correctly points out that this did used to be loff_t,
but was changed since it wasn't available everywhere.
Let's just use an int64_t, it's the same size and signed. Hopefully
this is it...
Signed-off-by: Jens Axboe <axboe@kernel.dk>
syscall.h is mising the forward declaration for struct io_uring_params, and sigset_t. Include the necessary
system header to make it independent.
Signed-off-by: Goro Fuji <g.psy.va@gmail.com>
If the ring is configured to operate in poll mode we need to always
enter the kernel to fetch new events. This behavior was introduced
in bf3aeb3dbb but recently broken.
Break me once, shame on you. Break me twice, shame on me:
- Add a unit test.
The unit test submits sqes manually through the system call, which
guarantees that IORING_ENTER_GETEVENTS will not be present in the flag
set during the initial submission.
The only way we can ever fetch new I/O events is if io_uring_submit
indeed will enter the ring despite not having new sqes to submit.
This test passes with 8e8cb865cd but fails before it due to the
aforementioned regression.
Signed-off-by: Glauber Costa <glauber@datadoghq.com>
This reverts commit c415b39d67.
Glauber reports a regressions for his polled setup with this change.
As it's purely speculative, just revert it.
Reported-by: Glauber Costa <glauber.costa@datadoghq.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The example currently assumes the file is at least 4*4096 bytes,
and errors when we get 0 reads on EOF. Fix this up.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We currently rely on this test being killed by runtests.sh, and
the test expects this and exits nicely when that happens. But let's
give it a finite runtime in general, so that running it independently
will have it exit nicely on its own as well.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This is the generated syzkaller reproducer. Should be fixed by this
mainline commit:
commit d4e7cd36a90e38e0276d6ce0c20f5ccef17ec38c (HEAD -> io_uring-5.9, origin/io_uring-5.9)
Author: Jens Axboe <axboe@kernel.dk>
Date: Sat Aug 15 11:44:50 2020 -0700
io_uring: sanitize double poll handling
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This should be fixed by the kernel commit:
commit f254ac04c8744cf7bfed012717eac34eacc65dfb
Author: Jens Axboe <axboe@kernel.dk>
Date: Wed Aug 12 17:33:30 2020 -0600
io_uring: enable lookup of links holding inflight files
Signed-off-by: Jens Axboe <axboe@kernel.dk>
* 'master-debian' of https://github.com/metze-samba/liburing:
update debian/changelog
update debian/liburing1.symbols
debian/rules: pass down relativelibdir in order to get an absolute path
errno will be ENOSYS, not EOPNOTSUPP if the syscall is not there. This
also matches what errno is set to in do_statx if __NR_statx is not
defined.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Probably don't need this, but it's right before release and I'd hate
for a test to cause compilation failure.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Use __NR_statx in do_statx and unconditionally use it to check the
result on all architectures, not just x86_64. This relies on the
fact that __NR_statx should be defined if struct statx and STATX_ALL are
available as well.
Don't fail the test if the statx syscall returns EOPNOTSUPP though.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
In io_uring_peek_batch_cqe(), if the first peek could not find any
cqes, we check cq ring overflow, and if cq ring has been overflowed,
enter kernel to flush cqes, and do the second peek.
Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We only care about if we get less than 8, it's perfectly valid to
get the full 12. In fact, once we modify peek to ensure we flush
kernel side overflows, we will get more.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We only care about if we get less than 8, it's perfectly valid to
get the full 16. In fact, once we modify peek to ensure we flush
kernel side overflows, we will get more.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Stefano Garzarella