All of lore.kernel.org
 help / color / mirror / Atom feed
* 2.6.20 crash in tcp_tso_segment()
@ 2007-02-09  5:57 Mike Accetta
  2007-02-09 20:12 ` Herbert Xu
  0 siblings, 1 reply; 9+ messages in thread
From: Mike Accetta @ 2007-02-09  5:57 UTC (permalink / raw)
  To: netdev


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 {
		th->fin = th->psh = 0;

		th->check = ~csum_fold((__force __wsum)((__force u32)th->check +
				       (__force u32)delta));
		if (skb->ip_summed != CHECKSUM_PARTIAL)
			th->check = csum_fold(csum_partial(skb->h.raw, thlen,
							   skb->csum));

		seq += len;
		skb = skb->next;
		th = skb->h.th;

		th->seq = htonl(seq);
		th->cwr = 0;
	} while (skb->next);

which always runs at least once.  The loop looks safe to me as long as
there are at least two sk_buff's in the chain but it will clearly try
to dereference a null skb pointer on the first loop iteration if the
chain contains only a single sk_buff.

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 a private module loaded at the time
but it does no networking and I doubt it is the culprit.
--------------------------

	0xc030e8b1 <tcp_tso_segment+369>:       mov    (%esi),%esi
	0xc030e8b3 <tcp_tso_segment+371>:       mov    0x14(%esp,1),%ecx
EIP ->  0xc030e8b7 <tcp_tso_segment+375>:       mov    0x1c(%esi),%ebx

--------------------------

BUG: unable to handle kernel NULL pointer
dereference at virtual address 0000001c
 printing eip:
c030e8b7
*pde = 38966067
Oops: 0000 [#1]
Modules linked in: e1000 Depalma(P) w83627hf i2c_isa hwmon_vid i2c_core
CPU:    0
EIP:    0060:[<c030e8b7>]    Tainted: P      VLI
EFLAGS: 00010246   (2.6.20 #11)
EIP is at tcp_tso_segment+0x177/0x280
eax: 00000004   ebx: d9c1a034   ecx: 000005a8   edx: 8b810000
esi: 00000000   edi: b84f3728   ebp: 00000014   esp: d45a1a2c
ds: 007b   es: 007b   ss: 0068
Process rcpd (pid: 22462, ti=d45a1000 task=d2332030 task.ti=d45a1000)
Stack: c037fec5 c033635b c037fec5 a7050100 d45a1a58 000005a8 0000ffeb
eef1d0c0
       00001065 d0b36020 eee8e200 00000000 00001065 c03299e5 ffffffa3
c04499a0
       eee8e200 c0329920 00000008 c02dcdf4 d45a1ac8 00000000 00001065
eee8e200
Call Trace:
 [<c037fec5>] _read_unlock_bh+0x5/0x10
 [<c033635b>] ipt_do_table+0x27b/0x340
 [<c037fec5>] _read_unlock_bh+0x5/0x10
 [<c03299e5>] inet_gso_segment+0xc5/0x1a0
 [<c0329920>] inet_gso_segment+0x0/0x1a0
 [<c02dcdf4>] skb_gso_segment+0xb4/0x170
 [<c02dcf5b>] dev_gso_segment+0x2b/0xc0
 [<c02dd05d>] dev_hard_start_xmit+0x6d/0xf0
 [<c02dd35f>] dev_queue_xmit+0x27f/0x300
 [<c0304eec>] ip_output+0x15c/0x290
 [<c0304bd0>] ip_finish_output+0x0/0x1c0
 [<c0339764>] send_reset+0x324/0x430
 [<c0339870>] dst_output+0x0/0x10
 [<c02f2e38>] __nf_conntrack_find+0x18/0xf0
 [<c037fde8>] _read_lock_bh+0x8/0x10
 [<c037fec5>] _read_unlock_bh+0x5/0x10
 [<c033635b>] ipt_do_table+0x27b/0x340
 [<c02f3979>] nf_conntrack_in+0x1e9/0x290

--
Mike Accetta

ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 2.6.20 crash in tcp_tso_segment()
  2007-02-09  5:57 2.6.20 crash in tcp_tso_segment() Mike Accetta
@ 2007-02-09 20:12 ` Herbert Xu
  2007-02-13 14:34   ` Patrick McHardy
  0 siblings, 1 reply; 9+ messages in thread
From: Herbert Xu @ 2007-02-09 20:12 UTC (permalink / raw)
  To: Mike Accetta; +Cc: netdev

Mike Accetta <maccetta@laurelnetworks.com> 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 a private module loaded at the time
> but it does no networking and I doubt it is the culprit.

Yeah we should never get here if we only have one segment.
Could you get it to print out the value of skb->gso_*?

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 2.6.20 crash in tcp_tso_segment()
  2007-02-09 20:12 ` Herbert Xu
