On 2/17/25 6:37 AM, Pavel Begunkov wrote:
> At the moment we can't sanely handle queuing an async request from a
> multishot context, so disable them. It shouldn't matter as pollable
> files / socekts don't normally do async.
Having something pollable that can return -EIOCBQUEUED is odd, but
that's just a side comment.
> diff --git a/io_uring/rw.c b/io_uring/rw.c
> index 96b42c331267..4bda46c5eb20 100644
> --- a/io_uring/rw.c
> +++ b/io_uring/rw.c
> @@ -878,7 +878,15 @@ static int __io_read(struct io_kiocb *req, unsigned int issue_flags)
> if (unlikely(ret))
> return ret;
>
> - ret = io_iter_do_read(rw, &io->iter);
> + if (unlikely(req->opcode == IORING_OP_READ_MULTISHOT)) {
> + void *cb_copy = rw->kiocb.ki_complete;
> +
> + rw->kiocb.ki_complete = NULL;
> + ret = io_iter_do_read(rw, &io->iter);
> + rw->kiocb.ki_complete = cb_copy;
> + } else {
> + ret = io_iter_do_read(rw, &io->iter);
> + }
This looks a bit odd. Why can't io_read_mshot() just clear
->ki_complete?
The kiocb semantics of ki_complete == NULL -> sync kiocb is also odd,
but probably fine for this case as read mshot strictly deals with
pollable files. Otherwise you'd just be blocking off this issue,
regardless of whether or not IOCB_NOWAIT is set.
In any case, it'd be much nicer to container this in io_read_mshot()
where it arguably belongs, rather than sprinkle it in __io_read().
Possible?
--
Jens Axboe
