Re: Bug in computing data_len in tcp_sendmsg?

[Eric Dumazet <eric.dumazet@gmail.com>]

Le vendredi 02 décembre 2011 à 16:30 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 02 Dec 2011 21:45:56 +0100
> 
> > Retransmits could transmits 3 bytes already ACKed, is it a big deal ?
> 
> Unfortunately this kind of adjustment doesn't work.
> 
> When we trim the head in response to ACK'd data, the stack assumes that
> the first byte sitting at the front of the retransmit queue is ->snd_una.
> 
> So if you just back align the pull, and don't make amends for the setting
> of ->snd_una, we'll retransmit the wrong bytes.  The send queue will be
> out of sync with the sequence number state of the socket.
> 
> This has implications for SACK tagging state bit in the transmit queue
> as well.
> 
> In fact, this is a real dangerous road to go down, I think :-)


Yeah, it was not a good idea :)

My plan is to add a third parameter to pskb_copy(struct sk_buff *skb,
gfp_t gfp_mask, int reserve)

and use pskb_copy() in tcp_retransmit_skb() if it appears we need
between 1 and 3 bytes to re-align skb head before calling
tcp_transmit_skb(), (if NET_IP_ALIGN is not null)

[ In the unlikely case we had to allocate a new skb with pskb_copy(), we
will pass clone_it=0 to tcp_transmit_skb() ]

I'll send a fully tested patch before the end of week end.

Thanks !