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@xxxxxxxxxx/T/#m9cec13d26c0b2db03889e1b36c9bcc20f4f8244a -- Jens Axboe
