On Thu, 2013-02-28 at 16:45 +0000, Thomas Graf wrote:

On 02/28/13 at 08:18am, Eric Dumazet wrote:

quoted

but.... what is the value of skb_availroom(to) ?

The earlier test at line 2302 should already guard this case ?

               /* Punt if not enough space exists in the first SKB for
                 * the data in the second
                 */
                if (skb->len > skb_availroom(to))
                        break;

Only if it is guaranteed that we never see an MSS > 64K.

Assuming that is true forever, then a21d45726 (tcp: avoid order-1
allocations on wifi and tx path) does in fact resolve this
issue at the cost of not being able to use the extra room
kmalloc() might have given us in __alloc_skb() for collapsing.

Was that an intentional side effect of a21d45726?

This had a followup with 22b4a4f22da4
(tcp: fix retransmit of partially acked frames)

I also wonder if there is not another similar potential problem in
__tcp_retransmit_skb) after call to 

tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)

csum_start can overflow again because of MAX_TCP_HEADER headroom
reserve.

So maybe we should limit TCP MTU to (64K - MAX_TCP_HEADER)