search for: br_handle_frame_finish

...ard_finish+0xb8/0x140 [bridge] [<c0144611>] kmem_getpages+0x31/0xa0 [<c9167d70>] br_forward_finish+0x0/0x70 [bridge] [<c014537e>] cache_grow+0x9e/0x190 [<c01455bd>] cache_alloc_refill+0x14d/0x220 [<c9167d70>] br_forward_finish+0x0/0x70 [bridge] [<c9168a30>] br_handle_frame_finish+0x0/0x130 [bridge] [<c0145899>] kmem_cache_alloc+0x69/0x70 [<c916d132>] br_nf_pre_routing+0x1b2/0x480 [bridge] [<c9168990>] br_pass_frame_up_finish+0x0/0x20 [bridge] [<c029631e>] nf_hook_slow+0x6e/0x100 [<c0296018>] nf_iterate+0x78/0x90 [<c9168a30>] br_hand...

...f_pre_routing_finish+0x0/0x2c0 [<c0359b4d>] br_nf_pre_routing_finish+0x0/0x2c0 [<c030d562>] nf_iterate+0x3f/0x6d [<c0359b4d>] br_nf_pre_routing_finish+0x0/0x2c0 [<c030d5d7>] nf_hook_slow+0x47/0xba [<c0359b4d>] br_nf_pre_routing_finish+0x0/0x2c0 [<c035685b>] br_handle_frame_finish+0x0/0xca [<c035a446>] br_nf_pre_routing+0x35d/0x37a [<c035685b>] br_handle_frame_finish+0x0/0xca [<c035a454>] br_nf_pre_routing+0x36b/0x37a [<c030d562>] nf_iterate+0x3f/0x6d [<c035685b>] br_handle_frame_finish+0x0/0xca [<c030d5d7>] nf_hook_slow+0x47/0xba [...

...200286c042 <d> ffff88202ae7c6e0 ffff882002b9ceb8 ffff88013bc03950 ffffffffa04f36d5 Call Trace: <IRQ> [<ffffffffa04f3930>] ? __br_forward+0x0/0xd0 [bridge] [<ffffffffa04f36d5>] ? br_multicast_forward+0x15/0x20 [bridge] [<ffffffffa04f4a34>] ? br_handle_frame_finish+0x144/0x2a0 [bridge] [<ffffffffa04fa938>] ? br_nf_pre_routing_finish+0x238/0x350 [bridge] [<ffffffffa04faedb>] ? br_nf_pre_routing+0x48b/0x7b0 [bridge] [<ffffffff8143ba57>] ? __kfree_skb+0x47/0xa0 [<ffffffff814734f9>] ? nf_iterate+0x69/0xb0 [<ffff...

...0xa0 [<c05bbee0>] br_forward_finish+0x0/0x70 [<c05bbee0>] br_forward_finish+0x0/0x70 [<c04f0f4e>] nf_hook_slow+0x6e/0x120 [<c05bbee0>] br_forward_finish+0x0/0x70 [<c05bc044>] __br_forward+0x74/0x80 [<c05bbee0>] br_forward_finish+0x0/0x70 [<c05bceb1>] br_handle_frame_finish+0xd1/0x160 [<c05bcde0>] br_handle_frame_finish+0x0/0x160 [<c05c0e0b>] br_nf_pre_routing_finish+0xfb/0x480 [<c05bcde0>] br_handle_frame_finish+0x0/0x160 [<c05c0d10>] br_nf_pre_routing_finish+0x0/0x480 [<c054fe13>] ip_nat_in+0x43/0xc0 [<c05c0d10>] br_nf_pre_r...

..._pre_routing_finish+0x0/0x34e [<c0302017>] nf_iterate+0x6f/0x87 [<c035d274>] br_nf_pre_routing_finish+0x0/0x34e [<c035d274>] br_nf_pre_routing_finish+0x0/0x34e [<c030209a>] nf_hook_slow+0x6b/0x102 [<c035d274>] br_nf_pre_routing_finish+0x0/0x34e [<c035958e>] br_handle_frame_finish+0x0/0x109 [<c035db86>] br_nf_pre_routing+0x276/0x449 [<c035d274>] br_nf_pre_routing_finish+0x0/0x34e [<c0302017>] nf_iterate+0x6f/0x87 [<c035958e>] br_handle_frame_finish+0x0/0x109 [<c035958e>] br_handle_frame_finish+0x0/0x109 [<c030209a>] nf_hook_slow+0x6b...

...2.1.15 and 2.1.17. Specifically, I do not think BPDU's (generated from another bridge) are passed across the bridge when STP is disabled. I think this relates to the LLC handling of BPDU's directly invoking br_bpdu_rcv. In 2.6.15, the br_handle_frame function would pass a BPDU to the br_handle_frame_finish function which would transmit it across the bridge. But in 2.6.17, the br_bpdu_rcv function is invoked directly by the LLC layer, which does nothing if stp is disabled. Was this change intentional? The reason I ask is that I can introduce a loop into the network by doing the following: Two m...

...ug/28 12:21 pm> [<ffffffff8824f3c5>] :ipv6:ipv6_rcv+0x255/0x2ba <Aug/28 12:21 pm> [<ffffffff80395cbc>] netif_receive_skb+0x2d3/0x2f3 <Aug/28 12:21 pm> [<ffffffff8828f9b4>] :bridge:br_pass_frame_up+0x64/0x66 <Aug/28 12:21 pm> [<ffffffff8828fa7a>] :bridge:br_handle_frame_finish+0xc4/0xf6 <Aug/28 12:21 pm> [<ffffffff88292e57>] :bridge:br_nf_pre_routing_finish_ipv6+0xd f/0xe3 <Aug/28 12:21 pm> [<ffffffff882935e6>] :bridge:br_nf_pre_routing+0x39b/0x667 <Aug/28 12:21 pm> [<ffffffff803ad73c>] nf_iterate+0x52/0x79 <Aug/28 12:21 pm> [&...

Just gave 3.0 a spin. Had been running 2.0.7 for the past 3 months or so without problems (aside from intermittent failure during live migration). Anyway, 3.0 seems to have an issue with my machine. It starts up the 4 domains that I''ve got defined (was running 6 user domains with 2.0.7, but two of those were running 2.4 kernels which I can''t seem to build with Xen 3.0 yet, and

...em at davemloft.net> Cc: Adam Baker <linux at baker-net.org.uk> Signed-off-by: Cong Wang <amwang at redhat.com> --- diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c index 828e2bc..c706619 100644 --- a/net/bridge/br_input.c +++ b/net/bridge/br_input.c @@ -99,9 +99,11 @@ int br_handle_frame_finish(struct sk_buff *skb) else if (is_multicast_ether_addr(dest)) { mdst = br_mdb_get(br, skb, vid); if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) { - if ((mdst && mdst->mglist) || - br_multicast_is_router(br)) + bool to_br = mdst && mdst->mglist; + if (to_br...

Hi, I found this block of code in br_dev_queue_xmit() @ br_forward.c, after applying 'netfilter' patch for 2.4.21 kernel Can someone explain what this block of code is doin? #ifdef CONFIG_NETFILTER if (skb->nf_bridge) memcpy(skb->data - 16, skb->nf_bridge->hh, 16); #endif 1. What is 16 bytes here...? Ethernet hdr is just 14 bytes 2. Why the ethernet

The following series adds 2 new flags to bridge. One flag allows the user to control whether mac learning is performed on the interface or not. By default mac learning is on. The other flag allows the user to control whether unicast traffic is flooded (send without an fdb) to a given unicast port. Default is on. Changes since v4: - Implemented Stephen's suggestions. Changes since v2: -

...58/0x5d Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012132] [<ffffffff81543b22>] br_flood+0xa2/0xbb Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012135] [<ffffffff81543b4b>] br_flood_forward+0x10/0x12 Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012137] [<ffffffff81544872>] br_handle_frame_finish+0x13a/0x151 Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012141] [<ffffffff81548616>] br_nf_pre_routing_finish+0x249/0x258 Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012144] [<ffffffff815492d3>] br_nf_pre_routing+0x55d/0x57e Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012147] [...

http://bugzilla.netfilter.org/show_bug.cgi?id=765 Summary: Netfilter crash on bridged/TAP device on 2.6.38 & 3.0 kernels Product: netfilter/iptables Version: linux-2.6.x Platform: x86_64 OS/Version: Ubuntu Status: NEW Severity: major Priority: P2 Component: bridging

..._flood+116/207] br_flood+0x74/0xcf Dec 8 12:19:26 server kernel: [__br_forward+0/87] __br_forward+0x0/0x57 Dec 8 12:19:26 server kernel: [br_flood_forward+22/27] br_flood_forward+0x16/0x1b Dec 8 12:19:26 server kernel: [__br_forward+0/87] __br_forward+0x0/0x57 Dec 8 12:19:26 server kernel: [br_handle_frame_finish+134/252] br_handle_frame_finish+0x86/0xfc Dec 8 12:19:26 server kernel: [br_handle_frame+358/421] br_handle_frame+0x166/0x1a5 Dec 8 12:19:26 server kernel: [netif_receive_skb+333/538] netif_receive_skb+0x14d/0x21a Dec 8 12:19:26 server kernel: [tg3_rx+732/957] tg3_rx+0x2dc/0x3bd Dec 8 12:19:...

...ge, a small but possible security risk. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Index: bridge/net/bridge/br_input.c =================================================================== --- bridge.orig/net/bridge/br_input.c +++ bridge/net/bridge/br_input.c @@ -54,6 +54,9 @@ int br_handle_frame_finish(struct sk_buf struct net_bridge_fdb_entry *dst; int passedup = 0; + /* insert into forwarding database after filtering to avoid spoofing */ + br_fdb_update(p->br, p, eth_hdr(skb)->h_source); + if (br->dev->flags & IFF_PROMISC) { struct sk_buff *skb2; @@ -108,8 +111,7 @@...

...setup_pre_routing 1417 bridge.ko br_fdb_cleanup 1425 sky2.ko sky2_put_idx 1766 ipt_physdev.ko .text 2113 bridge.ko br_nf_pre_routing_finish 2133 bridge.ko br_nf_forward_ip 2314 bridge.ko br_handle_frame_finish 2454 bridge.ko br_dev_queue_push_xmit 2515 bridge.ko ip_sabotage_out 2718 sky2.ko sky2_rx_add 2858 sch_htb.ko htb_enqueue 3983 bridge.ko br_handle_frame 4796 bridge.ko br_nf_pre_routin...

Hi, I just want to know if somebody use 2.6.31.4 xenified kernel (aka OpenSUSE) in production? We have been testing it on new Nehalem Xeon server for few weeks w/o any problem. But as soon we tried it on production machine - after several production domUs started - hard OS failure. We had to switch back to 2.6.18.8 - xen stock kernel. Peter _______________________________________________

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in

...bcd4c000 CR4: 0000000000002660 Stack: ffff88013f403d30 ffff880006de6800 ffff8800adfee1c0 ffff88013f403e54 000000015786e75a 00000040a0351878 ffffc90012c2def0 000000015786e73c ffffc90012c280d0 ffffc90012c2def0 ffffffffa03516c0 ffff8800bf29e000 Call Trace: <IRQ> [<ffffffffa03516c0>] ? br_handle_frame_finish+0x3f0/0x3f0 [bridge] [<ffffffff815a2b9e>] ? __netif_receive_skb_core+0x1ee/0x640 [<ffffffff815a3017>] ? __netif_receive_skb+0x27/0x70 [<ffffffff815a326d>] ? netif_receive_skb_internal+0x2d/0x90 [<ffffffffa01d5053>] ? igb_alloc_rx_buffers+0x63/0xe0 [igb] [<ffffffffa02...