linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Pavel Begunkov <asml.silence@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] iov_iter fixes
Date: Thu, 9 Sep 2021 19:35:13 -0600	[thread overview]
Message-ID: <88f83037-0842-faba-b68f-1d4574fb45cb@kernel.dk> (raw)
In-Reply-To: <CAHk-=wi2fJ1XrgkfSYgn9atCzmJZ8J3HO5wnPO0Fvh5rQx9mmA@mail.gmail.com>

On 9/9/21 4:56 PM, Linus Torvalds wrote:
> 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?

Yep ok I follow you now. And yes, if we get a partial one but one that
has more consumed than what was returned, that would not work well. I'm
guessing that a) we've never seen that, or b) we always end up with
either correctly advanced OR fully advanced, and the fully advanced case
would then just return 0 next time and we'd just get a short IO back to
userspace.

The safer way here would likely be to import the iovec again. We're
still in the context of the original submission, and the sqe hasn't been
consumed in the ring yet, so that can be done safely.

-- 
Jens Axboe


  reply	other threads:[~2021-09-10  1:35 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09  4:22 [git pull] iov_iter fixes Al Viro
2021-09-09 19:37 ` Linus Torvalds
2021-09-09 21:19   ` Jens Axboe
2021-09-09 21:39     ` Jens Axboe
2021-09-09 21:56       ` Linus Torvalds
2021-09-09 22:21         ` Jens Axboe
2021-09-09 22:56           ` Linus Torvalds
2021-09-10  1:35             ` Jens Axboe [this message]
2021-09-10  2:43               ` Jens Axboe
2021-09-10  2:48               ` Al Viro
2021-09-10  3:06                 ` Jens Axboe
2021-09-10  3:15                   ` Al Viro
2021-09-10  3:23                     ` Jens Axboe
2021-09-10  3:24                     ` Al Viro
2021-09-10  3:28                       ` Jens Axboe
2021-09-13 15:29                 ` David Laight
2021-09-09 21:42     ` Dave Chinner
2021-09-10  2:57     ` Al Viro
2021-09-10  3:05       ` Jens Axboe
2021-09-10  3:11         ` Al Viro
2021-09-10  3:22           ` Jens Axboe
2021-09-10  3:27             ` Al Viro
2021-09-10  3:30               ` Jens Axboe
2021-09-10  3:36                 ` Al Viro
2021-09-10 13:57                   ` Jens Axboe
2021-09-10 14:42                     ` Al Viro
2021-09-10 15:08                       ` Jens Axboe
2021-09-10 15:32                         ` Al Viro
2021-09-10 15:36                           ` Jens Axboe
2021-09-10 15:04                     ` Jens Axboe
2021-09-10 16:06                       ` Jens Axboe
2021-09-10 16:44                         ` Linus Torvalds
2021-09-10 16:56                         ` Al Viro
2021-09-10 16:58                           ` Linus Torvalds
2021-09-10 17:26                             ` Jens Axboe
2021-09-10 17:31                               ` Linus Torvalds
2021-09-10 17:32                                 ` Jens Axboe
2021-09-10 18:48                                 ` Al Viro
2021-09-10 19:04                                   ` Linus Torvalds
2021-09-10 19:10                                     ` Linus Torvalds
2021-09-10 19:10                                   ` Jens Axboe
2021-09-10 17:04                           ` Jens Axboe
2021-09-09 22:54   ` Pavel Begunkov
2021-09-09 22:57     ` Pavel Begunkov
2021-09-09 23:14   ` Pavel Begunkov
2021-09-09 20:03 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=88f83037-0842-faba-b68f-1d4574fb45cb@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=asml.silence@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).