liburing 500f9fbadef8-test test failure on top-of-tree

liburing 500f9fbadef8-test test failure on top-of-tree

[Jeff Moyer]

Hi,

This test case is failing for me when run atop a dm device.  The test
sets up a ring with IO_SETUP_IOPOLL, creates a file and opens it with
O_DIRECT, and then issues a writev.  The writev operation is returning
-22 (-EINVAL).  The failure comes from this check inside io_import_iov:

	/* buffer index only valid with fixed read/write, or buffer select  */
        if (req->rw.kiocb.private && !(req->flags & REQ_F_BUFFER_SELECT))
                return -EINVAL;

req->rw.kiocb.private is being used by the iomap code to store a pointer
to the request queue.  The sequence of events is as follows:

io_write is called in the context of the system call, it calls
call_write_iter, which returns -EAGAIN.  The I/O is punted to a
workqueue.

The work item then tries to issue the I/O after clearing IOCB_NOWAIT,
and for some reason fails again with -EAGAIN.

On the *third* call to io_write, the private pointer has been
overwitten, and we trigger the above -EINVAL return.

I have no idea why we're getting EAGAIN on the first call in the
workqueue context, so I'm not sure if that's the problem, of if we
simply can't use the kiocb.private pointer for this purpose.  It seems
clear that once we've called into the iomap code, we can't rely on the
contents of kiocb.private.

Jens, what do you think?

-Jeff

Re: liburing 500f9fbadef8-test test failure on top-of-tree

[Jens Axboe]

On 5/19/20 3:58 PM, Jeff Moyer wrote:
> Hi,
> 
> This test case is failing for me when run atop a dm device.  The test
> sets up a ring with IO_SETUP_IOPOLL, creates a file and opens it with
> O_DIRECT, and then issues a writev.  The writev operation is returning
> -22 (-EINVAL).  The failure comes from this check inside io_import_iov:
> 
> 	/* buffer index only valid with fixed read/write, or buffer select  */
>         if (req->rw.kiocb.private && !(req->flags & REQ_F_BUFFER_SELECT))
>                 return -EINVAL;
> 
> req->rw.kiocb.private is being used by the iomap code to store a pointer
> to the request queue.  The sequence of events is as follows:
> 
> io_write is called in the context of the system call, it calls
> call_write_iter, which returns -EAGAIN.  The I/O is punted to a
> workqueue.
> 
> The work item then tries to issue the I/O after clearing IOCB_NOWAIT,
> and for some reason fails again with -EAGAIN.
> 
> On the *third* call to io_write, the private pointer has been
> overwitten, and we trigger the above -EINVAL return.
> 
> I have no idea why we're getting EAGAIN on the first call in the
> workqueue context, so I'm not sure if that's the problem, of if we
> simply can't use the kiocb.private pointer for this purpose.  It seems
> clear that once we've called into the iomap code, we can't rely on the
> contents of kiocb.private.
> 
> Jens, what do you think?

See: https://lore.kernel.org/io-uring/1589925170-48687-1-git-send-email-bijan.mottahedeh@oracle.com/T/#m9cec13d26c0b2db03889e1b36c9bcc20f4f8244a

-- 
Jens Axboe

Re: liburing 500f9fbadef8-test test failure on top-of-tree

[Jeff Moyer]

Jens Axboe <axboe@kernel.dk> writes:

>> Jens, what do you think?
>
> See: https://lore.kernel.org/io-uring/1589925170-48687-1-git-send-email-bijan.mottahedeh@oracle.com/T/#m9cec13d26c0b2db03889e1b36c9bcc20f4f8244a

Hmm, I wonder why that hasn't landed in my inbox yet.  Oh well, glad
it's resolved.  I think I also hit the issue fixed by patch2.  I'll test
that as well.

Thanks!
Jeff