From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, brauner@kernel.org,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH 5/8] IB/hfi1: make hfi1_write_iter() deal with ITER_UBUF iov_iter
Date: Tue, 28 Mar 2023 15:38:50 -0600 [thread overview]
Message-ID: <ee35b429-bc53-c070-5998-97475e0ae9ff@kernel.dk> (raw)
In-Reply-To: <fc3e4956-9956-01ee-7c11-e9eef59b5e38@kernel.dk>
On 3/28/23 3:21?PM, Jens Axboe wrote:
> On 3/28/23 1:16?PM, Linus Torvalds wrote:
>> On Tue, Mar 28, 2023 at 12:05?PM Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>>
>>> But it's not like adding a 'struct iovec' explicitly to the members
>>> just as extra "code documentation" would be wrong.
>>>
>>> I don't think it really helps, though, since you have to have that
>>> other explicit structure there anyway to get the member names right.
>>
>> Actually, thinking a bit more about it, adding a
>>
>> const struct iovec xyzzy;
>>
>> member might be a good idea just to avoid a cast. Then that
>> iter_ubuf_to_iov() macro becomes just
>>
>> #define iter_ubuf_to_iov(iter) (&(iter)->xyzzy)
>>
>> and that looks much nicer (plus still acts kind of as a "code comment"
>> to clarify things).
>
> I went down this path, and it _mostly_ worked out. You can view the
> series here, I'll send it out when I've actually tested it:
>
> https://git.kernel.dk/cgit/linux-block/log/?h=iter-ubuf
>
> A few mental notes I made along the way:
>
> - The IB/sound changes are now just replacing an inappropriate
> iter_is_iovec() with iter->user_backed. That's nice and simple.
>
> - The iov_iter_iovec() case becomes a bit simpler. Or so I thought,
> because we still need to add in the offset so we can't just use
> out embedded iovec for that. The above branch is just using the
> iovec, but I don't think this is right.
>
> - Looks like it exposed a block bug, where the copy in
> bio_alloc_map_data() was obvious garbage but happened to work
> before.
>
> I'm still inclined to favor this approach over the previous, even if the
> IB driver is a pile of garbage and lighting it a bit more on fire would
> not really hurt.
>
> Opinions? Or do you want me to just send it out for easier reading
While cleaning up that stuff, we only have a few users of iov_iter_iovec().
Why don't we just kill them off and the helper too? That drops that
part of it and it kind of works out nicely beyond that.
diff --git a/fs/read_write.c b/fs/read_write.c
index 7a2ff6157eda..fb932d0997d4 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -749,15 +749,15 @@ static ssize_t do_loop_readv_writev(struct file *filp, struct iov_iter *iter,
return -EOPNOTSUPP;
while (iov_iter_count(iter)) {
- struct iovec iovec = iov_iter_iovec(iter);
+ const struct iovec *iov = iter->iov;
ssize_t nr;
if (type == READ) {
- nr = filp->f_op->read(filp, iovec.iov_base,
- iovec.iov_len, ppos);
+ nr = filp->f_op->read(filp, iov->iov_base,
+ iov->iov_len, ppos);
} else {
- nr = filp->f_op->write(filp, iovec.iov_base,
- iovec.iov_len, ppos);
+ nr = filp->f_op->write(filp, iov->iov_base,
+ iov->iov_len, ppos);
}
if (nr < 0) {
@@ -766,7 +766,7 @@ static ssize_t do_loop_readv_writev(struct file *filp, struct iov_iter *iter,
break;
}
ret += nr;
- if (nr != iovec.iov_len)
+ if (nr != iov->iov_len)
break;
iov_iter_advance(iter, nr);
}
diff --git a/io_uring/rw.c b/io_uring/rw.c
index 4c233910e200..585461a6f6a0 100644
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@ -454,7 +454,8 @@ static ssize_t loop_rw_iter(int ddir, struct io_rw *rw, struct iov_iter *iter)
iovec.iov_base = iter->ubuf + iter->iov_offset;
iovec.iov_len = iov_iter_count(iter);
} else if (!iov_iter_is_bvec(iter)) {
- iovec = iov_iter_iovec(iter);
+ iovec.iov_base = iter->iov->iov_base;
+ iovec.iov_len = iter->iov->iov_len;
} else {
iovec.iov_base = u64_to_user_ptr(rw->addr);
iovec.iov_len = rw->len;
diff --git a/mm/madvise.c b/mm/madvise.c
index 340125d08c03..0701a3bd530b 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -1456,7 +1456,8 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const struct iovec __user *, vec,
size_t, vlen, int, behavior, unsigned int, flags)
{
ssize_t ret;
- struct iovec iovstack[UIO_FASTIOV], iovec;
+ struct iovec iovstack[UIO_FASTIOV];
+ const struct iovec *iovec;
struct iovec *iov = iovstack;
struct iov_iter iter;
struct task_struct *task;
@@ -1503,12 +1504,12 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const struct iovec __user *, vec,
total_len = iov_iter_count(&iter);
while (iov_iter_count(&iter)) {
- iovec = iov_iter_iovec(&iter);
- ret = do_madvise(mm, (unsigned long)iovec.iov_base,
- iovec.iov_len, behavior);
+ iovec = iter.iov;
+ ret = do_madvise(mm, (unsigned long)iovec->iov_base,
+ iovec->iov_len, behavior);
if (ret < 0)
break;
- iov_iter_advance(&iter, iovec.iov_len);
+ iov_iter_advance(&iter, iovec->iov_len);
}
ret = (total_len - iov_iter_count(&iter)) ? : ret;
--
Jens Axboe
next prev parent reply other threads:[~2023-03-28 21:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 17:36 [PATCHSET v4 0/8] Turn single segment imports into ITER_UBUF Jens Axboe
2023-03-28 17:36 ` [PATCH 1/8] iov_iter: teach iov_iter_iovec() to deal with ITER_UBUF Jens Axboe
2023-03-28 17:36 ` [PATCH 2/8] iov_iter: add iovec_nr_user_vecs() helper Jens Axboe
2023-03-28 18:42 ` Al Viro
2023-03-28 18:45 ` Linus Torvalds
2023-03-28 19:27 ` Jens Axboe
2023-03-28 17:36 ` [PATCH 3/8] snd: move mapping an iov_iter to user bufs into a helper Jens Axboe
2023-03-28 17:36 ` [PATCH 4/8] snd: make snd_map_bufs() deal with ITER_UBUF Jens Axboe
2023-03-28 17:50 ` Linus Torvalds
2023-03-28 17:52 ` Jens Axboe
2023-03-28 18:52 ` Al Viro
2023-03-28 19:28 ` Jens Axboe
2023-03-28 17:36 ` [PATCH 5/8] IB/hfi1: make hfi1_write_iter() deal with ITER_UBUF iov_iter Jens Axboe
2023-03-28 18:43 ` Linus Torvalds
2023-03-28 18:55 ` Matthew Wilcox
2023-03-28 19:05 ` Linus Torvalds
2023-03-28 19:16 ` Linus Torvalds
2023-03-28 21:21 ` Jens Axboe
2023-03-28 21:38 ` Jens Axboe [this message]
2023-03-28 21:51 ` Jens Axboe
2023-03-28 19:30 ` Jens Axboe
2023-03-28 20:38 ` Al Viro
2023-03-28 20:46 ` Jens Axboe
2023-03-28 22:06 ` Linus Torvalds
2023-03-28 17:36 ` [PATCH 6/8] IB/qib: make qib_write_iter() " Jens Axboe
2023-03-28 17:36 ` [PATCH 7/8] iov_iter: convert import_single_range() to ITER_UBUF Jens Axboe
2023-03-28 17:36 ` [PATCH 8/8] 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=ee35b429-bc53-c070-5998-97475e0ae9ff@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 \
--cc=willy@infradead.org \
/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).