Timestamping cmsgs are not returned when the user buffer supplied to
recvmsg is too small to copy at least one skbuff in entirety. Support
for TCP rx timestamps came from commit 98aaa913b4ed ("tcp: Extend
SOF_TIMESTAMPING_RX_SOFTWARE to TCP recvmsg") which noted that the cmsg
should "return the timestamp corresponding to the highest sequence
number data returned." The commit further notes that when coalescing
skbs code should "maintain the invariant of returning the timestamp of
the last byte in the recvmsg buffer."
This is consistent with Section 1.4 of timestamping.txt, a document that
discusses expected behavior when timestamping streaming protocols. It's
worth noting that Section 1.4 alludes to a "buffer" in a way that might
have resulted in the current behavior:
> The SO_TIMESTAMPING interface supports timestamping of bytes in a
bytestream. Each request is interpreted as a request for when the entire
contents of the buffer has passed a timestamping point....In practice,
timestamps can be correlated with segments of a bytestream consistently,
if both semantics of the timestamp and the timing of measurement are
chosen correctly....For bytestreams, we chose that a timestamp is
generated only when all bytes have passed a point.
An interpretation of skbs as delineators for timestamping points makes
sense for tx timestamps but poses implementation challenges on the rx
side. Under the current API unless tcp_recvmsg happens to return bytes
copied from precisely one skb there's no useful mapping from bytes to
timestamps. Some sequences of reads will result in timestamps getting
lost and others will result in the user receiving a timestamp from the
second to last skb that tcp_recvmsg copied from instead of the last. The
proposed change addresses both problems while remaining consistent with
1.4 and the wording of commit 98aaa913b4ed ("tcp: Extend
SOF_TIMESTAMPING_RX_SOFTWARE to TCP recvmsg").
Co-developed-by: Iris Liu <i...@onechronos.com>
Signed-off-by: Iris Liu <i...@onechronos.com>
Signed-off-by: Kelly Littlepage <ke...@onechronos.com>
---
net/ipv4/tcp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 6d87de434377..e72bd651d21a 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2154,13 +2154,15 @@ int tcp_recvmsg(struct sock *sk, struct msghdr *msg,
size_t len, int nonblock,
tp->urg_data = 0;
tcp_fast_path_check(sk);
}
- if (used + offset < skb->len)
- continue;
if (TCP_SKB_CB(skb)->has_rxtstamp) {
tcp_update_recv_tstamps(skb, &tss);
cmsg_flags |= 2;
}
+
+ if (used + offset < skb->len)
+ continue;
+
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
goto found_fin_ok;
if (!(flags & MSG_PEEK))
--
2.26.2
--
This email and any attachments thereto may contain private, confidential,
and privileged material for the sole use of the intended recipient. If you
are not the intended recipient or otherwise believe that you have received
this message in error, please notify the sender immediately and delete the
original. Any review, copying, or distribution of this email (or any
attachments thereto) by others is strictly prohibited. If this message was
misdirected, OCX Group Inc. does not waive any confidentiality or privilege.
