Many ops such as statx do not support nonblock issuing (for now). At the moment the code goes through the issue call just to receive -EAGAIN and then be run async. There is no need for this as internally the REQ_F_FORCE_ASYNC flag can just be added on. The upside for this is generally minimal, and possibly you may decide that it's not worth the extra risk of bugs. Though as far as I can tell the risk is simply doing a blocking call from io_uring_enter(2), which while still a bug is not disasterous. While doing this I noticed that linked requests are actually issued with IO_URING_F_NONBLOCK first regardless of the IOSQE_ASYNC flag, and so I fixed this at the same time. The difference should be neglegible I assume. Note this depends on the drain fix I have just sent for 6.2. Patch 1 is the fix. Patch 2 forces async for the easy cases where it is always on Patch 3/4 is for fadvise/open which require a bit of logic to determine whether or not to force async Dylan Yudaken (4): io_uring: if a linked request has REQ_F_FORCE_ASYNC then run it async io_uring: for requests that require async, force it io_uring: always go async for unsupported fadvise flags io_uring: always go async for unsupported open flags io_uring/advise.c | 29 +++++++++++++++++------------ io_uring/fs.c | 20 ++++++++++---------- io_uring/io_uring.c | 8 +++++--- io_uring/net.c | 4 ++-- io_uring/openclose.c | 18 ++++++++++++------ io_uring/splice.c | 7 +++---- io_uring/statx.c | 4 ++-- io_uring/sync.c | 14 ++++++++------ io_uring/xattr.c | 14 ++++++-------- 9 files changed, 65 insertions(+), 53 deletions(-) base-commit: cea6756d62abfc4791efc81d1f6afa016ed8df8c -- 2.30.2
