On Fri, 2016-04-15 at 13:11 -0400, Jeff Moyer wrote:
"Verma, Vishal L" <vishal.l.verma(a)intel.com>
writes:
>
> On Fri, 2016-04-15 at 12:11 -0400, Jeff Moyer wrote:
> >
> > Vishal Verma <vishal.l.verma(a)intel.com> writes:
> > >
> > > + if (IS_DAX(inode)) {
> > > + ret = dax_do_io(iocb, inode, iter, offset,
> > > blkdev_get_block,
> > > NULL, DIO_SKIP_DIO_COUNT);
> > > - return __blockdev_direct_IO(iocb, inode,
> > > I_BDEV(inode),
> > > iter, offset,
> > > + if (ret == -EIO && (iov_iter_rw(iter) ==
> > > WRITE))
> > > + ret_saved = ret;
> > > + else
> > > + return ret;
> > > + }
> > > +
> > > + ret = __blockdev_direct_IO(iocb, inode, I_BDEV(inode),
> > > iter, offset,
> > > blkdev_get_block, NULL,
> > > NULL,
> > > DIO_SKIP_DIO_COUNT);
> > > + if (ret < 0 && ret_saved)
> > > + return ret_saved;
> > > +
> > Hmm, did you just break async DIO? I think you did! :)
> > __blockdev_direct_IO can return -EIOCBQUEUED, and you've now
> > turned
> > that
> > into -EIO. Really, I don't see a reason to save that first
> > -EIO. The
> > same applies to all instances in this patch.
> The reason I saved it was if __blockdev_direct_IO fails for some
> reason, we should return the original cause o the error, which was
> an
> EIO.. i.e. we shouldn't be hiding the EIO if the direct_IO fails
> with
> something else..
OK.
>
> But, how does _EIOCBQUEUED work? Maybe we need an exception for it?
For async direct I/O, only the setup phase of the I/O is performed
and
then we return to the caller. -EIOCBQUEUED signifies this.
You're heading towards code that looks like this:
if (IS_DAX(inode)) {
ret = dax_do_io(iocb, inode, iter, offset,
blkdev_get_block,
NULL, DIO_SKIP_DIO_COUNT);
if (ret == -EIO && (iov_iter_rw(iter) == WRITE))
ret_saved = ret;
else
return ret;
}
ret = __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
offset,
blkdev_get_block, NULL, NULL,
DIO_SKIP_DIO_COUNT);
if (ret < 0 && ret != -EIOCBQUEUED && ret_saved)
return ret_saved;
There's a lot of special casing here, so you might consider adding
comments.
Correct - maybe we should reconsider wrapper-izing this? :)
Thanks for the explanation and for catching this. I'll fix it for the
next revision.
>
> Cheers,
> Jeff