Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [git pull] iov_iter fixes
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>
References: <YTmL/plKyujwhoaR@zeniv-ca.linux.org.uk>
 <CAHk-=wiacKV4Gh-MYjteU0LwNBSGpWrK-Ov25HdqB1ewinrFPg@mail.gmail.com>
 <5971af96-78b7-8304-3e25-00dc2da3c538@kernel.dk>
 <ebc6cc5e-dd43-6370-b462-228e142beacb@kernel.dk>
 <CAHk-=whoMLW-WP=8DikhfE4xAu_Tw9jDNkdab4RGEWWMagzW8Q@mail.gmail.com>
 <ebb7b323-2ae9-9981-cdfd-f0f460be43b3@kernel.dk>
 <CAHk-=wi2fJ1XrgkfSYgn9atCzmJZ8J3HO5wnPO0Fvh5rQx9mmA@mail.gmail.com>
 <88f83037-0842-faba-b68f-1d4574fb45cb@kernel.dk>
 <YTrHYYEQslQzvnWW@zeniv-ca.linux.org.uk>
 <8d9e4f7c-bcf4-2751-9978-6283cabeda52@kernel.dk>
 <YTrN16wu/KE0X/QZ@zeniv-ca.linux.org.uk>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <641dbf64-b1c4-41f1-6522-e3b0ac9328c2@kernel.dk>
Date:   Thu, 9 Sep 2021 21:23:08 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <YTrN16wu/KE0X/QZ@zeniv-ca.linux.org.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/9/21 9:15 PM, 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"...

If the application changes the iovec passed in while it hasn't been
consumed yet, it's buggy. Period. We obviously need to ensure that we
only do this re-import IFF we're in the same original submit context
still.

-- 
Jens Axboe