| Message ID | 20200504162948.4146-1-kelly@onechronos.com |
|---|---|
| State | New |
| Headers | show |
| Series | net: tcp: fix rx timestamp behavior for tcp_recvmsg | expand |
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))
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 <iris@onechronos.com> Signed-off-by: Iris Liu <iris@onechronos.com> Signed-off-by: Kelly Littlepage <kelly@onechronos.com> --- net/ipv4/tcp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)