@ 2007-02-13 14:34   ` Patrick McHardy
  2007-02-13 16:18     ` Mike Accetta
  2007-02-13 17:51     ` Herbert Xu
  0 siblings, 2 replies; 9+ messages in thread
From: Patrick McHardy @ 2007-02-13 14:34 UTC (permalink / raw)
  To: Herbert Xu; +Cc: Mike Accetta, netdev

Herbert Xu wrote:
> Mike Accetta <maccetta@laurelnetworks.com> 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 a private module loaded at the time
>>but it does no networking and I doubt it is the culprit.
> 
> 
> Yeah we should never get here if we only have one segment.
> Could you get it to print out the value of skb->gso_*?

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 2.6.20 crash in tcp_tso_segment()
  2007-02-13 14:34   ` Patrick McHardy
@ 2007-02-13 16:18     ` Mike Accetta
  2007-02-13 17:51     ` Herbert Xu
  1 sibling, 0 replies; 9+ messages in thread
From: Mike Accetta @ 2007-02-13 16:18 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Herbert Xu, netdev

Patrick McHardy writes:
> Herbert Xu wrote:
> > Mike Accetta <maccetta@laurelnetworks.com> 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 a private module loaded at the time
> >>but it does no networking and I doubt it is the culprit.
> > 
> > 
> > Yeah we should never get here if we only have one segment.
> > Could you get it to print out the value of skb->gso_*?
> 
> 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.

I've instrumented the code to print the gso_* fields as requested.
I also made a stab at keeping the box from crashing as well, but that
part may not be right.  In any case, the new code snippet is

    if (skb->next) {
	do {
		th->fin = th->psh = 0;

		th->check = ~csum_fold((__force __wsum)((__force u32)th->check +
				       (__force u32)delta));
		if (skb->ip_summed != CHECKSUM_PARTIAL)
			th->check = csum_fold(csum_partial(skb->h.raw, thlen,
							   skb->csum));

		seq += len;
		skb = skb->next;
		th = skb->h.th;

		th->seq = htonl(seq);
		th->cwr = 0;
	} while (skb->next);
    } else {
	th->cwr = 0;
	printk("gso_size %d\n",  skb_shinfo(skb)->gso_size);
	printk("gso_segs %d\n",  skb_shinfo(skb)->gso_segs);
	printk("gso_type %d\n",  skb_shinfo(skb)->gso_type);
	WARN_ON(skb->next == 0);
    }

and the output was

