Herbert Xu writes:
[NETFILTER]: Clear GSO bits for TCP reset packet
The TCP reset packet is copied from the original. This
includes all the GSO bits which do not apply to the new
packet. So we should clear those bits.
Spotted by Patrick McHardy.
Signed-off-by: Herbert Xu [EMAIL
Herbert Xu wrote:
Mike Accetta [EMAIL PROTECTED] wrote:
Obviously the code believes it can assume that there are always multiple
sk_buff's in the chain. The stack trace seems to implicate iptables in
the scenario (twice) if that means anything. Any ideas about what may
be going wrong here?
Patrick McHardy writes:
Herbert Xu wrote:
Mike Accetta [EMAIL PROTECTED] wrote:
Obviously the code believes it can assume that there are always multiple
sk_buff's in the chain. The stack trace seems to implicate iptables in
the scenario (twice) if that means anything. Any ideas about
On Tue, Feb 13, 2007 at 03:34:43PM +0100, Patrick McHardy wrote:
The callpath shows the REJECT target sending a TCP reset.
I'm guessing it has something to do with skb_copy_expand
copying the gso fields.
Indeed. We need to reset the GSO bits there since the new
packet is nothing like the one
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 14 Feb 2007 04:51:21 +1100
On Tue, Feb 13, 2007 at 03:34:43PM +0100, Patrick McHardy wrote:
The callpath shows the REJECT target sending a TCP reset.
I'm guessing it has something to do with skb_copy_expand
copying the gso fields.
Indeed.
On Tue, Feb 13, 2007 at 12:34:13PM -0800, David Miller wrote:
I'm kind of challenged for time as I'll be out of town from
Wednesday until Sunday, so if someone could cook up the TSO
variable of the patch for pre-GSO kernels I'd appreciate it.
Sure, here is the patch for any kernel prior to
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 14 Feb 2007 08:51:58 +1100
On Tue, Feb 13, 2007 at 12:34:13PM -0800, David Miller wrote:
I'm kind of challenged for time as I'll be out of town from
Wednesday until Sunday, so if someone could cook up the TSO
variable of the patch for pre-GSO
Mike Accetta [EMAIL PROTECTED] wrote:
Obviously the code believes it can assume that there are always multiple
sk_buff's in the chain. The stack trace seems to implicate iptables in
the scenario (twice) if that means anything. Any ideas about what may
be going wrong here? There is indeed
In 2.6.20 (and at least 2.6.19) we occasionally see a crash in
tcp_tso_segment() which looks like it is occuring because the sk_buff
chain has only a single element. Based on the register dump, the code
looks to be crashing at the statement
th = skb-h.th;
in the loop
do {
