On 05/21, Mina Almasry wrote:
On Tue, May 20, 2025 at 1:30 PM Stanislav Fomichev stfomichev@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 viro@zeniv.linux.org.uk Cc: Pavel Begunkov asml.silence@gmail.com Cc: Mina Almasry almasrymina@google.com Fixes: bd61848900bf ("net: devmem: Implement TX path") Signed-off-by: Stanislav Fomichev stfomichev@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-2445dac22498@gmail.co...
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.