On Fri, 2016-04-15 at 12:11 -0400, Jeff Moyer wrote:
> Vishal Verma <vishal.l.verma@xxxxxxxxx> writes:
>
> >
> > dax_do_io (called for read() or write() for a dax file system) may
> > fail
> > in the presence of bad blocks or media errors. Since we expect that
> > a
> > write should clear media errors on nvdimms, make dax_do_io fall
> > back to
> > the direct_IO path, which will send down a bio to the driver, which
> > can
> > then attempt to clear the error.
> [snip]
>
> >
> > + 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..
But, how does _EIOCBQUEUED work? Maybe we need an exception for it?
Thanks,
-Vishal��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