gso_size 0
gso_segs 0
gso_type 0
BUG: at /u/mjaccetta/p4/mos/hog/1/BUILD/kernel-2.6/net/ipv4/tcp.c:2239
tcp_tso_segment()
 [<c030e9f8>] tcp_tso_segment+0x2b8/0x320
 [<c0329a85>] inet_gso_segment+0xc5/0x1a0
 [<c03299c0>] inet_gso_segment+0x0/0x1a0
 [<c02dcdf4>] skb_gso_segment+0xb4/0x170
 [<c02dcf5b>] dev_gso_segment+0x2b/0xc0
 [<c02dd05d>] dev_hard_start_xmit+0x6d/0xf0
 [<c02dd35f>] dev_queue_xmit+0x27f/0x300
 [<c0304eec>] ip_output+0x15c/0x290
 [<c0304bd0>] ip_finish_output+0x0/0x1c0
 [<c0339804>] send_reset+0x324/0x430
 [<c0339910>] dst_output+0x0/0x10
 [<c02f2e38>] __nf_conntrack_find+0x18/0xf0
 [<c037fe88>] _read_lock_bh+0x8/0x10
 [<c037ff65>] _read_unlock_bh+0x5/0x10
 [<c03363fb>] ipt_do_table+0x27b/0x340
 [<c02f3979>] nf_conntrack_in+0x1e9/0x290
 [<c0339978>] reject+0x58/0xb0
 [<c0336471>] ipt_do_table+0x2f1/0x340
 [<c02f1425>] nf_iterate+0x55/0x90
 [<c0304690>] dst_output+0x0/0x10
 [<c02f14c6>] nf_hook_slow+0x66/0x100
 [<c0304690>] dst_output+0x0/0x10
 [<c03053f8>] ip_queue_xmit+0x3d8/0x4c0
 [<c0304690>] dst_output+0x0/0x10
 [<c0216c4e>] copy_to_user+0x3e/0x50
 [<c02d9959>] memcpy_toiovec+0x29/0x50
 [<c015da63>] cache_alloc_refill+0x113/0x1c0
 [<c0315c07>] tcp_cwnd_restart+0x27/0xf0
 [<c031635d>] tcp_transmit_skb+0x2cd/0x460
 [<c03171dd>] tso_fragment+0x11d/0x1c0
 [<c0317c3c>] tcp_push_one+0xbc/0xf0
 [<c030c39d>] tcp_sendmsg+0x6bd/0xb40
 [<c037ff35>] _spin_unlock_bh+0x5/0x10
 [<c030cf84>] tcp_recvmsg+0x2e4/0x750
 [<c02d63d5>] sock_common_recvmsg+0x45/0x70
 [<c0329077>] inet_sendmsg+0x47/0x60
 [<c02d1fff>] sock_sendmsg+0xbf/0x110
 [<c02d5f9c>] sk_reset_timer+0xc/0x20
 [<c031913a>] tcp_connect+0x1aa/0x1c0
 [<c012a850>] autoremove_wake_function+0x0/0x50
 [<c012a850>] autoremove_wake_function+0x0/0x50
 [<c01071ef>] convert_fxsr_to_user+0x12f/0x1a0
 [<c02d32a7>] sys_sendto+0xf7/0x140
 [<c037ff25>] _spin_unlock_irq+0x5/0x10
 [<c01029c1>] handle_signal+0x121/0x170
 [<c014dee1>] do_wp_page+0x231/0x440
 [<c0102aac>] do_signal+0x9c/0x190
 [<c014f236>] __handle_mm_fault+0x276/0x2e0
 [<c02d3323>] sys_send+0x33/0x40
 [<c02d3c65>] sys_socketcall+0x195/0x2b0
 [<c0102180>] sys_sigreturn+0xd0/0xe0
 [<c0102d08>] syscall_call+0x7/0xb
 [<c0380000>] error_code+0x28/0x7c

gso_size 0
gso_segs 0
gso_type 0
BUG: at /u/mjaccetta/p4/mos/hog/1/BUILD/kernel-2.6/net/ipv4/tcp.c:2239
tcp_tso_segment()
 [<c030e9f8>] tcp_tso_segment+0x2b8/0x320
 [<c0329a85>] inet_gso_segment+0xc5/0x1a0
 [<c03299c0>] inet_gso_segment+0x0/0x1a0
 [<c02dcdf4>] skb_gso_segment+0xb4/0x170
 [<c02dcf5b>] dev_gso_segment+0x2b/0xc0
 [<c02dd05d>] dev_hard_start_xmit+0x6d/0xf0
 [<c02dd35f>] dev_queue_xmit+0x27f/0x300
 [<c0304eec>] ip_output+0x15c/0x290
 [<c0304bd0>] ip_finish_output+0x0/0x1c0
 [<c0339804>] send_reset+0x324/0x430
 [<c0339910>] dst_output+0x0/0x10
 [<c02f2e38>] __nf_conntrack_find+0x18/0xf0
 [<c037fe88>] _read_lock_bh+0x8/0x10
 [<c037ff65>] _read_unlock_bh+0x5/0x10
 [<c03363fb>] ipt_do_table+0x27b/0x340
 [<c02f3979>] nf_conntrack_in+0x1e9/0x290
 [<c0339978>] reject+0x58/0xb0
 [<c0336471>] ipt_do_table+0x2f1/0x340
 [<c02f1425>] nf_iterate+0x55/0x90
 [<c0304690>] dst_output+0x0/0x10
 [<c02f14c6>] nf_hook_slow+0x66/0x100
 [<c0304690>] dst_output+0x0/0x10
 [<c03053f8>] ip_queue_xmit+0x3d8/0x4c0
 [<c0304690>] dst_output+0x0/0x10
 [<c03053f8>] ip_queue_xmit+0x3d8/0x4c0
 [<c0304690>] dst_output+0x0/0x10
 [<c0216c4e>] copy_to_user+0x3e/0x50
 [<c02d9959>] memcpy_toiovec+0x29/0x50
 [<c0315c07>] tcp_cwnd_restart+0x27/0xf0
 [<c031635d>] tcp_transmit_skb+0x2cd/0x460
 [<c0145711>] get_page_from_freelist+0x71/0xc0
 [<c03179d8>] tcp_write_xmit+0x168/0x280
 [<c0145710>] get_page_from_freelist+0x70/0xc0
 [<c0317b17>] __tcp_push_pending_frames+0x27/0x90
 [<c030c753>] tcp_sendmsg+0xa73/0xb40
 [<c037ff35>] _spin_unlock_bh+0x5/0x10
 [<c030cf84>] tcp_recvmsg+0x2e4/0x750
 [<c02d63d5>] sock_common_recvmsg+0x45/0x70
 [<c0329077>] inet_sendmsg+0x47/0x60
 [<c02d1fff>] sock_sendmsg+0xbf/0x110
 [<c02d5f9c>] sk_reset_timer+0xc/0x20
 [<c031913a>] tcp_connect+0x1aa/0x1c0
 [<c012a850>] autoremove_wake_function+0x0/0x50
 [<c012a850>] autoremove_wake_function+0x0/0x50
 [<c01071ef>] convert_fxsr_to_user+0x12f/0x1a0
 [<c02d32a7>] sys_sendto+0xf7/0x140
 [<c037ff25>] _spin_unlock_irq+0x5/0x10
 [<c01029c1>] handle_signal+0x121/0x170
 [<c014dee1>] do_wp_page+0x231/0x440
 [<c0102aac>] do_signal+0x9c/0x190
 [<c014f236>] __handle_mm_fault+0x276/0x2e0
 [<c02d3323>] sys_send+0x33/0x40
 [<c02d3c65>] sys_socketcall+0x195/0x2b0
 [<c0102180>] sys_sigreturn+0xd0/0xe0
 [<c0102d08>] syscall_call+0x7/0xb
 [<c0380000>] error_code+0x28/0x7c

