On Thu, Sep 9, 2021 at 3:21 PM Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> On 9/9/21 3:56 PM, Linus Torvalds wrote:
> >
> > IOW, can't we have that
> >
> > ret = io_iter_do_read(req, iter);
> >
> > return partial success - and if XFS does that "update iovec on
> > failure", I could easily see that same code - or something else -
> > having done the exact same thing.
> >
> > Put another way: if the iovec isn't guaranteed to be coherent when an
> > actual error occurs, then why would it be guaranteed to be coherent
> > with a partial success value?
> >
> > Because in most cases - I'd argue pretty much all - those "partial
> > success" cases are *exactly* the same as the error cases, it's just
> > that we had a loop and one or more iterations succeeded before it hit
> > the error case.
>
> Right, which is why the reset would be nice, but reexpand + revert at
> least works and accomplishes the same even if it doesn't look as pretty.
You miss my point.
The partial success case seems to do the wrong thing.
Or am I misreading things? Lookie here, in io_read():
ret = io_iter_do_read(req, iter);
let's say that something succeeds partially, does X bytes, and returns
a positive X.
The if-statements following it then do not trigger:
if (ret == -EAGAIN || (req->flags & REQ_F_REISSUE)) {
.. not this case ..
} else if (ret == -EIOCBQUEUED) {
.. nor this ..
} else if (ret <= 0 || ret == io_size || !force_nonblock ||
(req->flags & REQ_F_NOWAIT) || !(req->flags & REQ_F_ISREG)) {
.. nor this ..
}
so nothing has been done to the iovec at all.
Then it does
ret2 = io_setup_async_rw(req, iovec, inline_vecs, iter, true);
using that iovec that has *not* been reset, even though it really
should have been reset to "X bytes read".
See what I'm trying to say?
Linus
