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

Message

Dylan Yudaken Jan. 27, 2023, 1:52 p.m. UTC

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

Comments

Jens Axboe Jan. 29, 2023, 10:20 p.m. UTC | #1

On Fri, 27 Jan 2023 05:52:23 -0800, Dylan Yudaken wrote:
> 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.
> 
> [...]

Applied, thanks!

[1/4] io_uring: if a linked request has REQ_F_FORCE_ASYNC then run it async
      (no commit info)
[2/4] io_uring: for requests that require async, force it
      (no commit info)
[3/4] io_uring: always go async for unsupported fadvise flags
      (no commit info)
[4/4] io_uring: always go async for unsupported open flags
      (no commit info)

Best regards,