Thread (46 messages) 46 messages, 7 authors, 2021-09-13

Re: [git pull] iov_iter fixes

From: Jens Axboe <axboe@kernel.dk>
Date: 2021-09-09 22:21:32
Also in: linux-fsdevel

On 9/9/21 3:56 PM, Linus Torvalds wrote:
On Thu, Sep 9, 2021 at 2:39 PM Jens Axboe [off-list ref] wrote:
quoted
OK, one that I immediately found is just doing O_DIRECT to a block
device or file on XFS. As pages are mapped and added, the iov_iter is
advanced. If we then go and submit and get -EAGAIN, for example, then we
return with what we mapped already consumed.
Ok, that's annoying but understandable. Dave points to a commit that
removes one of the EAGAIN cases, but apparently not some others.
That one just catches it upfront so we -EAGAIN immediately, which does
make it a lot easier to handle. But yes, that's an example.

The case I mention we basically always consume the whole iov, to the
extent that we can map it to a bio. But there's really no way around
that, we have to map it before we can attempt to do that IO.
I do kind of wonder if you can't have the exact same case when *some*
of the IO succeeds, though.

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.
We do return how much IO was actually done from the various
->read/write_iter() obviously, and that cannot be incorrect. It's just
that the iov_iter doesn't necessarily agree with that view and more (or
all) may have been consumed regardless of the return value. The truncate
was really the part that made it impossible to handle.

-- 
Jens Axboe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help