From: Torin Carey <torin@tcarey.uk>
To: netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH] udp: change MSG_TRUNC return behaviour for MSG_PEEK in recvmsg
Date: Tue, 22 Mar 2022 19:03:52 +0000 [thread overview]
Message-ID: <YjodjXHN7j69h/kd@kappa> (raw)
Make UDP recvmsg only return the MSG_TRUNC flag if the read does not
copy the tail end of the datagram. Specifically, this targets MSG_PEEK
when we're using a positive peek offset.
The current behaviour means that if we have a positive peek offset `off`
and we're reading `r` bytes from a datagram of `ulen` length, we respond
with MSG_TRUNC if and only if `r <= ulen - off`. This is odd behaviour
as we return MSG_TRUNC if the user requests exactly `ulen - off` which
has no truncation.
The behaviour could be corrected in two ways:
This patch returns MSG_TRUNC only for tail-end truncation and not head
truncation. This is more consistent with recv(2):
> MSG_TRUNC
> indicates that the trailing portion of a datagram was discarded
> because the datagram was larger than the buffer supplied.
although this isn't written with SO_PEEK_OFF in mind.
The second option is to always return MSG_TRUNC if `off > 0` like the
man-pages socket(7) page states:
> For datagram sockets, if the "peek offset" points to the middle of a
> packet, the data returned will be marked with the MSG_TRUNC flag.
Signed-off-by: Torin Carey <torin@tcarey.uk>
---
net/ipv4/udp.c | 2 +-
net/ipv6/udp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 319dd7bbfe33..e57740a2c308 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1855,7 +1855,7 @@ int udp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
copied = len;
if (copied > ulen - off)
copied = ulen - off;
- else if (copied < ulen)
+ else if (copied < ulen - off)
msg->msg_flags |= MSG_TRUNC;
/*
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 14a94cddcf0b..d6c0eed94564 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -348,7 +348,7 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
copied = len;
if (copied > ulen - off)
copied = ulen - off;
- else if (copied < ulen)
+ else if (copied < ulen - off)
msg->msg_flags |= MSG_TRUNC;
is_udp4 = (skb->protocol == htons(ETH_P_IP));
--
2.34.1
next reply other threads:[~2022-03-22 19:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 19:03 Torin Carey [this message]
2022-03-23 1:57 ` [PATCH] udp: change MSG_TRUNC return behaviour for MSG_PEEK in recvmsg David Laight
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=YjodjXHN7j69h/kd@kappa \
--to=torin@tcarey.uk \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.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 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.