All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, brauner@kernel.org,
	viro@zeniv.linux.org.uk
Subject: Re: [PATCH 1/4] fs: make do_loop_readv_writev() deal with ITER_UBUF
Date: Mon, 27 Mar 2023 13:06:40 -0600	[thread overview]
Message-ID: <2d33d8dc-ed1f-ed74-5cc5-040e321ac34f@kernel.dk> (raw)
In-Reply-To: <CAHk-=wh4SOZ=kfxOe+pFvWFM4HHTAhXMwwcm3D_R6qR_m148Yw@mail.gmail.com>

On 3/27/23 1:03?PM, Linus Torvalds wrote:
> On Mon, Mar 27, 2023 at 11:04?AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -748,10 +748,21 @@ static ssize_t do_loop_readv_writev(struct file *filp, struct iov_iter *iter,
>>         if (flags & ~RWF_HIPRI)
>>                 return -EOPNOTSUPP;
>>
>> +       if (WARN_ON_ONCE(iter->iter_type != ITER_IOVEC &&
>> +                        iter->iter_type != ITER_UBUF))
>> +               return -EINVAL;
> 
> Hmm. I think it might actually be nicer for the "iter_is_ubuf(iter)"
> case to be outside the loop entirely, and be done before this
> WARN_ON_ONCE().
> 
> If it's a single ITER_UBUF, that code really shouldn't loop at all -
> it's literally just the old case of "call ->read/write with a single
> buffer".
> 
> So i think I'd prefer this patch to be something along the lines of
> this instead:

See Al's suggestion in the other thread, I like that a lot better as it
avoids any potential wack-a-mole with potentially similar cases. There
are not a lot of hits for iov_iter_iovec() in the three and I spotted
two, which lead to these two prep patches. But if we do:

https://git.kernel.dk/cgit/linux-block/commit/?h=iter-ubuf&id=8a825a6f52e8fab74e936f15eea6c34ac67272f6

then we don't really have to worry about those.

-- 
Jens Axboe


  reply	other threads:[~2023-03-27 19:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 18:04 [PATCHSET v2 0/4] Turn single segment imports into ITER_UBUF Jens Axboe
2023-03-27 18:04 ` [PATCH 1/4] fs: make do_loop_readv_writev() deal with ITER_UBUF Jens Axboe
2023-03-27 19:03   ` Linus Torvalds
2023-03-27 19:06     ` Jens Axboe [this message]
2023-03-27 19:11       ` Linus Torvalds
2023-03-27 19:13         ` Linus Torvalds
2023-03-27 19:14           ` Jens Axboe
2023-03-27 18:04 ` [PATCH 2/4] mm: make process_madvise() " Jens Axboe
2023-03-27 18:04 ` [PATCH 3/4] iov_iter: convert import_single_range() to ITER_UBUF Jens Axboe
2023-03-27 18:04 ` [PATCH 4/4] iov_iter: import single vector iovecs as ITER_UBUF Jens Axboe

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=2d33d8dc-ed1f-ed74-5cc5-040e321ac34f@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.