* Re: [PATCH 4/4] microblaze: Remove NO_IRQ from architecture
From: Ryan Mallon @ 2011-12-21 22:09 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, netdev, devicetree-discuss, Grant Likely,
Benjamin Herrenschmidt
In-Reply-To: <1324477932-19262-4-git-send-email-monstr@monstr.eu>
On 22/12/11 01:32, Michal Simek wrote:
> NO_IRQ shouldn't be used by any driver. All Microblaze
> drivers are fixed that's why NO_IRQ can be removed.
This only describes half of what the patch does. You should also state
that arch/microblaze/pci/pci-common.c has references to NO_IRQ removed.
Maybe it' worth splitting this patch in half so the final patch just
does the removal of the NO_IRQ definition, but maybe that is overkill?
Other than that, for the whole series:
Reviewed-by: Ryan Mallon <rmallon@gmail.com>
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> CC: Grant Likely <grant.likely@secretlab.ca>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Ryan Mallon <rmallon@gmail.com>
> ---
> arch/microblaze/include/asm/irq.h | 2 --
> arch/microblaze/pci/pci-common.c | 4 ++--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/microblaze/include/asm/irq.h b/arch/microblaze/include/asm/irq.h
> index b116a82..a175132 100644
> --- a/arch/microblaze/include/asm/irq.h
> +++ b/arch/microblaze/include/asm/irq.h
> @@ -27,8 +27,6 @@ typedef unsigned long irq_hw_number_t;
>
> extern unsigned int nr_irq;
>
> -#define NO_IRQ 0
> -
> struct pt_regs;
> extern void do_IRQ(struct pt_regs *regs);
>
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
> index db841c7..0d71b2e 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -242,7 +242,7 @@ int pci_read_irq_line(struct pci_dev *pci_dev)
> line, pin);
>
> virq = irq_create_mapping(NULL, line);
> - if (virq != NO_IRQ)
> + if (virq)
> irq_set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
> } else {
> pr_debug(" Got one, spec %d cells (0x%08x 0x%08x...) on %s\n",
> @@ -253,7 +253,7 @@ int pci_read_irq_line(struct pci_dev *pci_dev)
> virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
> oirq.size);
> }
> - if (virq == NO_IRQ) {
> + if (!virq) {
> pr_debug(" Failed to map !\n");
> return -1;
> }
^ permalink raw reply
* Re: [PATCH 2/3] netlink: use vzalloc()
From: Eric Dumazet @ 2011-12-21 22:12 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20111221134833.76af35e6@nehalam.linuxnetplumber.net>
Le mercredi 21 décembre 2011 à 13:48 -0800, Stephen Hemminger a écrit :
> The netlink pid hash can be allocated using vzalloc() rather than direct
> access to get_free_pages. It is also safe for nl_pid_hash_zalloc to use
> GFP_KERNEL since it is only called from netlink_proto_init and
> nl_pid_hash_rehash. The former is already allocating table with GFP_KERNEL,
> and the latter is called from netlink_insert() which already could
> sleep in netlink_table_grab()
>
But netlink_table_grab() returns with write_lock_irq(&nl_table_lock);
So we are not allowed to sleep in a
netlink_table_grab()/netlink_table_ungrab() section .
^ permalink raw reply
* Re: [PATCH 3/3] netlink: wake up netlink listeners sooner
From: David Miller @ 2011-12-21 23:00 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20111221134944.52223cdf@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 21 Dec 2011 13:49:44 -0800
> @@ -960,7 +960,7 @@ static int netlink_broadcast_deliver(str
> skb_set_owner_r(skb, sk);
> skb_queue_tail(&sk->sk_receive_queue, skb);
> sk->sk_data_ready(sk, skb->len);
> - return atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf;
> + return atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf / 2;
> }
Please mirror the logic we use in the generic socket code to do this
on the send side, namely use something like:
return (atomic_read(&sk->sk_rmem_alloc) << 1) > sk->sk_rcvbuf;
because sk_rcvbuf is an int and this "/ 2" expression will generate a
really silly sequence of multiple shifts, adds, and comparisons in
order to handle negative values correctly.
^ permalink raw reply
* Re: [PATCH 2/3] netlink: use vzalloc()
From: David Miller @ 2011-12-21 23:00 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <1324505551.2621.11.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Dec 2011 23:12:31 +0100
> Le mercredi 21 décembre 2011 à 13:48 -0800, Stephen Hemminger a écrit :
>> The netlink pid hash can be allocated using vzalloc() rather than direct
>> access to get_free_pages. It is also safe for nl_pid_hash_zalloc to use
>> GFP_KERNEL since it is only called from netlink_proto_init and
>> nl_pid_hash_rehash. The former is already allocating table with GFP_KERNEL,
>> and the latter is called from netlink_insert() which already could
>> sleep in netlink_table_grab()
>>
>
>
> But netlink_table_grab() returns with write_lock_irq(&nl_table_lock);
>
> So we are not allowed to sleep in a
> netlink_table_grab()/netlink_table_ungrab() section .
Right.
^ permalink raw reply
* Re: [PATCH 1/3] netlink: af_netlink cleanup
From: David Miller @ 2011-12-21 23:01 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20111221134729.3d652e24@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 21 Dec 2011 13:47:29 -0800
> -static inline struct sk_buff *netlink_trim(struct sk_buff *skb,
> +static struct sk_buff *netlink_trim(struct sk_buff *skb,
> gfp_t allocation)
Please fix up the subsequent lines so that the arguments still line
up properly with the preceeding line's openning parens.
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select_ident
From: Chris Boot @ 2011-12-21 23:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: lkml, netdev
In-Reply-To: <4EF2568C.6040006@bootc.net>
On 21 Dec 2011, at 21:58, Chris Boot wrote:
> On 21/12/2011 20:52, Eric Dumazet wrote:
>> Le mercredi 21 décembre 2011 à 21:28 +0100, Eric Dumazet a écrit :
>>> Le mercredi 21 décembre 2011 à 20:05 +0000, Chris Boot a écrit :
>>>> On 21/12/2011 18:00, Eric Dumazet wrote:
>>>>> Le mercredi 21 décembre 2011 à 18:36 +0100, Eric Dumazet a écrit :
>>>>>
>>>>>> Good point, thats a different problem then, since 3.1 is not supposed to
>>>>>> have this bug.
>>>>>>
>>>>>> It seems rt->rt6i_peer points to invalid memory in your crash.
>>>>>>
>>>>>> (RBX=00000000000001f4)
>>>>>>
>>>>>> 8b 83 a4 00 00 00 mov 0xa4(%rbx),%eax p->refcnt
>>>>>> 1f4+a4 -> CR2=0000000000000298
>>>>>>
>>>>> It would help if you can confirm latest linux tree can reproduce the
>>>>> bug.
>>>> Hi Eric,
>>>>
>>>> I just built a v3.2-rc6-140-gb9e26df with the same config as the Debian
>>>> 3.1.0 kernel. I can reproduce the bug just as easily with this kernel as
>>>> with the Debian kernel. Unfortunately I wasn't able to get an entire
>>>> trace, for some reason it didn't appear to be printed to the serial port
>>>> and hung after the (long) list of loaded kernel modules. The crash
>>>> happens at the same offset:
>>>>
>>> Thanks !
>>>
>>> Oh well, br_netfilter fake_rtable strikes again.
>>>
>>> I'll cook a patch in a couple of minutes...
>>>
>> Could you try following patch ?
>>
>> [snip]
>
> Eric,
>
> It looks good! The rsync that caused the crash real quick hasn't done it at all with the patch applied. I'll keep testing it of course, but I think that's done it.
No, sorry, false hope. The following does look rather different however:
[ 1944.056075] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 1944.063987] IP: [< (null)>] (null)
[ 1944.069156] PGD 412c75067 PUD 413722067 PMD 0
[ 1944.073783] Oops: 0010 [#1] SMP
[ 1944.077201] CPU 0
[ 1944.079136] Modules linked in: sha1_ssse3 sha1_generic hmac sha256_generic dlm configfs ebtable_nat ebtables acpi_cpufreq mperf cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_userspace microcode xt_NOTRACK ip_set_hash_net act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_hfsc sch_htb sch_ingress sch_sfq xt_realm xt_addrtype xt_connlimit ip_set_hash_ip iptable_raw xt_comment xt_recent ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ip6_queue xt_set ip_set nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_conntrack_proto_udplite nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp ts_kmp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_amanda nf_conntrack_h323 nf_conntrack_ftp xt_time xt_TCPMSS xt_TPROXY xt_sctp xt_policy nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit ip6t_LOG ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp ip6table_mangle xt_conntrack xt_connmark xt_CLASSIFY xt_AUDIT ipt_LOG xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables ip6table_filter ip6_tables x_tables bridge stp bonding w83627ehf hwmon_vid coretemp crc32c_intel aesni_intel cryptd aes_x86_64 aes_generic ipmi_poweroff ipmi_devintf ipmi_si ipmi_msghandler vhost_net macvtap macvlan tun drbd lru_cache cn loop kvm_intel kvm snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core processor psmouse iTCO_wdt thermal_sys evdev button pcspkr joydev serio_raw iTCO_vendor_support ext4 mbcache jbd2 crc16 dm_mod raid1 md_mod usb_storage usbhid uas hid sd_mod crc_t10dif ahci libahci libata ehci_hcd igb scsi_mod dca usbcore e1000e usb_common [last unloaded: scsi_wait_scan]
[ 1944.270355]
[ 1944.271898] Pid: 6833, comm: vhost-6831 Not tainted 3.2.0-rc6+ #2 Supermicro X9SCL/X9SCM/X9SCL/X9SCM
[ 1944.281431] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
[ 1944.288974] RSP: 0018:ffff88043fc03960 EFLAGS: 00010206
[ 1944.294422] RAX: ffffffffa0394940 RBX: ffff8804249ab580 RCX: 0000000000000000
[ 1944.301690] RDX: ffff880425f36f70 RSI: ffffffffa03897ac RDI: ffff880425f36f70
[ 1944.308975] RBP: ffff8803fb9a904e R08: ffff880425f36000 R09: ffff88043fc03970
[ 1944.316295] R10: ffff8804249ab580 R11: ffff8804249ab580 R12: 0000000000000014
[ 1944.323669] R13: ffff880427373200 R14: ffff880425f36000 R15: ffff88042315c000
[ 1944.330984] FS: 0000000000000000(0000) GS:ffff88043fc00000(0000) knlGS:0000000000000000
[ 1944.339247] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1944.345153] CR2: 0000000000000000 CR3: 0000000412e64000 CR4: 00000000000426e0
[ 1944.352471] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1944.359696] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1944.366948] Process vhost-6831 (pid: 6833, threadinfo ffff8804134b2000, task ffff880415e93080)
[ 1944.375836] Stack:
[ 1944.377893] ffffffff812a62e1 ffff880425f36f70 ffffffff8168f810 ffff880400000014
[ 1944.385566] ffffffffa038e82d ffff8804249ab580 ffffffffa03897ac ffff880427373200
[ 1944.393283] 0000000000000008 ffff880425f36000 ffff8804249ab580 ffff880425f36000
[ 1944.400926] Call Trace:
[ 1944.403442] <IRQ>
[ 1944.405668] [<ffffffff812a62e1>] ? ip_fragment+0x9d/0x62a
[ 1944.411264] [<ffffffffa038e82d>] ? br_parse_ip_options+0x19a/0x19a [bridge]
[ 1944.418403] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.424500] [<ffffffffa038e2cb>] ? br_nf_post_routing+0x17d/0x18f [bridge]
[ 1944.431661] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
[ 1944.437075] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.443168] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.449299] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
[ 1944.455055] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.461162] [<ffffffffa038e2fd>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
[ 1944.468782] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.474866] [<ffffffffa038985e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
[ 1944.481904] [<ffffffffa038e119>] ? nf_bridge_push_encap_header+0x1c/0x26 [bridge]
[ 1944.489657] [<ffffffffa038e387>] ? br_nf_forward_finish+0x8a/0x95 [bridge]
[ 1944.496793] [<ffffffffa038e6d0>] ? br_parse_ip_options+0x3d/0x19a [bridge]
[ 1944.503956] [<ffffffffa038ea5c>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
[ 1944.510928] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
[ 1944.516355] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
[ 1944.522803] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
[ 1944.529241] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
[ 1944.534941] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
[ 1944.541337] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
[ 1944.548501] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
[ 1944.554921] [<ffffffffa038985e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
[ 1944.561963] [<ffffffffa03899f2>] ? br_forward+0x16/0x5a [bridge]
[ 1944.568219] [<ffffffffa038a51b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
[ 1944.575725] [<ffffffffa038e5f4>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
[ 1944.583459] [<ffffffffa038dfe5>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
[ 1944.589926] [<ffffffffa038ef4d>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
[ 1944.597036] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
[ 1944.602482] [<ffffffffa0071d51>] ? scsi_request_fn+0x33f/0x404 [scsi_mod]
[ 1944.609613] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
[ 1944.616701] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
[ 1944.622438] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
[ 1944.629566] [<ffffffffa00714dd>] ? scsi_run_queue+0x212/0x221 [scsi_mod]
[ 1944.636506] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
[ 1944.643533] [<ffffffffa038a360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
[ 1944.650579] [<ffffffffa038a73c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
[ 1944.657440] [<ffffffffa038a589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
[ 1944.664924] [<ffffffff8127ae5d>] ? __netif_receive_skb+0x324/0x41f
[ 1944.671318] [<ffffffff8127afc4>] ? process_backlog+0x6c/0x123
[ 1944.677277] [<ffffffff81194394>] ? blk_done_softirq+0x65/0x74
[ 1944.683235] [<ffffffff8127ce3e>] ? net_rx_action+0xa1/0x1af
[ 1944.688995] [<ffffffff81036f83>] ? test_tsk_need_resched+0xa/0x13
[ 1944.695229] [<ffffffff8104bdc8>] ? __do_softirq+0xb9/0x177
[ 1944.700887] [<ffffffff8134122c>] ? call_softirq+0x1c/0x30
[ 1944.706513] <EOI>
[ 1944.708704] [<ffffffff8100f841>] ? do_softirq+0x3c/0x7b
[ 1944.714116] [<ffffffff8127d12e>] ? netif_rx_ni+0x1e/0x27
[ 1944.719617] [<ffffffffa0264721>] ? tun_get_user+0x39a/0x3c2 [tun]
[ 1944.725927] [<ffffffffa0264766>] ? tun_sendmsg+0x1d/0x1f [tun]
[ 1944.731950] [<ffffffffa026cb50>] ? handle_tx+0x340/0x3de [vhost_net]
[ 1944.738506] [<ffffffffa026a6cb>] ? vhost_worker+0x10b/0x121 [vhost_net]
[ 1944.745315] [<ffffffffa026a5c0>] ? vhost_attach_cgroups_work+0x1b/0x1b [vhost_net]
[ 1944.753141] [<ffffffff8105ee8d>] ? kthread+0x76/0x7e
[ 1944.758332] [<ffffffff81341134>] ? kernel_thread_helper+0x4/0x10
[ 1944.764533] [<ffffffff8105ee17>] ? kthread_worker_fn+0x139/0x139
[ 1944.770759] [<ffffffff81341130>] ? gs_change+0x13/0x13
[ 1944.776109] Code: Bad RIP value.
[ 1944.779528] RIP [< (null)>] (null)
[ 1944.784777] RSP <ffff88043fc03960>
[ 1944.788327] CR2: 0000000000000000
[ 1944.860298] ---[ end trace 7b7c89d77e0af47a ]---
[ 1944.864943] Kernel panic - not syncing: Fatal exception in interrupt
[ 1944.871420] Pid: 6833, comm: vhost-6831 Tainted: G D 3.2.0-rc6+ #2
[ 1944.878608] Call Trace:
[ 1944.881070] <IRQ> [<ffffffff81333a17>] ? panic+0x95/0x1a5
[ 1944.886655] [<ffffffff8133ae46>] ? oops_end+0xa9/0xb6
[ 1944.891815] [<ffffffff8133336e>] ? no_context+0x1ff/0x20e
[ 1944.897343] [<ffffffff8133ce59>] ? do_page_fault+0x1a8/0x337
[ 1944.903091] [<ffffffff81293e3c>] ? sch_direct_xmit+0x85/0x12f
[ 1944.908942] [<ffffffff8133a5b5>] ? page_fault+0x25/0x30
[ 1944.914291] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.920282] [<ffffffff812a62e1>] ? ip_fragment+0x9d/0x62a
[ 1944.925826] [<ffffffffa038e82d>] ? br_parse_ip_options+0x19a/0x19a [bridge]
[ 1944.932948] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.938939] [<ffffffffa038e2cb>] ? br_nf_post_routing+0x17d/0x18f [bridge]
[ 1944.945967] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
[ 1944.951296] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.957272] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.963246] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
[ 1944.968857] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.974810] [<ffffffffa038e2fd>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
[ 1944.982277] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
[ 1944.988264] [<ffffffffa038985e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
[ 1944.995213] [<ffffffffa038e119>] ? nf_bridge_push_encap_header+0x1c/0x26 [bridge]
[ 1945.002868] [<ffffffffa038e387>] ? br_nf_forward_finish+0x8a/0x95 [bridge]
[ 1945.009908] [<ffffffffa038e6d0>] ? br_parse_ip_options+0x3d/0x19a [bridge]
[ 1945.016924] [<ffffffffa038ea5c>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
[ 1945.023815] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
[ 1945.029154] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
[ 1945.035466] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
[ 1945.041807] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
[ 1945.047397] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
[ 1945.053711] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
[ 1945.060641] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
[ 1945.066982] [<ffffffffa038985e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
[ 1945.073908] [<ffffffffa03899f2>] ? br_forward+0x16/0x5a [bridge]
[ 1945.080083] [<ffffffffa038a51b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
[ 1945.087497] [<ffffffffa038e5f4>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
[ 1945.095719] [<ffffffffa038dfe5>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
[ 1945.102187] [<ffffffffa038ef4d>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
[ 1945.109095] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
[ 1945.114455] [<ffffffffa0071d51>] ? scsi_request_fn+0x33f/0x404 [scsi_mod]
[ 1945.121420] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
[ 1945.128399] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
[ 1945.134054] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
[ 1945.141043] [<ffffffffa00714dd>] ? scsi_run_queue+0x212/0x221 [scsi_mod]
[ 1945.147903] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
[ 1945.154875] [<ffffffffa038a360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
[ 1945.161830] [<ffffffffa038a73c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
[ 1945.168580] [<ffffffffa038a589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
[ 1945.175945] [<ffffffff8127ae5d>] ? __netif_receive_skb+0x324/0x41f
[ 1945.182243] [<ffffffff8127afc4>] ? process_backlog+0x6c/0x123
[ 1945.188118] [<ffffffff81194394>] ? blk_done_softirq+0x65/0x74
[ 1945.193958] [<ffffffff8127ce3e>] ? net_rx_action+0xa1/0x1af
[ 1945.199638] [<ffffffff81036f83>] ? test_tsk_need_resched+0xa/0x13
[ 1945.205887] [<ffffffff8104bdc8>] ? __do_softirq+0xb9/0x177
[ 1945.211498] [<ffffffff8134122c>] ? call_softirq+0x1c/0x30
[ 1945.217018] <EOI> [<ffffffff8100f841>] ? do_softirq+0x3c/0x7b
[ 1945.223149] [<ffffffff8127d12e>] ? netif_rx_ni+0x1e/0x27
[ 1945.228602] [<ffffffffa0264721>] ? tun_get_user+0x39a/0x3c2 [tun]
[ 1945.234841] [<ffffffffa0264766>] ? tun_sendmsg+0x1d/0x1f [tun]
[ 1945.240805] [<ffffffffa026cb50>] ? handle_tx+0x340/0x3de [vhost_net]
[ 1945.247269] [<ffffffffa026a6cb>] ? vhost_worker+0x10b/0x121 [vhost_net]
[ 1945.254020] [<ffffffffa026a5c0>] ? vhost_attach_cgroups_work+0x1b/0x1b [vhost_net]
[ 1945.261773] [<ffffffff8105ee8d>] ? kthread+0x76/0x7e
[ 1945.266844] [<ffffffff81341134>] ? kernel_thread_helper+0x4/0x10
[ 1945.272963] [<ffffffff8105ee17>] ? kthread_worker_fn+0x139/0x139
[ 1945.279100] [<ffffffff81341130>] ? gs_change+0x13/0x13
[ 1945.284417] Rebooting in 120 seconds..
(gdb) list *ip_fragment+0x9d
0xffffffff812a62e1 is in ip_fragment (include/net/dst.h:209).
204 return dst_metric(dst, RTAX_FEATURES) & feature;
205 }
206
207 static inline u32 dst_mtu(const struct dst_entry *dst)
208 {
209 return dst->ops->mtu(dst);
210 }
211
212 /* RTT metrics are stored in milliseconds for user ABI, but used as jiffies */
213 static inline unsigned long dst_metric_rtt(const struct dst_entry *dst, int metric)
(gdb) list *br_flood+0xfa
0x17ac is in br_dev_queue_push_xmit (net/bridge/br_forward.c:43).
38 {
39 return skb->len - (skb->protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
40 }
41
42 int br_dev_queue_push_xmit(struct sk_buff *skb)
43 {
44 /* ip_fragment doesn't copy the MAC header */
45 if (nf_bridge_maybe_copy_header(skb) ||
46 (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb))) {
47 kfree_skb(skb);
Thanks,
Chris
--
Chris Boot
bootc@bootc.net
^ permalink raw reply
* Re: [PATCH] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Xi Wang @ 2011-12-21 23:41 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, therbert, netdev
In-Reply-To: <20111221.144126.2213051521357190879.davem@davemloft.net>
Agreed too. ;-) Thanks for the suggestion.
I will do a v2 without using the magic number.
BTW, a similar magic number (1<<30) is used in rps_sock_flow_sysctl()
at net/core/sysctl_net_core.c. I will change that as well.
- xi
^ permalink raw reply
* [PATCH net-next] tcp: Fix bug in ofo queue pruning MIB stats
From: Vijay Subramanian @ 2011-12-21 23:50 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Alexey Kuznetsov, Vijay Subramanian
Linux MIB LINUX_MIB_OFOPRUNED is supposed to count the number of packets
dropped from the out-of-order queue due to socket buffer overrun. Instead
of counting the number of skbs freed, it counts the number of calls make to
__skb_queue_purge() which is not what the user (see f.e. netstat) is expecting.
Fix this by incrementing the counter correctly.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
net/ipv4/tcp_input.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2877c3e..0e2c21b 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4833,7 +4833,8 @@ static int tcp_prune_ofo_queue(struct sock *sk)
int res = 0;
if (!skb_queue_empty(&tp->out_of_order_queue)) {
- NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_OFOPRUNED);
+ NET_ADD_STATS_BH(sock_net(sk), LINUX_MIB_OFOPRUNED,
+ tp->out_of_order_queue.qlen);
__skb_queue_purge(&tp->out_of_order_queue);
/* Reset SACK state. A conforming SACK implementation will
--
1.7.0.4
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2011-12-22 0:31 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Hopefully the last set of fixes for 3.2.x:
1) iwlwifi fixes that cure the regressions reported by Ted T'so and
others, from Wey-Yi Guy, Johannes Berg, and Emmanuel Grumbach.
2) When we moved PMTU information to the inetpeer cache, we removed the
periodic garbage collector, but this is still needed and without
it we have regressions such as ARP entries sticking around forever
(even after a routing cache flush).
The GC scanner needs to run to see these routing cache entries with
an out-dated generation count, so then can be unlinked, put, and
that route's ARP table references dropped as well.
From Eric Dumazet.
3) The flow cache potentially sleeps, but it can be called in the packet
path with SW interrupts disabled. Add a deferred task that takes
care of this in such situations.
4) The x86-64 BPF JIT has a branch target calculation error, fix from
Markus Kötter.
5) SCTP Autoclose timeout overflow check is not correct, from Xi Wang.
6) SCTP accounts too much into receive buffer space used when estimating
the receive window, fix from Thomas Graf.
7) R8169 programs wrong regiater and bit for MSI enable, from François Romieu.
8) LLC socket layer can reference SKB after sk_eat_skb() when putting the
socket address back to userspace. Fix from Alex Juncu.
9) Add new device ID to ASIX driver, from Aurelien Jacobs.
10) ipconfig spins waiting for "link up" for a very long time even
if no devices have actually been brough up and added the ipconfig's
list of devices. Fix from Gerlando Falauto.
11) When bluetooth L2CAP performs configuration, it potentially references
an uninitialized on-stack l2cap_conf_rfc struct, fix from Mat Martineau.
12) Bluetooth RFCOMM forgets to kill session timer on last channel
disconnect.
13) Revert bluetooth L2CAP connect establishment fix, it causes regressions
when talking to legacy devices. From Gustavo F. Padovan.
14) Fix DMA channel locking in davinci-cpdma driver, from Ilya Yanok.
Please pull, thanks a lot!
The following changes since commit b9e26dfdad5a4f9cbdaacafac6998614cc9c41bc:
Merge git://git.infradead.org/mtd-2.6 (2011-12-20 18:39:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Alex Juncu (1):
llc: llc_cmsg_rcv was getting called after sk_eat_skb.
Aurelien Jacobs (1):
asix: new device id
Dan Carpenter (1):
nfc: signedness bug in __nci_request()
David S. Miller (1):
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
Emmanuel Grumbach (1):
iwlwifi: update SCD BC table for all SCD queues
Eric Dumazet (1):
ipv4: reintroduce route cache garbage collector
Gerlando Falauto (1):
net: have ipconfig not wait if no dev is available
Gustavo F. Padovan (1):
Revert "Bluetooth: Revert: Fix L2CAP connection establishment"
Ilya Yanok (1):
davinci-cpdma: fix locking issue in cpdma_chan_stop
Johannes Berg (1):
iwlwifi: tx_sync only on PAN context
John W. Linville (3):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Markus Kötter (1):
net: bpf_jit: fix an off-one bug in x86_64 cond jump target
Mat Martineau (2):
Bluetooth: Prevent uninitialized data access in L2CAP configuration
Bluetooth: Clear RFCOMM session timer when disconnecting last channel
Rajkumar Manoharan (1):
ath9k: fix max phy rate at rate control init
Steffen Klassert (1):
net: Add a flow_cache_flush_deferred function
Thomas Graf (1):
sctp: Do not account for sizeof(struct sk_buff) in estimated rwnd
Wey-Yi Guy (2):
iwlwifi: do not set the sequence control bit is not needed
iwlwifi: allow to switch to HT40 if not associated
Xi Wang (1):
sctp: fix incorrect overflow check on autoclose
Yogesh Ashok Powar (1):
mwifiex: avoid double list_del in command cancel path
françois romieu (1):
r8169: fix Config2 MSIEnable bit setting.
arch/x86/net/bpf_jit_comp.c | 4 +-
drivers/net/ethernet/realtek/r8169.c | 14 ++--
drivers/net/ethernet/ti/davinci_cpdma.c | 2 +
drivers/net/usb/asix.c | 4 +
drivers/net/wireless/ath/ath9k/rc.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 6 ++
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 4 +-
drivers/net/wireless/mwifiex/cmdevt.c | 9 +--
include/net/flow.h | 1 +
include/net/sctp/structs.h | 4 +
net/bluetooth/hci_conn.c | 2 +-
net/bluetooth/l2cap_core.c | 12 +++-
net/bluetooth/rfcomm/core.c | 1 +
net/core/flow.c | 12 +++
net/ipv4/ipconfig.c | 4 +
net/ipv4/route.c | 107 +++++++++++++++++++++++++
net/llc/af_llc.c | 14 +++-
net/nfc/nci/core.c | 2 +-
net/sctp/associola.c | 2 +-
net/sctp/output.c | 8 +--
net/sctp/outqueue.c | 6 +-
net/sctp/protocol.c | 3 +
net/sctp/socket.c | 2 -
net/sctp/sysctl.c | 13 +++
net/xfrm/xfrm_policy.c | 18 +++-
27 files changed, 220 insertions(+), 47 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] tcp: Fix bug in ofo queue pruning MIB stats
From: David Miller @ 2011-12-22 0:33 UTC (permalink / raw)
To: subramanian.vijay; +Cc: netdev, kuznet
In-Reply-To: <1324511401-2640-1-git-send-email-subramanian.vijay@gmail.com>
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Wed, 21 Dec 2011 15:50:01 -0800
> Linux MIB LINUX_MIB_OFOPRUNED is supposed to count the number of packets
> dropped from the out-of-order queue due to socket buffer overrun. Instead
> of counting the number of skbs freed, it counts the number of calls make to
> __skb_queue_purge() which is not what the user (see f.e. netstat) is expecting.
> Fix this by incrementing the counter correctly.
>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
I disagree, this is an event, and the counter is counting how many times
we prune the out of order queue, not how many packets we prune from that
queue.
^ permalink raw reply
* Re: [PATCH net-next V2] igb: add basic runtime PM support
From: Jeff Kirsher @ 2011-12-22 0:57 UTC (permalink / raw)
To: Yan, Zheng
Cc: netdev@vger.kernel.org, e1000-devel, davem@davemloft.net,
jesse.brandeburg, bruce.w.allan, carolyn.wyborny,
donald.c.skidmore, gregory.v.rose, peter.p.waskiewicz.jr,
alexander.h.duyck, john.ronciak, rjw
In-Reply-To: <4EF16CC2.80806@intel.com>
[-- Attachment #1: Type: text/plain, Size: 876 bytes --]
On Wed, 2011-12-21 at 13:21 +0800, Yan, Zheng wrote:
> Use the runtime power management framework to add basic runtime PM
> support
> to the igb driver. Namely, make the driver suspend the device when the
> link
> is off and set it up for generating a wakeup event after the link has
> been
> detected again. This feature is disabled by default.
>
> Based on e1000e's runtime PM code.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
> ---
> Changes since v1:
> Don't suspend the device when shutting down the interface.
> Avoid race between runtime suspending and ethtool operations.
>
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 16 +++
> drivers/net/ethernet/intel/igb/igb_main.c | 136
> ++++++++++++++++++++++----
> 2 files changed, 133 insertions(+), 19 deletions(-)
I have applied this to my queue of patches. Thanks Zheng!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] tcp: Fix bug in ofo queue pruning MIB stats
From: Vijay Subramanian @ 2011-12-22 1:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet
In-Reply-To: <20111221.193315.2134174670572741208.davem@davemloft.net>
On 21 December 2011 16:33, David Miller <davem@davemloft.net> wrote:
> From: Vijay Subramanian <subramanian.vijay@gmail.com>
> Date: Wed, 21 Dec 2011 15:50:01 -0800
>
>> Linux MIB LINUX_MIB_OFOPRUNED is supposed to count the number of packets
>> dropped from the out-of-order queue due to socket buffer overrun. Instead
>> of counting the number of skbs freed, it counts the number of calls make to
>> __skb_queue_purge() which is not what the user (see f.e. netstat) is expecting.
>> Fix this by incrementing the counter correctly.
>>
>> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
>
> I disagree, this is an event, and the counter is counting how many times
> we prune the out of order queue, not how many packets we prune from that
> queue.
David,
Thank you for the review.
The reason I felt this was a bug was because of what netstat reports.
Here are 2 sample output lines from netstat.
622 packets pruned from receive queue because of socket buffer overrun
--> (from LINUX_MIB_RCVPRUNED)
7 packets dropped from out-of-order queue because of socket buffer
overrun --> (from LINUX_MIB_OFOPRUNED)
netstat is interpreting this incorrectly if the mib counter is
supposed to be tracking events.
Also, LINUX_MIB_OFOPRUNED is named similarly to counters that track
dropped packets (e.g.LINUX_MIB_RCVPRUNED ) than counters that track
events such as a function call (e.g LINUX_MIB_PRUNECALLED). I realize
the naming scheme is not a clinching argument but taken with what
netstat reports, the intent seems to be to track dropped packets.
If the counter is tracking the right thing, is it worth fixing
netstat? The nstat tool in iproute2 tool does not print any
explanatory text in the output, so there is less chance of confusion
there. Maybe we just use the newer nstat and forget about this?
Thanks for your time.
Vijay
^ permalink raw reply
* Re: under-performing bonded interfaces
From: Simon Chen @ 2011-12-22 1:26 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Ben Greear, netdev
In-Reply-To: <1321498314.2885.78.camel@deadeye>
Hi folks,
I added an Intel X520 card to both the sender and receiver... Now I
have two 10G ports on a PCIe 2.0 x8 slot (5Gx8), so the bandwidth of
the PCI bus shouldn't be the bottleneck.
Now the throughput test gives me around 16Gbps in aggregate. Any ideas
how I can push closer to 20G? I don't quite understand where the
bottleneck is now.
Thanks.
-Simon
On Wed, Nov 16, 2011 at 9:51 PM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Wed, 2011-11-16 at 20:38 -0500, Simon Chen wrote:
>> Thanks, Ben. That's good discovery...
>>
>> Are you saying that both 10G NICs are on the same PCIe x4 slot, so
>> that they're subject to the 12G throughput bottleneck?
>
> I assumed you were using 2 ports on the same board, i.e. the same slot.
> If you were using 1 port each of 2 boards then I would have expected
> them both to be usable at full speed. So far as I can remember, PCIe
> bridges are usually set up so there isn't contention for bandwidth
> between slots.
>
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* RE: [PATCH] drivers/iwlwifi: use dma_zalloc_coherent() for DMA allocation
From: Guy, Wey-Yi W @ 2011-12-22 1:33 UTC (permalink / raw)
To: Djalal Harouni
Cc: Intel Linux Wireless, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Morton
In-Reply-To: <20111221194852.GA19795@dztty>
Hi Djalal,
>
> iwl-trans-pcie.c is one of the source files in iwlwifi driver hold
> dual-license (GPL + BSD), are you ok to release your code for the BSD
> license and relinquish the copyright?
Yes, It's ok.
Thank you very much
Wey
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: under-performing bonded interfaces
From: Stephen Hemminger @ 2011-12-22 1:36 UTC (permalink / raw)
To: Simon Chen; +Cc: Ben Hutchings, Ben Greear, netdev
In-Reply-To: <CANj2Eben0hrP6KwxyA1WPqiqzm84w=J2_sdtrKtGvxdftuksqg@mail.gmail.com>
On Wed, 21 Dec 2011 20:26:04 -0500
Simon Chen <simonchennj@gmail.com> wrote:
> Hi folks,
>
> I added an Intel X520 card to both the sender and receiver... Now I
> have two 10G ports on a PCIe 2.0 x8 slot (5Gx8), so the bandwidth of
> the PCI bus shouldn't be the bottleneck.
>
> Now the throughput test gives me around 16Gbps in aggregate. Any ideas
> how I can push closer to 20G? I don't quite understand where the
> bottleneck is now.
In my experience, Intel dual port cards can not run at full speed
when both ports are in use. You need separate slots to hit full
line rate.
^ permalink raw reply
* Re: under-performing bonded interfaces
From: Simon Chen @ 2011-12-22 2:28 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Ben Greear, netdev
In-Reply-To: <CANj2Eben0hrP6KwxyA1WPqiqzm84w=J2_sdtrKtGvxdftuksqg@mail.gmail.com>
Just a bit more info...
I have 24 cores, and the interrupts for each 10G NIC are distributed
to all 24 cores...
I am using the most recent 3.7.17 driver ixgbe driver from Intel.
layer3+4 xmit policy.
-Simon
On Wed, Dec 21, 2011 at 8:26 PM, Simon Chen <simonchennj@gmail.com> wrote:
> Hi folks,
>
> I added an Intel X520 card to both the sender and receiver... Now I
> have two 10G ports on a PCIe 2.0 x8 slot (5Gx8), so the bandwidth of
> the PCI bus shouldn't be the bottleneck.
>
> Now the throughput test gives me around 16Gbps in aggregate. Any ideas
> how I can push closer to 20G? I don't quite understand where the
> bottleneck is now.
>
> Thanks.
> -Simon
>
> On Wed, Nov 16, 2011 at 9:51 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
>> On Wed, 2011-11-16 at 20:38 -0500, Simon Chen wrote:
>>> Thanks, Ben. That's good discovery...
>>>
>>> Are you saying that both 10G NICs are on the same PCIe x4 slot, so
>>> that they're subject to the 12G throughput bottleneck?
>>
>> I assumed you were using 2 ports on the same board, i.e. the same slot.
>> If you were using 1 port each of 2 boards then I would have expected
>> them both to be usable at full speed. So far as I can remember, PCIe
>> bridges are usually set up so there isn't contention for bandwidth
>> between slots.
>>
>> Ben.
>>
>> --
>> Ben Hutchings, Staff Engineer, Solarflare
>> Not speaking for my employer; that's the marketing department's job.
>> They asked us to note that Solarflare product names are trademarked.
>>
^ permalink raw reply
* Re: [PATCH net-next] tcp: Fix bug in ofo queue pruning MIB stats
From: David Miller @ 2011-12-22 3:15 UTC (permalink / raw)
To: subramanian.vijay; +Cc: netdev, kuznet
In-Reply-To: <CAGK4HS8g41A8KB9iqyabZN85Ytgb+HPk3wwvoOuwkk8s9+iuCA@mail.gmail.com>
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Wed, 21 Dec 2011 17:14:05 -0800
> If the counter is tracking the right thing, is it worth fixing
> netstat?
Probably.
The thing is, I can see both intepretations being useful.
If we count packets, we can't tell that OFO pruning happened 4 times
vs. we pruned 4 packets.
But if you want to know the "extent" to which OFO pruning occurs, then
you want the packet count.
^ permalink raw reply
* Re: under-performing bonded interfaces
From: Ben Greear @ 2011-12-22 3:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Simon Chen, Ben Hutchings, netdev
In-Reply-To: <20111221173608.0f04bc8b@nehalam.linuxnetplumber.net>
On 12/21/2011 05:36 PM, Stephen Hemminger wrote:
> On Wed, 21 Dec 2011 20:26:04 -0500
> Simon Chen<simonchennj@gmail.com> wrote:
>
>> Hi folks,
>>
>> I added an Intel X520 card to both the sender and receiver... Now I
>> have two 10G ports on a PCIe 2.0 x8 slot (5Gx8), so the bandwidth of
>> the PCI bus shouldn't be the bottleneck.
>>
>> Now the throughput test gives me around 16Gbps in aggregate. Any ideas
>> how I can push closer to 20G? I don't quite understand where the
>> bottleneck is now.
>
> In my experience, Intel dual port cards can not run at full speed
> when both ports are in use. You need separate slots to hit full
> line rate.
We can run 2 ports right at 10Gbps tx + rx using a core-i7 980x
processor and 5gt/s pci-e bus. This is using a modified version of
pktgen to generate traffic. We can only push around 6 Gbps tx + rx
when generating tcp traffic to/from user-space, but our tcp generator
is not as optimized for bulk transfer as it could be.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH RFC] virtio_net: fix refill related races
From: Rusty Russell @ 2011-12-22 3:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Tejun Heo, Amit Shah, netdev, linux-kernel, virtualization
In-Reply-To: <20111221090637.GA31592@redhat.com>
On Wed, 21 Dec 2011 11:06:37 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Dec 21, 2011 at 10:13:18AM +1030, Rusty Russell wrote:
> > On Tue, 20 Dec 2011 21:45:19 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Tue, Dec 20, 2011 at 11:31:54AM -0800, Tejun Heo wrote:
> > > > On Tue, Dec 20, 2011 at 09:30:55PM +0200, Michael S. Tsirkin wrote:
> > > > > Hmm, in that case it looks like a nasty race could get
> > > > > triggered, with try_fill_recv run on multiple CPUs in parallel,
> > > > > corrupting the linked list within the vq.
> > > > >
> > > > > Using the mutex as my patch did will fix that naturally, as well.
> > > >
> > > > Don't know the code but just use nrt wq. There's even a system one
> > > > called system_nrq_wq.
> > > >
> > > > Thanks.
> > >
> > > We can, but we need the mutex for other reasons, anyway.
> >
> > Well, here's the alternate approach. What do you think?
>
> It looks very clean, thanks. Some documentation suggestions below.
> Also - Cc stable on this and the block patch?
AFAICT we haven't seen this bug, and theoretical bugs don't get into
-stable.
> > Finding two wq issues makes you justifiably cautious, but it almost
> > feels like giving up to simply wrap it in a lock. The APIs are designed
> > to let us do it without a lock; I was just using them wrong.
>
> One thing I note is that this scheme works because there's a single
> entity disabling/enabling napi and the refill thread.
> So it's possible that Amit will need to add a lock and track NAPI
> state anyway to make suspend work. But we'll see.
Fixed typo, documented the locking, queued for -next.
Thanks!
Rusty.
From: Rusty Russell <rusty@rustcorp.com.au>
Subject: virtio_net: set/cancel work on ndo_open/ndo_stop
Michael S. Tsirkin noticed that we could run the refill work after
ndo_close, which can re-enable napi - we don't disable it until
virtnet_remove. This is clearly wrong, so move the workqueue control
to ndo_open and ndo_stop (aka. virtnet_open and virtnet_close).
One subtle point: virtnet_probe() could simply fail if it couldn't
allocate a receive buffer, but that's less polite in virtnet_open() so
we schedule a refill as we do in the normal receive path if we run out
of memory.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/net/virtio_net.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -439,7 +439,13 @@ static int add_recvbuf_mergeable(struct
return err;
}
-/* Returns false if we couldn't fill entirely (OOM). */
+/*
+ * Returns false if we couldn't fill entirely (OOM).
+ *
+ * Normally run in the receive path, but can also be run from ndo_open
+ * before we're receiving packets, or from refill_work which is
+ * careful to disable receiving (using napi_disable).
+ */
static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
{
int err;
@@ -719,6 +725,10 @@ static int virtnet_open(struct net_devic
{
struct virtnet_info *vi = netdev_priv(dev);
+ /* Make sure we have some buffers: if oom use wq. */
+ if (!try_fill_recv(vi, GFP_KERNEL))
+ schedule_delayed_work(&vi->refill, 0);
+
virtnet_napi_enable(vi);
return 0;
}
@@ -772,6 +782,8 @@ static int virtnet_close(struct net_devi
{
struct virtnet_info *vi = netdev_priv(dev);
+ /* Make sure refill_work doesn't re-enable napi! */
+ cancel_delayed_work_sync(&vi->refill);
napi_disable(&vi->napi);
return 0;
@@ -1082,7 +1094,6 @@ static int virtnet_probe(struct virtio_d
unregister:
unregister_netdev(dev);
- cancel_delayed_work_sync(&vi->refill);
free_vqs:
vdev->config->del_vqs(vdev);
free_stats:
@@ -1121,9 +1132,7 @@ static void __devexit virtnet_remove(str
/* Stop all the virtqueues. */
vdev->config->reset(vdev);
-
unregister_netdev(vi->dev);
- cancel_delayed_work_sync(&vi->refill);
/* Free unused buffers in both send and recv, if any. */
free_unused_bufs(vi);
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select_ident
From: Eric Dumazet @ 2011-12-22 4:37 UTC (permalink / raw)
To: Chris Boot; +Cc: lkml, netdev, Steffen Klassert
In-Reply-To: <AEC29013-98F3-4A16-A88B-AD31C9E88EB8@bootc.net>
Le mercredi 21 décembre 2011 à 23:12 +0000, Chris Boot a écrit :
> On 21 Dec 2011, at 21:58, Chris Boot wrote:
>
> > On 21/12/2011 20:52, Eric Dumazet wrote:
> >> Le mercredi 21 décembre 2011 à 21:28 +0100, Eric Dumazet a écrit :
> >>> Le mercredi 21 décembre 2011 à 20:05 +0000, Chris Boot a écrit :
> >>>> On 21/12/2011 18:00, Eric Dumazet wrote:
> >>>>> Le mercredi 21 décembre 2011 à 18:36 +0100, Eric Dumazet a écrit :
> >>>>>
> >>>>>> Good point, thats a different problem then, since 3.1 is not supposed to
> >>>>>> have this bug.
> >>>>>>
> >>>>>> It seems rt->rt6i_peer points to invalid memory in your crash.
> >>>>>>
> >>>>>> (RBX=00000000000001f4)
> >>>>>>
> >>>>>> 8b 83 a4 00 00 00 mov 0xa4(%rbx),%eax p->refcnt
> >>>>>> 1f4+a4 -> CR2=0000000000000298
> >>>>>>
> >>>>> It would help if you can confirm latest linux tree can reproduce the
> >>>>> bug.
> >>>> Hi Eric,
> >>>>
> >>>> I just built a v3.2-rc6-140-gb9e26df with the same config as the Debian
> >>>> 3.1.0 kernel. I can reproduce the bug just as easily with this kernel as
> >>>> with the Debian kernel. Unfortunately I wasn't able to get an entire
> >>>> trace, for some reason it didn't appear to be printed to the serial port
> >>>> and hung after the (long) list of loaded kernel modules. The crash
> >>>> happens at the same offset:
> >>>>
> >>> Thanks !
> >>>
> >>> Oh well, br_netfilter fake_rtable strikes again.
> >>>
> >>> I'll cook a patch in a couple of minutes...
> >>>
> >> Could you try following patch ?
> >>
> >> [snip]
> >
> > Eric,
> >
> > It looks good! The rsync that caused the crash real quick hasn't done it at all with the patch applied. I'll keep testing it of course, but I think that's done it.
>
> No, sorry, false hope. The following does look rather different however:
>
> [ 1944.056075] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 1944.063987] IP: [< (null)>] (null)
> [ 1944.069156] PGD 412c75067 PUD 413722067 PMD 0
> [ 1944.073783] Oops: 0010 [#1] SMP
> [ 1944.077201] CPU 0
> [ 1944.079136] Modules linked in: sha1_ssse3 sha1_generic hmac sha256_generic dlm configfs ebtable_nat ebtables acpi_cpufreq mperf cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_userspace microcode xt_NOTRACK ip_set_hash_net act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_hfsc sch_htb sch_ingress sch_sfq xt_realm xt_addrtype xt_connlimit ip_set_hash_ip iptable_raw xt_comment xt_recent ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ip6_queue xt_set ip_set nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_conntrack_proto_udplite nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp ts_kmp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_amanda nf_conntrack_h323 nf_conntrack_ftp xt_time xt_TCPMSS xt_TPROXY xt_sctp xt_policy nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit ip6t_LOG ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp ip6table_mangle xt_conntrack xt_connmark xt_CLASSIFY xt_AUDIT ipt_LOG xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables ip6table_filter ip6_tables x_tables bridge stp bonding w83627ehf hwmon_vid coretemp crc32c_intel aesni_intel cryptd aes_x86_64 aes_generic ipmi_poweroff ipmi_devintf ipmi_si ipmi_msghandler vhost_net macvtap macvlan tun drbd lru_cache cn loop kvm_intel kvm snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core processor psmouse iTCO_wdt thermal_sys evdev button pcspkr joydev serio_raw iTCO_vendor_support ext4 mbcache jbd2 crc16 dm_mod raid1 md_mod usb_storage usbhid uas hid sd_mod crc_t10dif ahci libahci libata ehci_hcd igb scsi_mod dca usbcore e1000e usb_common [last unloaded: scsi_wait_scan]
> [ 1944.270355]
> [ 1944.271898] Pid: 6833, comm: vhost-6831 Not tainted 3.2.0-rc6+ #2 Supermicro X9SCL/X9SCM/X9SCL/X9SCM
> [ 1944.281431] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
> [ 1944.288974] RSP: 0018:ffff88043fc03960 EFLAGS: 00010206
> [ 1944.294422] RAX: ffffffffa0394940 RBX: ffff8804249ab580 RCX: 0000000000000000
> [ 1944.301690] RDX: ffff880425f36f70 RSI: ffffffffa03897ac RDI: ffff880425f36f70
> [ 1944.308975] RBP: ffff8803fb9a904e R08: ffff880425f36000 R09: ffff88043fc03970
> [ 1944.316295] R10: ffff8804249ab580 R11: ffff8804249ab580 R12: 0000000000000014
> [ 1944.323669] R13: ffff880427373200 R14: ffff880425f36000 R15: ffff88042315c000
> [ 1944.330984] FS: 0000000000000000(0000) GS:ffff88043fc00000(0000) knlGS:0000000000000000
> [ 1944.339247] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1944.345153] CR2: 0000000000000000 CR3: 0000000412e64000 CR4: 00000000000426e0
> [ 1944.352471] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1944.359696] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1944.366948] Process vhost-6831 (pid: 6833, threadinfo ffff8804134b2000, task ffff880415e93080)
> [ 1944.375836] Stack:
> [ 1944.377893] ffffffff812a62e1 ffff880425f36f70 ffffffff8168f810 ffff880400000014
> [ 1944.385566] ffffffffa038e82d ffff8804249ab580 ffffffffa03897ac ffff880427373200
> [ 1944.393283] 0000000000000008 ffff880425f36000 ffff8804249ab580 ffff880425f36000
> [ 1944.400926] Call Trace:
> [ 1944.403442] <IRQ>
> [ 1944.405668] [<ffffffff812a62e1>] ? ip_fragment+0x9d/0x62a
> [ 1944.411264] [<ffffffffa038e82d>] ? br_parse_ip_options+0x19a/0x19a [bridge]
> [ 1944.418403] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.424500] [<ffffffffa038e2cb>] ? br_nf_post_routing+0x17d/0x18f [bridge]
> [ 1944.431661] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
> [ 1944.437075] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.443168] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.449299] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
> [ 1944.455055] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.461162] [<ffffffffa038e2fd>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
> [ 1944.468782] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.474866] [<ffffffffa038985e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
> [ 1944.481904] [<ffffffffa038e119>] ? nf_bridge_push_encap_header+0x1c/0x26 [bridge]
> [ 1944.489657] [<ffffffffa038e387>] ? br_nf_forward_finish+0x8a/0x95 [bridge]
> [ 1944.496793] [<ffffffffa038e6d0>] ? br_parse_ip_options+0x3d/0x19a [bridge]
> [ 1944.503956] [<ffffffffa038ea5c>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
> [ 1944.510928] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
> [ 1944.516355] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
> [ 1944.522803] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
> [ 1944.529241] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
> [ 1944.534941] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
> [ 1944.541337] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
> [ 1944.548501] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
> [ 1944.554921] [<ffffffffa038985e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
> [ 1944.561963] [<ffffffffa03899f2>] ? br_forward+0x16/0x5a [bridge]
> [ 1944.568219] [<ffffffffa038a51b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
> [ 1944.575725] [<ffffffffa038e5f4>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
> [ 1944.583459] [<ffffffffa038dfe5>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
> [ 1944.589926] [<ffffffffa038ef4d>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
> [ 1944.597036] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
> [ 1944.602482] [<ffffffffa0071d51>] ? scsi_request_fn+0x33f/0x404 [scsi_mod]
> [ 1944.609613] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
> [ 1944.616701] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
> [ 1944.622438] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
> [ 1944.629566] [<ffffffffa00714dd>] ? scsi_run_queue+0x212/0x221 [scsi_mod]
> [ 1944.636506] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
> [ 1944.643533] [<ffffffffa038a360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
> [ 1944.650579] [<ffffffffa038a73c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
> [ 1944.657440] [<ffffffffa038a589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
> [ 1944.664924] [<ffffffff8127ae5d>] ? __netif_receive_skb+0x324/0x41f
> [ 1944.671318] [<ffffffff8127afc4>] ? process_backlog+0x6c/0x123
> [ 1944.677277] [<ffffffff81194394>] ? blk_done_softirq+0x65/0x74
> [ 1944.683235] [<ffffffff8127ce3e>] ? net_rx_action+0xa1/0x1af
> [ 1944.688995] [<ffffffff81036f83>] ? test_tsk_need_resched+0xa/0x13
> [ 1944.695229] [<ffffffff8104bdc8>] ? __do_softirq+0xb9/0x177
> [ 1944.700887] [<ffffffff8134122c>] ? call_softirq+0x1c/0x30
> [ 1944.706513] <EOI>
> [ 1944.708704] [<ffffffff8100f841>] ? do_softirq+0x3c/0x7b
> [ 1944.714116] [<ffffffff8127d12e>] ? netif_rx_ni+0x1e/0x27
> [ 1944.719617] [<ffffffffa0264721>] ? tun_get_user+0x39a/0x3c2 [tun]
> [ 1944.725927] [<ffffffffa0264766>] ? tun_sendmsg+0x1d/0x1f [tun]
> [ 1944.731950] [<ffffffffa026cb50>] ? handle_tx+0x340/0x3de [vhost_net]
> [ 1944.738506] [<ffffffffa026a6cb>] ? vhost_worker+0x10b/0x121 [vhost_net]
> [ 1944.745315] [<ffffffffa026a5c0>] ? vhost_attach_cgroups_work+0x1b/0x1b [vhost_net]
> [ 1944.753141] [<ffffffff8105ee8d>] ? kthread+0x76/0x7e
> [ 1944.758332] [<ffffffff81341134>] ? kernel_thread_helper+0x4/0x10
> [ 1944.764533] [<ffffffff8105ee17>] ? kthread_worker_fn+0x139/0x139
> [ 1944.770759] [<ffffffff81341130>] ? gs_change+0x13/0x13
> [ 1944.776109] Code: Bad RIP value.
> [ 1944.779528] RIP [< (null)>] (null)
> [ 1944.784777] RSP <ffff88043fc03960>
> [ 1944.788327] CR2: 0000000000000000
> [ 1944.860298] ---[ end trace 7b7c89d77e0af47a ]---
> [ 1944.864943] Kernel panic - not syncing: Fatal exception in interrupt
> [ 1944.871420] Pid: 6833, comm: vhost-6831 Tainted: G D 3.2.0-rc6+ #2
> [ 1944.878608] Call Trace:
> [ 1944.881070] <IRQ> [<ffffffff81333a17>] ? panic+0x95/0x1a5
> [ 1944.886655] [<ffffffff8133ae46>] ? oops_end+0xa9/0xb6
> [ 1944.891815] [<ffffffff8133336e>] ? no_context+0x1ff/0x20e
> [ 1944.897343] [<ffffffff8133ce59>] ? do_page_fault+0x1a8/0x337
> [ 1944.903091] [<ffffffff81293e3c>] ? sch_direct_xmit+0x85/0x12f
> [ 1944.908942] [<ffffffff8133a5b5>] ? page_fault+0x25/0x30
> [ 1944.914291] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.920282] [<ffffffff812a62e1>] ? ip_fragment+0x9d/0x62a
> [ 1944.925826] [<ffffffffa038e82d>] ? br_parse_ip_options+0x19a/0x19a [bridge]
> [ 1944.932948] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.938939] [<ffffffffa038e2cb>] ? br_nf_post_routing+0x17d/0x18f [bridge]
> [ 1944.945967] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
> [ 1944.951296] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.957272] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.963246] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
> [ 1944.968857] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.974810] [<ffffffffa038e2fd>] ? nf_bridge_update_protocol+0x20/0x20 [bridge]
> [ 1944.982277] [<ffffffffa03897ac>] ? br_flood+0xfa/0xfa [bridge]
> [ 1944.988264] [<ffffffffa038985e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
> [ 1944.995213] [<ffffffffa038e119>] ? nf_bridge_push_encap_header+0x1c/0x26 [bridge]
> [ 1945.002868] [<ffffffffa038e387>] ? br_nf_forward_finish+0x8a/0x95 [bridge]
> [ 1945.009908] [<ffffffffa038e6d0>] ? br_parse_ip_options+0x3d/0x19a [bridge]
> [ 1945.016924] [<ffffffffa038ea5c>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
> [ 1945.023815] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
> [ 1945.029154] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
> [ 1945.035466] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
> [ 1945.041807] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
> [ 1945.047397] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
> [ 1945.053711] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
> [ 1945.060641] [<ffffffffa0389918>] ? __br_deliver+0xa0/0xa0 [bridge]
> [ 1945.066982] [<ffffffffa038985e>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge]
> [ 1945.073908] [<ffffffffa03899f2>] ? br_forward+0x16/0x5a [bridge]
> [ 1945.080083] [<ffffffffa038a51b>] ? br_handle_frame_finish+0x1a1/0x20f [bridge]
> [ 1945.087497] [<ffffffffa038e5f4>] ? br_nf_pre_routing_finish+0x1d0/0x1dd [bridge]
> [ 1945.095719] [<ffffffffa038dfe5>] ? NF_HOOK_THRESH+0x3b/0x55 [bridge]
> [ 1945.102187] [<ffffffffa038ef4d>] ? br_nf_pre_routing+0x3e8/0x3f5 [bridge]
> [ 1945.109095] [<ffffffff8129db6d>] ? nf_iterate+0x41/0x77
> [ 1945.114455] [<ffffffffa0071d51>] ? scsi_request_fn+0x33f/0x404 [scsi_mod]
> [ 1945.121420] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
> [ 1945.128399] [<ffffffff8129dc0b>] ? nf_hook_slow+0x68/0x101
> [ 1945.134054] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
> [ 1945.141043] [<ffffffffa00714dd>] ? scsi_run_queue+0x212/0x221 [scsi_mod]
> [ 1945.147903] [<ffffffffa038a37a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge]
> [ 1945.154875] [<ffffffffa038a360>] ? NF_HOOK.constprop.4+0x3c/0x56 [bridge]
> [ 1945.161830] [<ffffffffa038a73c>] ? br_handle_frame+0x1b3/0x1cb [bridge]
> [ 1945.168580] [<ffffffffa038a589>] ? br_handle_frame_finish+0x20f/0x20f [bridge]
> [ 1945.175945] [<ffffffff8127ae5d>] ? __netif_receive_skb+0x324/0x41f
> [ 1945.182243] [<ffffffff8127afc4>] ? process_backlog+0x6c/0x123
> [ 1945.188118] [<ffffffff81194394>] ? blk_done_softirq+0x65/0x74
> [ 1945.193958] [<ffffffff8127ce3e>] ? net_rx_action+0xa1/0x1af
> [ 1945.199638] [<ffffffff81036f83>] ? test_tsk_need_resched+0xa/0x13
> [ 1945.205887] [<ffffffff8104bdc8>] ? __do_softirq+0xb9/0x177
> [ 1945.211498] [<ffffffff8134122c>] ? call_softirq+0x1c/0x30
> [ 1945.217018] <EOI> [<ffffffff8100f841>] ? do_softirq+0x3c/0x7b
> [ 1945.223149] [<ffffffff8127d12e>] ? netif_rx_ni+0x1e/0x27
> [ 1945.228602] [<ffffffffa0264721>] ? tun_get_user+0x39a/0x3c2 [tun]
> [ 1945.234841] [<ffffffffa0264766>] ? tun_sendmsg+0x1d/0x1f [tun]
> [ 1945.240805] [<ffffffffa026cb50>] ? handle_tx+0x340/0x3de [vhost_net]
> [ 1945.247269] [<ffffffffa026a6cb>] ? vhost_worker+0x10b/0x121 [vhost_net]
> [ 1945.254020] [<ffffffffa026a5c0>] ? vhost_attach_cgroups_work+0x1b/0x1b [vhost_net]
> [ 1945.261773] [<ffffffff8105ee8d>] ? kthread+0x76/0x7e
> [ 1945.266844] [<ffffffff81341134>] ? kernel_thread_helper+0x4/0x10
> [ 1945.272963] [<ffffffff8105ee17>] ? kthread_worker_fn+0x139/0x139
> [ 1945.279100] [<ffffffff81341130>] ? gs_change+0x13/0x13
> [ 1945.284417] Rebooting in 120 seconds..
>
> (gdb) list *ip_fragment+0x9d
> 0xffffffff812a62e1 is in ip_fragment (include/net/dst.h:209).
> 204 return dst_metric(dst, RTAX_FEATURES) & feature;
> 205 }
> 206
> 207 static inline u32 dst_mtu(const struct dst_entry *dst)
> 208 {
> 209 return dst->ops->mtu(dst);
> 210 }
> 211
> 212 /* RTT metrics are stored in milliseconds for user ABI, but used as jiffies */
This one is different, its not IPv6 related but IPv4 :
fake_dst_ops lacks a .mtu() field
Bug added in commit 618f9bc74a039da76 (net: Move mtu handling down to
the protocol depended handlers)
Here is an updated patch, thanks again !
include/net/dst.h | 1 +
net/bridge/br_netfilter.c | 8 +++++++-
net/ipv4/route.c | 4 ++--
net/ipv6/ip6_output.c | 2 +-
4 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 6faec1a..75766b4 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -53,6 +53,7 @@ struct dst_entry {
#define DST_NOHASH 0x0008
#define DST_NOCACHE 0x0010
#define DST_NOCOUNT 0x0020
+#define DST_NOPEER 0x0040
short error;
short obsolete;
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index d6ec372..fa8b8f7 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -114,12 +114,18 @@ static struct neighbour *fake_neigh_lookup(const struct dst_entry *dst, const vo
return NULL;
}
+static unsigned int fake_mtu(const struct dst_entry *dst)
+{
+ return dst->dev->mtu;
+}
+
static struct dst_ops fake_dst_ops = {
.family = AF_INET,
.protocol = cpu_to_be16(ETH_P_IP),
.update_pmtu = fake_update_pmtu,
.cow_metrics = fake_cow_metrics,
.neigh_lookup = fake_neigh_lookup,
+ .mtu = fake_mtu,
};
/*
@@ -141,7 +147,7 @@ void br_netfilter_rtable_init(struct net_bridge *br)
rt->dst.dev = br->dev;
rt->dst.path = &rt->dst;
dst_init_metrics(&rt->dst, br_dst_default_metrics, true);
- rt->dst.flags = DST_NOXFRM;
+ rt->dst.flags = DST_NOXFRM | DST_NOPEER;
rt->dst.ops = &fake_dst_ops;
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 252c512..a5004f1 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1366,7 +1366,7 @@ void __ip_select_ident(struct iphdr *iph, struct dst_entry *dst, int more)
{
struct rtable *rt = (struct rtable *) dst;
- if (rt) {
+ if (rt && !(rt->dst.flags & DST_NOPEER)) {
if (rt->peer == NULL)
rt_bind_peer(rt, rt->rt_dst, 1);
@@ -1377,7 +1377,7 @@ void __ip_select_ident(struct iphdr *iph, struct dst_entry *dst, int more)
iph->id = htons(inet_getid(rt->peer, more));
return;
}
- } else
+ } else if (!rt)
printk(KERN_DEBUG "rt_bind_peer(0) @%p\n",
__builtin_return_address(0));
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 84d0bd5..ec56271 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -603,7 +603,7 @@ void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
static atomic_t ipv6_fragmentation_id;
int old, new;
- if (rt) {
+ if (rt && !(rt->dst.flags & DST_NOPEER)) {
struct inet_peer *peer;
if (!rt->rt6i_peer)
^ permalink raw reply related
* Re: under-performing bonded interfaces
From: Eric Dumazet @ 2011-12-22 5:43 UTC (permalink / raw)
To: Simon Chen; +Cc: Ben Hutchings, Ben Greear, netdev
In-Reply-To: <CANj2Eben0hrP6KwxyA1WPqiqzm84w=J2_sdtrKtGvxdftuksqg@mail.gmail.com>
Le mercredi 21 décembre 2011 à 20:26 -0500, Simon Chen a écrit :
> Hi folks,
>
> I added an Intel X520 card to both the sender and receiver... Now I
> have two 10G ports on a PCIe 2.0 x8 slot (5Gx8), so the bandwidth of
> the PCI bus shouldn't be the bottleneck.
>
> Now the throughput test gives me around 16Gbps in aggregate. Any ideas
> how I can push closer to 20G? I don't quite understand where the
> bottleneck is now.
Could you post some "perf top" or "perf record / report" numbers ?
^ permalink raw reply
* [PATCH] bridge: provide a mtu() method for fake_dst_ops
From: Eric Dumazet @ 2011-12-22 6:00 UTC (permalink / raw)
To: Chris Boot, David Miller; +Cc: lkml, netdev, Steffen Klassert
In-Reply-To: <1324528656.2621.19.camel@edumazet-laptop>
Commit 618f9bc74a039da76 (net: Move mtu handling down to the protocol
depended handlers) forgot the bridge netfilter case, adding a NULL
dereference in ip_fragment().
Reported-by: Chris Boot <bootc@bootc.net>
CC: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/bridge/br_netfilter.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index d6ec372..08757dc 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -114,12 +114,18 @@ static struct neighbour *fake_neigh_lookup(const struct dst_entry *dst, const vo
return NULL;
}
+static unsigned int fake_mtu(const struct dst_entry *dst)
+{
+ return dst->dev->mtu;
+}
+
static struct dst_ops fake_dst_ops = {
.family = AF_INET,
.protocol = cpu_to_be16(ETH_P_IP),
.update_pmtu = fake_update_pmtu,
.cow_metrics = fake_cow_metrics,
.neigh_lookup = fake_neigh_lookup,
+ .mtu = fake_mtu,
};
/*
^ permalink raw reply related
* linux-next: build failure after merge of the final tree (net tree related)
From: Stephen Rothwell @ 2011-12-22 6:07 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Linus, Eric Dumazet
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
Hi all,
After merging the final tree, today's linux-next build (sparc32 defconfig)
failed like this:
net/ipv4/route.c: In function 'rt_check_expire':
net/ipv4/route.c:873:4: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
Caused by commit 9f28a2fc0bd7 ("ipv4: reintroduce route cache garbage
collector").
Linus, that commit is in the latest pull request you have from Dave ...
I applied the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 22 Dec 2011 17:03:29 +1100
Subject: [PATCH] ipv4: using prefetch requires including prefetch.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/ipv4/route.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 7460483..9c01f56 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -91,6 +91,7 @@
#include <linux/rcupdate.h>
#include <linux/times.h>
#include <linux/slab.h>
+#include <linux/prefetch.h>
#include <net/dst.h>
#include <net/net_namespace.h>
#include <net/protocol.h>
--
1.7.8.197.g73c6b
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: Eric Dumazet @ 2011-12-22 6:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David Miller, netdev, linux-next, linux-kernel, Linus
In-Reply-To: <20111222170726.b16565ef7d1434cc4ec170d7@canb.auug.org.au>
Le jeudi 22 décembre 2011 à 17:07 +1100, Stephen Rothwell a écrit :
> Hi all,
>
> After merging the final tree, today's linux-next build (sparc32 defconfig)
> failed like this:
>
> net/ipv4/route.c: In function 'rt_check_expire':
> net/ipv4/route.c:873:4: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
>
> Caused by commit 9f28a2fc0bd7 ("ipv4: reintroduce route cache garbage
> collector").
>
> Linus, that commit is in the latest pull request you have from Dave ...
>
> I applied the following patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 22 Dec 2011 17:03:29 +1100
> Subject: [PATCH] ipv4: using prefetch requires including prefetch.h
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> net/ipv4/route.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 7460483..9c01f56 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -91,6 +91,7 @@
> #include <linux/rcupdate.h>
> #include <linux/times.h>
> #include <linux/slab.h>
> +#include <linux/prefetch.h>
> #include <net/dst.h>
> #include <net/net_namespace.h>
> #include <net/protocol.h>
> --
> 1.7.8.197.g73c6b
>
Thanks Stephen
I did a revert of a previous patch, and at that time prefetch() was
probably included in some header.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select_ident
From: Steffen Klassert @ 2011-12-22 6:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Chris Boot, lkml, netdev
In-Reply-To: <1324528656.2621.19.camel@edumazet-laptop>
On Thu, Dec 22, 2011 at 05:37:36AM +0100, Eric Dumazet wrote:
> Le mercredi 21 décembre 2011 à 23:12 +0000, Chris Boot a écrit :
> >
> > (gdb) list *ip_fragment+0x9d
> > 0xffffffff812a62e1 is in ip_fragment (include/net/dst.h:209).
> > 204 return dst_metric(dst, RTAX_FEATURES) & feature;
> > 205 }
> > 206
> > 207 static inline u32 dst_mtu(const struct dst_entry *dst)
> > 208 {
> > 209 return dst->ops->mtu(dst);
> > 210 }
> > 211
> > 212 /* RTT metrics are stored in milliseconds for user ABI, but used as jiffies */
>
> This one is different, its not IPv6 related but IPv4 :
>
> fake_dst_ops lacks a .mtu() field
>
> Bug added in commit 618f9bc74a039da76 (net: Move mtu handling down to
> the protocol depended handlers)
>
Before I did this patch, I changed the .default_mtu field of "struct dst_ops"
to .mtu and converted all users of default_mtu to mtu. fake_dst_ops never
had a default_mtu field, so I did not touch it. I guess this bug is arround
since fake_dst_ops exists. It's now just much easier to trigger as commit
618f9bc74a039da76 changed dst_mtu() to call dst->ops->mtu() unconditionally.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox