On 9/9/21 8:48 PM, Al Viro wrote:

On Thu, Sep 09, 2021 at 07:35:13PM -0600, Jens Axboe wrote:

quoted

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.

If it's no longer valid, it'll get failed, and it's really on the
application having buggy behavior. The iovec cannot be modified until
we've signaled that it's been consumed, which hasn't happened yet. No
different than if an application modifies it mid readv(2) syscall.

-- 
Jens Axboe