From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Graf Subject: Re: [PATCH] net: Convert skb->csum_(start|offset) integrity BUG_ON() to WARN_ON() & drop Date: Wed, 13 Feb 2013 23:48:43 +0000 Message-ID: <20130213234843.GB21829@casper.infradead.org> References: <20130213234021.GA21829@casper.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org To: davem@davemloft.net Return-path: Received: from casper.infradead.org ([85.118.1.10]:47615 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752314Ab3BMXsn (ORCPT ); Wed, 13 Feb 2013 18:48:43 -0500 Content-Disposition: inline In-Reply-To: <20130213234021.GA21829@casper.infradead.org> Sender: netdev-owner@vger.kernel.org List-ID: On 02/13/13 at 11:40pm, Thomas Graf wrote: > They have been hit with IPoIB which uses a 64K MTU. If a TCP > retransmission gets partially ACKed and collapsed multiple times > it is possible for the headroom to grow beyond 64K which will > overflow the 16bit skb->csum_start. On the subject of fixing this, I considered: a) Reallocate the headroom in tcp_trim_head() if it would overflow. I disregarded this idea because replacing the old skb with the new skb on the write queue for such a rare situation seems overkill. b) No longer collapse if the new skb would result in a a headroom + data that exceeds 64K. This seems to be the most trivial fix. c) Increase size of csum_start or store checksum_start_offset differently. Other ideas?