From: Bandan Das <bandan.das@stratus.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>,
Bandan Das <bandan.das@stratus.com>,
David Miller <davem@davemloft.net>,
NetDev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Patrick McHardy <kaber@trash.net>
Subject: Re: [PATCH net-next-2.6] net/ipv4: push IP options to CB in ip_fragment
Date: Tue, 31 Aug 2010 09:50:07 -0400 [thread overview]
Message-ID: <20100831135007.GD10754@stratus.com> (raw)
In-Reply-To: <1283260409.2550.87.camel@edumazet-laptop>
On 0, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 31 août 2010 à 20:36 +0800, Herbert Xu a écrit :
> > On Tue, Aug 31, 2010 at 11:17:51AM +0200, Eric Dumazet wrote:
> > >
> > > Once again, the IP stack -> bridge -> IP stack flow bites us,
> > > because bridge likes to dirty IPCB.
> >
> > OK, so we're talking about a locally transmitted packet, with
> > IP options leaving the IP stack, entering bridging, and then
> > reentering the IP stack?
> >
> > In that case the packet should no longer be treated as an IP
> > packet when it enters the bridge. So if it did have options
> > and we want to support that in bridging then we need to parse
> > IP options there as my comment suggested.
>
> Bandan did not provide a full stack trace,
> but I believe the problem was :
>
> br_nf_dev_queue_xmit() -> ip_fragment -> icmp_send() ->
> ip_options_echo() : crash, because ip_options_echo take bridge CB as
> IPCB data.
>
> http://www.spinics.net/lists/netdev/msg139370.html
>
That flow is correct. Sorry about the stack trace, it's now pasted
below. But I am still wondering : Why not make sure in ip_fragment()
that we do not have a corrupt CB ? Today, it's the bridge, tomorrow it will be
someone else that would be doing this.
08-31 09:38:23 [root@kvm ~]# Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff8146dd13
08-31 09:38:32
08-31 09:38:32 Pid: 3209, comm: qemu-kvm Not tainted 2.6.32-63.el6.bdas.x86_64 #1
08-31 09:38:32 Call Trace:
08-31 09:38:32 <IRQ>
08-31 09:38:32 Message from [<ffffffff814c7fa5>] panic+0x78/0x137
08-31 09:38:32 syslogd@kvm at A [<ffffffff8146dd13>] ? icmp_send+0x743/0x780
08-31 09:38:32 ug 31 09:38:59 . [<ffffffff8106b30b>] __stack_chk_fail+0x1b/0x30
08-31 09:38:32 ..
08-31 09:38:32 kernel:Ker [<ffffffff8146dd13>] icmp_send+0x743/0x780
08-31 09:38:32 nel panic - not [<ffffffffa03b9fe0>] ? br_nf_dev_queue_xmit+0x0/0x90 [bridge]
08-31 09:38:32 syncing: stack-p [<ffffffffa03b4400>] ? br_dev_queue_push_xmit+0x0/0xa0 [bridge]
08-31 09:38:32 rotector: Kernel [<ffffffff81436944>] ? nf_hook_slow+0x74/0x100
08-31 09:38:32 stack is corrup [<ffffffffa03ba060>] ? br_nf_dev_queue_xmit+0x80/0x90 [bridge]
08-31 09:38:32 ted in: ffffffff [<ffffffffa03baa90>] ? br_nf_post_routing+0x1d0/0x280 [bridge]
08-31 09:38:32 8146dd13
08-31 09:38:32
08-31 09:38:32 M [<ffffffff8143688c>] ? nf_iterate+0x6c/0xb0
08-31 09:38:32 essage from sysl [<ffffffffa03b4400>] ? br_dev_queue_push_xmit+0x0/0xa0 [bridge]
08-31 09:38:32 ogd@kvm at Aug 3 [<ffffffff81436944>] ? nf_hook_slow+0x74/0x100
08-31 09:38:32 1 09:38:59 ... [<ffffffffa03b4400>] ? br_dev_queue_push_xmit+0x0/0xa0 [bridge]
08-31 09:38:32
08-31 09:38:32 kernel:
08-31 09:38:32 [<ffffffffa03b44a0>] ? br_forward_finish+0x0/0x60 [bridge]
08-31 09:38:32 [<ffffffffa03b44e3>] ? br_forward_finish+0x43/0x60 [bridge]
08-31 09:38:32 [<ffffffffa03ba638>] ? br_nf_forward_finish+0x128/0x140 [bridge]
08-31 09:38:32 [<ffffffffa03bbb00>] ? br_nf_forward_ip+0x310/0x3c0 [bridge]
08-31 09:38:32 [<ffffffff8143688c>] ? nf_iterate+0x6c/0xb0
08-31 09:38:32 [<ffffffffa03b44a0>] ? br_forward_finish+0x0/0x60 [bridge]
08-31 09:38:32 [<ffffffff81436944>] ? nf_hook_slow+0x74/0x100
08-31 09:38:32 [<ffffffffa03b44a0>] ? br_forward_finish+0x0/0x60 [bridge]
08-31 09:38:32 [<ffffffffa03b4572>] ? __br_forward+0x72/0xc0 [bridge]
08-31 09:38:32 [<ffffffffa03b461d>] ? br_forward+0x5d/0x70 [bridge]
08-31 09:38:32 [<ffffffffa03b5359>] ? br_handle_frame_finish+0x129/0x260 [bridge]
08-31 09:38:32 [<ffffffffa03baf88>] ? br_nf_pre_routing_finish+0x228/0x340 [bridge]
08-31 09:38:32 [<ffffffff81436944>] ? nf_hook_slow+0x74/0x100
08-31 09:38:32 [<ffffffffa03bad60>] ? br_nf_pre_routing_finish+0x0/0x340 [bridge]
08-31 09:38:32 [<ffffffffa03bb4ef>] ? br_nf_pre_routing+0x44f/0x750 [bridge]
08-31 09:38:32 [<ffffffff8143688c>] ? nf_iterate+0x6c/0xb0
08-31 09:38:32 [<ffffffffa03b5230>] ? br_handle_frame_finish+0x0/0x260 [bridge]
08-31 09:38:32 [<ffffffff81436944>] ? nf_hook_slow+0x74/0x100
08-31 09:38:32 [<ffffffffa03b5230>] ? br_handle_frame_finish+0x0/0x260 [bridge]
08-31 09:38:32 [<ffffffffa03b561c>] ? br_handle_frame+0x18c/0x250 [bridge]
08-31 09:38:32 [<ffffffff8140f5e3>] ? netif_receive_skb+0x1c3/0x670
08-31 09:38:32 [<ffffffff81094962>] ? enqueue_hrtimer+0x82/0xd0
08-31 09:38:32 [<ffffffff8140fb13>] ? process_backlog+0x83/0xe0
08-31 09:38:32 [<ffffffff81410333>] ? net_rx_action+0x103/0x210
08-31 09:38:32 [<ffffffff81073597>] ? __do_softirq+0xb7/0x1e0
08-31 09:38:32 [<ffffffff810142cc>] ? call_softirq+0x1c/0x30
08-31 09:38:32 <EOI> [<ffffffff81015f35>] ? do_softirq+0x65/0xa0
08-31 09:38:32 [<ffffffff814143a8>] ? netif_rx_ni+0x28/0x30
08-31 09:38:32 [<ffffffffa01bf445>] ? tun_chr_aio_write+0x295/0x580 [tun]
08-31 09:38:32 [<ffffffffa01bf1b0>] ? tun_chr_aio_write+0x0/0x580 [tun]
08-31 09:38:33 [<ffffffff8116c63b>] ? do_sync_readv_writev+0xfb/0x140
08-31 09:38:33 [<ffffffff810916d0>] ? autoremove_wake_function+0x0/0x40
08-31 09:38:33 [<ffffffff8120c51f>] ? selinux_file_permission+0xbf/0x150
08-31 09:38:33 [<ffffffff811ff936>] ? security_file_permission+0x16/0x20
08-31 09:38:33 [<ffffffff8116d6ff>] ? do_readv_writev+0xcf/0x1f0
08-31 09:38:33 [<ffffffff8117f94a>] ? do_vfs_ioctl+0x3aa/0x580
08-31 09:38:33 [<ffffffff8116d866>] ? vfs_writev+0x46/0x60
08-31 09:38:33 [<ffffffff8116d991>] ? sys_writev+0x51/0xb0
08-31 09:38:33 [<ffffffff81013172>] ? system_call_fastpath+0x16/0x1b
--
Bandan
next prev parent reply other threads:[~2010-08-31 13:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-30 20:09 [PATCH net-next-2.6] net/ipv4: push IP options to CB in ip_fragment Bandan Das
2010-08-30 21:35 ` Eric Dumazet
2010-08-30 23:21 ` Bandan Das
2010-08-31 5:20 ` Eric Dumazet
2010-08-31 8:24 ` Herbert Xu
2010-08-31 9:17 ` Eric Dumazet
2010-08-31 12:36 ` Herbert Xu
2010-08-31 13:13 ` Eric Dumazet
2010-08-31 13:50 ` Bandan Das [this message]
2010-09-01 16:57 ` Bandan Das
2010-09-03 4:49 ` Herbert Xu
2010-09-15 17:32 ` Bandan Das
2010-09-17 6:51 ` Herbert Xu
2010-09-17 23:43 ` David Miller
2010-09-19 19:36 ` Bandan Das
2010-09-01 21:46 ` David Miller
2010-09-01 23:30 ` Herbert Xu
2010-09-02 1:09 ` David Miller
2010-09-02 2:05 ` Bandan Das
2010-09-02 2:17 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100831135007.GD10754@stratus.com \
--to=bandan.das@stratus.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.hengli.com.au \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox