[PATCH for-next 0/4] io_uring: force async only ops to go async

[Dylan Yudaken <dylany@meta.com>]

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