Re: [PATCH] io_uring/rw: transform single vector readv/writev into ubuf

[Keith Busch <kbusch@kernel.org>]

On Fri, Mar 24, 2023 at 05:54:36PM -0600, Keith Busch wrote:
> On Fri, Mar 24, 2023 at 08:35:38AM -0600, Jens Axboe wrote:
> > @@ -402,7 +402,22 @@ static struct iovec *__io_import_iovec(int ddir, struct io_kiocb *req,
> >  			      req->ctx->compat);
> >  	if (unlikely(ret < 0))
> >  		return ERR_PTR(ret);
> > -	return iovec;
> > +	if (iter->nr_segs != 1)
> > +		return iovec;
> > +	/*
> > +	 * Convert to non-vectored request if we have a single segment. If we
> > +	 * need to defer the request, then we no longer have to allocate and
> > +	 * maintain a struct io_async_rw. Additionally, we won't have cleanup
> > +	 * to do at completion time
> > +	 */
> > +	rw->addr = (unsigned long) iter->iov[0].iov_base;
> > +	rw->len = iter->iov[0].iov_len;
> > +	iov_iter_ubuf(iter, ddir, iter->iov[0].iov_base, rw->len);
> > +	/* readv -> read distance is the same as writev -> write */
> > +	BUILD_BUG_ON((IORING_OP_READ - IORING_OP_READV) !=
> > +			(IORING_OP_WRITE - IORING_OP_WRITEV));
> > +	req->opcode += (IORING_OP_READ - IORING_OP_READV);
> > +	return NULL;
> >  }
> 
> This may break anyone using io_uring with those bizarre drivers that have
> entirely different readv semantics from normal read. I think we can safely say
> no one's using io_uring for such interfaces, so probably a moot point. If you
> wanted to be extra cautious though, you may want to skip this transformation if
> the file->f_op implements both .read+read_iter and .write+.write_iter.

Sorry, scratch that; those drivers are already broken if they implement both
with different semantics, so we can definitely say none of those are using
io_uring. This new patch should be safe then.