gso_size 0
gso_segs 0
gso_type 0
BUG: at /u/mjaccetta/p4/mos/hog/1/BUILD/kernel-2.6/net/ipv4/tcp.c:2239
tcp_tso_segment()
 [<c030e9f8>] tcp_tso_segment+0x2b8/0x320
 [<c0329a85>] inet_gso_segment+0xc5/0x1a0
 [<c03299c0>] inet_gso_segment+0x0/0x1a0
 [<c02dcdf4>] skb_gso_segment+0xb4/0x170
 [<c02dcf5b>] dev_gso_segment+0x2b/0xc0
 [<c02dd05d>] dev_hard_start_xmit+0x6d/0xf0
 [<c02dd35f>] dev_queue_xmit+0x27f/0x300
 [<c0304eec>] ip_output+0x15c/0x290
 [<c0304bd0>] ip_finish_output+0x0/0x1c0
 [<c0339804>] send_reset+0x324/0x430
 [<c0339910>] dst_output+0x0/0x10
 [<c02f2e38>] __nf_conntrack_find+0x18/0xf0
 [<c037fe88>] _read_lock_bh+0x8/0x10
 [<c037ff65>] _read_unlock_bh+0x5/0x10
 [<c03363fb>] ipt_do_table+0x27b/0x340
 [<c02f3979>] nf_conntrack_in+0x1e9/0x290
 [<c0339978>] reject+0x58/0xb0
 [<c0336471>] ipt_do_table+0x2f1/0x340
 [<c02f1425>] nf_iterate+0x55/0x90
 [<c0304690>] dst_output+0x0/0x10
 [<c02f14c6>] nf_hook_slow+0x66/0x100
 [<c0304690>] dst_output+0x0/0x10
 [<c03053f8>] ip_queue_xmit+0x3d8/0x4c0
 [<c0304690>] dst_output+0x0/0x10
 [<c0216a64>] __copy_to_user_ll+0x34/0x60
 [<c0216c4e>] copy_to_user+0x3e/0x50
 [<c02d9959>] memcpy_toiovec+0x29/0x50
 [<c037fe39>] _spin_lock_irqsave+0x9/0x10
 [<c0145507>] buffered_rmqueue+0x77/0x110
 [<c031635d>] tcp_transmit_skb+0x2cd/0x460
 [<c03171dd>] tso_fragment+0x11d/0x1c0
 [<c0317c3c>] tcp_push_one+0xbc/0xf0
 [<c030c39d>] tcp_sendmsg+0x6bd/0xb40
 [<c037ff35>] _spin_unlock_bh+0x5/0x10
 [<c030cf84>] tcp_recvmsg+0x2e4/0x750
 [<c02d623b>] release_sock+0x1b/0xa0
 [<c0329077>] inet_sendmsg+0x47/0x60
 [<c02d1fff>] sock_sendmsg+0xbf/0x110
 [<c02d5f9c>] sk_reset_timer+0xc/0x20
 [<c031913a>] tcp_connect+0x1aa/0x1c0
 [<c012a850>] autoremove_wake_function+0x0/0x50
 [<c012a850>] autoremove_wake_function+0x0/0x50
 [<c01071ef>] convert_fxsr_to_user+0x12f/0x1a0
 [<c0144b61>] free_pages_bulk+0x31/0x1a0
 [<c02d32a7>] sys_sendto+0xf7/0x140
 [<c014dee1>] do_wp_page+0x231/0x440
 [<c032844e>] inet_sock_destruct+0xbe/0x200
 [<c014f236>] __handle_mm_fault+0x276/0x2e0
 [<c02d3323>] sys_send+0x33/0x40
 [<c02d3c65>] sys_socketcall+0x195/0x2b0
 [<c01600f6>] sys_close+0x66/0xd0
 [<c0102d08>] syscall_call+0x7/0xb
 [<c0380000>] error_code+0x28/0x7c

gso_size 0
gso_segs 0
gso_type 0
BUG: at /u/mjaccetta/p4/mos/hog/1/BUILD/kernel-2.6/net/ipv4/tcp.c:2239
tcp_tso_segment()
 [<c030e9f8>] tcp_tso_segment+0x2b8/0x320
 [<c0329a85>] inet_gso_segment+0xc5/0x1a0
 [<c03299c0>] inet_gso_segment+0x0/0x1a0
 [<c02dcdf4>] skb_gso_segment+0xb4/0x170
 [<c02dcf5b>] dev_gso_segment+0x2b/0xc0
 [<c02dd05d>] dev_hard_start_xmit+0x6d/0xf0
 [<c02dd35f>] dev_queue_xmit+0x27f/0x300
 [<c0304eec>] ip_output+0x15c/0x290
 [<c0304bd0>] ip_finish_output+0x0/0x1c0
 [<c0339804>] send_reset+0x324/0x430
 [<c0339910>] dst_output+0x0/0x10
 [<c02f2e38>] __nf_conntrack_find+0x18/0xf0
 [<c037fe88>] _read_lock_bh+0x8/0x10
 [<c037ff65>] _read_unlock_bh+0x5/0x10
 [<c03363fb>] ipt_do_table+0x27b/0x340
 [<c02f3979>] nf_conntrack_in+0x1e9/0x290
 [<c0339978>] reject+0x58/0xb0
 [<c0336471>] ipt_do_table+0x2f1/0x340
 [<c02f1425>] nf_iterate+0x55/0x90
 [<c0304690>] dst_output+0x0/0x10
 [<c02f14c6>] nf_hook_slow+0x66/0x100
 [<c0304690>] dst_output+0x0/0x10
 [<c03053f8>] ip_queue_xmit+0x3d8/0x4c0
 [<c0304690>] dst_output+0x0/0x10
 [<c03053f8>] ip_queue_xmit+0x3d8/0x4c0
 [<c0304690>] dst_output+0x0/0x10
 [<c0216a64>] __copy_to_user_ll+0x34/0x60
 [<c0216c4e>] copy_to_user+0x3e/0x50
 [<c02d9959>] memcpy_toiove
--
Mike Accetta

ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 2.6.20 crash in tcp_tso_segment()
  2007-02-13 14:34   ` Patrick McHardy
  2007-02-13 16:18     ` Mike Accetta
@ 2007-02-13 17:51     ` Herbert Xu
  2007-02-13 20:34       ` David Miller
  2007-02-14 16:27       ` Mike Accetta
  1 sibling, 2 replies; 9+ messages in thread
From: Herbert Xu @ 2007-02-13 17:51 UTC (permalink / raw)
  To: Patrick McHardy, David S. Miller; +Cc: Mike Accetta, netdev

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 it's copied from.

[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 <herbert@gondor.apana.org.au>

Something like this is needed for all trees with GSO.
Actually it applies to TSO too although the effect there
is a bit harder to notice.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index a9eb363..80f739e 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -80,6 +80,10 @@ static void send_reset(struct sk_buff *oldskb, int hook)
 	nskb->mark = 0;
 	skb_init_secmark(nskb);
 
+	skb_shinfo(nskb)->gso_size = 0;
+	skb_shinfo(nskb)->gso_segs = 0;
+	skb_shinfo(nskb)->gso_type = 0;
+
 	tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
 
 	/* Swap source and dest */

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: 2.6.20 crash in tcp_tso_segment()
  2007-02-13 17:51     ` Herbert Xu
