On 5/21/25 18:33, Stanislav Fomichev wrote:
On 05/21, Mina Almasry wrote:
On Tue, May 20, 2025 at 1:30 PM Stanislav Fomichev <stfomic...@gmail.com> wrote:
sendmsg() with a single iov becomes ITER_UBUF, sendmsg() with multiple
iovs becomes ITER_IOVEC. iter_iov_len does not return correct
value for UBUF, so teach to treat UBUF differently.
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: Pavel Begunkov <asml.sile...@gmail.com>
Cc: Mina Almasry <almasrym...@google.com>
Fixes: bd61848900bf ("net: devmem: Implement TX path")
Signed-off-by: Stanislav Fomichev <stfomic...@gmail.com>
---
include/linux/uio.h | 8 +++++++-
net/core/datagram.c | 3 ++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 49ece9e1888f..393d0622cc28 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -99,7 +99,13 @@ static inline const struct iovec *iter_iov(const struct
iov_iter *iter)
}
#define iter_iov_addr(iter) (iter_iov(iter)->iov_base + (iter)->iov_offset)
-#define iter_iov_len(iter) (iter_iov(iter)->iov_len - (iter)->iov_offset)
+
+static inline size_t iter_iov_len(const struct iov_iter *i)
+{
+ if (i->iter_type == ITER_UBUF)
+ return i->count;
+ return iter_iov(i)->iov_len - i->iov_offset;
+}
This change looks good to me from devmem perspective, but aren't you
potentially breaking all these existing callers to iter_iov_len?
ackc -i iter_iov_len
fs/read_write.c
846: iter_iov_len(iter), ppos);
849: iter_iov_len(iter), ppos);
858: if (nr != iter_iov_len(iter))
mm/madvise.c
1808: size_t len_in = iter_iov_len(iter);
1838: iov_iter_advance(iter, iter_iov_len(iter));
io_uring/rw.c
710: len = iter_iov_len(iter);
Or are you confident this change is compatible with these callers for
some reason?
Pavel did go over all callers, see:
https://lore.kernel.org/netdev/7f06216e-1e66-433e-a247-2445dac22...@gmail.com/
Yes, the patch should work
Reviewed-by: Pavel Begunkov <asml.sile...@gmail.com>
Maybe better to handle this locally in zerocopy_fill_skb_from_devmem,
and then follow up with a more ambitious change that streamlines how
all the iters behave.
Yes, I can definitely do that, but it seems a bit strange that the
callers need to distinguish between IOVEC and UBUF (which is a 1-entry
IOVEC), so having working iter_iov_len seems a bit cleaner.
It might be a good idea to rename it at some point to highlight that
it also works with ubufs (but not as a part of this fix).
--
Pavel Begunkov
