[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1322924992.2762.117.camel@edumazet-laptop>
Date: Sat, 03 Dec 2011 16:09:52 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Miller <davem@...emloft.net>
Cc: subramanian.vijay@...il.com, therbert@...gle.com,
netdev@...r.kernel.org
Subject: Re: Bug in computing data_len in tcp_sendmsg?
Le vendredi 02 décembre 2011 à 16:30 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@...il.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 !
--
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
Powered by blists - more mailing lists