* Re: [slab poison overwritten] Re: [GIT] Networking
From: Ingo Molnar @ 2011-03-22 9:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg
In-Reply-To: <20110321173941.GB3892@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> here's the same but with kallsyms enabled.
Sorry, wrong log - find below a kallsyms enabled one.
I'll test the patches in this thread.
Thanks,
Ingo
--------------->
calling dell_init+0x0/0xa @ 1
initcall dell_init+0x0/0xa returned -19 after 2 usecs
calling dell_wmi_init+0x0/0xd4 @ 1
dell-wmi: No known WMI GUID found
initcall dell_wmi_init+0x0/0xd4 returned -19 after 2 usecs
calling tc1100_init+0x0/0x78 @ 1
initcall tc1100_init+0x0/0x78 returned -19 after 2 usecs
calling hdaps_init+0x0/0x2d @ 1
hdaps: supported laptop not found!
hdaps: driver init failed (ret=-19)!
initcall hdaps_init+0x0/0x2d returned -19 after 2 usecs
calling fujitsu_init+0x0/0x21d @ 1
fujitsu-laptop: driver 0.6.0 successfully loaded.
initcall fujitsu_init+0x0/0x21d returned 0 after 393 usecs
calling acpi_pcc_init+0x0/0x23 @ 1
initcall acpi_pcc_init+0x0/0x23 returned 0 after 59 usecs
calling intel_menlow_module_init+0x0/0x8f @ 1
initcall intel_menlow_module_init+0x0/0x8f returned -19 after 13 usecs
calling msi_wmi_init+0x0/0x15b @ 1
This machine doesn't have MSI-hotkeys through WMI
initcall msi_wmi_init+0x0/0x15b returned -19 after 3 usecs
calling asus_acpi_init+0x0/0xdf @ 1
initcall asus_acpi_init+0x0/0xdf returned -19 after 98 usecs
calling topstar_laptop_init+0x0/0x22 @ 1
Topstar Laptop ACPI extras driver loaded
initcall topstar_laptop_init+0x0/0x22 returned 0 after 50 usecs
calling ibm_rtl_init+0x0/0x245 @ 1
initcall ibm_rtl_init+0x0/0x245 returned -19 after 2 usecs
calling flow_cache_init_global+0x0/0x112 @ 1
initcall flow_cache_init_global+0x0/0x112 returned 0 after 179 usecs
calling pg_init+0x0/0x2b0 @ 1
pktgen: Packet Generator for packet performance testing. Version: 2.74
usb usb2: rpm_suspend returns 0
usb usb1: rpm_suspend flags 0x9
usb usb1: rpm_suspend returns 0
initcall pg_init+0x0/0x2b0 returned 0 after 1543240 usecs
calling llc_init+0x0/0x1b @ 1
initcall llc_init+0x0/0x1b returned 0 after 2 usecs
calling snap_init+0x0/0x33 @ 1
initcall snap_init+0x0/0x33 returned 0 after 6 usecs
calling blackhole_module_init+0x0/0xf @ 1
initcall blackhole_module_init+0x0/0xf returned 0 after 2 usecs
calling police_init_module+0x0/0xf @ 1
initcall police_init_module+0x0/0xf returned 0 after 2 usecs
calling ipt_init_module+0x0/0xf @ 1
initcall ipt_init_module+0x0/0xf returned 0 after 1 usecs
calling skbedit_init_module+0x0/0xf @ 1
initcall skbedit_init_module+0x0/0xf returned 0 after 1 usecs
calling red_module_init+0x0/0xf @ 1
initcall red_module_init+0x0/0xf returned 0 after 1 usecs
calling gred_module_init+0x0/0xf @ 1
initcall gred_module_init+0x0/0xf returned 0 after 1 usecs
calling ingress_module_init+0x0/0xf @ 1
initcall ingress_module_init+0x0/0xf returned 0 after 1 usecs
calling dsmark_module_init+0x0/0xf @ 1
initcall dsmark_module_init+0x0/0xf returned 0 after 2 usecs
calling sfb_module_init+0x0/0xf @ 1
initcall sfb_module_init+0x0/0xf returned 0 after 1 usecs
calling sfq_module_init+0x0/0xf @ 1
initcall sfq_module_init+0x0/0xf returned 0 after 1 usecs
calling prio_module_init+0x0/0xf @ 1
initcall prio_module_init+0x0/0xf returned 0 after 1 usecs
calling multiq_module_init+0x0/0xf @ 1
initcall multiq_module_init+0x0/0xf returned 0 after 1 usecs
calling atm_init+0x0/0xf @ 1
initcall atm_init+0x0/0xf returned 0 after 1 usecs
calling netem_module_init+0x0/0x1c @ 1
netem: version 1.3
initcall netem_module_init+0x0/0x1c returned 0 after 1710 usecs
calling mqprio_module_init+0x0/0xf @ 1
initcall mqprio_module_init+0x0/0xf returned 0 after 1 usecs
calling choke_module_init+0x0/0xf @ 1
initcall choke_module_init+0x0/0xf returned 0 after 1 usecs
calling init_fw+0x0/0xf @ 1
initcall init_fw+0x0/0xf returned 0 after 1 usecs
calling init_rsvp+0x0/0xf @ 1
initcall init_rsvp+0x0/0xf returned 0 after 1 usecs
calling init_basic+0x0/0xf @ 1
initcall init_basic+0x0/0xf returned 0 after 1 usecs
calling cls_flow_init+0x0/0xf @ 1
initcall cls_flow_init+0x0/0xf returned 0 after 1 usecs
calling init_em_cmp+0x0/0xf @ 1
initcall init_em_cmp+0x0/0xf returned 0 after 1 usecs
calling init_em_meta+0x0/0xf @ 1
initcall init_em_meta+0x0/0xf returned 0 after 1 usecs
calling nfnetlink_init+0x0/0x26 @ 1
Netfilter messages via NETLINK v0.30.
initcall nfnetlink_init+0x0/0x26 returned 0 after 3335 usecs
calling nfnetlink_log_init+0x0/0xbe @ 1
initcall nfnetlink_log_init+0x0/0xbe returned 0 after 12 usecs
calling nf_conntrack_standalone_init+0x0/0xf @ 1
nf_conntrack version 0.5.0 (16004 buckets, 64016 max)
initcall nf_conntrack_standalone_init+0x0/0xf returned 0 after 5043 usecs
calling nf_conntrack_ftp_init+0x0/0x1ae @ 1
initcall nf_conntrack_ftp_init+0x0/0x1ae returned 0 after 3 usecs
calling nf_conntrack_irc_init+0x0/0x15e @ 1
initcall nf_conntrack_irc_init+0x0/0x15e returned 0 after 2 usecs
calling xt_init+0x0/0xc6 @ 1
initcall xt_init+0x0/0xc6 returned 0 after 4 usecs
calling tcpudp_mt_init+0x0/0x14 @ 1
initcall tcpudp_mt_init+0x0/0x14 returned 0 after 2 usecs
calling ip_vs_init+0x0/0xe9 @ 1
IPVS: Creating netns size=904 id=0
IPVS: __ip_vs_control_init(): alloc_percpu.
usb usb1: rpm_suspend flags 0xa
usb usb1: rpm_suspend returns 0
IPVS: cannot register namespace.
IPVS: can't setup control.
initcall ip_vs_init+0x0/0xe9 returned -12 after 27614 usecs
initcall ip_vs_init+0x0/0xe9 returned with error code -12
calling ip_vs_rr_init+0x0/0xf @ 1
IPVS: [rr] scheduler registered.
initcall ip_vs_rr_init+0x0/0xf returned 0 after 2902 usecs
calling ip_vs_wlc_init+0x0/0xf @ 1
IPVS: [wlc] scheduler registered.
initcall ip_vs_wlc_init+0x0/0xf returned 0 after 2978 usecs
calling ip_vs_lblc_init+0x0/0x33 @ 1
IPVS: [lblc] scheduler registered.
initcall ip_vs_lblc_init+0x0/0x33 returned 0 after 3080 usecs
calling ip_vs_sed_init+0x0/0xf @ 1
IPVS: [sed] scheduler registered.
initcall ip_vs_sed_init+0x0/0xf returned 0 after 2987 usecs
calling ip_vs_nq_init+0x0/0xf @ 1
IPVS: [nq] scheduler registered.
initcall ip_vs_nq_init+0x0/0xf returned 0 after 2902 usecs
calling sysctl_ipv4_init+0x0/0x71 @ 1
initcall sysctl_ipv4_init+0x0/0x71 returned 0 after 274 usecs
calling init_syncookies+0x0/0x16 @ 1
initcall init_syncookies+0x0/0x16 returned 0 after 31 usecs
calling ah4_init+0x0/0x63 @ 1
initcall ah4_init+0x0/0x63 returned 0 after 2 usecs
calling esp4_init+0x0/0x63 @ 1
initcall esp4_init+0x0/0x63 returned 0 after 1 usecs
calling tunnel4_init+0x0/0x63 @ 1
initcall tunnel4_init+0x0/0x63 returned 0 after 1 usecs
calling ipv4_netfilter_init+0x0/0x10 @ 1
initcall ipv4_netfilter_init+0x0/0x10 returned 0 after 1 usecs
calling ip_tables_init+0x0/0x8d @ 1
ip_tables: (C) 2000-2006 Netfilter Core Team
initcall ip_tables_init+0x0/0x8d returned 0 after 3935 usecs
calling iptable_mangle_init+0x0/0x40 @ 1
=============================================================================
BUG kmalloc-1024: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xbd542464-0xbd54246f. First byte 0x0 instead of 0x6b
INFO: Allocated in ops_init.constprop.5+0x4a/0xe0 age=186 cpu=1 pid=1
INFO: Freed in ops_free+0x2a/0x30 age=168 cpu=1 pid=1
INFO: Slab 0xbf818800 objects=15 used=8 fp=0xbd542180 flags=0x3d0040c1
INFO: Object 0xbd542180 @offset=8576 fp=0xbd5425b0
Bytes b4 0xbd542170: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
Object 0xbd542180: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542190: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5421a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5421b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5421c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5421d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5421e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5421f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542200: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542210: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542220: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542230: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542240: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542250: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542260: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542270: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542280: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542290: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5422a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5422b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5422c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5422d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5422e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5422f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542300: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542310: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542320: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542330: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542340: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542350: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542360: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542370: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542380: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542390: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5423a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5423b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5423c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5423d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5423e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5423f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542400: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542410: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542420: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542430: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542440: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542450: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542460: 6b 6b 6b 6b 00 5c 26 05 e0 75 54 bd 80 14 c1 81 kkkk.\&.�uT�..�.
Object 0xbd542470: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542480: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542490: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5424a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5424b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5424c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5424d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5424e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd5424f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542500: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542510: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542520: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542530: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542540: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542550: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542560: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xbd542570: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk�
Redzone 0xbd542580: bb bb bb bb ����
Padding 0xbd5425a8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Pid: 1, comm: swapper Not tainted 2.6.38-tip-08708-g9ad1933-dirty #109548
Call Trace:
[<8109919b>] print_trailer+0xab/0x110
[<8109932c>] check_bytes_and_report+0xdc/0x120
[<8109a04b>] check_object+0x1db/0x230
[<81098dbb>] ? check_valid_pointer+0x2b/0x60
[<818bb338>] alloc_debug_processing+0x74/0xf2
[<8102f834>] ? __call_console_drivers+0x64/0x80
[<818bb878>] __slab_alloc.constprop.18+0x1a3/0x1fd
[<81792dc1>] ? ipt_alloc_initial_table+0x31/0x1b0
[<81792dc1>] ? ipt_alloc_initial_table+0x31/0x1b0
[<8109b11a>] __kmalloc+0xca/0x100
[<81792dc1>] ipt_alloc_initial_table+0x31/0x1b0
[<81c74fa5>] iptable_mangle_net_init+0x11/0x4c
[<816f89ef>] ops_init.constprop.5+0x2f/0xe0
[<8173e5ea>] ? xt_register_match+0x4a/0x60
[<816f8ae3>] register_pernet_operations+0x43/0x80
[<816f8b8c>] register_pernet_subsys+0x1c/0x30
[<81c74fee>] iptable_mangle_init+0xe/0x40
[<81c3881e>] do_one_initcall+0x51/0x134
[<81c74fe0>] ? iptable_mangle_init+0x0/0x40
[<81c74fe0>] ? iptable_mangle_init+0x0/0x40
[<81c38a2a>] kernel_init+0x129/0x1b5
[<81c38901>] ? kernel_init+0x0/0x1b5
[<818c907e>] kernel_thread_helper+0x6/0xd
FIX kmalloc-1024: Restoring 0xbd542464-0xbd54246f=0x6b
FIX kmalloc-1024: Marking all objects used
usb usb2: rpm_suspend flags 0x9
usb usb2: rpm_suspend returns 0
initcall iptable_mangle_init+0x0/0x40 returned 0 after 674576 usecs
calling ulog_tg_init+0x0/0xe2 @ 1
initcall ulog_tg_init+0x0/0xe2 returned 0 after 9 usecs
calling cubictcp_register+0x0/0x73 @ 1
TCP cubic registered
initcall cubictcp_register+0x0/0x73 returned 0 after 1879 usecs
calling xfrm_user_init+0x0/0x41 @ 1
Initializing XFRM netlink socket
initcall xfrm_user_init+0x0/0x41 returned 0 after 2914 usecs
calling inet6_init+0x0/0x27f @ 1
NET: Registered protocol family 10
initcall inet6_init+0x0/0x27f returned 0 after 6231 usecs
calling ah6_init+0x0/0x63 @ 1
initcall ah6_init+0x0/0x63 returned 0 after 1 usecs
calling esp6_init+0x0/0x63 @ 1
initcall esp6_init+0x0/0x63 returned 0 after 2 usecs
calling ipcomp6_init+0x0/0x63 @ 1
initcall ipcomp6_init+0x0/0x63 returned 0 after 1 usecs
calling xfrm6_tunnel_init+0x0/0xc5 @ 1
initcall xfrm6_tunnel_init+0x0/0xc5 returned 0 after 141 usecs
calling tunnel6_init+0x0/0x63 @ 1
initcall tunnel6_init+0x0/0x63 returned 0 after 1 usecs
calling xfrm6_transport_init+0x0/0x14 @ 1
initcall xfrm6_transport_init+0x0/0x14 returned 0 after 2 usecs
calling xfrm6_mode_tunnel_init+0x0/0x14 @ 1
initcall xfrm6_mode_tunnel_init+0x0/0x14 returned 0 after 1 usecs
calling xfrm6_ro_init+0x0/0x14 @ 1
initcall xfrm6_ro_init+0x0/0x14 returned 0 after 1 usecs
calling mip6_init+0x0/0xb4 @ 1
Mobile IPv6
initcall mip6_init+0x0/0xb4 returned 0 after 1116 usecs
calling ip6_tables_init+0x0/0x8d @ 1
ip6_tables: (C) 2000-2006 Netfilter Core Team
initcall ip6_tables_init+0x0/0x8d returned 0 after 4010 usecs
calling nf_conntrack_l3proto_ipv6_init+0x0/0xd9 @ 1
initcall nf_conntrack_l3proto_ipv6_init+0x0/0xd9 returned 0 after 93 usecs
calling nf_defrag_init+0x0/0x4a @ 1
initcall nf_defrag_init+0x0/0x4a returned 0 after 23 usecs
calling log_tg6_init+0x0/0x24 @ 1
initcall log_tg6_init+0x0/0x24 returned 0 after 1 usecs
calling sit_init+0x0/0x52 @ 1
IPv6 over IPv4 tunneling driver
initcall sit_init+0x0/0x52 returned 0 after 3741 usecs
calling packet_init+0x0/0x39 @ 1
NET: Registered protocol family 17
initcall packet_init+0x0/0x39 returned 0 after 3078 usecs
calling ipsec_pfkey_init+0x0/0x69 @ 1
NET: Registered protocol family 15
^ permalink raw reply
* Re: [Security] [SECURITY] DECnet: need to validate user data and access data?
From: Steven Whitehouse @ 2011-03-22 9:13 UTC (permalink / raw)
To: Eugene Teo; +Cc: Dan Rosenberg, davem, netdev, security, linux-decnet-user
In-Reply-To: <AANLkTinbj295sZvXrQm6uhH9+DbAbY1AZU7Eo5_dC6HP@mail.gmail.com>
Hi,
On Tue, 2011-03-22 at 15:42 +0800, Eugene Teo wrote:
> Cc'ed the decnet list. Looks like it's still active even though the
> status is orphan.
>
Well, kind of active :-) I don't think there is a lot of development
going on despite davem's recent changes to the routing code.
These functions are used in relation to conninit messages which, on the
incoming side are checked in dn_nsp_in.c:dn_find_listener() via the
calls to dn_check_idf() so that we should never queue an incorrectly
formatted message to the socket. The intent was that all messages should
be checked as early as possible on entry to the code so that we can then
rely on their content later on without needing to check again.
I hope that answers your question, but let me know if you need anything
else,
Steve.
> On Tue, Mar 22, 2011 at 7:41 AM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> > In net/decnet/af_decnet.c, in the dn_access_copy() and dn_user_copy()
> > functions, which are called from dn_connect(), length values are
> > retrieved from incoming skb data and used as size values to copy
> > functions:
> >
> > static void dn_access_copy(struct sk_buff *skb, struct accessdata_dn *acc)
> > {
> > unsigned char *ptr = skb->data;
> >
> > acc->acc_userl = *ptr++;
> > memcpy(&acc->acc_user, ptr, acc->acc_userl);
> > ptr += acc->acc_userl;
> >
> > acc->acc_passl = *ptr++;
> > memcpy(&acc->acc_pass, ptr, acc->acc_passl);
> > ptr += acc->acc_passl;
> >
> > acc->acc_accl = *ptr++;
> > memcpy(&acc->acc_acc, ptr, acc->acc_accl);
> >
> > skb_pull(skb, acc->acc_accl + acc->acc_passl + acc->acc_userl + 3);
> >
> > }
> >
> > static void dn_user_copy(struct sk_buff *skb, struct optdata_dn *opt)
> > {
> > unsigned char *ptr = skb->data;
> > u16 len = *ptr++; /* yes, it's 8bit on the wire */
> >
> > BUG_ON(len > 16); /* we've checked the contents earlier */
> > opt->opt_optl = cpu_to_le16(len);
> > opt->opt_status = 0;
> > memcpy(opt->opt_data, ptr, len);
> > skb_pull(skb, len + 1);
> > }
> >
> >
> > Despite the BUG_ON and comment suggesting these lengths have been
> > validated, I don't think this is actually the case - it looks like these
> > fields are validated for outbound data, but I see no validation for
> > inbound data (unless I'm mistaken, which is entirely possible). If this
> > is the case, this can allow remote attackers to cause controllable heap
> > corruption. I'd appreciate it if someone who knows this protocol better
> > than I do took a look at this and implemented appropriate error handling
> > if it needs it.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Security] [SECURITY] DECnet: need to validate user data and access data?
From: David Miller @ 2011-03-22 9:21 UTC (permalink / raw)
To: swhiteho; +Cc: eugeneteo, drosenberg, netdev, security, linux-decnet-user
In-Reply-To: <1300785230.2558.6.camel@dolmen>
From: Steven Whitehouse <swhiteho@redhat.com>
Date: Tue, 22 Mar 2011 09:13:50 +0000
> These functions are used in relation to conninit messages which, on the
> incoming side are checked in dn_nsp_in.c:dn_find_listener() via the
> calls to dn_check_idf() so that we should never queue an incorrectly
> formatted message to the socket. The intent was that all messages should
> be checked as early as possible on entry to the code so that we can then
> rely on their content later on without needing to check again.
Ok, so we should be find here.
Thanks for the explanation Steven.
^ permalink raw reply
* Re: [PATCH 3/4] drivers/net/fec: Fix dual MAC support on i.MX28
From: Shawn Guo @ 2011-03-22 9:22 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, u.kleine-koenig
In-Reply-To: <19848.22512.18596.3017@ipc1.ka-ro>
On Tue, Mar 22, 2011 at 09:04:00AM +0100, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
> > Hi Lothar,
> >
> > On Mon, Mar 21, 2011 at 05:37:35PM +0100, Lothar Waßmann wrote:
> > > The variant of the FEC chip found on i.MX28 features two distinct
> > > ethernet MACs that both share a single MII interface. When
> > > deconfiguring the eth0 interface, the MII interface is currently being
> > > switched off, so that the second MAC won't work any more.
> > >
> > I'm wondering what the use case is you intend to support with this
> > patch.
> >
> The patch enables the use of both MACs independently from each other.
> Without this patch deconfiguring eth0 would leave eth1 in an unusable
> state.
>
Ah, I see. Just tested it. It really helps. Thanks for the patch.
With the patch cleaned up, please add:
Acked-by: <shawn.guo@freescale.com>
Tested-by: <shawn.guo@freescale.com>
--
Regards,
Shawn
^ permalink raw reply
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Ingo Molnar @ 2011-03-22 9:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Simon Horman, Julian Anastasov
In-Reply-To: <1300738540.2837.5.camel@edumazet-laptop>
* Eric Dumazet <eric.dumazet@gmail.com> wrote:
> [PATCH] ipvs: fix a typo in __ip_vs_control_init()
This fix and Simon's:
IPVS: Use global mutex in ip_vs_app.c
Did the trick here, the IPVS related SLAB corruptions are now gone.
Thanks guys!
Ingo
^ permalink raw reply
* [PATCH 3/4] drivers/net/fec: Fix dual MAC support on i.MX28
From: Lothar Waßmann @ 2011-03-22 10:00 UTC (permalink / raw)
To: netdev; +Cc: Shawn Guo, u.kleine-koenig, Lothar Waßmann
In-Reply-To: <20110322092256.GG28098@S2100-06.ap.freescale.net>
The variant of the FEC chip found on i.MX28 features two distinct
ethernet MACs that both share a single MII interface. When
deconfiguring the eth0 interface, the MII interface is currently being
switched off, so that the second MAC won't work any more.
Make sure, the first MAC is never disabled when the second FEC device
is registered.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: <shawn.guo@freescale.com>
Tested-by: <shawn.guo@freescale.com>
---
drivers/net/fec.c | 38 +++++++++++++++++++++++++++++++++-----
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 2436db8..3666524 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -82,6 +82,8 @@ static unsigned char macaddr[ETH_ALEN];
module_param_array(macaddr, byte, NULL, 0);
MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
+static int dual_mac;
+
#if defined(CONFIG_M5272)
/*
* Some hardware gets it MAC address out of local flash memory.
@@ -456,6 +459,8 @@ static void
fec_stop(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
/* We cannot expect a graceful transmit stop without link !!! */
if (fep->link) {
@@ -466,11 +471,22 @@ fec_stop(struct net_device *ndev)
printk("fec_stop : Graceful transmit stop did not complete !\n");
}
- /* Whack a reset. We should wait for this. */
- writel(FEC_ECNTRL_RESET, fep->hwp + FEC_ECNTRL);
- udelay(10);
- writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
- writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+ if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && dual_mac &&
+ fep->pdev->id == 0) {
+ /* clear the RDAR/TDAR bits to stop recv/xmit,
+ * but do not reset the controller since the second MAC
+ * may still be using the MII interface and requires ETHER_EN
+ * on the first MAC to be asserted for MII interrupts!
+ */
+ writel(0, fep->hwp + FEC_ECNTRL);
+ writel(FEC_ECNTRL_ETHER_EN, fep->hwp + FEC_ECNTRL);
+ } else {
+ /* Whack a reset. We should wait for this. */
+ writel(FEC_ECNTRL_RESET, fep->hwp + FEC_ECNTRL);
+ udelay(10);
+ writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
+ writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+ }
}
static void
@@ -1435,6 +1461,9 @@ fec_probe(struct platform_device *pdev)
if (ret)
goto failed_register;
+ if (pdev->id > 0)
+ dual_mac = 1;
+
return 0;
failed_register:
--
1.5.6.5
^ permalink raw reply related
* [PATCH 4/4] drivers/net/fec: Don't mess with configured MAC addresses.
From: Lothar Waßmann @ 2011-03-22 10:00 UTC (permalink / raw)
To: netdev; +Cc: Shawn Guo, u.kleine-koenig, Lothar Waßmann
In-Reply-To: <49cf2dff25189eb7b7a0ff9eaceefab359f08b2e.1300724245.git.LW@KARO-electronics.de>
The FEC driver currently uses the MAC address assigned to the first
interface incremented by one for the second interface.
Change this to be able to configure distinct MAC addresses via
platform_data.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/net/fec.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 3666524..9d89e99 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -736,7 +736,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
struct fec_platform_data *pdata = fep->pdev->dev.platform_data;
- unsigned char *iap, tmpaddr[ETH_ALEN];
+ unsigned char iap[ETH_ALEN], tmpaddr[ETH_ALEN];
/*
* try to get mac address in following order:
@@ -744,7 +744,10 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
* 1) module parameter via kernel command line in form
* fec.macaddr=0x00,0x04,0x9f,0x01,0x30,0xe0
*/
- iap = macaddr;
+ if (fep->pdev->id == 0)
+ memcpy(iap, macaddr, ETH_ALEN);
+ else
+ memset(iap, 0, ETH_ALEN);
/*
* 2) from flash or fuse (via platform data)
@@ -767,14 +770,10 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
be32_to_cpu(readl(fep->hwp + FEC_ADDR_LOW));
*((unsigned short *) &tmpaddr[4]) =
be16_to_cpu(readl(fep->hwp + FEC_ADDR_HIGH) >> 16);
- iap = &tmpaddr[0];
+ memcpy(iap, tmpaddr, ETH_ALEN);
}
memcpy(ndev->dev_addr, iap, ETH_ALEN);
-
- /* Adjust MAC if using macaddr */
- if (iap == macaddr)
- ndev->dev_addr[ETH_ALEN-1] = macaddr[ETH_ALEN-1] + fep->pdev->id;
}
/* ------------------------------------------------------------------------- */
--
1.5.6.5
^ permalink raw reply related
* Re: [GIT] Networking
From: Ingo Molnar @ 2011-03-22 10:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTinN3qszBjbJdkXb2TPBkAW0mXGC=Ri1zKL9gdNg@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sun, Mar 20, 2011 at 7:51 PM, David Miller <davem@davemloft.net> wrote:
> >
> > 1) The R8169 PHY fix from Eric Dumazet, which I see you've added to
> > your tree too. :-)
>
> Yeah, since my machine didn't have networking without it, and I could
> test it myself, I didn't wait to pull.
>
> That said, I'm delaying this pull request due to the known issues with
> it - let me know when you've updated it with the fix for the
> use-after-free fixes and the slab corruptor (the latter of which I
> haven't seen a patch for yet)
All problems i was able to trigger in this area are fixed by these patches:
ipvs: Fix a typo in __ip_vs_control_init()
IPVS: Use global mutex in ip_vs_app.c
ipx: Fix ipx_release()
net/appletalk: fix atalk_release use after free
Thanks,
Ingo
^ permalink raw reply
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Eric Dumazet @ 2011-03-22 10:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Simon Horman, Julian Anastasov
In-Reply-To: <20110322095638.GA26130@elte.hu>
Le mardi 22 mars 2011 à 10:56 +0100, Ingo Molnar a écrit :
> * Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > [PATCH] ipvs: fix a typo in __ip_vs_control_init()
>
> This fix and Simon's:
>
> IPVS: Use global mutex in ip_vs_app.c
>
> Did the trick here, the IPVS related SLAB corruptions are now gone.
>
> Thanks guys!
Thanks for testing Ingo ;)
^ permalink raw reply
* [PATCH] net: davinci_emac:Fix translation logic for buffer descriptor
From: Sriramakrishnan @ 2011-03-22 10:06 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, davem, srk
With recent changes to the driver(switch to new cpdma layer),
the support for buffer descriptor address translation logic
is broken. This affects platforms where the physical address of
the descriptors as seen by the DMA engine is different from the
physical address.
Original Patch adding translation logic support:
Commit: ad021ae8862209864dc8ebd3b7d3a55ce84b9ea2
Signed-off-by: Sriramakrishnan <srk@ti.com>
---
This patch has been generated against tip of Linus tree.
drivers/net/davinci_cpdma.c | 11 ++++++++---
drivers/net/davinci_cpdma.h | 1 +
drivers/net/davinci_emac.c | 5 ++++-
include/linux/davinci_emac.h | 1 +
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
index e92b2b6..ae47f23 100644
--- a/drivers/net/davinci_cpdma.c
+++ b/drivers/net/davinci_cpdma.c
@@ -76,6 +76,7 @@ struct cpdma_desc {
struct cpdma_desc_pool {
u32 phys;
+ u32 hw_addr;
void __iomem *iomap; /* ioremap map */
void *cpumap; /* dma_alloc map */
int desc_size, mem_size;
@@ -137,7 +138,8 @@ struct cpdma_chan {
* abstract out these details
*/
static struct cpdma_desc_pool *
-cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
+cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
+ int size, int align)
{
int bitmap_size;
struct cpdma_desc_pool *pool;
@@ -161,10 +163,12 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
if (phys) {
pool->phys = phys;
pool->iomap = ioremap(phys, size);
+ pool->hw_addr = hw_addr;
} else {
pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
GFP_KERNEL);
pool->iomap = (void __force __iomem *)pool->cpumap;
+ pool->hw_addr = pool->phys;
}
if (pool->iomap)
@@ -201,14 +205,14 @@ static inline dma_addr_t desc_phys(struct cpdma_desc_pool *pool,
{
if (!desc)
return 0;
- return pool->phys + (__force dma_addr_t)desc -
+ return pool->hw_addr + (__force dma_addr_t)desc -
(__force dma_addr_t)pool->iomap;
}
static inline struct cpdma_desc __iomem *
desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t dma)
{
- return dma ? pool->iomap + dma - pool->phys : NULL;
+ return dma ? pool->iomap + dma - pool->hw_addr : NULL;
}
static struct cpdma_desc __iomem *
@@ -260,6 +264,7 @@ struct cpdma_ctlr *cpdma_ctlr_create(struct cpdma_params *params)
ctlr->pool = cpdma_desc_pool_create(ctlr->dev,
ctlr->params.desc_mem_phys,
+ ctlr->params.desc_hw_addr,
ctlr->params.desc_mem_size,
ctlr->params.desc_align);
if (!ctlr->pool) {
diff --git a/drivers/net/davinci_cpdma.h b/drivers/net/davinci_cpdma.h
index 868e50e..afa19a0 100644
--- a/drivers/net/davinci_cpdma.h
+++ b/drivers/net/davinci_cpdma.h
@@ -33,6 +33,7 @@ struct cpdma_params {
bool has_soft_reset;
int min_packet_size;
u32 desc_mem_phys;
+ u32 desc_hw_addr;
int desc_mem_size;
int desc_align;
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 082d6ea..df850fc 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1854,10 +1854,13 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
dma_params.rxcp = priv->emac_base + 0x660;
dma_params.num_chan = EMAC_MAX_TXRX_CHANNELS;
dma_params.min_packet_size = EMAC_DEF_MIN_ETHPKTSIZE;
- dma_params.desc_mem_phys = hw_ram_addr;
+ dma_params.desc_hw_addr = hw_ram_addr;
dma_params.desc_mem_size = pdata->ctrl_ram_size;
dma_params.desc_align = 16;
+ dma_params.desc_mem_phys = (pdata->no_bd_ram) ? 0 :
+ ((u32 __force)res->start + pdata->ctrl_ram_offset);
+
priv->dma = cpdma_ctlr_create(&dma_params);
if (!priv->dma) {
dev_err(emac_dev, "DaVinci EMAC: Error initializing DMA\n");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 5dd4285..5428885 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -36,6 +36,7 @@ struct emac_platform_data {
u8 rmii_en;
u8 version;
+ bool no_bd_ram;
void (*interrupt_enable) (void);
void (*interrupt_disable) (void);
};
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH] net: davinci_emac:Fix translation logic for buffer descriptor
From: Sergei Shtylyov @ 2011-03-22 10:11 UTC (permalink / raw)
To: Sriramakrishnan; +Cc: netdev, davinci-linux-open-source, davem
In-Reply-To: <1300788382-12658-1-git-send-email-srk@ti.com>
Hello.
On 22-03-2011 13:06, Sriramakrishnan wrote:
> With recent changes to the driver(switch to new cpdma layer),
> the support for buffer descriptor address translation logic
> is broken. This affects platforms where the physical address of
> the descriptors as seen by the DMA engine is different from the
> physical address.
> Original Patch adding translation logic support:
> Commit: ad021ae8862209864dc8ebd3b7d3a55ce84b9ea2
> Signed-off-by: Sriramakrishnan <srk@ti.com>
AFAIK, full name is required for signoff.
[...]
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 082d6ea..df850fc 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -1854,10 +1854,13 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
> dma_params.rxcp = priv->emac_base + 0x660;
> dma_params.num_chan = EMAC_MAX_TXRX_CHANNELS;
> dma_params.min_packet_size = EMAC_DEF_MIN_ETHPKTSIZE;
> - dma_params.desc_mem_phys = hw_ram_addr;
> + dma_params.desc_hw_addr = hw_ram_addr;
> dma_params.desc_mem_size = pdata->ctrl_ram_size;
> dma_params.desc_align = 16;
>
> + dma_params.desc_mem_phys = (pdata->no_bd_ram) ? 0 :
Parens not needed here.
> + ((u32 __force)res->start + pdata->ctrl_ram_offset);
Here either not necessary.
WBR, Sergei
^ permalink raw reply
* Re: oops / kernel panic in bonding.
From: Jiri Pirko @ 2011-03-22 10:16 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jay Vosburgh, Andy Gospodarek, netdev@vger.kernel.org
In-Reply-To: <4D866F59.5070703@gmail.com>
Sun, Mar 20, 2011 at 10:19:21PM CET, nicolas.2p.debian@gmail.com wrote:
>Le 20/03/2011 21:17, Nicolas de Pesloüan a écrit :
>>Hi Jiri,
>>
>>I suspect we have a race condition somewhere in the new
>>bond_handle_frame function:
>>
>>The following commands produce one of the following errors:
>>
>>modprobe bonding max_bonds=0
>>echo +bond0>/sys/class/net/bonding_masters
>>echo +bond1>/sys/class/net/bonding_masters
>>echo +eth1>/sys/class/net/bond1/bonding/slaves
>>
>>This is mostly reproducible, under VirtualBox.
>>
>>All tests done with 08351fc6a75731226e1112fc7254542bd3a2912e at the top
>>commit (current net-next-2.6).
>
>I suspect netdev_rx_handler_register is called too early in bond_enslave.
>
>I think it should be the last thing we do in bond_enslave, if we
>don't want to face the risk to have bond_handle_frame being called
>before everything is properly setup.
>
> Nicolas.
Nicolas, would you please give the following patch a drive?
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 1a6e9eb..c339eb1 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1482,21 +1482,16 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
{
struct sk_buff *skb = *pskb;
struct slave *slave;
- struct net_device *bond_dev;
struct bonding *bond;
- slave = bond_slave_get_rcu(skb->dev);
- bond_dev = ACCESS_ONCE(slave->dev->master);
- if (unlikely(!bond_dev))
- return RX_HANDLER_PASS;
-
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
return RX_HANDLER_CONSUMED;
*pskb = skb;
- bond = netdev_priv(bond_dev);
+ slave = bond_slave_get_rcu(skb->dev);
+ bond = slave->bond;
if (bond->params.arp_interval)
slave->dev->last_rx = jiffies;
@@ -1505,10 +1500,10 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_EXACT;
}
- skb->dev = bond_dev;
+ skb->dev = bond->dev;
if (bond->params.mode == BOND_MODE_ALB &&
- bond_dev->priv_flags & IFF_BRIDGE_PORT &&
+ bond->dev->priv_flags & IFF_BRIDGE_PORT &&
skb->pkt_type == PACKET_HOST) {
if (unlikely(skb_cow_head(skb,
@@ -1516,7 +1511,7 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
kfree_skb(skb);
return RX_HANDLER_CONSUMED;
}
- memcpy(eth_hdr(skb)->h_dest, bond_dev->dev_addr, ETH_ALEN);
+ memcpy(eth_hdr(skb)->h_dest, bond->dev->dev_addr, ETH_ALEN);
}
return RX_HANDLER_ANOTHER;
@@ -1698,20 +1693,15 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
pr_debug("Error %d calling netdev_set_bond_master\n", res);
goto err_restore_mac;
}
- res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
- new_slave);
- if (res) {
- pr_debug("Error %d calling netdev_rx_handler_register\n", res);
- goto err_unset_master;
- }
/* open the slave since the application closed it */
res = dev_open(slave_dev);
if (res) {
pr_debug("Opening slave %s failed\n", slave_dev->name);
- goto err_unreg_rxhandler;
+ goto err_unset_master;
}
+ new_slave->bond = bond;
new_slave->dev = slave_dev;
slave_dev->priv_flags |= IFF_BONDING;
@@ -1907,6 +1897,13 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
if (res)
goto err_close;
+ res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
+ new_slave);
+ if (res) {
+ pr_debug("Error %d calling netdev_rx_handler_register\n", res);
+ goto err_dest_symlinks;
+ }
+
pr_info("%s: enslaving %s as a%s interface with a%s link.\n",
bond_dev->name, slave_dev->name,
bond_is_active_slave(new_slave) ? "n active" : " backup",
@@ -1916,13 +1913,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
return 0;
/* Undo stages on error */
+err_dest_symlinks:
+ bond_destroy_slave_symlinks(bond_dev, slave_dev);
+
err_close:
dev_close(slave_dev);
-err_unreg_rxhandler:
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
-
err_unset_master:
netdev_set_bond_master(slave_dev, NULL);
@@ -1988,6 +1984,12 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
return -EINVAL;
}
+ /* unregister rx_handler early so bond_handle_frame wouldn't be called
+ * for this slave anymore.
+ */
+ netdev_rx_handler_unregister(slave_dev);
+ synchronize_net();
+
if (!bond->params.fail_over_mac) {
if (!compare_ether_addr(bond_dev->dev_addr, slave->perm_hwaddr) &&
bond->slave_cnt > 1)
@@ -2104,8 +2106,6 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
netif_addr_unlock_bh(bond_dev);
}
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
netdev_set_bond_master(slave_dev, NULL);
slave_disable_netpoll(slave);
@@ -2171,13 +2171,20 @@ static int bond_release_all(struct net_device *bond_dev)
bond_change_active_slave(bond, NULL);
while ((slave = bond->first_slave) != NULL) {
+ slave_dev = slave->dev;
+
+ /* unregister rx_handler early so bond_handle_frame wouldn't
+ * be called for this slave anymore.
+ */
+ netdev_rx_handler_unregister(slave_dev);
+ synchronize_net();
+
/* Inform AD package of unbinding of slave
* before slave is detached from the list.
*/
if (bond->params.mode == BOND_MODE_8023AD)
bond_3ad_unbind_slave(slave);
- slave_dev = slave->dev;
bond_detach_slave(bond, slave);
/* now that the slave is detached, unlock and perform
@@ -2217,8 +2224,6 @@ static int bond_release_all(struct net_device *bond_dev)
netif_addr_unlock_bh(bond_dev);
}
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
netdev_set_bond_master(slave_dev, NULL);
slave_disable_netpoll(slave);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 6b26962..90736cb 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -187,6 +187,7 @@ struct slave {
struct net_device *dev; /* first - useful for panic debug */
struct slave *next;
struct slave *prev;
+ struct bonding *bond; /* our master */
int delay;
unsigned long jiffies;
unsigned long last_arp_rx;
^ permalink raw reply related
* Re: [PATCH] net: davinci_emac:Fix translation logic for buffer descriptor
From: David Miller @ 2011-03-22 10:22 UTC (permalink / raw)
To: sshtylyov; +Cc: srk, netdev, davinci-linux-open-source
In-Reply-To: <4D8875C1.9090004@mvista.com>
From: Sergei Shtylyov <sshtylyov@mvista.com>
Date: Tue, 22 Mar 2011 13:11:13 +0300
> Hello.
>
> On 22-03-2011 13:06, Sriramakrishnan wrote:
>
>> With recent changes to the driver(switch to new cpdma layer),
>> the support for buffer descriptor address translation logic
>> is broken. This affects platforms where the physical address of
>> the descriptors as seen by the DMA engine is different from the
>> physical address.
>
>> Original Patch adding translation logic support:
>> Commit: ad021ae8862209864dc8ebd3b7d3a55ce84b9ea2
>
>> Signed-off-by: Sriramakrishnan <srk@ti.com>
>
> AFAIK, full name is required for signoff.
Indeed, please provide your full name in your signoff lines.
Thanks.
^ permalink raw reply
* Re: bnx2 vlan issue
From: Seblu @ 2011-03-22 10:59 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev
In-Reply-To: <AANLkTik1JJO7mqxPzqfshMfH2JFUXn+yxbTqVdr4QDf6@mail.gmail.com>
On Tue, Mar 22, 2011 at 3:05 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Thu, Mar 17, 2011 at 4:22 PM, Seblu <seblu@seblu.net> wrote:
>> On Thu, Mar 17, 2011 at 8:16 PM, Jesse Gross <jesse@nicira.com> wrote:
>>> On Thu, Mar 17, 2011 at 11:02 AM, Seblu <seblu@seblu.net> wrote:
>>>> On Thu, Mar 17, 2011 at 3:51 PM, Seblu <seblu@seblu.net> wrote:
>> How can I create a bridge with the untagged vlan from an interface?
>>
>>> * bridge on interface, vlans on bridge device. This gives you a
>>> bridge with all packets and vlan devices can give you specific vlans.
>> I cannot use this schema, i used bridge to bring together vnet
>> interface and vlan interface.
>
> I'm not sure I understand why you say you can't use this. You can
> combine vlans and bridging pretty much arbitrarily, including stacking
> multiple layers.
I don't see _how I can bridge an interface with an untagged vlan from
another interface_.
I little example is maybe more clear:
My dekstop have 2 NIC (eth0, eth1). I receive from network admin 2
vlans. 20 untag and 21 tagged. My laptop is plugged to eth1.
I want "export" untagged vlan 20 to eth1.
Before 2.6.37, i do something like br0 = (eth0 + eth1). I put an ip on
br0 and on eth0.21. And br0 just have untagged frame from eth0 which
was transmitted to eth1. eth0.21 have only tagged frame from vlan 21.
eth1 did not receive tagged vlan 21.
After 2.6.37, i can do a bridge like before (br0 = eth0 + eth1) but i
must use br0.21 to have access to vlan 21 network in my desktop. But,
my laptop can also access to tagged vlan 21, and i don't want this.
A lot of old xen based setup use this behaviour.
About my kvm test, I'm looking to the pci passtrough and macvtap, but
this requires configuration that supports it.
Why cannot have a eth0.U with only untagged frames?
>
>>
>>> * Use ebtables rules in the bridge to accept/reject certain packets as desired.
>> I don't see how use ebtables to push untagged frame to a dedicated
>> iface which can be added in a bridge.
>
> You could have a bridge on the raw interface and connect all of the
> VMs that need untagged traffic. If you add an ebtables rule to reject
> tagged traffic then vlan devices on the interface will continue to
> work as before.
>
If I ignores the fact that the name of the card is not fixed, i see.
But performance will follow? I don't believe this kind of config will
allow ~7/8Gbit/s of traffic.
Traversing ebtables rules is not free. And starting filtering traffic
is a really different job than just bridge cards together.
Regards,
--
Sébastien Luttringer
www.seblu.net
^ permalink raw reply
* Re: [Security] [SECURITY] DECnet: need to validate user data and access data?
From: Dan Rosenberg @ 2011-03-22 11:01 UTC (permalink / raw)
To: Steven Whitehouse; +Cc: Eugene Teo, davem, netdev, security, linux-decnet-user
In-Reply-To: <1300785230.2558.6.camel@dolmen>
On Tue, 2011-03-22 at 09:13 +0000, Steven Whitehouse wrote:
> Hi,
>
> On Tue, 2011-03-22 at 15:42 +0800, Eugene Teo wrote:
> > Cc'ed the decnet list. Looks like it's still active even though the
> > status is orphan.
> >
> Well, kind of active :-) I don't think there is a lot of development
> going on despite davem's recent changes to the routing code.
>
> These functions are used in relation to conninit messages which, on the
> incoming side are checked in dn_nsp_in.c:dn_find_listener() via the
> calls to dn_check_idf() so that we should never queue an incorrectly
> formatted message to the socket. The intent was that all messages should
> be checked as early as possible on entry to the code so that we can then
> rely on their content later on without needing to check again.
>
> I hope that answers your question, but let me know if you need anything
> else,
Thanks very much, that does clear it up. I must have missed it because
I was expecting it to use the array size macro (DN_MAXACCL) rather than
a hard-coded value. Glad it's a non-issue.
-Dan
> Steve.
>
> > On Tue, Mar 22, 2011 at 7:41 AM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> > > In net/decnet/af_decnet.c, in the dn_access_copy() and dn_user_copy()
> > > functions, which are called from dn_connect(), length values are
> > > retrieved from incoming skb data and used as size values to copy
> > > functions:
> > >
> > > static void dn_access_copy(struct sk_buff *skb, struct accessdata_dn *acc)
> > > {
> > > unsigned char *ptr = skb->data;
> > >
> > > acc->acc_userl = *ptr++;
> > > memcpy(&acc->acc_user, ptr, acc->acc_userl);
> > > ptr += acc->acc_userl;
> > >
> > > acc->acc_passl = *ptr++;
> > > memcpy(&acc->acc_pass, ptr, acc->acc_passl);
> > > ptr += acc->acc_passl;
> > >
> > > acc->acc_accl = *ptr++;
> > > memcpy(&acc->acc_acc, ptr, acc->acc_accl);
> > >
> > > skb_pull(skb, acc->acc_accl + acc->acc_passl + acc->acc_userl + 3);
> > >
> > > }
> > >
> > > static void dn_user_copy(struct sk_buff *skb, struct optdata_dn *opt)
> > > {
> > > unsigned char *ptr = skb->data;
> > > u16 len = *ptr++; /* yes, it's 8bit on the wire */
> > >
> > > BUG_ON(len > 16); /* we've checked the contents earlier */
> > > opt->opt_optl = cpu_to_le16(len);
> > > opt->opt_status = 0;
> > > memcpy(opt->opt_data, ptr, len);
> > > skb_pull(skb, len + 1);
> > > }
> > >
> > >
> > > Despite the BUG_ON and comment suggesting these lengths have been
> > > validated, I don't think this is actually the case - it looks like these
> > > fields are validated for outbound data, but I see no validation for
> > > inbound data (unless I'm mistaken, which is entirely possible). If this
> > > is the case, this can allow remote attackers to cause controllable heap
> > > corruption. I'd appreciate it if someone who knows this protocol better
> > > than I do took a look at this and implemented appropriate error handling
> > > if it needs it.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/7] TCP CUBIC Hystart fixes
From: Lucas Nussbaum @ 2011-03-22 11:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
On 14/03/11 at 10:52 -0700, Stephen Hemminger wrote:
> This is the merge of my patches and recent update Sangtae.
> It addresses the problems reported by Lucas Nussbaum that Hystart causes
> poor startup performance over links with lots of buffering.
Hi,
I've tested the patches, and they work fine.
Here are some results (gigabit link, RTT=11ms).
Without the patches, hystart disabled:
Segments (cwnd, ssthresh)
2500 ++-----------+-------------+------------+-------------+-----------++
+ + + + snd_cwnd ****** +
| snd_ssthresh ###### |
2000 ++ ************************************************* ++
| ** |
| * |
| * |
1500 ++ * ++
| * |
| * |
1000 ++ * ++
| ** |
| * |
| * |
500 ++ * ++
| ** |
+ ** + + + + +
0 ++-***####################################################--------++
0 0.5 1 1.5 2 2.5
time (seconds)
Without the patches, hystart enabled:
Segments (cwnd, ssthresh)
300 ++------------+------------+-------------+------------+------------++
+ + + + snd_cwnd ****** +
| ***snd_ssthresh ###### |
250 ++ *********************** ++
| ******************################################### |
| * |
200 ++ * ++
| * |
150 ++ * ++
| * |
| * |
100 ++ ** ++
| *# |
| *# |
50 ++ *# ++
| **# |
+ ** # + + + + +
0 ++-*###-------+------------+-------------+------------+------------++
0 0.5 1 1.5 2 2.5
time (seconds)
Note how slow start ends very early (~ 230 segments), resulting in poor performance.
With the patches, hystart enabled, run 1:
Segments (cwnd, ssthresh)
2500 ++-----+-------+------+-------+------+-------+------+-------+-----++
+ + + + + + + snd_cwnd ****** +
| snd_ssthresh ###### |
2000 ++ ********************************************************* ++
| * |
| * |
| * |
1500 ++ * ++
| * |
| ** |
1000 ++ * ++
| * |
| * |
| * |
500 ++ * ++
| ** |
+ * + + + + + + + + +
0 ++**##########################################################----++
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
time (seconds)
There's no perceived delay increase, but also no losses. The NIC sends data at
line rate without congestion. we don't exit slow start, but that's fine:
With the patch, hystart enabled, run 2: (that's the most frequent situation)
Segments (cwnd, ssthresh)
2500 ++-----+-------+------+-------+------+-------+------+-------+-----++
+ + + + + + + snd_cwnd ****** +
| snd_ssthresh ###### |
2000 ++ ******************************************************** ++
| *# |
| *# |
| *# |
1500 ++ *# ++
| *# |
| *# |
1000 ++ **# ++
| * # |
| * # |
| * # |
500 ++ ** # ++
| * # |
+ ** # + + + + + + + +
0 ++**####-------+------+-------+------+-------+------+-------+-----++
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
time (seconds)
Hystart detects a delay increase, so we exit slow start, but at a reasonable point.
Hystart works fine in that case. (no impact on performance).
With the patch, hystart enabled, run 3:
Segments (cwnd, ssthresh)
2500 ++-----+-------+------+-------+------+-------+------+-------+-----++
+ + + + + + + snd_cwnd ****** +
| snd_ssthresh ###### |
2000 ++ ******************************************************* ++
| * |
| ** |
| * |
1500 ++ **####################################################### ++
| *# |
| *# |
1000 ++ *# ++
| *# |
| **# |
| * # |
500 ++ * # ++
| * # |
+ ** #+ + + + + + + + +
0 ++**###+-------+------+-------+------+-------+------+-------+-----++
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
time (seconds)
Hystart causes slow start to end a bit too early, but late enough not to affect
performance significantly. Hystart behaves fine in that case too.
Tested-By: Lucas Nussbaum <lucas.nussbaum@loria.fr>
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: [PATCH 0/7] TCP CUBIC Hystart fixes
From: Lucas Nussbaum @ 2011-03-22 11:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
On 14/03/11 at 10:52 -0700, Stephen Hemminger wrote:
> This is the merge of my patches and recent update Sangtae.
> It addresses the problems reported by Lucas Nussbaum that Hystart causes
> poor startup performance over links with lots of buffering.
What do you plan to do regarding stable kernels? We should probably
either push that patch serie, or disable hystart if HZ < 1000.
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Michael S. Tsirkin @ 2011-03-22 11:36 UTC (permalink / raw)
To: Shirley Ma; +Cc: Herbert Xu, rusty, davem, kvm, netdev
In-Reply-To: <1300730587.3441.24.camel@localhost.localdomain>
On Mon, Mar 21, 2011 at 11:03:07AM -0700, Shirley Ma wrote:
> On Fri, 2011-03-18 at 18:41 -0700, Shirley Ma wrote:
> > > > + /* Drop packet instead of stop queue for better
> > performance
> > > */
> > >
> > > I would like to see some justification as to why this is the right
> > > way to go and not just papering over the real problem.
> >
> > Fair. KVM guest virtio_net TX queue stop/restart is pretty expensive,
> > which involves:
> >
> > 1. Guest enable callback: one memory barrier, interrupt flag set
>
> Missed this cost: for history reason, it also involves a guest exit from
> I/O write (PCI_QUEUE_NOTIFY).
OK, after some research, it looks like the reason was the tx timer that
qemu used to use. So the hack of avoiding the add_buf call will
avoid this kick and so break these hosts.
I guess we can add a feature bit to detect a new host
and so avoid the kick. We are running low on feature bits
unfortunately, but just fo testing, could you quantify the difference
that this makes using the following patch:
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cc2f73e..6106017 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -185,11 +185,6 @@ int virtqueue_add_buf_gfp(struct virtqueue *_vq,
if (vq->num_free < out + in) {
pr_debug("Can't add buf len %i - avail = %i\n",
out + in, vq->num_free);
- /* FIXME: for historical reasons, we force a notify here if
- * there are outgoing parts to the buffer. Presumably the
- * host should service the ring ASAP. */
- if (out)
- vq->notify(&vq->vq);
END_USE(vq);
return -ENOSPC;
}
--
MST
^ permalink raw reply related
* [PATCH] netfilter: h323: bug in parsing of ASN1 SEQOF field
From: David Sterba @ 2011-03-22 11:55 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Sterba, David Miller, stable
Static analyzer of clang found a dead store which appears to be a bug in
reading count of items in SEQOF field, only the lower byte of word is
stored. This may lead to corrupted read and communication shutdown.
The bug has been in the module since it's first inclusion into linux
kernel.
Signed-off-by: David Sterba <dsterba@suse.cz>
CC: David Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
CC: stable@kernel.org
---
net/netfilter/nf_conntrack_h323_asn1.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/nf_conntrack_h323_asn1.c b/net/netfilter/nf_conntrack_h323_asn1.c
index 8678823..bcd5ed6 100644
--- a/net/netfilter/nf_conntrack_h323_asn1.c
+++ b/net/netfilter/nf_conntrack_h323_asn1.c
@@ -631,7 +631,7 @@ static int decode_seqof(bitstr_t *bs, const struct field_t *f,
CHECK_BOUND(bs, 2);
count = *bs->cur++;
count <<= 8;
- count = *bs->cur++;
+ count += *bs->cur++;
break;
case SEMI:
BYTE_ALIGN(bs);
--
1.7.4.1.176.g501cc
^ permalink raw reply related
* [Patch] net: remove useless comments in net/core/dev.c
From: Amerigo Wang @ 2011-03-22 11:59 UTC (permalink / raw)
To: linux-kernel
Cc: WANG Cong, David S. Miller, Eric Dumazet, Changli Gao,
Tom Herbert, Jesse Gross, netdev
The code itself can explain what it is doing, no need these comments.
Signed-off-by: WANG Cong <amwang@redhat.com>
---
net/core/dev.c | 54 ------------------------------------------------------
1 files changed, 0 insertions(+), 54 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..2c2f243 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1140,9 +1140,6 @@ static int __dev_open(struct net_device *dev)
ASSERT_RTNL();
- /*
- * Is it even present?
- */
if (!netif_device_present(dev))
return -ENODEV;
@@ -1151,9 +1148,6 @@ static int __dev_open(struct net_device *dev)
if (ret)
return ret;
- /*
- * Call device private open method
- */
set_bit(__LINK_STATE_START, &dev->state);
if (ops->ndo_validate_addr)
@@ -1162,31 +1156,12 @@ static int __dev_open(struct net_device *dev)
if (!ret && ops->ndo_open)
ret = ops->ndo_open(dev);
- /*
- * If it went open OK then:
- */
-
if (ret)
clear_bit(__LINK_STATE_START, &dev->state);
else {
- /*
- * Set the flags.
- */
dev->flags |= IFF_UP;
-
- /*
- * Enable NET_DMA
- */
net_dmaengine_get();
-
- /*
- * Initialize multicasting status
- */
dev_set_rx_mode(dev);
-
- /*
- * Wakeup transmit queue engine
- */
dev_activate(dev);
}
@@ -1209,22 +1184,13 @@ int dev_open(struct net_device *dev)
{
int ret;
- /*
- * Is it already up?
- */
if (dev->flags & IFF_UP)
return 0;
- /*
- * Open device
- */
ret = __dev_open(dev);
if (ret < 0)
return ret;
- /*
- * ... and announce new interface.
- */
rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_UP|IFF_RUNNING);
call_netdevice_notifiers(NETDEV_UP, dev);
@@ -1240,10 +1206,6 @@ static int __dev_close_many(struct list_head *head)
might_sleep();
list_for_each_entry(dev, head, unreg_list) {
- /*
- * Tell people we are going down, so that they can
- * prepare to death, when device is still operating.
- */
call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
clear_bit(__LINK_STATE_START, &dev->state);
@@ -1272,15 +1234,7 @@ static int __dev_close_many(struct list_head *head)
if (ops->ndo_stop)
ops->ndo_stop(dev);
- /*
- * Device is now down.
- */
-
dev->flags &= ~IFF_UP;
-
- /*
- * Shutdown NET_DMA
- */
net_dmaengine_put();
}
@@ -1309,9 +1263,6 @@ static int dev_close_many(struct list_head *head)
__dev_close_many(head);
- /*
- * Tell people we are down
- */
list_for_each_entry(dev, head, unreg_list) {
rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_UP|IFF_RUNNING);
call_netdevice_notifiers(NETDEV_DOWN, dev);
@@ -1368,11 +1319,6 @@ EXPORT_SYMBOL(dev_disable_lro);
static int dev_boot_phase = 1;
-/*
- * Device change register/unregister. These are not inline or static
- * as we export them to the world.
- */
-
/**
* register_netdevice_notifier - register a network notifier block
* @nb: notifier
^ permalink raw reply related
* Re: [PATCH 0/7] TCP CUBIC Hystart fixes
From: David Miller @ 2011-03-22 12:05 UTC (permalink / raw)
To: lucas.nussbaum; +Cc: shemminger, netdev
In-Reply-To: <20110322113542.GB21254@xanadu.blop.info>
From: Lucas Nussbaum <lucas.nussbaum@loria.fr>
Date: Tue, 22 Mar 2011 12:35:42 +0100
> On 14/03/11 at 10:52 -0700, Stephen Hemminger wrote:
>> This is the merge of my patches and recent update Sangtae.
>> It addresses the problems reported by Lucas Nussbaum that Hystart causes
>> poor startup performance over links with lots of buffering.
>
> What do you plan to do regarding stable kernels? We should probably
> either push that patch serie, or disable hystart if HZ < 1000.
I think once the patch series gets some soaking time in Linus's tree
we can send it over to -stable.
^ permalink raw reply
* [PATCHv2] net: davinci_emac:Fix translation logic for buffer descriptor
From: Sriramakrishnan A G @ 2011-03-22 12:31 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, davem, srk, sshtylyov
With recent changes to the driver(switch to new cpdma layer),
the support for buffer descriptor address translation logic
is broken. This affects platforms where the physical address of
the descriptors as seen by the DMA engine is different from the
physical address.
Original Patch adding translation logic support:
Commit: ad021ae8862209864dc8ebd3b7d3a55ce84b9ea2
Signed-off-by: Sriramakrishnan A G <srk@ti.com>
---
Addresses review comments from Sergei. Generated against tip of Linus tree.
drivers/net/davinci_cpdma.c | 11 ++++++++---
drivers/net/davinci_cpdma.h | 1 +
drivers/net/davinci_emac.c | 5 ++++-
include/linux/davinci_emac.h | 1 +
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
index e92b2b6..ae47f23 100644
--- a/drivers/net/davinci_cpdma.c
+++ b/drivers/net/davinci_cpdma.c
@@ -76,6 +76,7 @@ struct cpdma_desc {
struct cpdma_desc_pool {
u32 phys;
+ u32 hw_addr;
void __iomem *iomap; /* ioremap map */
void *cpumap; /* dma_alloc map */
int desc_size, mem_size;
@@ -137,7 +138,8 @@ struct cpdma_chan {
* abstract out these details
*/
static struct cpdma_desc_pool *
-cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
+cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
+ int size, int align)
{
int bitmap_size;
struct cpdma_desc_pool *pool;
@@ -161,10 +163,12 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
if (phys) {
pool->phys = phys;
pool->iomap = ioremap(phys, size);
+ pool->hw_addr = hw_addr;
} else {
pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
GFP_KERNEL);
pool->iomap = (void __force __iomem *)pool->cpumap;
+ pool->hw_addr = pool->phys;
}
if (pool->iomap)
@@ -201,14 +205,14 @@ static inline dma_addr_t desc_phys(struct cpdma_desc_pool *pool,
{
if (!desc)
return 0;
- return pool->phys + (__force dma_addr_t)desc -
+ return pool->hw_addr + (__force dma_addr_t)desc -
(__force dma_addr_t)pool->iomap;
}
static inline struct cpdma_desc __iomem *
desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t dma)
{
- return dma ? pool->iomap + dma - pool->phys : NULL;
+ return dma ? pool->iomap + dma - pool->hw_addr : NULL;
}
static struct cpdma_desc __iomem *
@@ -260,6 +264,7 @@ struct cpdma_ctlr *cpdma_ctlr_create(struct cpdma_params *params)
ctlr->pool = cpdma_desc_pool_create(ctlr->dev,
ctlr->params.desc_mem_phys,
+ ctlr->params.desc_hw_addr,
ctlr->params.desc_mem_size,
ctlr->params.desc_align);
if (!ctlr->pool) {
diff --git a/drivers/net/davinci_cpdma.h b/drivers/net/davinci_cpdma.h
index 868e50e..afa19a0 100644
--- a/drivers/net/davinci_cpdma.h
+++ b/drivers/net/davinci_cpdma.h
@@ -33,6 +33,7 @@ struct cpdma_params {
bool has_soft_reset;
int min_packet_size;
u32 desc_mem_phys;
+ u32 desc_hw_addr;
int desc_mem_size;
int desc_align;
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 082d6ea..baca6bf 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1854,10 +1854,13 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
dma_params.rxcp = priv->emac_base + 0x660;
dma_params.num_chan = EMAC_MAX_TXRX_CHANNELS;
dma_params.min_packet_size = EMAC_DEF_MIN_ETHPKTSIZE;
- dma_params.desc_mem_phys = hw_ram_addr;
+ dma_params.desc_hw_addr = hw_ram_addr;
dma_params.desc_mem_size = pdata->ctrl_ram_size;
dma_params.desc_align = 16;
+ dma_params.desc_mem_phys = pdata->no_bd_ram ? 0 :
+ (u32 __force)res->start + pdata->ctrl_ram_offset;
+
priv->dma = cpdma_ctlr_create(&dma_params);
if (!priv->dma) {
dev_err(emac_dev, "DaVinci EMAC: Error initializing DMA\n");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 5dd4285..5428885 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -36,6 +36,7 @@ struct emac_platform_data {
u8 rmii_en;
u8 version;
+ bool no_bd_ram;
void (*interrupt_enable) (void);
void (*interrupt_disable) (void);
};
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH 4/4] drivers/net/fec: Don't mess with configured MAC addresses.
From: Shawn Guo @ 2011-03-22 12:33 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, u.kleine-koenig
In-Reply-To: <e7cec31bec3eb7dad56688c4390a59f99625ea83.1300724245.git.LW@KARO-electronics.de>
On Tue, Mar 22, 2011 at 11:00:02AM +0100, Lothar Waßmann wrote:
> The FEC driver currently uses the MAC address assigned to the first
> interface incremented by one for the second interface.
>
> Change this to be able to configure distinct MAC addresses via
> platform_data.
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: <shawn.guo@freescale.com>
--
Regards,
Shawn
> ---
> drivers/net/fec.c | 9 ++-------
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 3666524..9d89e99 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -736,7 +736,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> {
> struct fec_enet_private *fep = netdev_priv(ndev);
> struct fec_platform_data *pdata = fep->pdev->dev.platform_data;
> - unsigned char *iap, tmpaddr[ETH_ALEN];
> + unsigned char iap[ETH_ALEN], tmpaddr[ETH_ALEN];
>
> /*
> * try to get mac address in following order:
> @@ -744,7 +744,10 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> * 1) module parameter via kernel command line in form
> * fec.macaddr=0x00,0x04,0x9f,0x01,0x30,0xe0
> */
> - iap = macaddr;
> + if (fep->pdev->id == 0)
> + memcpy(iap, macaddr, ETH_ALEN);
> + else
> + memset(iap, 0, ETH_ALEN);
>
> /*
> * 2) from flash or fuse (via platform data)
> @@ -767,14 +770,10 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> be32_to_cpu(readl(fep->hwp + FEC_ADDR_LOW));
> *((unsigned short *) &tmpaddr[4]) =
> be16_to_cpu(readl(fep->hwp + FEC_ADDR_HIGH) >> 16);
> - iap = &tmpaddr[0];
> + memcpy(iap, tmpaddr, ETH_ALEN);
> }
>
> memcpy(ndev->dev_addr, iap, ETH_ALEN);
> -
> - /* Adjust MAC if using macaddr */
> - if (iap == macaddr)
> - ndev->dev_addr[ETH_ALEN-1] = macaddr[ETH_ALEN-1] + fep->pdev->id;
> }
>
> /* ------------------------------------------------------------------------- */
> --
> 1.5.6.5
>
^ permalink raw reply
* [patch net-2.6] bonding: fix rx_handler locking
From: Jiri Pirko @ 2011-03-22 12:38 UTC (permalink / raw)
To: netdev; +Cc: davem, nicolas.2p.debian, andy, fubar
This prevents possible race between bond_enslave and bond_handle_frame
as reported by Nicolas by moving rx_handler register/unregister.
slave->bond is added to hold pointer to master bonding sructure. That
way dev->master is no longer used in bond_handler_frame.
Also, this removes "BUG: scheduling while atomic" message
Reported-by: Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/bonding/bond_main.c | 56 +++++++++++++++++++++-----------------
drivers/net/bonding/bonding.h | 1 +
2 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 338bea1..16d6fe9 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1482,21 +1482,16 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
{
struct sk_buff *skb = *pskb;
struct slave *slave;
- struct net_device *bond_dev;
struct bonding *bond;
- slave = bond_slave_get_rcu(skb->dev);
- bond_dev = ACCESS_ONCE(slave->dev->master);
- if (unlikely(!bond_dev))
- return RX_HANDLER_PASS;
-
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
return RX_HANDLER_CONSUMED;
*pskb = skb;
- bond = netdev_priv(bond_dev);
+ slave = bond_slave_get_rcu(skb->dev);
+ bond = slave->bond;
if (bond->params.arp_interval)
slave->dev->last_rx = jiffies;
@@ -1505,10 +1500,10 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_EXACT;
}
- skb->dev = bond_dev;
+ skb->dev = bond->dev;
if (bond->params.mode == BOND_MODE_ALB &&
- bond_dev->priv_flags & IFF_BRIDGE_PORT &&
+ bond->dev->priv_flags & IFF_BRIDGE_PORT &&
skb->pkt_type == PACKET_HOST) {
if (unlikely(skb_cow_head(skb,
@@ -1516,7 +1511,7 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
kfree_skb(skb);
return RX_HANDLER_CONSUMED;
}
- memcpy(eth_hdr(skb)->h_dest, bond_dev->dev_addr, ETH_ALEN);
+ memcpy(eth_hdr(skb)->h_dest, bond->dev->dev_addr, ETH_ALEN);
}
return RX_HANDLER_ANOTHER;
@@ -1698,20 +1693,15 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
pr_debug("Error %d calling netdev_set_bond_master\n", res);
goto err_restore_mac;
}
- res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
- new_slave);
- if (res) {
- pr_debug("Error %d calling netdev_rx_handler_register\n", res);
- goto err_unset_master;
- }
/* open the slave since the application closed it */
res = dev_open(slave_dev);
if (res) {
pr_debug("Opening slave %s failed\n", slave_dev->name);
- goto err_unreg_rxhandler;
+ goto err_unset_master;
}
+ new_slave->bond = bond;
new_slave->dev = slave_dev;
slave_dev->priv_flags |= IFF_BONDING;
@@ -1907,6 +1897,13 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
if (res)
goto err_close;
+ res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
+ new_slave);
+ if (res) {
+ pr_debug("Error %d calling netdev_rx_handler_register\n", res);
+ goto err_dest_symlinks;
+ }
+
pr_info("%s: enslaving %s as a%s interface with a%s link.\n",
bond_dev->name, slave_dev->name,
bond_is_active_slave(new_slave) ? "n active" : " backup",
@@ -1916,13 +1913,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
return 0;
/* Undo stages on error */
+err_dest_symlinks:
+ bond_destroy_slave_symlinks(bond_dev, slave_dev);
+
err_close:
dev_close(slave_dev);
-err_unreg_rxhandler:
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
-
err_unset_master:
netdev_set_bond_master(slave_dev, NULL);
@@ -1988,6 +1984,14 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
return -EINVAL;
}
+ /* unregister rx_handler early so bond_handle_frame wouldn't be called
+ * for this slave anymore.
+ */
+ netdev_rx_handler_unregister(slave_dev);
+ write_unlock_bh(&bond->lock);
+ synchronize_net();
+ write_lock_bh(&bond->lock);
+
if (!bond->params.fail_over_mac) {
if (!compare_ether_addr(bond_dev->dev_addr, slave->perm_hwaddr) &&
bond->slave_cnt > 1)
@@ -2104,8 +2108,6 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
netif_addr_unlock_bh(bond_dev);
}
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
netdev_set_bond_master(slave_dev, NULL);
slave_disable_netpoll(slave);
@@ -2186,6 +2188,12 @@ static int bond_release_all(struct net_device *bond_dev)
*/
write_unlock_bh(&bond->lock);
+ /* unregister rx_handler early so bond_handle_frame wouldn't
+ * be called for this slave anymore.
+ */
+ netdev_rx_handler_unregister(slave_dev);
+ synchronize_net();
+
if (bond_is_lb(bond)) {
/* must be called only after the slave
* has been detached from the list
@@ -2217,8 +2225,6 @@ static int bond_release_all(struct net_device *bond_dev)
netif_addr_unlock_bh(bond_dev);
}
- netdev_rx_handler_unregister(slave_dev);
- synchronize_net();
netdev_set_bond_master(slave_dev, NULL);
slave_disable_netpoll(slave);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 6b26962..90736cb 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -187,6 +187,7 @@ struct slave {
struct net_device *dev; /* first - useful for panic debug */
struct slave *next;
struct slave *prev;
+ struct bonding *bond; /* our master */
int delay;
unsigned long jiffies;
unsigned long last_arp_rx;
--
1.7.4
^ permalink raw reply related
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Steffen Klassert @ 2011-03-22 13:14 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev
In-Reply-To: <4D87F5A6.90704@cn.fujitsu.com>
On Tue, Mar 22, 2011 at 09:04:38AM +0800, Wei Yongjun wrote:
>
> BTW, looking into more about this, another path, XFRM_MSG_NEWAE,
> can overwrite the x->replay_esn with the nla_data length, which
> may larger then the size we malloc.
>
Yes, I've noticed that yesterday too. I'll fix it up.
Thanks!
^ 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