- Feb 11, 2012
-
-
Neil Horman authored
When the netprio_cgroup module is not loaded, net_prio_subsys_id is -1, and so sock_update_prioidx() accesses cgroup_subsys array with negative index subsys[-1]. Make the code resembles cls_cgroup code, which is bug free. Origionally-authored-by:
Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Neil Horman authored
So we delay the allocation till the priority is set through cgroup, and this makes skb_update_priority() faster when it's not set. This also eliminates an off-by-one bug similar with the one fixed in the previous patch. Origionally-authored-by:
-
Neil Horman authored
# mount -t cgroup xxx /mnt # mkdir /mnt/tmp # cat /mnt/tmp/net_prio.ifpriomap lo 0 eth0 0 virbr0 0 # echo 'lo 999' > /mnt/tmp/net_prio.ifpriomap # cat /mnt/tmp/net_prio.ifpriomap lo 999 eth0 0 virbr0 4101267344 We got weired output, because we exceeded the boundary of the array. We may even crash the kernel.. Origionally-authored-by:
-
- Feb 10, 2012
-
-
Dan Carpenter authored
The current error handling doesn't work because we flash_part is a u32 so the checks for negative error codes don't work. I considered making things signed but I don't know the hardware enough to say if that's a problem. Really, we don't use the error codes so just returning zero for all problems is fine. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
We use len to store the return value from eth_header(). eth_header() can return -ETH_HLEN (-14). We want to pass this back instead of truncating it to 65522 and returning that. Signed-off-by:
-
David S. Miller authored
Just like skb->cb[], so that qdisc_skb_cb can be encapsulated inside of other data structures. This is intended to be used by IPoIB so that it can remember addressing information stored at hard_header_ops->create() time that it can fetch when the packet gets to the transmit routine. Signed-off-by:
-
- Feb 09, 2012
-
-
John Fastabend authored
If the number of tx/rx queues changes the ethtool ioctl ETHTOOL_GSTATS may overrun the userspace buffer. This occurs because the general practice in user space to query stats is to issue a ETHTOOL_GSSET cmd to learn the buffer size needed, allocate the buffer, then call ETHTOOL_GSTIRNGS and ETHTOOL_GSTATS. If the number of real_num_queues is changed or flow control attributes are changed after ETHTOOL_GSSET but before the ETHTOOL_GSTRINGS/ETHTOOL_GSTATS a user space buffer overrun occurs. To fix the overrun always return the max buffer size needed from get_sset_count() then return all strings and stats from get_strings()/get_ethtool_stats(). This _will_ change the output from the ioctl() call which could break applications and script parsing in theory. I believe these changes should not break existing tools because the only changes will be more {tx|rx}_queues and the {tx|rx}_pb_* stats will always be returned. Existing scripts already need to handle changing number of queues because this occurs today depending on system and current features. The {tx|rx}_pb_* stats are at the end of the output and should be handled by scripts today regardless. Finally get_ethtool_stats and get_strings are free-form outputs tools parsing these outputs should be defensive anyways. In the end these updates are better then having a tool segfault because of a buffer overrun. Signed-off-by:John Fastabend <john.r.fastabend@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
John Fastabend authored
Users expect the up2tc mapping to be maintained across a DCB enable/disable/enable transition. And since we maintain all the other DCB attributes we should do this for up2tc mappings as well just to be consistent. Also without this we break user space applications that expect this to occur that previously worked. Signed-off-by:
Stephen Ko <stephen.s.ko@intel.com> Tested-by:
Ross Brattain <ross.b.brattain@intel.com> Signed-off-by:
-
Yi Zou authored
If the netdev is already in NETREG_UNREGISTERING/_UNREGISTERED state, do not update the real num tx queues. netdev_queue_update_kobjects() is already called via remove_queue_kobjects() at NETREG_UNREGISTERING time. So, when upper layer driver, e.g., FCoE protocol stack is monitoring the netdev event of NETDEV_UNREGISTER and calls back to LLD ndo_fcoe_disable() to remove extra queues allocated for FCoE, the associated txq sysfs kobjects are already removed, and trying to update the real num queues would cause something like below: ... PID: 25138 TASK: ffff88021e64c440 CPU: 3 COMMAND: "kworker/3:3" #0 [ffff88021f007760] machine_kexec at ffffffff810226d9 #1 [ffff88021f0077d0] crash_kexec at ffffffff81089d2d #2 [ffff88021f0078a0] oops_end at ffffffff813bca78 #3 [ffff88021f0078d0] no_context at ffffffff81029e72 #4 [ffff88021f007920] __bad_area_nosemaphore at ffffffff8102a155 #5 [ffff88021f0079f0] bad_area_nosemaphore at ffffffff8102a23e #6 [ffff88021f007a00] do_page_fault at ffffffff813bf32e #7 [ffff88021f007b10] page_fault at ffffffff813bc045 [exception RIP: sysfs_find_dirent+17] RIP: ffffffff81178611 RSP: ffff88021f007bc0 RFLAGS: 00010246 RAX: ffff88021e64c440 RBX: ffffffff8156cc63 RCX: 0000000000000004 RDX: ffffffff8156cc63 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88021f007be0 R8: 0000000000000004 R9: 0000000000000008 R10: ffffffff816fed00 R11: 0000000000000004 R12: 0000000000000000 R13: ffffffff8156cc63 R14: 0000000000000000 R15: ffff8802222a0000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffff88021f007be8] sysfs_get_dirent at ffffffff81178c07 #9 [ffff88021f007c18] sysfs_remove_group at ffffffff8117ac27 #10 [ffff88021f007c48] netdev_queue_update_kobjects at ffffffff813178f9 #11 [ffff88021f007c88] netif_set_real_num_tx_queues at ffffffff81303e38 #12 [ffff88021f007cc8] ixgbe_set_num_queues at ffffffffa0249763 [ixgbe] #13 [ffff88021f007cf8] ixgbe_init_interrupt_scheme at ffffffffa024ea89 [ixgbe] #14 [ffff88021f007d48] ixgbe_fcoe_disable at ffffffffa0267113 [ixgbe] #15 [ffff88021f007d68] vlan_dev_fcoe_disable at ffffffffa014fef5 [8021q] #16 [ffff88021f007d78] fcoe_interface_cleanup at ffffffffa02b7dfd [fcoe] #17 [ffff88021f007df8] fcoe_destroy_work at ffffffffa02b7f08 [fcoe] #18 [ffff88021f007e18] process_one_work at ffffffff8105d7ca #19 [ffff88021f007e68] worker_thread at ffffffff81060513 #20 [ffff88021f007ee8] kthread at ffffffff810648b6 #21 [ffff88021f007f48] kernel_thread_helper at ffffffff813c40f4 Signed-off-by:Yi Zou <yi.zou@intel.com> Tested-by:
-
Alexander Duyck authored
This patch fixes an issue in which RSC will generate corrupted frames when PAGE_SIZE is larger than 8K. Specifically it looks like that in 2.6.39 a change was made so that GRO would always have at least 16 frags available for coalescing, but the ixgbe RSC logic was not updated. As such the RSC feature would generate a frame larger than 64K and then overflow the value in the IP length field. To correct that I am now basing things on the PAGE_SIZE. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
-
Greg Rose authored
A check for the number of VFs allocated should have used a greater than equal operator instead of just greater than. This caused allocation of exactly 32 VFs to not enable the PF transmit and receive enables. Signed-off-by:
Greg Rose <gregory.v.rose@intel.com> Tested-by:
Robert E Garrett <robertX.e.garrett@intel.com> Signed-off-by:
-
Greg Rose authored
Recent addition of code to find already allocated VFs failed to take account that systems with 2 or more multi-port SR-IOV capable controllers might have already enabled VFs. Make sure that the VFs the function is finding are actually subordinate to the particular instance of the adapter that is looking for them and not subordinate to some device that has previously enabled SR-IOV. This bug exists in 3.2 stable as well as 3.3 release candidates. CC: stable@vger.kernel.org Reported-by:
David Ahern <daahern@cisco.com> Signed-off-by:
-
Greg Rose authored
Recent addition of code to find already allocated VFs failed to take account that systems with 2 or more multi-port SR-IOV capable controllers might have already enabled VFs. Make sure that the VFs the function is finding are actually subordinate to the particular instance of the adapter that is looking for them and not subordinate to some device that has previously enabled SR-IOV. This is applicable to 3.2+ kernels. CC: stable@vger.kernel.org Reported-by:
-
Dean Nelson authored
Commit d5bc77a2 broke Wake-on-LAN by inadvertently dropping the enabling of DMA receives. Restore the enabling of DMA receives for WoL. This is applicable to 3.1+ stable trees. CC: stable@vger.stable.org Reported-by:
Tobias Klausmann <klausman@schwarzvogel.de> Signed-off-by:
Dean Nelson <dnelson@redhat.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
-
Eric Dumazet authored
Shlomo Pongratz reported GRO L2 header check was suited for Ethernet only, and failed on IB/ipoib traffic. He provided a patch faking a zeroed header to let GRO aggregates frames. Roland Dreier, Herbert Xu, and others suggested we change GRO L2 header check to be more generic, ie not assuming L2 header is 14 bytes, but taking into account hard_header_len. __napi_gro_receive() has special handling for the common case (Ethernet) to avoid a memcmp() call and use an inline optimized function instead. Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Reported-by:
Shlomo Pongratz <shlomop@mellanox.com> Cc: Roland Dreier <roland@kernel.org> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Tested-by:
Sean Hefty <sean.hefty@intel.com> Signed-off-by:
-
Roland Dreier authored
Commit a0417fa3 ("net: Make qdisc_skb_cb upper size bound explicit.") made it possible for a netdev driver to use skb->cb between its header_ops.create method and its .ndo_start_xmit method. Use this in ipoib_hard_header() to stash away the LL address (GID + QPN), instead of the "ipoib_pseudoheader" hack. This allows IPoIB to stop lying about its hard_header_len, which will let us fix the L2 check for GRO. Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
-
- Feb 08, 2012
-
-
Tomas Vanek authored
Some devices (iwl5100) cannot connect to zd1211rw based AP. It appears that zd1211 firmware messes up duration_id field if it is not set to zero by driver. Sniffing traffic shows that zd1211 is transmitting frames with duration_id bits 14 and 15 set and other bits appearing random. Setting duration_id at driver to zero results zd1211 outputting sane duration_id. This means that firmware is setting correct values itself and expects duration_id to be zero in first place. Looking at vendor driver shows that only PSPoll frames have duration_id set by driver, for other frames duration_id left zero. Original bug-report and attached patch at: http://sourceforge.net/mailarchive/message.php?msg_id=28759111 Reported-by:
Tomas Vanek <Tomas.Vanek@fbl.cz> [modified original patch from bug-report, added check for pspoll frame] Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Atsushi Nemoto authored
8<---------------------------------------------------------------------- From: Ralf Roesch <ralf.roesch@rw-gmbh.de> Date: Wed, 16 Nov 2011 09:33:50 +0100 Subject: [PATCH] net: enable TC35815 for MIPS again TX493[8,9] MIPS SoCs support 2 Ethernet channels of type TC35815 which are connected to the internal PCI controller. And JMR3927 MIPS board has a TC35815 chip on board. These dependencies were lost on movement to drivers/net/ethernet/toshiba. Signed-off-by:
Ralf Roesch <ralf.roesch@rw-gmbh.de> Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> CC: stable@vger.kernel.org [3.2+] Signed-off-by:
-
Yoshihiro Shimoda authored
When this GETHER controller received a large frame (about 1800 bytes or more), skb_over_panic() happened. This is because the previous driver set the RFLR to 0x1000 (4096 bytes) and the skb allocate size is smaller than 4096 bytes. So, the controller accepted such a frame. The controller can discard a large frame by the RFLR setting. So, the patch modifies the value of RFLR to mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Anisse Astier authored
Tested-by:
Anisse Astier <anisse@astier.eu> Signed-off-by:
-
Jesper Juhl authored
We allocate memory for 'new_data' with kmalloc(). If we get the memory we then try to build_skb() and if that should fail (which it can) we do not enter 'if (likely(skb)) {' and actually use 'new_data' but instead fall through to the 'drop:' label and end up returning from the function without ever assigning 'new'data' to anything or freeing it. That leaks the memory allocated to 'new_data'. This patch fixes the memory leak by doing a kfree(new_data) in the case where build_skb() fails (or where allocation of 'new_data' itself fails, but in taht case it's just a harmless kfree(NULL)). Signed-off-by:Jesper Juhl <jj@chaosbits.net> Acked-by:
Eilon Greenstein <eilong@broadcom.com> Signed-off-by:
-
Al Viro authored
As it is, with PCI/ISA/MCA/CCW all set to n and PCMCIA set to m setting TR to y will set LLC to m, with very unpleasant results - net/802/psnap gets picked into obj-y, resulting in the kernel that won't link - psnap calls functions from llc. The cause, AFAICS, is that kconfig gets rev_dep for LLC containing || TR && (deps for TR) and even though TR is boolean, both LLC and PCMCIA are tristate and that thing becomes || y && (n || m), i.e. || m. The reason for dependency on PCMCIA is that when none of PCI, ISA, MCA, CCW or PCMCIA is set there'll be no tokenring drivers, so there's no point building tokenring core. Proper fix probably belongs in kconfig (we need strict and, such that y <strict_and> m would be y, so that rev_deps added for tristate selected by bool would use that instead of &&; we'd have || TR <strict_and> (deps for TR) in this case), but it's a rather intrusive change. There's an easy workaround in case of TR -> LLC select, namely to have a def_bool y symbol sitting under if TR and have that symbol selecting LLC. Kudos to johill for suggesting that one... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
stephen hemminger authored
As reported by several people... The code in rx_clean was panic'ing so revert commit d0249e44 . Will redo DMA mapping checks as new patches for a later release. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
- Feb 07, 2012
-
-
Thadeu Lima de Souza Cascardo authored
mlx4_en_prepare_rx_desc does not correctly clean up after it finds an allocation failure. It should unmap a page before calling put_page, but it only calls the later. This bug would prevent a device removal using hotplug after setting the device MTU to 9000 and opening the network interface. After the fix, we still see the allocation failure with MTU 9000, but we are able to remove the device. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
After opening the network interface, Mellanox ConnectX device cannot be removed by hotplug because it has not properly unmapped all DMA memory. It happens that mlx4_en_activate_rx_rings overrides the variable that keeps the size of the memory mapped. This is fixed by passing to mlx4_en_destroy_rx_ring the same size that is given to mlx4_en_create_rx_ring. After applying this patch, hot unplugging the device works after opening the interface. Signed-off-by:
-
Henrik Rydberg authored
The brcmsmac driver is now using the bcma SPROM CRC check, which does not recognize all chipsets that were functional prior to the switch. In particular, the current code bails out on odd CRC errors in recent Macbooks. This patch ignores those errors, with the argument that an unrecognized SPROM should be treated similarly to a non-existing one. Signed-off-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
-
Eugenia Emantayev authored
Use port number for correct steering (list per port). Before the fix all steering entries (for both physical ports) were managed in first port structures, so we had leakage of resources for port 2. Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.co.il> Signed-off-by:
-
Eugenia Emantayev authored
Use MLX4_DEV_CAP_FLAG_VEP_UC_STEER for unicast_promisc_add/remove Unicast entries were managed in wrong data structures. Signed-off-by:
-
Eugenia Emantayev authored
Perform cleanup also in non-master flow. The VFs use communication channel as well. Signed-off-by:
-
Felix Fietkau authored
commit adb5066a "ath9k_hw: do not apply the 2.4 ghz ack timeout workaround to cts" reduced the hardware CTS timeout to the normal values specified by the standard, but it turns out while it doesn't need the same extra time that it needs for the ACK timeout, it does need more than the value specified in the standard, but only for 2.4 GHz. This patch brings the CTS timeout value in sync with the initialization values, while still allowing adjustment for bigger distances. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Reported-by:
Seth Forshee <seth.forshee@canonical.com> Reported-by:
Marek Lindner <lindner_marek@yahoo.de> Signed-off-by:
-
Felix Fietkau authored
commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag" fixed the interpretation of the KeyMiss flag for keycache based lookups, however WEP encryption uses a static index, so KeyMiss is always asserted for it, even though frames are decrypted properly. Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based lookup was performed. Signed-off-by:
Laurent Bonnans <bonnans.l@gmail.com> Reported-by:
Jurica Vukadin <u.ra604@googlemail.com> Signed-off-by:
-
Amitkumar Karwar authored
If driver load is failed, sometimes few pointers may remain uninitialized ex. priv->wdev, priv->netdev, adapter->sleep_cfm This will cause NULL pointer dereferance while unloading the driver. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kiran Divekar <dkiran@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
- Feb 06, 2012
-
-
David Lv authored
Initially diagnosed on Ubuntu 11.04 with kernel 2.6.38. velocity_close is not called during a suspend / resume cycle in this driver and it has no business playing directly with power states. Signed-off-by:
David Lv <DavidLv@viatech.com.cn> Acked-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
- Feb 05, 2012
-
-
Julian Anastasov authored
Eric Dumazet found that commit 813b3b5d (ipv4: Use caller's on-stack flowi as-is in output route lookups.) that comes in 3.0 added a regression. The problem appears to be that resulting flowi4_oif is used incorrectly as input parameter to some routing lookups. The result is that when connecting to local port without listener if the IP address that is used is not on a loopback interface we incorrectly assign RTN_UNICAST to the output route because no route is matched by oif=lo. The RST packet can not be sent immediately by tcp_v4_send_reset because it expects RTN_LOCAL. So, change ip_route_connect and ip_route_newports to update the flowi4 fields that are input parameters because we do not want unnecessary binding to oif. To make it clear what are the input parameters that can be modified during lookup and to show which fields of floiw4 are reused add a new function to update the flowi4 structure: flowi4_update_output. Thanks to Yurij M. Plotnikov for providing a bug report including a program to reproduce the problem. Thanks to Eric Dumazet for tracking the problem down to tcp_v4_send_reset and providing initial fix. Reported-by:
Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru> Signed-off-by:
Julian Anastasov <ja@ssi.bg> Acked-by:
-
Shawn Lu authored
Binding RST packet outgoing interface to incoming interface for tcp v4 when there is no socket associate with it. when sk is not NULL, using sk->sk_bound_dev_if instead. (suggested by Eric Dumazet). This has few benefits: 1. tcp_v6_send_reset already did that. 2. This helps tcp connect with SO_BINDTODEVICE set. When connection is lost, we still able to sending out RST using same interface. 3. we are sending reply, it is most likely to be succeed if iif is used Signed-off-by:
Shawn Lu <shawn.lu@ericsson.com> Acked-by:
-
Neil Horman authored
It was recently pointed out to me that the get_prioidx function sets a bit in the prioidx map prior to checking to see if the index being set is out of bounds. This patch corrects that, avoiding the possiblity of us writing beyond the end of the array Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> CC: Stanislaw Gruszka <sgruszka@redhat.com> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
-
- Feb 04, 2012
-
-
Mohammed Shafi Shajakhan authored
all works need to be initialized before ieee80211_register_hw to prevent mac80211 call backs such as drv_start, drv_config getting started. otherwise we would queue/cancel works before initializing them and it leads to kernel panic. this issue can be recreated with the following script in Chrome laptops with AR928X cards, with background scan running (or) Network manager is running while true do sudo modprobe -v ath9k sleep 3 sudo modprobe -r ath9k sleep 3 done EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70 ---[ end trace 4f86d6139a9900ef ]--- Registered led device: ath9k-phy0 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000, irq=16 Kernel panic - not syncing: Fatal exception Pid: 456, comm: wpa_supplicant Tainted: G D 3.0.13 #1 Call Trace: [<81379e21>] panic+0x53/0x14a [<81004a30>] oops_end+0x73/0x81 [<81004b53>] die+0x4c/0x55 [<81002710>] do_trap+0x7c/0x83 [<81002855>] ? do_bounds+0x58/0x58 [<810028cc>] do_invalid_op+0x77/0x81 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1 [<810489ec>] ? sched_clock_cpu+0x81/0x11f [<8103f809>] ? wait_on_work+0xe2/0xf7 [<8137f807>] error_code+0x67/0x6c [<810300d8>] ? wait_consider_task+0x4ba/0x84c [<81040a47>] ? __cancel_work_timer+0xb8/0xe1 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67 [<81040a91>] cancel_work_sync+0xf/0x11 [<f88d7b7c>] ath_set_channel+0x62/0x25c [ath9k] [<f88d67d1>] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k] [<f88d8899>] ath_radio_disable+0x3f1/0x68e [ath9k] [<f90d0edb>] ieee80211_hw_config+0x111/0x116 [mac80211] [<f90dd95c>] __ieee80211_recalc_idle+0x919/0xa37 [mac80211] [<f90dda76>] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211] [<812dbed8>] __dev_open+0x82/0xab Cc: <stable@vger.kernel.org> Cc: Gary Morain <gmorain@google.com> Cc: Paul Stewart <pstew@google.com> Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com> Tested-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
-
