[PATCH] Fix io_read() and io_write() when io_import_fixed() is used.

[PATCH] Fix io_read() and io_write() when io_import_fixed() is used.

[David Laight]

io_import_fixed() returns 0 on success so io_import_iovec() may
not return the length of the transfer.

Instead always use the value from iov_iter_count()
(Which is called at the same place.)

Fixes 9d93a3f5a (modded by 491381ce0) and 9e645e110.

Signed-off-by: David Laight <david.laight@aculab.com>
---

Spotted while working on another patch to change the return value
of import_iovec() to be the address of the memory to kfree().

 fs/io_uring.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index bde73b1..28128aa 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1376,7 +1376,7 @@ static int io_read(struct io_kiocb *req, const struct sqe_submit *s,
 	struct iov_iter iter;
 	struct file *file;
 	size_t iov_count;
-	ssize_t read_size, ret;
+	ssize_t ret;
 
 	ret = io_prep_rw(req, s, force_nonblock);
 	if (ret)
@@ -1390,11 +1390,10 @@ static int io_read(struct io_kiocb *req, const struct sqe_submit *s,
 	if (ret < 0)
 		return ret;
 
-	read_size = ret;
+	iov_count = iov_iter_count(&iter);
 	if (req->flags & REQ_F_LINK)
-		req->result = read_size;
+		req->result = iov_count;
 
-	iov_count = iov_iter_count(&iter);
 	ret = rw_verify_area(READ, file, &kiocb->ki_pos, iov_count);
 	if (!ret) {
 		ssize_t ret2;
@@ -1414,7 +1413,7 @@ static int io_read(struct io_kiocb *req, const struct sqe_submit *s,
 		 */
 		if (force_nonblock && !(req->flags & REQ_F_NOWAIT) &&
 		    (req->flags & REQ_F_ISREG) &&
-		    ret2 > 0 && ret2 < read_size)
+		    ret2 > 0 && ret2 < iov_count)
 			ret2 = -EAGAIN;
 		/* Catch -EAGAIN return for forced non-blocking submission */
 		if (!force_nonblock || ret2 != -EAGAIN) {
@@ -1455,10 +1454,9 @@ static int io_write(struct io_kiocb *req, const struct sqe_submit *s,
 	if (ret < 0)
 		return ret;
 
-	if (req->flags & REQ_F_LINK)
-		req->result = ret;
-
 	iov_count = iov_iter_count(&iter);
+	if (req->flags & REQ_F_LINK)
+		req->result = iov_count;
 
 	ret = -EAGAIN;
 	if (force_nonblock && !(kiocb->ki_flags & IOCB_DIRECT)) {
-- 
1.8.1.2

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH] Fix io_read() and io_write() when io_import_fixed() is used.

[Jens Axboe]

On 2/4/20 4:20 AM, David Laight wrote:
> io_import_fixed() returns 0 on success so io_import_iovec() may
> not return the length of the transfer.
> 
> Instead always use the value from iov_iter_count()
> (Which is called at the same place.)
> 
> Fixes 9d93a3f5a (modded by 491381ce0) and 9e645e110.

What kernel is this against? This shouldn't be an issue
in anything newer than 5.3-stable.

-- 
Jens Axboe

RE: [PATCH] Fix io_read() and io_write() when io_import_fixed() is used.

[David Laight]

From: Jens Axboe
> Sent: 04 February 2020 14:01
> On 2/4/20 4:20 AM, David Laight wrote:
> > io_import_fixed() returns 0 on success so io_import_iovec() may
> > not return the length of the transfer.
> >
> > Instead always use the value from iov_iter_count()
> > (Which is called at the same place.)
> >
> > Fixes 9d93a3f5a (modded by 491381ce0) and 9e645e110.
> 
> What kernel is this against? This shouldn't be an issue
> in anything newer than 5.3-stable.

Sources are 5.4.0-rc7.
So not entirely 'the latest'.
I didn't update late in the 5.5 cycle and won't until
we get to rc4 (or so).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH] Fix io_read() and io_write() when io_import_fixed() is used.

[Jens Axboe]

On 2/4/20 7:05 AM, David Laight wrote:
> From: Jens Axboe
>> Sent: 04 February 2020 14:01
>> On 2/4/20 4:20 AM, David Laight wrote:
>>> io_import_fixed() returns 0 on success so io_import_iovec() may
>>> not return the length of the transfer.
>>>
>>> Instead always use the value from iov_iter_count()
>>> (Which is called at the same place.)
>>>
>>> Fixes 9d93a3f5a (modded by 491381ce0) and 9e645e110.
>>
>> What kernel is this against? This shouldn't be an issue
>> in anything newer than 5.3-stable.
> 
> Sources are 5.4.0-rc7.
> So not entirely 'the latest'.
> I didn't update late in the 5.5 cycle and won't until
> we get to rc4 (or so).

Ah ok, I think that's why. 5.4-stable will have a fix, 5.4.0
probably not. 5.5-rc and forward should be fine.

-- 
Jens Axboe