linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	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 21:28:51 -0600	[thread overview]
Message-ID: <4f9960f0-26bd-5972-3dcf-f2e2d63ea283@kernel.dk> (raw)
In-Reply-To: <YTrP0EbPaZ4c67Ij@zeniv-ca.linux.org.uk>

On 9/9/21 9:24 PM, Al Viro wrote:
> On Fri, Sep 10, 2021 at 03:15:35AM +0000, Al Viro wrote:
>> On Thu, Sep 09, 2021 at 09:06:58PM -0600, Jens Axboe wrote:
>>> On 9/9/21 8:48 PM, Al Viro wrote:
>>>> On Thu, Sep 09, 2021 at 07:35:13PM -0600, Jens Axboe wrote:
>>>>
>>>>> 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.
>>>>
>>>> ... until you end up with something assuming that you've got the same
>>>> iovec from userland the second time around.
>>>>
>>>> IOW, generally it's a bad idea to do that kind of re-imports.
>>>
>>> That's really no different than having one thread do the issue, and
>>> another modify the iovec while it happens. It's only an issue if you
>>> don't validate it, just like you did the first time you imported. No
>>> assumptions need to be made here.
>>
>> 	It's not "need to be made", it's "will be mistakenly made by
>> somebody several years down the road"...
> 
> E.g. somebody blindly assuming that the amount of data read the last
> time around will not exceed the size of reimported iov_iter.  What I'm
> saying is that there's a plenty of ways to fuck up in that direction,
> and they will *not* be caught by normal fuzzers.

If the plan pans out, it's literally doing the _exact_ same thing that
we did originally. No assumptions are made about the contents of the
iovecs originally passed in, none of that state is reused. It's an
identical import to what was originally done.

I'm not saying it's trivial, but as long as the context is correct, then
it really should be pretty straight forward...

> I'm not arguing in favour of an uncoditional copy, BTW - I would like
> to see something resembling profiling data, but it's obviously not a
> pretty solution.

I can tell you right now that it's unworkable, it'll be a very
noticeable slowdown. And it's very much a case of doing the slow path
for the extreme corner case of ever hitting this case. For most
workloads, you'll _never_ hit it. But we obviously have to be able to do
it, for the slower cases (like SCSI with low QD, it'd trigger pretty
easily).

-- 
Jens Axboe


  reply	other threads:[~2021-09-10  3:28 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
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 [this message]
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=4f9960f0-26bd-5972-3dcf-f2e2d63ea283@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).