Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 9 Sep 2021 15:56:09 -0700 | Subject | Re: [git pull] iov_iter fixes |
| |
On Thu, Sep 9, 2021 at 3:21 PM Jens Axboe <axboe@kernel.dk> 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
| |