netdev - Re: [PATCH net-next v4 5/6] net-timestamp: TCP timestamping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 06 Aug 2014 09:05:49 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Willem de Bruijn <willemb@...gle.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net,
	richardcochran@...il.com
Subject: Re: [PATCH net-next v4 5/6] net-timestamp: TCP timestamping

On Mon, 2014-08-04 at 22:11 -0400, Willem de Bruijn wrote:
> TCP timestamping extends SO_TIMESTAMPING to bytestreams.
> 
> Bytestreams do not have a 1:1 relationship between send() buffers and
> network packets. The feature interprets a send call on a bytestream as
> a request for a timestamp for the last byte in that send() buffer.
> 
> The choice corresponds to a request for a timestamp when all bytes in
> the buffer have been sent. That assumption depends on in-order kernel
> transmission. This is the common case. That said, it is possible to
> construct a traffic shaping tree that would result in reordering.
> The guarantee is strong, then, but not ironclad.
> 
> This implementation supports send and sendpages (splice). GSO replaces
> one large packet with multiple smaller packets. This patch also copies
> the option into the correct smaller packet.
> 
> This patch does not yet support timestamping on data in an initial TCP
> Fast Open SYN, because that takes a very different data path.
> 
> If ID generation in ee_data is enabled, bytestream timestamps return a
> byte offset, instead of the packet counter for datagrams.
> 
> The implementation supports a single timestamp per packet. It silenty
> replaces requests for previous timestamps. To avoid missing tstamps,
> flush the tcp queue by disabling Nagle, cork and autocork. Missing
> tstamps can be detected by offset when the ee_data ID is enabled.
> 
> Implementation details:
> 
> - On GSO, the timestamping code can be included in the main loop. I
> moved it into its own loop to reduce the impact on the common case
> to a single branch.
> 
> - To avoid leaking the absolute seqno to userspace, the offset
> returned in ee_data must always be relative. It is an offset between
> an skb and sk field. The first is always set (also for GSO & ACK).
> The second must also never be uninitialized. Only allow the ID
> option on sockets in the ESTABLISHED state, for which the seqno
> is available. Never reset it to zero (instead, move it to the
> current seqno when reenabling the option).
> 
> Signed-off-by: Willem de Bruijn <willemb@...gle.com>
> 


I believe you missed fact that a GSO packet can be split into 2 or many
skbs, when tcp_write_xmit() has to send a lower amount.

This is done in tso_fragment()

Also, I am a bit worried about retransmits ?



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html