@ 2007-02-13 20:34       ` David Miller
  2007-02-13 21:51         ` Herbert Xu
  2007-02-14 16:27       ` Mike Accetta
  1 sibling, 1 reply; 9+ messages in thread
From: David Miller @ 2007-02-13 20:34 UTC (permalink / raw)
  To: herbert; +Cc: kaber, maccetta, netdev

From: Herbert Xu <herbert@gondor.apana.org.au>
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.  We need to reset the GSO bits there since the new
> packet is nothing like the one it's copied from.
> 
> [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 <herbert@gondor.apana.org.au>
> 
> Something like this is needed for all trees with GSO.
> Actually it applies to TSO too although the effect there
> is a bit harder to notice.

Applied, thanks Herbert.

I'll push this to -stable.

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 2.6.20 crash in tcp_tso_segment()
  2007-02-13 20:34       ` David Miller
@ 2007-02-13 21:51         ` Herbert Xu
  2007-02-13 21:53           ` David Miller
  0 siblings, 1 reply; 9+ messages in thread
From: Herbert Xu @ 2007-02-13 21:51 UTC (permalink / raw)
  To: David Miller; +Cc: kaber, maccetta, netdev

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 2.6.18.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index 0bba3c2..ff396c4 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -148,6 +148,9 @@ static void send_reset(struct sk_buff *oldskb, int hook)
 	nf_reset(nskb);
 	nskb->nfmark = 0;
 
+	skb_shinfo(nskb)->tso_size = 0;
+	skb_shinfo(nskb)->tso_segs = 0;
+
 	tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
 
 	/* Swap source and dest */

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: 2.6.20 crash in tcp_tso_segment()
  2007-02-13 21:51         ` Herbert Xu
@ 2007-02-13 21:53           ` David Miller
  0 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2007-02-13 21:53 UTC (permalink / raw)
  To: herbert; +Cc: kaber, maccetta, netdev

From: Herbert Xu <herbert@gondor.apana.org.au>
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 kernels I'd appreciate it.
> 
> Sure, here is the patch for any kernel prior to 2.6.18.

Thanks a lot Herbert.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 2.6.20 crash in tcp_tso_segment()
  2007-02-13 17:51     ` Herbert Xu
  2007-02-13 20:34       ` David Miller
@ 2007-02-14 16:27       ` Mike Accetta
  1 sibling, 0 replies; 9+ messages in thread
From: Mike Accetta @ 2007-02-14 16:27 UTC (permalink / raw)
  To: Herbert Xu; +Cc: Patrick McHardy, David S. Miller, netdev

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 <herbert@gondor.apana.org.au>
> 
> Something like this is needed for all trees with GSO.
> Actually it applies to TSO too although the effect there
> is a bit harder to notice.
> 
> Cheers,
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.
> c
> index a9eb363..80f739e 100644
> --- a/net/ipv4/netfilter/ipt_REJECT.c
> +++ b/net/ipv4/netfilter/ipt_REJECT.c
> @@ -80,6 +80,10 @@ static void send_reset(struct sk_buff *oldskb, int hook)
>  	nskb->mark = 0;
>  	skb_init_secmark(nskb);
>  
> +	skb_shinfo(nskb)->gso_size = 0;
> +	skb_shinfo(nskb)->gso_segs = 0;
> +	skb_shinfo(nskb)->gso_type = 0;
> +
>  	tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
>  
>  	/* Swap source and dest */

I picked up this patch and we ran the overnight stress tests that had been
experiencing this problem against it.  No problems so far, which based on
past results probably means the problem has indeed been fixed.  Thank you!
--
Mike Accetta

ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2007-02-14 16:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-09  5:57 2.6.20 crash in tcp_tso_segment() Mike Accetta
2007-02-09 20:12 ` Herbert Xu
2007-02-13 14:34   ` Patrick McHardy
2007-02-13 16:18     ` Mike Accetta
2007-02-13 17:51     ` Herbert Xu
2007-02-13 20:34       ` David Miller
2007-02-13 21:51         ` Herbert Xu
2007-02-13 21:53           ` David Miller
2007-02-14 16:27       ` Mike Accetta

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.