summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2011-05-13bonding,llc: Fix structure sizeof incompatibility for some PDUsVitalii Demianets
With some combinations of arch/compiler (e.g. arm-linux-gcc) the sizeof operator on structure returns value greater than expected. In cases when the structure is used for mapping PDU fields it may lead to unexpected results (such as holes and alignment problems in skb data). __packed prevents this undesired behavior. Signed-off-by: Vitalii Demianets <vitas@nppfactor.kiev.ua> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-12ipv6: restore correct ECN handling on TCP xmitSteinar H. Gunderson
Since commit e9df2e8fd8fbc9 (Use appropriate sock tclass setting for routing lookup) we lost ability to properly add ECN codemarks to ipv6 TCP frames. It seems like TCP_ECN_send() calls INET_ECN_xmit(), which only sets the ECN bit in the IPv4 ToS field (inet_sk(sk)->tos), but after the patch, what's checked is inet6_sk(sk)->tclass, which is a completely different field. Close bug https://bugzilla.kernel.org/show_bug.cgi?id=34322 [Eric Dumazet] : added the INET_ECN_dontxmit() fix and replace macros by inline functions for clarity. Signed-off-by: Steinar H. Gunderson <sgunderson@bigfoot.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-12ne-h8300: Fix regression caused during net_device_ops conversionGeert Uytterhoeven
Changeset dcd39c90290297f6e6ed8a04bb20da7ac2b043c5 ("ne-h8300: convert to net_device_ops") broke ne-h8300 by adding 8390.o to the link. That meant that lib8390.c was included twice, once in ne-h8300.c and once in 8390.c, subject to different macros. This patch reverts that by avoiding the wrappers in 8390.c. Fix based on commits 217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390: fix regression caused during net_device_ops conversion") and 4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with NET_POLL_CONTROLLER"). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-12hydra: Fix regression caused during net_device_ops conversionGeert Uytterhoeven
Changeset 5618f0d1193d6b051da9b59b0e32ad24397f06a4 ("hydra: convert to net_device_ops") broke hydra by adding 8390.o to the link. That meant that lib8390.c was included twice, once in hydra.c and once in 8390.c, subject to different macros. This patch reverts that by avoiding the wrappers in 8390.c. Fix based on commits 217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390: fix regression caused during net_device_ops conversion") and 4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with NET_POLL_CONTROLLER"). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-12zorro8390: Fix regression caused during net_device_ops conversionGeert Uytterhoeven
Changeset b6114794a1c394534659f4a17420e48cf23aa922 ("zorro8390: convert to net_device_ops") broke zorro8390 by adding 8390.o to the link. That meant that lib8390.c was included twice, once in zorro8390.c and once in 8390.c, subject to different macros. This patch reverts that by avoiding the wrappers in 8390.c. Fix based on commits 217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390: fix regression caused during net_device_ops conversion") and 4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with NET_POLL_CONTROLLER"). Reported-by: Christian T. Steigies <cts@debian.org> Suggested-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Christian T. Steigies <cts@debian.org> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-12Merge branch 'sfc-2.6.39' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-2.6
2011-05-12sfc: Always map MCDI shared memory as uncacheableBen Hutchings
We enabled write-combining for memory-mapped registers in commit 65f0b417dee94f779ce9b77102b7d73c93723b39, but inhibited it for the MCDI shared memory where this is not supported. However, write-combining mappings also allow read-reordering, which may also be a problem. I found that when an SFC9000-family controller is connected to an Intel 3000 chipset, and write-combining is enabled, the controller stops responding to PCIe read requests during driver initialisation while the driver is polling for completion of an MCDI command. This results in an NMI and system hang. Adding read memory barriers between all reads to the shared memory area appears to reduce but not eliminate the probability of this. We have not yet established whether this is a bug in our BIU or in the PCIe bridge. For now, work around by mapping the shared memory area separately. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
2011-05-12ehea: Fix memory hotplug oopsAnton Blanchard
The ehea driver oopses during memory hotplug if the ports are not up. A simple testcase: # ifconfig ethX down # echo offline > /sys/devices/system/memory/memory32/state Oops: Kernel access of bad area, sig: 11 [#1] last sysfs file: /sys/devices/system/memory/memory32/state REGS: c000000709393110 TRAP: 0300 Not tainted (2.6.39-rc2-01385-g7ef73bc-dirty) DAR: 0000000000000000, DSISR: 40000000 ... NIP [c000000000067c98] .__wake_up_common+0x48/0xf0 LR [c00000000006d034] .__wake_up+0x54/0x90 Call Trace: [c00000000006d034] .__wake_up+0x54/0x90 [d000000006bb6270] .ehea_rereg_mrs+0x140/0x730 [ehea] [d000000006bb69c4] .ehea_mem_notifier+0x164/0x170 [ehea] [c0000000006fc8a8] .notifier_call_chain+0x78/0xf0 [c0000000000b3d70] .__blocking_notifier_call_chain+0x70/0xb0 [c000000000458d78] .memory_notify+0x28/0x40 [c0000000001871d8] .remove_memory+0x208/0x6d0 [c000000000458264] .memory_section_action+0x94/0x140 [c0000000004583ec] .memory_block_change_state+0xdc/0x1d0 [c0000000004585cc] .store_mem_state+0xec/0x160 [c00000000044768c] .sysdev_store+0x3c/0x50 [c00000000020b48c] .sysfs_write_file+0xec/0x1f0 [c00000000018f86c] .vfs_write+0xec/0x1e0 [c00000000018fa88] .SyS_write+0x58/0xd0 To fix this, initialise the waitqueues during port probe instead of port open. Signed-off-by: Anton Blanchard <anton@samba.org> Cc: stable@kernel.org Acked-by: Breno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-11Merge branch 'master' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
2011-05-10Merge branch 'pablo/nf-2.6-updates' of git://1984.lsi.us.es/net-2.6David S. Miller
2011-05-10slcan: fix ldisc->open retvalOliver Hartkopp
TTY layer expects 0 if the ldisc->open operation succeeded. Reported-by: Matvejchikov Ilya <matvejchikov@gmail.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-10net/usb: mark LG VL600 LTE modem ethernet interface as WWANDan Williams
Like other mobile broadband device ethernet interfaces, mark the LG VL600 with the 'wwan' devtype so userspace knows it needs additional configuration via the AT port before the interface can be used. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-10xfrm: Don't allow esn with disabled anti replay detectionSteffen Klassert
Unlike the standard case, disabled anti replay detection needs some nontrivial extra treatment on ESN. RFC 4303 states: Note: If a receiver chooses to not enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high-order bits of the ESN, which are employed in the ICV computation), which is generally contrary to the notion of disabling anti-replay for an SA. So return an error if an ESN state with disabled anti replay detection is inserted for now and add the extra treatment later if we need it. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-10xfrm: Assign the inner mode output function to the dst entrySteffen Klassert
As it is, we assign the outer modes output function to the dst entry when we create the xfrm bundle. This leads to two problems on interfamily scenarios. We might insert ipv4 packets into ip6_fragment when called from xfrm6_output. The system crashes if we try to fragment an ipv4 packet with ip6_fragment. This issue was introduced with git commit ad0081e4 (ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed). The second issue is, that we might insert ipv4 packets in netfilter6 and vice versa on interfamily scenarios. With this patch we assign the inner mode output function to the dst entry when we create the xfrm bundle. So xfrm4_output/xfrm6_output from the inner mode is used and the right fragmentation and netfilter functions are called. We switch then to outer mode with the output_finish functions. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-10net: dev_close() should check IFF_UPEric Dumazet
Commit 443457242beb (factorize sync-rcu call in unregister_netdevice_many) mistakenly removed one test from dev_close() Following actions trigger a BUG : modprobe bonding modprobe dummy ifconfig bond0 up ifenslave bond0 dummy0 rmmod dummy dev_close() must not close a non IFF_UP device. With help from Frank Blaschka and Einar EL Lueck Reported-by: Frank Blaschka <blaschka@linux.vnet.ibm.com> Reported-by: Einar EL Lueck <ELELUECK@de.ibm.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-10vlan: fix GVRP at dismantle timeEric Dumazet
ip link add link eth2 eth2.103 type vlan id 103 gvrp on loose_binding on ip link set eth2.103 up rmmod tg3 # driver providing eth2 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0030c9e>] garp_request_leave+0x3e/0xc0 [garp] PGD 11d251067 PUD 11b9e0067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/net/eth2.104/ifindex CPU 0 Modules linked in: tg3(-) 8021q garp nfsd lockd auth_rpcgss sunrpc libphy sg [last unloaded: x_tables] Pid: 11494, comm: rmmod Tainted: G W 2.6.39-rc6-00261-gfd71257-dirty #580 HP ProLiant BL460c G6 RIP: 0010:[<ffffffffa0030c9e>] [<ffffffffa0030c9e>] garp_request_leave+0x3e/0xc0 [garp] RSP: 0018:ffff88007a19bae8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88011b5e2000 RCX: 0000000000000002 RDX: 0000000000000000 RSI: 0000000000000175 RDI: ffffffffa0030d5b RBP: ffff88007a19bb18 R08: 0000000000000001 R09: ffff88011bd64a00 R10: ffff88011d34ec00 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88007a19bc48 R14: ffff88007a19bb88 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88011fc00000(0063) knlGS:00000000f77d76c0 CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000011a675000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process rmmod (pid: 11494, threadinfo ffff88007a19a000, task ffff8800798595c0) Stack: ffff88007a19bb36 ffff88011c84b800 ffff88011b5e2000 ffff88007a19bc48 ffff88007a19bb88 0000000000000006 ffff88007a19bb38 ffffffffa003a5f6 ffff88007a19bb38 670088007a19bba8 ffff88007a19bb58 ffffffffa00397e7 Call Trace: [<ffffffffa003a5f6>] vlan_gvrp_request_leave+0x46/0x50 [8021q] [<ffffffffa00397e7>] vlan_dev_stop+0xb7/0xc0 [8021q] [<ffffffff8137e427>] __dev_close_many+0x87/0xe0 [<ffffffff8137e507>] dev_close_many+0x87/0x110 [<ffffffff8137e630>] rollback_registered_many+0xa0/0x240 [<ffffffff8137e7e9>] unregister_netdevice_many+0x19/0x60 [<ffffffffa00389eb>] vlan_device_event+0x53b/0x550 [8021q] [<ffffffff8143f448>] ? ip6mr_device_event+0xa8/0xd0 [<ffffffff81479d03>] notifier_call_chain+0x53/0x80 [<ffffffff81062539>] __raw_notifier_call_chain+0x9/0x10 [<ffffffff81062551>] raw_notifier_call_chain+0x11/0x20 [<ffffffff8137df82>] call_netdevice_notifiers+0x32/0x60 [<ffffffff8137e69f>] rollback_registered_many+0x10f/0x240 [<ffffffff8137e85f>] rollback_registered+0x2f/0x40 [<ffffffff8137e8c8>] unregister_netdevice_queue+0x58/0x90 [<ffffffff8137e9eb>] unregister_netdev+0x1b/0x30 [<ffffffffa005d73f>] tg3_remove_one+0x6f/0x10b [tg3] We should call vlan_gvrp_request_leave() from unregister_vlan_dev(), not from vlan_dev_stop(), because vlan_gvrp_uninit_applicant() is called right after unregister_netdevice_queue(). In batch mode, unregister_netdevice_queue() doesn’t immediately call vlan_dev_stop(). Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-10libertas: fix cmdpendingq lockingPaul Fox
We occasionally see list corruption using libertas. While we haven't been able to diagnose this precisely, we have spotted a possible cause: cmdpendingq is generally modified with driver_lock held. However, there are a couple of points where this is not the case. Fix up those operations to execute under the lock, it seems like the correct thing to do and will hopefully improve the situation. Signed-off-by: Paul Fox <pgf@laptop.org> Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Dan Williams <dcbw@redhat.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-05-10iwlegacy: fix IBSS mode crashesStanislaw Gruszka
We should not switch to non-IBSS channels when working in IBSS mode, otherwise there are microcode errors, and after some time system crashes. This bug is only observable when software scan is used in IBSS mode, so should be considered as regression after: commit 0263aa45293838b514b8af674a03faf040991a90 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Tue Mar 29 11:24:21 2011 +0200 iwl3945: disable hw scan by default However IBSS mode check, which this patch add again, was removed by commit b2f30e8bdd8ef5f3b5a7ef9146509585a15347d3 Author: Johannes Berg <johannes.berg@intel.com> Date: Thu Jan 21 07:32:20 2010 -0800 iwlwifi: remove IBSS channel sanity check That commit claim that mac80211 will not use non-IBSS channel in IBSS mode, what definitely is not true. Bug probably should be fixed in mac80211, but that will require more work, so better to apply that patch temporally, and provide proper mac80211 fix latter. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=34452 Reported-and-tested-by: Mikko Rapeli <mikko.rapeli@iki.fi> Cc: stable@kernel.org # 2.6.38.5+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-05-10ath9k: Fix a warning due to a queued work during S3 stateMohammed Shafi Shajakhan
during suspend/S3 state drv_flush is called from mac80211 irrespective of interface count. In ath9k we queue a work in ath9k_flush which we expect to be cancelled in the drv_stop call back. during suspend process mac80211 calls drv_stop only when the interface count(local->count) is non-zero. unfortunately when the network manager is enabled, drv_flush is called while drv_stop is not called as local->count reaches '0'. So fix this by simply checking for the device presence in the drv_flush call back in the driver before queueing work or anything else. this patch fixes the following WARNING Call Trace: [<c014c6e2>] warn_slowpath_common+0x72/0xa0 [<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211] [<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211] [<c014c75b>] warn_slowpath_fmt+0x2b/0x30 [<fc133f99>] ieee80211_can_queue_work+0x39/0x50 [mac80211] [<fc134ed1>] ieee80211_queue_delayed_work+0x21/0x50 [mac80211] [<fc1e5b22>] ath_tx_complete_poll_work+0xb2/0x100 [ath9k] [<c016399e>] run_workqueue+0x8e/0x150 [<fc1e5a70>] ? ath_tx_complete_poll_work+0x0/0x100 [ath9k] [<c0163ae4>] worker_thread+0x84/0xe0 [<c0167a60>] ? autoremove_wake_function+0x0/0x50 [<c0163a60>] ? worker_thread+0x0/0xe0 [<c01677d4>] kthread+0x74/0x80 [<c0167760>] ? kthread+0x0/0x80 [<c0104087>] kernel_thread_helper+0x7/0x10 ---[ end trace 2aff81010df9215b ]--- Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-05-10mac80211: don't start the dynamic ps timer if not associatedLuciano Coelho
When we are disconnecting, we set PS off, but this happens before we send the deauth/disassoc request. When the deauth/disassoc frames are sent, we trigger the dynamic ps timer, which then times out and turns PS back on. Thus, PS remains on after disconnecting, causing problems when associating again. This can be fixed by preventing the timer to start when we're not associated anymore. Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-05-10netfilter: revert a2361c8735e07322023aedc36e4938b35af31eb0Pablo Neira Ayuso
This patch reverts a2361c8735e07322023aedc36e4938b35af31eb0: "[PATCH] netfilter: xt_conntrack: warn about use in raw table" Florian Wesphal says: "... when the packet was sent from the local machine the skb already has ->nfct attached, and -m conntrack seems to do the right thing." Acked-by: Jan Engelhardt <jengelh@medozas.de> Reported-by: Florian Wesphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2011-05-10netfilter: IPv6: fix DSCP mangle codeFernando Luis Vazquez Cao
The mask indicates the bits one wants to zero out, so it needs to be inverted before applying to the original TOS field. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2011-05-10netfilter: IPv6: initialize TOS field in REJECT target moduleFernando Luis Vazquez Cao
The IPv6 header is not zeroed out in alloc_skb so we must initialize it properly unless we want to see IPv6 packets with random TOS fields floating around. The current implementation resets the flow label but this could be changed if deemed necessary. We stumbled upon this issue when trying to apply a mangle rule to the RST packet generated by the REJECT target module. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2011-05-10IPVS: init and cleanup restructuringHans Schillstrom
DESCRIPTION This patch tries to restore the initial init and cleanup sequences that was before namspace patch. Netns also requires action when net devices unregister which has never been implemented. I.e this patch also covers when a device moves into a network namespace, and has to be released. IMPLEMENTATION The number of calls to register_pernet_device have been reduced to one for the ip_vs.ko Schedulers still have their own calls. This patch adds a function __ip_vs_service_cleanup() and an enable flag for the netfilter hooks. The nf hooks will be enabled when the first service is loaded and never disabled again, except when a namespace exit starts. Signed-off-by: Hans Schillstrom <hans@schillstrom.com> Acked-by: Julian Anastasov <ja@ssi.bg> [horms@verge.net.au: minor edit to changelog] Signed-off-by: Simon Horman <horms@verge.net.au>
2011-05-10IPVS: Change of socket usage to enable name space exit.Hans Schillstrom
If the sync daemons run in a name space while it crashes or get killed, there is no way to stop them except for a reboot. When all patches are there, ip_vs_core will handle register_pernet_(), i.e. ip_vs_sync_init() and ip_vs_sync_cleanup() will be removed. Kernel threads should not increment the use count of a socket. By calling sk_change_net() after creating a socket this is avoided. sock_release cant be used intead sk_release_kernel() should be used. Thanks Eric W Biederman for your advices. Signed-off-by: Hans Schillstrom <hans@schillstrom.com> [horms@verge.net.au: minor edit to changelog] Signed-off-by: Simon Horman <horms@verge.net.au>
2011-05-10netfilter: ebtables: only call xt_compat_add_offset once per ruleFlorian Westphal
The optimizations in commit 255d0dc34068a976 (netfilter: x_table: speedup compat operations) assume that xt_compat_add_offset is called once per rule. ebtables however called it for each match/target found in a rule. The match/watcher/target parser already returns the needed delta, so it is sufficient to move the xt_compat_add_offset call to a more reasonable location. While at it, also get rid of the unused COMPAT iterator macros. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
2011-05-10netfilter: fix ebtables compat supportEric Dumazet
commit 255d0dc34068a976 (netfilter: x_table: speedup compat operations) made ebtables not working anymore. 1) xt_compat_calc_jump() is not an exact match lookup 2) compat_table_info() has a typo in xt_compat_init_offsets() call 3) compat_do_replace() misses a xt_compat_init_offsets() call Reported-by: dann frazier <dannf@dannf.org> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net>
2011-05-10netfilter: ctnetlink: fix timestamp support for new conntracksPablo Neira Ayuso
This patch fixes the missing initialization of the start time if the timestamp support is enabled. libnetfilter_conntrack/utils# conntrack -E & libnetfilter_conntrack/utils# ./conntrack_create tcp 6 109 ESTABLISHED src=1.1.1.1 dst=2.2.2.2 sport=1025 dport=21 packets=0 bytes=0 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=21 dport=1025 packets=0 bytes=0 mark=0 delta-time=1303296401 use=2 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Patrick McHardy <kaber@trash.net>
2011-05-09pch_gbe: support ML7223 IOHTomoya
Support new device OKI SEMICONDUCTOR ML7223 IOH(Input/Output Hub). The ML7223 IOH is for MP(Media Phone) use. The ML7223 is companion chip for Intel Atom E6xx series. The ML7223 is completely compatible for Intel EG20T PCH. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-09PCH_GbE : Fixed the issue of checksum judgmentToshiharu Okada
The checksum judgment was mistaken. Judgment result 0:Correct 1:Wrong This patch fixes the issue. Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-09PCH_GbE : Fixed the issue of collision detectionToshiharu Okada
The collision detection setting was invalid. When collision occurred, because data was not resent, there was an issue to which a transmitting throughput falls. This patch enables the collision detection. Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-09NET: slip, fix ldisc->open retvalMatvejchikov Ilya
TTY layer expects 0 if the ldisc->open operation succeeded. Signed-off-by : Matvejchikov Ilya <matvejchikov@gmail.com> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-09be2net: Fixed bugs related to PVID.Somnath Kotur
Fixed bug to make sure 'pvid' retrieval will work on big endian hosts. Fixed incorrect comparison between the Rx Completion's 16-bit VLAN TCI and the PVID. Now comparing only the relevant 12 bits corresponding to the VID. Renamed 'vid' field under Rx Completion to 'vlan_tag' to reflect accurate description. Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-09ehea: fix wrongly reported speed and portKleber Sacilotto de Souza
Currently EHEA reports to ethtool as supporting 10M, 100M, 1G and 10G and connected to FIBRE independent of the hardware configuration. However, when connected to FIBRE the only supported speed is 10G full-duplex, and the other speeds and modes are only supported when connected to twisted pair. Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Acked-by: Breno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-08tcp_cubic: limit delayed_ack ratio to prevent divide errorstephen hemminger
TCP Cubic keeps a metric that estimates the amount of delayed acknowledgements to use in adjusting the window. If an abnormally large number of packets are acknowledged at once, then the update could wrap and reach zero. This kind of ACK could only happen when there was a large window and huge number of ACK's were lost. This patch limits the value of delayed ack ratio. The choice of 32 is just a conservative value since normally it should be range of 1 to 4 packets. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-08ipheth: Properly distinguish length and alignment in URBs and skbsBen Hutchings
The USB protocol this driver implements appears to require 2 bytes of padding in front of each received packet. This used to be equal to the value of NET_IP_ALIGN on x86, so the driver abused that constant and mostly worked, but this is no longer the case. The driver also mixed up the URB and packet lengths, resulting in 2 bytes of junk at the end of the skb. Introduce a private constant for the 2 bytes of padding; fix this confusion and check for the under-length case. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-06vmxnet3: Consistently disable irqs when taking adapter->cmd_lockRoland Dreier
Using the vmxnet3 driver produces a lockdep warning because vmxnet3_set_mc(), which is called with mc->mca_lock held, takes adapter->cmd_lock. However, there are a couple of places where adapter->cmd_lock is taken with softirqs enabled, lockdep warns that a softirq that tries to take mc->mca_lock could happen while adapter->cmd_lock is held, leading to an AB-BA deadlock. I'm not sure if this is a real potential deadlock or not, but the simplest and best fix seems to be simply to make sure we take cmd_lock with spin_lock_irqsave() everywhere -- the places with plain spin_lock just look like oversights. The full enormous lockdep warning is: ========================================================= [ INFO: possible irq lock inversion dependency detected ] 2.6.39-rc6+ #1 --------------------------------------------------------- ifconfig/567 just changed the state of lock: (&(&mc->mca_lock)->rlock){+.-...}, at: [<ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280 but this lock took another, SOFTIRQ-unsafe lock in the past: (&(&adapter->cmd_lock)->rlock){+.+...} and interrupts could create inverse lock ordering between them. other info that might help us debug this: 4 locks held by ifconfig/567: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8147d547>] rtnl_lock+0x17/0x20 #1: ((inetaddr_chain).rwsem){.+.+.+}, at: [<ffffffff810896cf>] __blocking_notifier_call_chain+0x5f/0xb0 #2: (&idev->mc_ifc_timer){+.-...}, at: [<ffffffff8106f21b>] run_timer_softirq+0xeb/0x3f0 #3: (&ndev->lock){++.-..}, at: [<ffffffff81531dd2>] mld_ifc_timer_expire+0x32/0x280 the shortest dependencies between 2nd lock and 1st lock: -> (&(&adapter->cmd_lock)->rlock){+.+...} ops: 11 { HARDIRQ-ON-W at: [<ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff81571156>] _raw_spin_lock+0x36/0x70 [<ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3] [<ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3] [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0 [<ffffffff812dfde9>] pci_device_probe+0x119/0x120 [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0 [<ffffffff81373fcb>] __driver_attach+0xab/0xb0 [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90 [<ffffffff81373a2e>] driver_attach+0x1e/0x20 [<ffffffff813735b8>] bus_add_driver+0xc8/0x290 [<ffffffff813745b6>] driver_register+0x76/0x140 [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0 [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw] [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff810aa76b>] sys_init_module+0xfb/0x250 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b SOFTIRQ-ON-W at: [<ffffffff8109adb7>] __lock_acquire+0x827/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff81571156>] _raw_spin_lock+0x36/0x70 [<ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3] [<ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3] [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0 [<ffffffff812dfde9>] pci_device_probe+0x119/0x120 [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0 [<ffffffff81373fcb>] __driver_attach+0xab/0xb0 [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90 [<ffffffff81373a2e>] driver_attach+0x1e/0x20 [<ffffffff813735b8>] bus_add_driver+0xc8/0x290 [<ffffffff813745b6>] driver_register+0x76/0x140 [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0 [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw] [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff810aa76b>] sys_init_module+0xfb/0x250 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b INITIAL USE at: [<ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff81571156>] _raw_spin_lock+0x36/0x70 [<ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3] [<ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3] [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0 [<ffffffff812dfde9>] pci_device_probe+0x119/0x120 [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0 [<ffffffff81373fcb>] __driver_attach+0xab/0xb0 [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90 [<ffffffff81373a2e>] driver_attach+0x1e/0x20 [<ffffffff813735b8>] bus_add_driver+0xc8/0x290 [<ffffffff813745b6>] driver_register+0x76/0x140 [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0 [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw] [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff810aa76b>] sys_init_module+0xfb/0x250 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b } ... key at: [<ffffffffa0017590>] __key.42516+0x0/0xffffffffffffda70 [vmxnet3] ... acquired at: [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff81571bb5>] _raw_spin_lock_irqsave+0x55/0xa0 [<ffffffffa000de27>] vmxnet3_set_mc+0x97/0x1a0 [vmxnet3] [<ffffffff8146ffa0>] __dev_set_rx_mode+0x40/0xb0 [<ffffffff81470040>] dev_set_rx_mode+0x30/0x50 [<ffffffff81470127>] __dev_open+0xc7/0x100 [<ffffffff814703c1>] __dev_change_flags+0xa1/0x180 [<ffffffff81470568>] dev_change_flags+0x28/0x70 [<ffffffff814da960>] devinet_ioctl+0x730/0x800 [<ffffffff814db508>] inet_ioctl+0x88/0xa0 [<ffffffff814541f0>] sock_do_ioctl+0x30/0x70 [<ffffffff814542a9>] sock_ioctl+0x79/0x2f0 [<ffffffff81188798>] do_vfs_ioctl+0x98/0x570 [<ffffffff81188d01>] sys_ioctl+0x91/0xa0 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b -> (_xmit_ETHER){+.....} ops: 6 { HARDIRQ-ON-W at: [<ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70 [<ffffffff81475618>] __dev_mc_add+0x38/0x90 [<ffffffff814756a0>] dev_mc_add+0x10/0x20 [<ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0 [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430 [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450 [<ffffffff81519f27>] addrconf_notify+0x2f7/0xb10 [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0 [<ffffffff81089586>] raw_notifier_call_chain+0x16/0x20 [<ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70 [<ffffffff8146a944>] register_netdevice+0x244/0x2d0 [<ffffffff8146aa0f>] register_netdev+0x3f/0x60 [<ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3] [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0 [<ffffffff812dfde9>] pci_device_probe+0x119/0x120 [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0 [<ffffffff81373fcb>] __driver_attach+0xab/0xb0 [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90 [<ffffffff81373a2e>] driver_attach+0x1e/0x20 [<ffffffff813735b8>] bus_add_driver+0xc8/0x290 [<ffffffff813745b6>] driver_register+0x76/0x140 [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0 [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw] [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff810aa76b>] sys_init_module+0xfb/0x250 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b INITIAL USE at: [<ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70 [<ffffffff81475618>] __dev_mc_add+0x38/0x90 [<ffffffff814756a0>] dev_mc_add+0x10/0x20 [<ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0 [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430 [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450 [<ffffffff81519f27>] addrconf_notify+0x2f7/0xb10 [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0 [<ffffffff81089586>] raw_notifier_call_chain+0x16/0x20 [<ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70 [<ffffffff8146a944>] register_netdevice+0x244/0x2d0 [<ffffffff8146aa0f>] register_netdev+0x3f/0x60 [<ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3] [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0 [<ffffffff812dfde9>] pci_device_probe+0x119/0x120 [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0 [<ffffffff81373fcb>] __driver_attach+0xab/0xb0 [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90 [<ffffffff81373a2e>] driver_attach+0x1e/0x20 [<ffffffff813735b8>] bus_add_driver+0xc8/0x290 [<ffffffff813745b6>] driver_register+0x76/0x140 [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0 [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw] [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff810aa76b>] sys_init_module+0xfb/0x250 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b } ... key at: [<ffffffff827fd868>] netdev_addr_lock_key+0x8/0x1e0 ... acquired at: [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70 [<ffffffff81475618>] __dev_mc_add+0x38/0x90 [<ffffffff814756a0>] dev_mc_add+0x10/0x20 [<ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0 [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430 [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450 [<ffffffff81519f27>] addrconf_notify+0x2f7/0xb10 [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0 [<ffffffff81089586>] raw_notifier_call_chain+0x16/0x20 [<ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70 [<ffffffff8146a944>] register_netdevice+0x244/0x2d0 [<ffffffff8146aa0f>] register_netdev+0x3f/0x60 [<ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3] [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0 [<ffffffff812dfde9>] pci_device_probe+0x119/0x120 [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0 [<ffffffff81373fcb>] __driver_attach+0xab/0xb0 [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90 [<ffffffff81373a2e>] driver_attach+0x1e/0x20 [<ffffffff813735b8>] bus_add_driver+0xc8/0x290 [<ffffffff813745b6>] driver_register+0x76/0x140 [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0 [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw] [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff810aa76b>] sys_init_module+0xfb/0x250 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b -> (&(&mc->mca_lock)->rlock){+.-...} ops: 6 { HARDIRQ-ON-W at: [<ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70 [<ffffffff81532bd5>] igmp6_group_added+0x45/0x1b0 [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430 [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450 [<ffffffff81ce0d16>] addrconf_init+0x4e/0x183 [<ffffffff81ce0ba1>] inet6_init+0x191/0x2a6 [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff81ca4d3f>] kernel_init+0xe3/0x168 [<ffffffff8157b2e4>] kernel_thread_helper+0x4/0x10 IN-SOFTIRQ-W at: [<ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70 [<ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280 [<ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0 [<ffffffff810666d0>] __do_softirq+0xc0/0x210 [<ffffffff8157b3dc>] call_softirq+0x1c/0x30 [<ffffffff8100d42d>] do_softirq+0xad/0xe0 [<ffffffff81066afe>] irq_exit+0x9e/0xb0 [<ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b [<ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20 [<ffffffff8149d857>] rt_do_flush+0x87/0x2a0 [<ffffffff814a16b6>] rt_cache_flush+0x46/0x60 [<ffffffff814e36e0>] fib_disable_ip+0x40/0x60 [<ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0 [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0 [<ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0 [<ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0 [<ffffffff814d8223>] inet_del_ifa+0x13/0x20 [<ffffffff814da731>] devinet_ioctl+0x501/0x800 [<ffffffff814db508>] inet_ioctl+0x88/0xa0 [<ffffffff814541f0>] sock_do_ioctl+0x30/0x70 [<ffffffff814542a9>] sock_ioctl+0x79/0x2f0 [<ffffffff81188798>] do_vfs_ioctl+0x98/0x570 [<ffffffff81188d01>] sys_ioctl+0x91/0xa0 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b INITIAL USE at: [<ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70 [<ffffffff81532bd5>] igmp6_group_added+0x45/0x1b0 [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430 [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450 [<ffffffff81ce0d16>] addrconf_init+0x4e/0x183 [<ffffffff81ce0ba1>] inet6_init+0x191/0x2a6 [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff81ca4d3f>] kernel_init+0xe3/0x168 [<ffffffff8157b2e4>] kernel_thread_helper+0x4/0x10 } ... key at: [<ffffffff82801be2>] __key.40877+0x0/0x8 ... acquired at: [<ffffffff810997bc>] check_usage_forwards+0x9c/0x110 [<ffffffff8109a32c>] mark_lock+0x19c/0x400 [<ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70 [<ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280 [<ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0 [<ffffffff810666d0>] __do_softirq+0xc0/0x210 [<ffffffff8157b3dc>] call_softirq+0x1c/0x30 [<ffffffff8100d42d>] do_softirq+0xad/0xe0 [<ffffffff81066afe>] irq_exit+0x9e/0xb0 [<ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b [<ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20 [<ffffffff8149d857>] rt_do_flush+0x87/0x2a0 [<ffffffff814a16b6>] rt_cache_flush+0x46/0x60 [<ffffffff814e36e0>] fib_disable_ip+0x40/0x60 [<ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0 [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0 [<ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0 [<ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0 [<ffffffff814d8223>] inet_del_ifa+0x13/0x20 [<ffffffff814da731>] devinet_ioctl+0x501/0x800 [<ffffffff814db508>] inet_ioctl+0x88/0xa0 [<ffffffff814541f0>] sock_do_ioctl+0x30/0x70 [<ffffffff814542a9>] sock_ioctl+0x79/0x2f0 [<ffffffff81188798>] do_vfs_ioctl+0x98/0x570 [<ffffffff81188d01>] sys_ioctl+0x91/0xa0 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b stack backtrace: Pid: 567, comm: ifconfig Not tainted 2.6.39-rc6+ #1 Call Trace: <IRQ> [<ffffffff810996f6>] print_irq_inversion_bug+0x146/0x170 [<ffffffff81099720>] ? print_irq_inversion_bug+0x170/0x170 [<ffffffff810997bc>] check_usage_forwards+0x9c/0x110 [<ffffffff8109a32c>] mark_lock+0x19c/0x400 [<ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10 [<ffffffff8109a383>] ? mark_lock+0x1f3/0x400 [<ffffffff8109b497>] ? __lock_acquire+0xf07/0x1e10 [<ffffffff81012255>] ? native_sched_clock+0x15/0x70 [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130 [<ffffffff81531e9f>] ? mld_ifc_timer_expire+0xff/0x280 [<ffffffff8109759d>] ? lock_release_holdtime+0x3d/0x1a0 [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70 [<ffffffff81531e9f>] ? mld_ifc_timer_expire+0xff/0x280 [<ffffffff8157170b>] ? _raw_spin_unlock+0x2b/0x40 [<ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280 [<ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0 [<ffffffff8106f21b>] ? run_timer_softirq+0xeb/0x3f0 [<ffffffff810122b9>] ? sched_clock+0x9/0x10 [<ffffffff81531da0>] ? mld_gq_timer_expire+0x30/0x30 [<ffffffff810666d0>] __do_softirq+0xc0/0x210 [<ffffffff8109455f>] ? tick_program_event+0x1f/0x30 [<ffffffff8157b3dc>] call_softirq+0x1c/0x30 [<ffffffff8100d42d>] do_softirq+0xad/0xe0 [<ffffffff81066afe>] irq_exit+0x9e/0xb0 [<ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b [<ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81571f14>] ? retint_restore_args+0x13/0x13 [<ffffffff810974a7>] ? lock_is_held+0x17/0xd0 [<ffffffff8149d857>] rt_do_flush+0x87/0x2a0 [<ffffffff814a16b6>] rt_cache_flush+0x46/0x60 [<ffffffff814e36e0>] fib_disable_ip+0x40/0x60 [<ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0 [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0 [<ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0 [<ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0 [<ffffffff814d8223>] inet_del_ifa+0x13/0x20 [<ffffffff814da731>] devinet_ioctl+0x501/0x800 [<ffffffff8108a3af>] ? local_clock+0x6f/0x80 [<ffffffff81575898>] ? do_page_fault+0x268/0x560 [<ffffffff814db508>] inet_ioctl+0x88/0xa0 [<ffffffff814541f0>] sock_do_ioctl+0x30/0x70 [<ffffffff814542a9>] sock_ioctl+0x79/0x2f0 [<ffffffff810dfe87>] ? __call_rcu+0xa7/0x190 [<ffffffff81188798>] do_vfs_ioctl+0x98/0x570 [<ffffffff8117737e>] ? fget_light+0x33e/0x430 [<ffffffff81571ef9>] ? retint_swapgs+0x13/0x1b [<ffffffff81188d01>] sys_ioctl+0x91/0xa0 [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com> Signed-off-by: Scott J. Goldman <scottjg@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-06dccp: handle invalid feature options lengthDan Rosenberg
A length of zero (after subtracting two for the type and len fields) for the DCCPO_{CHANGE,CONFIRM}_{L,R} options will cause an underflow due to the subtraction. The subsequent code may read past the end of the options value buffer when parsing. I'm unsure of what the consequences of this might be, but it's probably not good. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Cc: stable@kernel.org Acked-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-05can: fix SJA1000 dlc for RTR packetsKurt Van Dijck
RTR frames do have a valid data length code on CAN. The driver for SJA1000 did not handle that situation properly. Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-05usbnet: runtime pm: fix out of memoryMing Lei
This patch makes use of the EVENT_DEV_OPEN flag introduced recently to fix one out of memory issue, which can be reproduced on omap3/4 based pandaboard/beagle XM easily with steps below: - enable runtime pm echo auto > /sys/devices/platform/usbhs-omap.0/ehci-omap.0/usb1/1-1/1-1.1/power/control - ifconfig eth0 up - then out of memroy happened, see [1] for kernel message. Follows my analysis: - 'ifconfig eth0 up' brings eth0 out of suspend, and usbnet_resume is called to schedule dev->bh, then rx urbs are submited to prepare for recieving data; - some usbnet devices will produce garbage rx packets flood if info->reset is not called in usbnet_open. - so there is no enough chances for usbnet_bh to handle and release recieved skb buffers since many rx interrupts consumes cpu, so out of memory for atomic allocation in rx_submit happened. This patch fixes the issue by simply not allowing schedule of usbnet_bh until device is opened. [1], dmesg [ 234.712005] smsc95xx 1-1.1:1.0: rpm_resume flags 0x4 [ 234.712066] usb 1-1.1: rpm_resume flags 0x0 [ 234.712066] usb 1-1: rpm_resume flags 0x0 [ 234.712097] usb usb1: rpm_resume flags 0x0 [ 234.712127] usb usb1: usb auto-resume [ 234.712158] ehci-omap ehci-omap.0: resume root hub [ 234.754028] hub 1-0:1.0: hub_resume [ 234.754821] hub 1-0:1.0: port 1: status 0507 change 0000 [ 234.756011] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000 [ 234.756042] hub 1-0:1.0: rpm_resume flags 0x4 [ 234.756072] usb usb1: rpm_resume flags 0x0 [ 234.756164] usb usb1: rpm_resume returns 1 [ 234.756195] hub 1-0:1.0: rpm_resume returns 0 [ 234.756195] hub 1-0:1.0: rpm_suspend flags 0x4 [ 234.756225] hub 1-0:1.0: rpm_suspend returns 0 [ 234.756256] usb usb1: rpm_resume returns 0 [ 234.757141] usb 1-1: usb auto-resume [ 234.793151] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 234.816558] usb 1-1: finish resume [ 234.817871] hub 1-1:1.0: hub_resume [ 234.818420] hub 1-1:1.0: port 1: status 0507 change 0000 [ 234.820495] ehci-omap ehci-omap.0: reused qh eec50220 schedule [ 234.820495] usb 1-1: link qh256-0001/eec50220 start 1 [1/0 us] [ 234.820587] usb 1-1: rpm_resume returns 0 [ 234.820800] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0000 [ 234.820800] hub 1-1:1.0: rpm_resume flags 0x4 [ 234.820831] hub 1-1:1.0: rpm_resume returns 0 [ 234.820861] hub 1-1:1.0: rpm_suspend flags 0x4 [ 234.820861] hub 1-1:1.0: rpm_suspend returns 0 [ 234.821777] usb 1-1.1: usb auto-resume [ 234.868591] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0002 [ 234.868591] hub 1-1:1.0: rpm_resume flags 0x4 [ 234.868621] hub 1-1:1.0: rpm_resume returns 0 [ 234.868652] hub 1-1:1.0: rpm_suspend flags 0x4 [ 234.868652] hub 1-1:1.0: rpm_suspend returns 0 [ 234.879486] usb 1-1.1: finish resume [ 234.880279] usb 1-1.1: rpm_resume returns 0 [ 234.880310] smsc95xx 1-1.1:1.0: rpm_resume returns 0 [ 238.880187] ksoftirqd/0: page allocation failure. order:0, mode:0x20 [ 238.880218] Backtrace: [ 238.880249] [<c01b9800>] (dump_backtrace+0x0/0xf8) from [<c065e1dc>] (dump_stack+0x18/0x1c) [ 238.880249] r6:00000000 r5:00000000 r4:00000020 r3:00000002 [ 238.880310] [<c065e1c4>] (dump_stack+0x0/0x1c) from [<c026ece4>] (__alloc_pages_nodemask+0x620/0x724) [ 238.880340] [<c026e6c4>] (__alloc_pages_nodemask+0x0/0x724) from [<c02986d4>] (kmem_getpages.clone.34+0x34/0xc8) [ 238.880371] [<c02986a0>] (kmem_getpages.clone.34+0x0/0xc8) from [<c02988f8>] (cache_grow.clone.42+0x84/0x154) [ 238.880371] r6:ef871aa4 r5:ef871a80 r4:ef81fd40 r3:00000020 [ 238.880401] [<c0298874>] (cache_grow.clone.42+0x0/0x154) from [<c0298b64>] (cache_alloc_refill+0x19c/0x1f0) [ 238.880432] [<c02989c8>] (cache_alloc_refill+0x0/0x1f0) from [<c0299804>] (kmem_cache_alloc+0x90/0x190) [ 238.880462] [<c0299774>] (kmem_cache_alloc+0x0/0x190) from [<c052e260>] (__alloc_skb+0x34/0xe8) [ 238.880493] [<c052e22c>] (__alloc_skb+0x0/0xe8) from [<bf0509f4>] (rx_submit+0x2c/0x1d4 [usbnet]) [ 238.880523] [<bf0509c8>] (rx_submit+0x0/0x1d4 [usbnet]) from [<bf050d38>] (rx_complete+0x19c/0x1b0 [usbnet]) [ 238.880737] [<bf050b9c>] (rx_complete+0x0/0x1b0 [usbnet]) from [<bf006fd0>] (usb_hcd_giveback_urb+0xa8/0xf4 [usbcore]) [ 238.880737] r8:eeeced34 r7:eeecec00 r6:eeecec00 r5:00000000 r4:eec2dd20 [ 238.880767] r3:bf050b9c [ 238.880859] [<bf006f28>] (usb_hcd_giveback_urb+0x0/0xf4 [usbcore]) from [<bf03c8f8>] (ehci_urb_done+0xb0/0xbc [ehci_hcd]) [ 238.880859] r6:00000000 r5:eec2dd20 r4:eeeced44 r3:eec2dd34 [ 238.880920] [<bf03c848>] (ehci_urb_done+0x0/0xbc [ehci_hcd]) from [<bf040204>] (qh_completions+0x308/0x3bc [ehci_hcd]) [ 238.880920] r7:00000000 r6:eeda21a0 r5:ffdfe3c0 r4:eeda21ac [ 238.880981] [<bf03fefc>] (qh_completions+0x0/0x3bc [ehci_hcd]) from [<bf040ef8>] (scan_async+0xb0/0x16c [ehci_hcd]) [ 238.881011] [<bf040e48>] (scan_async+0x0/0x16c [ehci_hcd]) from [<bf040fec>] (ehci_work+0x38/0x90 [ehci_hcd]) [ 238.881042] [<bf040fb4>] (ehci_work+0x0/0x90 [ehci_hcd]) from [<bf042940>] (ehci_irq+0x300/0x34c [ehci_hcd]) [ 238.881072] r4:eeeced34 r3:00000001 [ 238.881134] [<bf042640>] (ehci_irq+0x0/0x34c [ehci_hcd]) from [<bf006828>] (usb_hcd_irq+0x40/0xac [usbcore]) [ 238.881195] [<bf0067e8>] (usb_hcd_irq+0x0/0xac [usbcore]) from [<c0239764>] (handle_irq_event_percpu+0xb8/0x240) [ 238.881225] r6:eec504e0 r5:0000006d r4:eec504e0 r3:bf0067e8 [ 238.881256] [<c02396ac>] (handle_irq_event_percpu+0x0/0x240) from [<c0239930>] (handle_irq_event+0x44/0x64) [ 238.881256] [<c02398ec>] (handle_irq_event+0x0/0x64) from [<c023bbd0>] (handle_level_irq+0xe0/0x114) [ 238.881286] r6:0000006d r5:c080c14c r4:c080c100 r3:00020000 [ 238.881317] [<c023baf0>] (handle_level_irq+0x0/0x114) from [<c01ab090>] (asm_do_IRQ+0x90/0xd0) [ 238.881317] r5:00000000 r4:0000006d [ 238.881347] [<c01ab000>] (asm_do_IRQ+0x0/0xd0) from [<c06624d0>] (__irq_svc+0x50/0x134) [ 238.881378] Exception stack(0xef837e20 to 0xef837e68) [ 238.881378] 7e20: 00000001 00185610 016cc000 c00490c0 eb380000 ef800540 00000020 00004ae0 [ 238.881408] 7e40: 00000020 bf0509f4 60000013 ef837e9c ef837e40 ef837e68 c0226f0c c0298ca0 [ 238.881408] 7e60: 20000013 ffffffff [ 238.881408] r5:fa240100 r4:ffffffff [ 238.881439] [<c0298bb8>] (__kmalloc_track_caller+0x0/0x1d0) from [<c052e284>] (__alloc_skb+0x58/0xe8) [ 238.881469] [<c052e22c>] (__alloc_skb+0x0/0xe8) from [<bf0509f4>] (rx_submit+0x2c/0x1d4 [usbnet]) [ 238.881500] [<bf0509c8>] (rx_submit+0x0/0x1d4 [usbnet]) from [<bf0513d8>] (usbnet_bh+0x1b4/0x250 [usbnet]) [ 238.881530] [<bf051224>] (usbnet_bh+0x0/0x250 [usbnet]) from [<c01f912c>] (tasklet_action+0xb0/0x1f8) [ 238.881530] r6:00000000 r5:ef9757f0 r4:ef9757ec r3:bf051224 [ 238.881561] [<c01f907c>] (tasklet_action+0x0/0x1f8) from [<c01f97ac>] (__do_softirq+0x140/0x290) [ 238.881561] r8:00000006 r7:00000101 r6:00000000 r5:c0806098 r4:00000001 [ 238.881591] r3:c01f907c [ 238.881622] [<c01f966c>] (__do_softirq+0x0/0x290) from [<c01f99cc>] (run_ksoftirqd+0xd0/0x1f4) [ 238.881622] [<c01f98fc>] (run_ksoftirqd+0x0/0x1f4) from [<c02113b0>] (kthread+0x90/0x98) [ 238.881652] r7:00000013 r6:c01f98fc r5:00000000 r4:ef831efc [ 238.881683] [<c0211320>] (kthread+0x0/0x98) from [<c01f62f4>] (do_exit+0x0/0x374) [ 238.881713] r6:c01f62f4 r5:c0211320 r4:ef831efc [ 238.881713] Mem-info: [ 238.881744] Normal per-cpu: [ 238.881744] CPU 0: hi: 186, btch: 31 usd: 38 [ 238.881744] CPU 1: hi: 186, btch: 31 usd: 169 [ 238.881774] HighMem per-cpu: [ 238.881774] CPU 0: hi: 90, btch: 15 usd: 66 [ 238.881774] CPU 1: hi: 90, btch: 15 usd: 86 [ 238.881805] active_anon:544 inactive_anon:71 isolated_anon:0 [ 238.881805] active_file:926 inactive_file:2538 isolated_file:0 [ 238.881805] unevictable:0 dirty:10 writeback:0 unstable:0 [ 238.881805] free:57782 slab_reclaimable:864 slab_unreclaimable:186898 [ 238.881805] mapped:632 shmem:144 pagetables:50 bounce:0 [ 238.881835] Normal free:1328kB min:3532kB low:4412kB high:5296kB active_anon:0kB inactive_anon:0kB active_file:880kB inactive_file:848kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:780288kB mlocked:0kB dirty:36kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:3456kB slab_unreclaimable:747592kB kernel_stack:392kB pagetables:200kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 238.881866] lowmem_reserve[]: 0 1904 1904 [ 238.881896] HighMem free:229800kB min:236kB low:508kB high:784kB active_anon:2176kB inactive_anon:284kB active_file:2824kB inactive_file:9304kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:243712kB mlocked:0kB dirty:4kB writeback:0kB mapped:2528kB shmem:576kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 238.881927] lowmem_reserve[]: 0 0 0 [ 238.881958] Normal: 0*4kB 4*8kB 6*16kB 0*32kB 1*64kB 1*128kB 0*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB = 1344kB [ 238.882019] HighMem: 6*4kB 2*8kB 4*16kB 4*32kB 1*64kB 1*128kB 0*256kB 2*512kB 3*1024kB 0*2048kB 55*4096kB = 229800kB [ 238.882080] 3610 total pagecache pages [ 238.882080] 0 pages in swap cache [ 238.882080] Swap cache stats: add 0, delete 0, find 0/0 [ 238.882110] Free swap = 0kB [ 238.882110] Total swap = 0kB [ 238.933776] 262144 pages of RAM [ 238.933776] 58240 free pages [ 238.933776] 10503 reserved pages [ 238.933776] 187773 slab pages [ 238.933807] 2475 pages shared [ 238.933807] 0 pages swap cached Signed-off-by: Ming Lei <tom.leiming@gmail.com> Acked-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-04net: ip_expire() must revalidate routeEric Dumazet
Commit 4a94445c9a5c (net: Use ip_route_input_noref() in input path) added a bug in IP defragmentation handling, in case timeout is fired. When a frame is defragmented, we use last skb dst field when building final skb. Its dst is valid, since we are in rcu read section. But if a timeout occurs, we take first queued fragment to build one ICMP TIME EXCEEDED message. Problem is all queued skb have weak dst pointers, since we escaped RCU critical section after their queueing. icmp_send() might dereference a now freed (and possibly reused) part of memory. Calling skb_dst_drop() and ip_route_input_noref() to revalidate route is the only possible choice. Reported-by: Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-02sysctl: net: call unregister_net_sysctl_table where neededLucian Adrian Grijincu
ctl_table_headers registered with register_net_sysctl_table should have been unregistered with the equivalent unregister_net_sysctl_table Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-02Revert: veth: remove unneeded ifname code from veth_newlink()Jiri Pirko
84c49d8c3e4abefb0a41a77b25aa37ebe8d6b743 ("veth: remove unneeded ifname code from veth_newlink()") caused regression on veth creation. This patch reverts the original one. Reported-by: Michał Mirosław <mirqus@gmail.com> Signed-off-by: Jiri Pirko <jpirko@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-02smsc95xx: fix reset checkRabin Vincent
The reset loop check should check the MII_BMCR register value for BMCR_RESET rather than for MII_BMCR (the register address, which also happens to be zero). Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-02tg3: Fix failure to enable WoL by default when possibleRafael J. Wysocki
tg3 is supposed to enable WoL by default on adapters which support that, but it fails to do so unless the adapter's /sys/devices/.../power/wakeup file contains 'enabled' during the initialization of the adapter. Fix that by making tg3 use device_set_wakeup_enable() to enable wakeup automatically whenever WoL should be enabled by default. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-02networking: inappropriate ioctl operation should return ENOTTYLifeng Sun
ioctl() calls against a socket with an inappropriate ioctl operation are incorrectly returning EINVAL rather than ENOTTY: [ENOTTY] Inappropriate I/O control operation. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=33992 Signed-off-by: Lifeng Sun <lifongsun@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-02amd8111e: trivial typo spelling: Negotitate -> NegotiateJoe Perches
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-02Merge branch 'master' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
2011-05-02ipv4: don't spam dmesg with "Using LC-trie" messagesAlexey Dobriyan
fib_trie_table() is called during netns creation and Chromium uses clone(CLONE_NEWNET) to sandbox renderer process. Don't print anything. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-02af_unix: Only allow recv on connected seqpacket sockets.Eric W. Biederman
This fixes the following oops discovered by Dan Aloni: > Anyway, the following is the output of the Oops that I got on the > Ubuntu kernel on which I first detected the problem > (2.6.37-12-generic). The Oops that followed will be more useful, I > guess. >[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference > at           (null) > [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420 > [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0 > [ 5594.693720] Oops: 0002 [#1] SMP > [ 5594.699888] last sysfs file: The bug was that unix domain sockets use a pseduo packet for connecting and accept uses that psudo packet to get the socket. In the buggy seqpacket case we were allowing unconnected sockets to call recvmsg and try to receive the pseudo packet. That is always wrong and as of commit 7361c36c5 the pseudo packet had become enough different from a normal packet that the kernel started oopsing. Do for seqpacket_recv what was done for seqpacket_send in 2.5 and only allow it on connected seqpacket sockets. Cc: stable@kernel.org Tested-by: Dan Aloni <dan@aloni.org> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>