[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Sep 2021 14:56:18 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Pavel Begunkov <asml.silence@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] iov_iter fixes
On Thu, Sep 9, 2021 at 2:39 PM Jens Axboe <axboe@...nel.dk> wrote:
>
> 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.
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.
Hmm?
Linus
Powered by blists - more mailing lists