- 07 Oct, 2015 1 commit
-
-
Kalle Valo authored
Merge tag 'iwlwifi-for-kalle-2015-10-05' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes * some fixes for PN key programming when entering D3; * fix for CSA when the AP is stopped during a channel switch; * fix firmware name for 3160 devices; * add some new PCI IDs for 7265 devices; * fix CT-kill entry; * fix kernel panic when a sysassert occurs in the init ucode flow;
-
- 05 Oct, 2015 8 commits
-
-
Andrei Otcheretianski authored
FW dump may be triggered when running init ucode, for example due to a sysassert. In this case fw_dump_wk may run after mvm is freed, resulting in a kernel panic. Fix it by flushing the work. Fixes: 01b988a708af ("iwlwifi: mvm: allow to collect debug data when restart is disabled") Cc: <stable@vger.kernel.org> [3.18+] Signed-off-by:Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Arik Nemtsov authored
During the CT-kill exit flow, the card is powered up and partially initialized to check if the temperature is already low enough. Unfortunately the init bails early because the CT-kill flag is set. Make the code bail early only for HW RF-kill, as was intended by the author. CT-kill is self-imposed and is not really RF-kill. Fixes: 31b8b343 ("iwlwifi: fix RFkill while calibrating") Cc: <stable@vger.kernel.org> [3.18+] Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
-
Luca Coelho authored
Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B device ID. Cc: <stable@vger.kernerl.org> [3.13+] Reported-by:
Jeremy <jeremy.bomkamp@gmail.com> Signed-off-by:
-
Johannes Berg authored
The MODULE_FIRMWARE() for 3160 should be using the 7260 version as it's done in the device configuration struct instead of referencing IWL3160_UCODE_API_OK which doesn't even exist. Cc: <stable@vger.kernel.org> [3.8+] Reported-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Avraham Stern authored
The csa_countdown flag was not cleared when the AP is stopped. As a result, if the AP was stopped after csa_countdown had started, all the folowing channel switch commands would fail. Fix that by clearing the csa_countdown flag when the AP is stopped. Cc: <stable@vger.kernel.org> [3.17+] Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Johannes Berg authored
The code to send the RX PN data (for each TID) to the firmware has a devastating bug: it overwrites the data for TID 0 with all the TID data, leaving the remaining TIDs zeroed. This will allow replays to actually be accepted by the firmware, which could allow waking up the system. Cc: <stable@vger.kernel.org> [3.1+] Signed-off-by:
-
Johannes Berg authored
The code to send the RX PN data (for each TID) to the firmware has a devastating bug: it overwrites the data for TID 0 with all the TID data, leaving the remaining TIDs zeroed. This will allow replays to actually be accepted by the firmware, which could allow waking up the system. Cc: <stable@vger.kernel.org> [3.1+] Signed-off-by:
-
Johannes Berg authored
When going into/coming out of D3, the TX PN must be programmed into and restored from the firmware respectively. The restore was broken due to my previous commit to move PN assignment into the driver. Sending the PN to the firmware still worked since we now use the counter that's shared with mac80211, but accessing it through the mac80211 API makes no sense now. Fix this by reading/writing the counter directly. This actually simplifies the code since we don't need to round-trip through the key_seq structure. Fixes: ca8c0f4b ("iwlwifi: mvm: move TX PN assignment for CCMP to the driver") Cc: <stable@vger.kernel.org> [4.1+] Reported-by:
-
- 03 Oct, 2015 1 commit
-
-
Larry Finger authored
In commit 1277fa2a ("rtlwifi: Remove the clear interrupt routine from all drivers"), the code that cleared all interrupt enable bits before setting them was removed for all PCI drivers. This fixed an issue that caused TX to be blocked for 3-5 seconds. On some RTL8821AE units, this change causes soft lockups to occur on boot. For that reason, the portion of the earlier commit that applied to rtl8821ae is reverted. Kernels 4.1 and newer are affected. See http://marc.info/?l=linux-wireless&m=144373370103285&w=2 and https://bugzilla.opensuse.org/show_bug.cgi?id=944978 for two cases where this regression affected user systems. Note that this bug does not appear on any of the developer's setups. For those users whose systems are affected by the TX blockage, but do not lock up on boot, a module parameter is added to disable the interrupt clear Fixes: 1277fa2a ("rtlwifi: Remove the clear interrupt routine from all drivers") Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [V4.1+] Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
- 26 Sep, 2015 6 commits
-
-
Felix Fietkau authored
Some platforms really don't like DMA bursts of 256 bytes, and this causes the firmware to crash when sending beacons. Also, changing this based on the firmware version does not seem to make much sense, so use 128 bytes for all versions. Cc: stable@vger.kernel.org Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com>
-
Rafał Miłecki authored
OpenWrt user reported b43 doesn't probe wireless core on SoC BCM5356A1: [ 0.000000] bcma: bus0: Found chip with id 0x5356, rev 0x01 and package 0x04 it is because this chip uses different 802.11 core revison than others: [ 0.000000] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x15, class 0x0) Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Stanislaw Gruszka authored
Brand: Airlive (Ovislink Corp.) Name: Turbo-G USB Adaptor Model: WT-2000USB USB ID: 1b75:3070 Reported-and-tested-by:
Michael Coates <michlinux@hotmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Felix Fietkau authored
ath9k inserts padding between the 802.11 header and the data area (to align it). Since it didn't declare this extra required headroom, this led to some nasty issues like randomly dropped packets in some setups. Cc: stable@vger.kernel.org Signed-off-by:
-
David Ahern authored
Andrey reported a panic: [ 7249.865507] BUG: unable to handle kernel pointer dereference at 000000b4 [ 7249.865559] IP: [<c16afeca>] icmp_route_lookup+0xaa/0x320 [ 7249.865598] *pdpt = 0000000030f7f001 *pde = 0000000000000000 [ 7249.865637] Oops: 0000 [#1] ... [ 7249.866811] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.3.0-999-generic #201509220155 [ 7249.866876] Hardware name: MSI MS-7250/MS-7250, BIOS 080014 08/02/2006 [ 7249.866916] task: c1a5ab00 ti: c1a52000 task.ti: c1a52000 [ 7249.866949] EIP: 0060:[<c16afeca>] EFLAGS: 00210246 CPU: 0 [ 7249.866981] EIP is at icmp_route_lookup+0xaa/0x320 [ 7249.867012] EAX: 00000000 EBX: f483ba48 ECX: 00000000 EDX: f2e18a00 [ 7249.867045] ESI: 000000c0 EDI: f483ba70 EBP: f483b9ec ESP: f483b974 [ 7249.867077] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 7249.867108] CR0: 8005003b CR2: 000000b4 CR3: 36ee07c0 CR4: 000006f0 [ 7249.867141] Stack: [ 7249.867165] 320310ee 00000000 00000042 320310ee 00000000 c1aeca00 f3920240 f0c69180 [ 7249.867268] f483ba04 f855058b a89b66cd f483ba44 f8962f4b 00000000 e659266c f483ba54 [ 7249.867361] 8004753c f483ba5c f8962f4b f2031140 000003c1 ffbd8fa0 c16b0e00 00000064 [ 7249.867448] Call Trace: [ 7249.867494] [<f855058b>] ? e1000_xmit_frame+0x87b/0xdc0 [e1000e] [ 7249.867534] [<f8962f4b>] ? tcp_in_window+0xeb/0xb10 [nf_conntrack] [ 7249.867576] [<f8962f4b>] ? tcp_in_window+0xeb/0xb10 [nf_conntrack] [ 7249.867615] [<c16b0e00>] ? icmp_send+0xa0/0x380 [ 7249.867648] [<c16b102f>] icmp_send+0x2cf/0x380 [ 7249.867681] [<f89c8126>] nf_send_unreach+0xa6/0xc0 [nf_reject_ipv4] [ 7249.867714] [<f89cd0da>] reject_tg+0x7a/0x9f [ipt_REJECT] [ 7249.867746] [<f88c29a7>] ipt_do_table+0x317/0x70c [ip_tables] [ 7249.867780] [<f895e0a6>] ? __nf_conntrack_find_get+0x166/0x3b0 [nf_conntrack] [ 7249.867838] [<f895eea8>] ? nf_conntrack_in+0x398/0x600 [nf_conntrack] [ 7249.867889] [<f84c0035>] iptable_filter_hook+0x35/0x80 [iptable_filter] [ 7249.867933] [<c16776a1>] nf_iterate+0x71/0x80 [ 7249.867970] [<c1677715>] nf_hook_slow+0x65/0xc0 [ 7249.868002] [<c1681811>] __ip_local_out_sk+0xc1/0xd0 [ 7249.868034] [<c1680f30>] ? ip_forward_options+0x1a0/0x1a0 [ 7249.868066] [<c1681836>] ip_local_out_sk+0x16/0x30 [ 7249.868097] [<c1684054>] ip_send_skb+0x14/0x80 [ 7249.868129] [<c16840f4>] ip_push_pending_frames+0x34/0x40 [ 7249.868163] [<c16844a2>] ip_send_unicast_reply+0x282/0x310 [ 7249.868196] [<c16a0863>] tcp_v4_send_reset+0x1b3/0x380 [ 7249.868227] [<c16a1b63>] tcp_v4_rcv+0x323/0x990 [ 7249.868257] [<c16776a1>] ? nf_iterate+0x71/0x80 [ 7249.868289] [<c167dc2b>] ip_local_deliver_finish+0x8b/0x230 [ 7249.868322] [<c167df4c>] ip_local_deliver+0x4c/0xa0 [ 7249.868353] [<c167dba0>] ? ip_rcv_finish+0x390/0x390 [ 7249.868384] [<c167d88c>] ip_rcv_finish+0x7c/0x390 [ 7249.868415] [<c167e280>] ip_rcv+0x2e0/0x420 ... Prior to the VRF change the oif was not set in the flow struct, so the VRF support should really have only added the vrf_master_ifindex lookup. Fixes: 613d09b3 ("net: Use VRF device index for lookups on TX") Cc: Andrey Melnikov <temnota.am@gmail.com> Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King authored
Update the docbook comment for __mdiobus_register() to include the new module owner argument. This resolves a warning found by the 0-day builder. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
- 25 Sep, 2015 13 commits
-
-
Guillaume Nault authored
ppp_dev_uninit() locks all_ppp_mutex while under rtnl mutex protection. ppp_create_interface() must then lock these mutexes in that same order to avoid possible deadlock. [ 120.880011] ====================================================== [ 120.880011] [ INFO: possible circular locking dependency detected ] [ 120.880011] 4.2.0 #1 Not tainted [ 120.880011] ------------------------------------------------------- [ 120.880011] ppp-apitest/15827 is trying to acquire lock: [ 120.880011] (&pn->all_ppp_mutex){+.+.+.}, at: [<ffffffffa0145f56>] ppp_dev_uninit+0x64/0xb0 [ppp_generic] [ 120.880011] [ 120.880011] but task is already holding lock: [ 120.880011] (rtnl_mutex){+.+.+.}, at: [<ffffffff812e4255>] rtnl_lock+0x12/0x14 [ 120.880011] [ 120.880011] which lock already depends on the new lock. [ 120.880011] [ 120.880011] [ 120.880011] the existing dependency chain (in reverse order) is: [ 120.880011] [ 120.880011] -> #1 (rtnl_mutex){+.+.+.}: [ 120.880011] [<ffffffff81073a6f>] lock_acquire+0xcf/0x10e [ 120.880011] [<ffffffff813ab18a>] mutex_lock_nested+0x56/0x341 [ 120.880011] [<ffffffff812e4255>] rtnl_lock+0x12/0x14 [ 120.880011] [<ffffffff812d9d94>] register_netdev+0x11/0x27 [ 120.880011] [<ffffffffa0147b17>] ppp_ioctl+0x289/0xc98 [ppp_generic] [ 120.880011] [<ffffffff8113b367>] do_vfs_ioctl+0x4ea/0x532 [ 120.880011] [<ffffffff8113b3fd>] SyS_ioctl+0x4e/0x7d [ 120.880011] [<ffffffff813ad7d7>] entry_SYSCALL_64_fastpath+0x12/0x6f [ 120.880011] [ 120.880011] -> #0 (&pn->all_ppp_mutex){+.+.+.}: [ 120.880011] [<ffffffff8107334e>] __lock_acquire+0xb07/0xe76 [ 120.880011] [<ffffffff81073a6f>] lock_acquire+0xcf/0x10e [ 120.880011] [<ffffffff813ab18a>] mutex_lock_nested+0x56/0x341 [ 120.880011] [<ffffffffa0145f56>] ppp_dev_uninit+0x64/0xb0 [ppp_generic] [ 120.880011] [<ffffffff812d5263>] rollback_registered_many+0x19e/0x252 [ 120.880011] [<ffffffff812d5381>] rollback_registered+0x29/0x38 [ 120.880011] [<ffffffff812d53fa>] unregister_netdevice_queue+0x6a/0x77 [ 120.880011] [<ffffffffa0146a94>] ppp_release+0x42/0x79 [ppp_generic] [ 120.880011] [<ffffffff8112d9f6>] __fput+0xec/0x192 [ 120.880011] [<ffffffff8112dacc>] ____fput+0x9/0xb [ 120.880011] [<ffffffff8105447a>] task_work_run+0x66/0x80 [ 120.880011] [<ffffffff81001801>] prepare_exit_to_usermode+0x8c/0xa7 [ 120.880011] [<ffffffff81001900>] syscall_return_slowpath+0xe4/0x104 [ 120.880011] [<ffffffff813ad931>] int_ret_from_sys_call+0x25/0x9f [ 120.880011] [ 120.880011] other info that might help us debug this: [ 120.880011] [ 120.880011] Possible unsafe locking scenario: [ 120.880011] [ 120.880011] CPU0 CPU1 [ 120.880011] ---- ---- [ 120.880011] lock(rtnl_mutex); [ 120.880011] lock(&pn->all_ppp_mutex); [ 120.880011] lock(rtnl_mutex); [ 120.880011] lock(&pn->all_ppp_mutex); [ 120.880011] [ 120.880011] *** DEADLOCK *** Fixes: 8cb775bc ("ppp: fix device unregistration upon netns deletion") Reported-by:Sedat Dilek <sedat.dilek@gmail.com> Tested-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Sudip Mukherjee authored
The builds of allmodconfig of avr32 is failing with: drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration of function 'pci_iomap' [-Werror=implicit-function-declaration] drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration of function 'pci_iounmap' [-Werror=implicit-function-declaration] The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI is not defined and CONFIG_GENERIC_PCI_IOMAP is defined. Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both are not defined. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Russell King authored
Read the standard link partner advertisment registers and store it in phydev->lp_advertising, so ethtool can report this information to userspace via ethtool. Zero it as per genphy if autonegotiation is disabled. Tested with a Marvell 88E1512 PHY. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== Phy, mdiobus, and netdev struct device fixes The third version of this series fixes the build error which David identified, and drops the broken changes for the Cavium Thunger BGX ethernet driver as this driver requires some complex changes to resolve the leakage - and this is best done by people who can test the driver. Compared to v2, the only patch which has changed is patch 6 "net: fix phy refcounting in a bunch of drivers" I _think_ I've been able to build-test all the drivers touched by that patch to some degree now, though several of them needed the Kconfig hacked to allow it (not all had || COMPILE_TEST clause on their dependencies.) Previous cover letters below: This is the second version of the series, with the comments David had on the first patch fixed up. Original series description with updated diffstat below. While looking at the DSA code, I noticed we have a of_find_net_device_by_node(), and it looks like users of that are similarly buggy - it looks like net/dsa/dsa.c is the only user. Fix that too. Hi, While looking at the phy code, I identified a number of weaknesses where refcounting on device structures was being leaked, where modules could be removed while in-use, and where the fixed-phy could end up having unintended consequences caused by incorrect calls to fixed_phy_update_state(). This patch series resolves those issues, some of which were discovered with testing on an Armada 388 board. Not all patches are fully tested, particularly the one which touches several network drivers. When resolving the struct device refcounting problems, several different solutions were considered before settling on the implementation here - one of the considerations was to avoid touching many network drivers. The solution here is: phy_attach*() - takes a refcount phy_detach*() - drops the phy_attach refcount Provided drivers always attach and detach their phys, which they should already be doing, this should change nothing, even if they leak a refcount. of_phy_find_device() and of_* functions which use that take a refcount. Arrange for this refcount to be dropped once the phy is attached. This is the reason why the previous change is important - we can't drop this refcount taken by of_phy_find_device() until something else holds a reference on the device. This resolves the leaked refcount caused by using of_phy_connect() or of_phy_attach(). Even without the above changes, these drivers are leaking by calling of_phy_find_device(). These drivers are addressed by adding the appropriate release of that refcount. The mdiobus code also suffered from the same kind of leak, but thankfully this only happened in one place - the mdio-mux code. I also found that the try_module_get() in the phy layer code was utterly useless: phydev->dev.driver was guaranteed to always be NULL, so try_module_get() was always being called with a NULL argument. I proved this with my SFP code, which declares its own MDIO bus - the module use count was never incremented irrespective of how I set the MDIO bus up. This allowed the MDIO bus code to be removed from the kernel while there were still PHYs attached to it. One other bug was discovered: while using in-band-status with mvneta, it was found that if a real phy is attached with in-band-status enabled, and another ethernet interface is using the fixed-phy infrastructure, the interface using the fixed-phy infrastructure is configured according to the other interface using the in-band-status - which is caused by the fixed-phy code not verifying that the phy_device passed in is actually a fixed-phy device, rather than a real MDIO phy. Lastly, having mdio_bus reversing phy_device_register() internals seems like a layering violation - it's trivial to move that code to the phy device layer. ==================== Tested-by:
-
Russell King authored
of_find_net_device_by_node() uses class_find_device() internally to lookup the corresponding network device. class_find_device() returns a reference to the embedded struct device, with its refcount incremented. Add a comment to the definition in net/core/net-sysfs.c indicating the need to drop this refcount, and fix the DSA code to drop this refcount when the OF-generated platform data is cleaned up and freed. Also arrange for the ref to be dropped when handling errors. Signed-off-by:
-
Russell King authored
Add a phy_device_remove() function to complement phy_device_register(), which undoes the effects of phy_device_register() by removing the phy device from visibility, but not freeing it. This allows these details to be moved out of the mdio bus code into the phy code where this action belongs. Signed-off-by:
-
Russell King authored
Validate that the phy_device passed into fixed_phy_update_state() is a fixed-phy device before walking the list of phys for a fixed phy at the same address. Signed-off-by:
-
Russell King authored
of_phy_find_device() increments the phy struct device refcount, which we need to properly balance. Add code to network drivers using this function to ensure that the struct device refcount is correctly balanced. For xgene, looking back in the history, we should be able to use of_phy_connect() with a zero flags argument for the DT case as this is how the driver used to operate prior to de7b5b3d ("net: eth: xgene: change APM X-Gene SoC platform ethernet to support ACPI"). This leaves the Cavium Thunder BGX unfixed; fixing this driver is a complicated task, one which the maintainers need to be involved with. Signed-off-by:
-
Russell King authored
bus_find_device() is defined as: * This is similar to the bus_for_each_dev() function above, but it * returns a reference to a device that is 'found' for later use, as * determined by the @match callback. and it does indeed return a reference-counted pointer to the device: while ((dev = next_device(&i))) if (match(dev, data) && get_device(dev)) ^^^^^^^^^^^^^^^ break; klist_iter_exit(&i); return dev; What that means is that when we're done with the struct device, we must drop that reference. Neither of_phy_connect() nor of_phy_attach() did this when phy_connect_direct() or phy_attach_direct() failed. With our previous patch, phy_connect_direct() and phy_attach_direct() take a new refcount on the phy device when successful, so we can drop our local reference immediatley after these functions, whether or not they succeeded. Signed-off-by:Rob Herring <robh@kernel.org> Signed-off-by:
-
Russell King authored
Take a refcount on the phy struct device when the phy device is attached to a network device, and drop it after it's detached. This ensures that a refcount is held on the phy device while the device is being used by a network device, thereby preventing the phy_device from being unexpectedly kfree()'d by phy_device_release(). Signed-off-by:
-
Russell King authored
Re-implement the mdiobus module refcounting to ensure that we actually ensure that the mdiobus module code does not go away while we might call into it. The old scheme using bus->dev.driver was buggy, because bus->dev is a class device which never has a struct device_driver associated with it, and hence the associated code trying to obtain a refcount did nothing useful. Instead, take the approach that other subsystems do: pass the module when calling mdiobus_register(), and record that in the mii_bus struct. When we need to increment the module use count in the phy code, use this stored pointer. When the phy is deteched, drop the module refcount, remembering that the phy device might go away at that point. This doesn't stop the mii_bus going away while there are in-use phys - it merely stops the underlying code vanishing. Signed-off-by:
-
Russell King authored
Current users of of_mdio_find_bus() leak a struct device refcount, as they fail to clean up the reference obtained inside class_find_device(). Fix the DSA code to properly refcount the returned MDIO bus by: 1. taking a reference on the struct device whenever we assign it to pd->chip[x].host_dev. 2. dropping the reference when we overwrite the existing reference. 3. dropping the reference when we free the data structure. 4. dropping the initial reference we obtained after setting up the platform data structure, or on failure. In step 2 above, where we obtain a new MDIO bus, there is no need to take a reference on it as we would only have to drop it immediately after assignment again, iow: put_device(cd->host_dev); /* drop original assignment ref */ cd->host_dev = get_device(&mdio_bus_switch->dev); /* get our ref */ put_device(&mdio_bus_switch->dev); /* drop of_mdio_find_bus ref */ Signed-off-by:
-
Russell King authored
of_mdio_find_bus() leaks a struct device refcount, caused by using class_find_device() and not realising that the device reference has its refcount incremented: * Note, you will need to drop the reference with put_device() after use. ... while ((dev = class_dev_iter_next(&iter))) { if (match(dev, data)) { get_device(dev); break; } Update the comment, and arrange for the phy code to drop this refcount when disposing of a reference to it. Signed-off-by:
-
- 24 Sep, 2015 11 commits
-
-
Matt Bennett authored
Currently error log messages in ip6_tnl_err are printed at 'warn' level. This is different to other tunnel types which don't print any messages. These log messages don't provide any information that couldn't be deduced with networking tools. Also it can be annoying to have one end of the tunnel go down and have the logs fill with pointless messages such as "Path to destination invalid or inactive!". This patch reduces the log level of these messages to 'dbg' level to bring the visible behaviour into line with other tunnel types. Signed-off-by:
Matt Bennett <matt.bennett@alliedtelesis.co.nz> Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-for-davem-2015-09-22' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== Just two small fixes: * VHT MCS mask array overrun, reported by Dan Carpenter * reset CQM history to always get a notification, from Sara Sharon ==================== Signed-off-by:
-
Matt Bennett authored
Currently error log messages in ip6gre_err are printed at 'warn' level. This is different to most other tunnel types which don't print any messages. These log messages don't provide any information that couldn't be deduced with networking tools. Also it can be annoying to have one end of the tunnel go down and have the logs fill with pointless messages such as "Path to destination invalid or inactive!". This patch reduces the log level of these messages to 'dbg' level to bring the visible behaviour into line with other tunnel types. Signed-off-by:
-
Wilson Kok authored
dump_rules returns skb length and not error. But when family == AF_UNSPEC, the caller of dump_rules assumes that it returns an error. Hence, when family == AF_UNSPEC, we continue trying to dump on -EMSGSIZE errors resulting in incorrect dump idx carried between skbs belonging to the same dump. This results in fib rule dump always only dumping rules that fit into the first skb. This patch fixes dump_rules to return error so that we exit correctly and idx is correctly maintained between skbs that are part of the same dump. Signed-off-by:
Wilson Kok <wkok@cumulusnetworks.com> Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
Eric Dumazet authored
After a good amount of debugging, I found bnx2x was byte swaping the 40 bytes of rss_key. If we byte swap the key, then bnx2x generates hashes matching MSDN specs as documented in (Verifying the RSS Hash Calculation) https://msdn.microsoft.com/en-us/library/windows/hardware/ff571021% 28v=vs.85%29.aspx It is mostly a non issue, unless we want to mix different NIC in a host, and want consistent hashing among all of them, ie if they all use the boot time generated rss key, or if some application is choosing specific tuple(s) so that incoming traffic lands into known rx queue(s). Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
WANG Cong authored
fw filter uses tp->root==NULL to check if it is the old method, so it doesn't need allocation at all in this case. This patch reverts the offending commit and adds some comments for old method to make it obvious. Fixes: 33f8b9ec ("net_sched: move tp->root allocation into fw_init()") Reported-by:
Akshat Kakkar <akshat.1984@gmail.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
David S. Miller authored
Jiri Benc says: ==================== lwtunnel: make it really work, for IPv4 One of the selling points of lwtunnel was the ability to specify the tunnel destination using routes. However, this doesn't really work currently, as ARP and ndisc replies are not handled correctly. ARP and ndisc replies won't have tunnel metadata attached, thus they will be sent out with the default parameters or not sent at all, either way never reaching the requester. Most of the egress tunnel parameters can be inferred from the ingress metada. The only and important exception is UDP ports. This patchset infers the egress data from the ingress data and disallow settings of UDP ports in tunnel routes. If there's a need for different UDP ports, a new interface needs to be created for each port combination. Note that it's still possible to specify the UDP ports to use, it just needs to be done while creating the vxlan/geneve interface. This covers only ARPs. IPv6 ndisc has the same problem but is harder to solve, as there's already dst attached to outgoing skbs. Ideas to solve this are welcome. ==================== Signed-off-by: -
Jiri Benc authored
The UDP tunnel config is asymmetric wrt. to the ports used. The source and destination ports from one direction of the tunnel are not related to the ports of the other direction. We need to be able to respond to ARP requests using the correct ports without involving routing. As the consequence, UDP ports need to be fixed property of the tunnel interface and cannot be set per route. Remove the ability to set ports per route. This is still okay to do, as no kernel has been released with these attributes yet. Note that the ability to specify source and destination ports is preserved for other users of the lwtunnel API which don't use routes for tunnel key specification (like openvswitch). If in the future we rework ARP handling to allow port specification, the attributes can be added back. Signed-off-by:
Jiri Benc <jbenc@redhat.com> Acked-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Jiri Benc authored
When using ip lwtunnels, the additional data for xmit (basically, the actual tunnel to use) are carried in ip_tunnel_info either in dst->lwtstate or in metadata dst. When replying to ARP requests, we need to send the reply to the same tunnel the request came from. This means we need to construct proper metadata dst for ARP replies. We could perform another route lookup to get a dst entry with the correct lwtstate. However, this won't always ensure that the outgoing tunnel is the same as the incoming one, and it won't work anyway for IPv4 duplicate address detection. The only thing to do is to "reverse" the ip_tunnel_info. Signed-off-by:
-
Sudeep Holla authored
The device is set as wakeup capable using proper wakeup API but the driver misuses IRQF_NO_SUSPEND to set the interrupt as wakeup source which is incorrect. This patch removes the use of IRQF_NO_SUSPEND flags replacing it with enable_irq_wake instead. Cc: "David S. Miller" <davem@davemloft.net> Cc: Claudiu Manoil <claudiu.manoil@freescale.com> Cc: Kevin Hao <haokexin@gmail.com> Cc: netdev@vger.kernel.org Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Acked-by:
Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by:
-
Pravin B Shelar authored
VXLAN device can receive skb with checksum partial. But the checksum offset could be in outer header which is pulled on receive. This results in negative checksum offset for the skb. Such skb can cause the assert failure in skb_checksum_help(). Following patch fixes the bug by setting checksum-none while pulling outer header. Following is the kernel panic msg from old kernel hitting the bug. ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1906! RIP: 0010:[<ffffffff81518034>] skb_checksum_help+0x144/0x150 Call Trace: <IRQ> [<ffffffffa0164c28>] queue_userspace_packet+0x408/0x470 [openvswitch] [<ffffffffa016614d>] ovs_dp_upcall+0x5d/0x60 [openvswitch] [<ffffffffa0166236>] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch] [<ffffffffa016629b>] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch] [<ffffffffa016c51a>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa0171383>] vxlan_rcv+0x53/0x60 [openvswitch] [<ffffffffa01734cb>] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch] [<ffffffff8157addc>] udp_queue_rcv_skb+0x2dc/0x3b0 [<ffffffff8157b56f>] __udp4_lib_rcv+0x1cf/0x6c0 [<ffffffff8157ba7a>] udp_rcv+0x1a/0x20 [<ffffffff8154fdbd>] ip_local_deliver_finish+0xdd/0x280 [<ffffffff81550128>] ip_local_deliver+0x88/0x90 [<ffffffff8154fa7d>] ip_rcv_finish+0x10d/0x370 [<ffffffff81550365>] ip_rcv+0x235/0x300 [<ffffffff8151ba1d>] __netif_receive_skb+0x55d/0x620 [<ffffffff8151c360>] netif_receive_skb+0x80/0x90 [<ffffffff81459935>] virtnet_poll+0x555/0x6f0 [<ffffffff8151cd04>] net_rx_action+0x134/0x290 [<ffffffff810683d8>] __do_softirq+0xa8/0x210 [<ffffffff8162fe6c>] call_softirq+0x1c/0x30 [<ffffffff810161a5>] do_softirq+0x65/0xa0 [<ffffffff810687be>] irq_exit+0x8e/0xb0 [<ffffffff81630733>] do_IRQ+0x63/0xe0 [<ffffffff81625f2e>] common_interrupt+0x6e/0x6e Reported-by:
Anupam Chanda <achanda@vmware.com> Signed-off-by:
Pravin B Shelar <pshelar@nicira.com> Acked-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
-
