io_uring: not good enough for release

From: "Stefan Bühler" <source@stbuehler.de>
To: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: io_uring: not good enough for release
Date: Tue, 23 Apr 2019 21:06:38 +0200	[thread overview]
Message-ID: <366484f9-cc5b-e477-6cc5-6c65f21afdcb@stbuehler.de> (raw)

Hi,

now that I've got some of my rust code running with io_uring I don't
think io_uring is ready.

If marking it as EXPERIMENTAL (and not "default y") is considered a
clear flag for "API might still change" I'd recommend going for that.

Here is my current issue list:

---

1. An error for a submission should be returned as completion for that
submission.  Please don't break my main event loop with strange error
codes just because a single operation is broken/not supported/...

2. {read,write}_iter and FMODE_NOWAIT / IOCB_NOWAIT is broken at the vfs
layer: vfs_{read,write} should set IOCB_NOWAIT if O_NONBLOCK is set when
they call {read,write}_iter (i.e. init_sync_kiocb/iocb_flags needs to
convert the flag).

And all {read,write}_iter should check IOCB_NOWAIT instead of O_NONBLOCK
(hi there pipe.c!), and set FMODE_NOWAIT if they support IOCB_NOWAIT.

{read,write}_iter should only queue the IOCB though if is_sync_kiocb()
returns false (i.e. if ki_callback is set).

Because right now an IORING_OP_READV on a blocking pipe *blocks*
io_uring_enter, and on a non-blocking pipe completes with EAGAIN all the
time.

So io_uring (readv) doesn't even work on a pipe!  (At least
IORING_OP_POLL_ADD is working...)

As another side note: timerfd doesn't have read_iter, so needs
IORING_OP_POLL_ADD too... :(

(Also RWF_NOWAIT doesn't work in io_uring right now: IOCB_NOWAIT is
always removed in the workqueue context, and I don't see an early EAGAIN
completion).

3. io_file_supports_async should check for FMODE_NOWAIT instead of using
some hard-coded magic checks.

4. io_prep_rw shouldn't disable force_nonblock if FMODE_NOWAIT isn't
available; it should return EAGAIN instead and let the workqueue handle it.

Because otherwise the event loop is blocking again.

---

I'm guessing especially 2. has something to do with why aio never took
off - so maybe it's time to fix the underlying issues first.

I'd be happy to contribute a few patches to those issues if there is an
agreement what the result should look like :)

I have one other question: is there any way to cancel an IO read/write
operation? I don't think closing io_uring has any effect, what about
closing the files I'm reading/writing?  (Adding cancelation to kiocb
sounds like a non-trivial task; and I don't think it already supports it.)

So cleanup in general seems hard to me: do I have to wait for all
read/write operations to complete so I can safely free all buffers
before I close the event loop?

cheers,
Stefan