- 07 Mar, 2016 16 commits
-
-
Douglas Miller authored
The adapter->pcicfg resource is either mapped via pci_iomap() or derived from adapter->db. During be_remove() this resource was ignored and so could remain mapped after remove. Add a flag to track whether adapter->pcicfg was mapped or not, then use that flag in be_unmap_pci_bars() to unmap if required. Fixes: 25848c90 ("use PCI MMIO read instead of config read for errors") Signed-off-by: Douglas Miller <dougmill@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Neil Horman authored
vmxnet3 has a function vmxnet3_parse_and_copy_hdr which, among other operations, uses pskb_may_pull to linearize the header portion of an skb. That operation eventually uses local_bh_disable/enable to ensure that it doesn't race with the drivers bottom half handler. Unfortunately, vmxnet3 preforms this parse_and_copy operation with a spinlock held and interrupts disabled. This causes us to run afoul of the WARN_ON_ONCE(irqs_disabled()) warning in local_bh_enable, resulting in this: WARNING: at kernel/softirq.c:159 local_bh_enable+0x59/0x90() (Not tainted) Hardware name: VMware Virtual Platform Modules linked in: ipv6 ppdev parport_pc parport microcode e1000 vmware_balloon vmxnet3 i2c_piix4 sg ext4 jbd2 mbcache sd_mod crc_t10dif sr_mod cdrom mptspi mptscsih mptbase scsi_transport_spi pata_acpi ata_generic ata_piix vmwgfx ttm drm_kms_helper drm i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mperf] Pid: 6229, comm: sshd Not tainted 2.6.32-616.el6.i686 #1 Call Trace: [<c04624d9>] ? warn_slowpath_common+0x89/0xe0 [<c0469e99>] ? local_bh_enable+0x59/0x90 [<c046254b>] ? warn_slowpath_null+0x1b/0x20 [<c0469e99>] ? local_bh_enable+0x59/0x90 [<c07bb936>] ? skb_copy_bits+0x126/0x210 [<f8d1d9fe>] ? ext4_ext_find_extent+0x24e/0x2d0 [ext4] [<c07bc49e>] ? __pskb_pull_tail+0x6e/0x2b0 [<f95a6164>] ? vmxnet3_xmit_frame+0xba4/0xef0 [vmxnet3] [<c05d15a6>] ? selinux_ip_postroute+0x56/0x320 [<c0615988>] ? cfq_add_rq_rb+0x98/0x110 [<c0852df8>] ? packet_rcv+0x48/0x350 [<c07c5839>] ? dev_queue_xmit_nit+0xc9/0x140 ... Fix it by splitting vmxnet3_parse_and_copy_hdr into two functions: vmxnet3_parse_hdr, which sets up the internal/on stack ctx datastructure, and pulls the skb (both of which can be done without holding the spinlock with irqs disabled and vmxnet3_copy_header, which just copies the skb to the tx ring under the lock safely. tested and shown to correct the described problem. Applies cleanly to the head of the net tree Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: Shrikrishna Khare <skhare@vmware.com> CC: "VMware, Inc." <pv-drivers@vmware.com> CC: "David S. Miller" <davem@davemloft.net> Acked-by: Shrikrishna Khare <skhare@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'wireless-drivers-for-davem-2016-03-04' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 4.5 iwlwifi * free firmware paging memory when the module is unloaded or device removed * fix pending frames counter to fix an issue when removing stations ssb * fix a build problem related to ssb_fill_sprom_with_fallback() ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Krzysztof Kozlowski authored
The MFD_SYSCON depends on HAS_IOMEM so when selecting it avoid unmet direct dependencies. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thomas Falcon authored
If skb_linearize fails, the driver should drop the packet instead of trying to copy it into the bounce buffer. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Some devices will silently fail setup unless they are reset first. This is necessary even if the data interface is already in altsetting 0, which it will be when the device is probed for the first time. Briefly toggling the altsetting forces a function reset regardless of the initial state. This fixes a setup problem observed on a number of Huawei devices, appearing to operate in NTB-32 mode even if we explicitly set them to NTB-16 mode. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Oliver Neukum authored
In case bind() works, but a later error forces bailing in probe() in error cases work and a timer may be scheduled. They must be killed. This fixes an error case related to the double free reported in http://www.spinics.net/lists/netdev/msg367669.html and needs to go on top of Linus' fix to cdc-ncm. Signed-off-by: Oliver Neukum <ONeukum@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: couple of fixes Couple of fixes from Ido. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
The descriptor queues for sending (SDQs) and receiving (RDQs) packets are managed by two counters - producer and consumer - which are both 16-bit in size. A queue is considered full when the difference between the two equals the queue's maximum number of descriptors. However, if the producer counter overflows, then it's possible for the full queue check to fail, as it doesn't take the overflow into account. In such a case, descriptors already passed to the device - but for which a completion has yet to be posted - will be overwritten, thereby causing undefined behavior. The above can be achieved under heavy load (~30 netperf instances). Fix that by casting the subtraction result to u16, preventing it from being treated as a signed integer. Fixes: eda6500a ("mlxsw: Add PCI bus implementation") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Since we only support one VLAN filtering bridge we need to associate a reference count with it, so that when the last port netdev leaves it, we would know that a different bridge can be offloaded to hardware. When a LAG device is memeber in a bridge and port netdevs are leaving the LAG, we should always decrement the bridge's reference count, as it's incremented for any port in the LAG. Fixes: 4dc236c3 ("mlxsw: spectrum: Handle port leaving LAG while bridged") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Parthasarathy Bhuvaragan authored
commit 4d5cfcba ('tipc: fix connection abort during subscription cancel'), removes the check for a valid subscription before calling tipc_nametbl_subscribe(). This will lead to a nullptr exception when we process a subscription cancel request. For a cancel request, a null subscription is passed to tipc_nametbl_subscribe() resulting in exception. In this commit, we call tipc_nametbl_subscribe() only for a valid subscription. Fixes: 4d5cfcba ('tipc: fix connection abort during subscription cancel') Reported-by: Anders Widell <anders.widell@ericsson.com> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
priv->mdio->irq used to be allocated and required freeing, but it is now a fixed sized array and should no longer be free'd. Issue detected using static analysis with CoverityScan Fixes: e7f4dc35 ("mdio: Move allocation of interrupts into core") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
priv->mdio->irq used to be allocated and required freeing, but it is now a fixed sized array and should no longer be free'd. Issue detected using static analysis with CoverityScan Fixes: e7f4dc35 ("mdio: Move allocation of interrupts into core") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Tobias Klauser <tklauser@distanz.ch> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phil Sutter authored
Before calling the destroy() or target() callbacks, the family parameter field has to be initialized. Otherwise at least the LOG target will refuse to work and upon removal oops the kernel. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
Used to be allocated and required freeing, but now priv->mdio->irq is now a fixed sized array and should no longer be free'd. Issue detected using static analysis with CoverityScan Fixes: e7f4dc35 ("mdio: Move allocation of interrupts into core") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Atsushi Nemoto authored
Enable workaround for MPC8548E erratum eTSEC 106, "Excess delays when transmitting TOE=1 large frames". (see commit 53fad773 "gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1") This erratum was fixed in Rev 3.1.x. Signed-off-by: Atsushi Nemoto <nemoto@toshiba-tops.co.jp> Acked-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 04 Mar, 2016 2 commits
-
-
David S. Miller authored
Merge tag 'linux-can-fixes-for-4.5-20160304' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2016-03-04 this is a pull request for net/master. There is one patch from Ed Spiridonov, which increases the performance of the mcp251x SPI CAN driver, by avoiding to write to error flag register if it's unnecessary. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ed Spiridonov authored
Only two bits (RX0OVR and RX1OVR) are writable in EFLG, write is useless if these bits aren't set. Signed-off-by: Ed Spiridonov <edo.rus@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
- 03 Mar, 2016 13 commits
-
-
Venkat Duvvuru authored
When the interface is opened (in be_open()) the routine be_enable_if_filters() must be called to switch on the basic filtering capabilities of an interface that are not changed at run-time. These include the flags UNTAGGED, BROADCAST and PASS_L3L4_ERRORS. Other flags such as MULTICAST and PROMISC must be enabled later by be_set_rx_mode() based on the state in the netdev/adapter struct. be_enable_if_filters() routine is wrongly trying to enable MULTICAST flag without checking the current adapter state. This can cause the RX_FILTER cmds to the FW to fail. This patch fixes this problem by only enabling the basic filtering flags in be_enable_if_filters(). The VF must be able to issue RX_FILTER cmd with any filter flag, as long as the PF allowed those flags (if_cap_flags) in the iface it provisioned for the VF. This rule is applicable even when the VF doesn't have the FILTMGMT privilege. There is a bug in BE3 FW that wrongly fails RX_FILTER multicast programming cmds on VFs that don't have FILTMGMT privilege. This patch also helps in insulating the VF driver from be_open failures due to the FW bug. A fix for the BE3 FW issue will be available in versions >= 11.0.283.0 and 10.6.334.0 Reported-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Venkat Duvvuru <venkatkumar.duvvuru@avagotech.com> Signed-off-by: Sathya Perla <sathya.perla@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
We accidentally return IS_ERR(priv->base) which is 1 instead of PTR_ERR(priv->base) which is the error code. Fixes: 6c821bd9 ('net: Add MOXA ART SoCs ethernet driver') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nimrod Andy authored
Add a maintainer entry for FREESCALE FEC ethernet driver and add myself as a maintainer. Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Acked-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
When signalling to metadata consumers that the metadata_dst entry carries additional GBP extension data for vxlan (TUNNEL_VXLAN_OPT), the dst's vxlan_metadata information is populated, but options_len is left to zero. F.e. in ovs, ovs_flow_key_extract() checks for options_len before extracting the data through ip_tunnel_info_opts_get(). Geneve uses ip_tunnel_info_opts_set() helper in receive path, which sets options_len internally, vxlan however uses ip_tunnel_info_opts(), so when filling vxlan_metadata, we do need to update options_len. Fixes: 4c222798 ("ip-tunnel: Use API to access tunnel metadata options.") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
This change will also make Coverity happy by avoiding a theoretical NULL pointer dereference; yet another reason is to use the above helper function to tighten the code and make it more readable. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
This change will also make Coverity happy by avoiding a theoretical NULL pointer dereference; yet another reason is to use the above helper function to tighten the code and make it more readable. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thomas Falcon authored
The ibmvnic_capability struct was defined incorrectly. The last two elements of the struct are in the wrong order. In addition, the number element should be 64-bit. Byteswapping functions are updated as well. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
When ipv6_find_hdr is used to find a fragment header (caller specifies target NEXTHDR_FRAGMENT) we erronously return -ENOENT for all fragments with nonzero offset. Before commit 9195bb8e, when target was specified, we did not enter the exthdr walk loop as nexthdr == target so this used to work. Now we do (so we can skip empty route headers). When we then stumble upon a frag with nonzero frag_off we must return -ENOENT ("header not found") only if the caller did not specifically request NEXTHDR_FRAGMENT. This allows nfables exthdr expression to match ipv6 fragments, e.g. via nft add rule ip6 filter input frag frag-off gt 0 Fixes: 9195bb8e ("ipv6: improve ipv6_find_hdr() to skip empty routing headers") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
The MC74xx and EM74xx modules use different IDs by default, according to the Lenovo EM7455 driver for Windows. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Parthasarathy Bhuvaragan authored
reverts commit 94153e36 ("tipc: use existing sk_write_queue for outgoing packet chain") In Commit 94153e36, we assume that we fill & empty the socket's sk_write_queue within the same lock_sock() session. This is not true if the link is congested. During congestion, the socket lock is released while we wait for the congestion to cease. This implementation causes a nullptr exception, if the user space program has several threads accessing the same socket descriptor. Consider two threads of the same program performing the following: Thread1 Thread2 -------------------- ---------------------- Enter tipc_sendmsg() Enter tipc_sendmsg() lock_sock() lock_sock() Enter tipc_link_xmit(), ret=ELINKCONG spin on socket lock.. sk_wait_event() : release_sock() grab socket lock : Enter tipc_link_xmit(), ret=0 : release_sock() Wakeup after congestion lock_sock() skb = skb_peek(pktchain); !! TIPC_SKB_CB(skb)->wakeup_pending = tsk->link_cong; In this case, the second thread transmits the buffers belonging to both thread1 and thread2 successfully. When the first thread wakeup after the congestion it assumes that the pktchain is intact and operates on the skb's in it, which leads to the following exception: [2102.439969] BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0 [2102.440074] IP: [<ffffffffa005f330>] __tipc_link_xmit+0x2b0/0x4d0 [tipc] [2102.440074] PGD 3fa3f067 PUD 3fa6b067 PMD 0 [2102.440074] Oops: 0000 [#1] SMP [2102.440074] CPU: 2 PID: 244 Comm: sender Not tainted 3.12.28 #1 [2102.440074] RIP: 0010:[<ffffffffa005f330>] [<ffffffffa005f330>] __tipc_link_xmit+0x2b0/0x4d0 [tipc] [...] [2102.440074] Call Trace: [2102.440074] [<ffffffff8163f0b9>] ? schedule+0x29/0x70 [2102.440074] [<ffffffffa006a756>] ? tipc_node_unlock+0x46/0x170 [tipc] [2102.440074] [<ffffffffa005f761>] tipc_link_xmit+0x51/0xf0 [tipc] [2102.440074] [<ffffffffa006d8ae>] tipc_send_stream+0x11e/0x4f0 [tipc] [2102.440074] [<ffffffff8106b150>] ? __wake_up_sync+0x20/0x20 [2102.440074] [<ffffffffa006dc9c>] tipc_send_packet+0x1c/0x20 [tipc] [2102.440074] [<ffffffff81502478>] sock_sendmsg+0xa8/0xd0 [2102.440074] [<ffffffff81507895>] ? release_sock+0x145/0x170 [2102.440074] [<ffffffff815030d8>] ___sys_sendmsg+0x3d8/0x3e0 [2102.440074] [<ffffffff816426ae>] ? _raw_spin_unlock+0xe/0x10 [2102.440074] [<ffffffff81115c2a>] ? handle_mm_fault+0x6ca/0x9d0 [2102.440074] [<ffffffff8107dd65>] ? set_next_entity+0x85/0xa0 [2102.440074] [<ffffffff816426de>] ? _raw_spin_unlock_irq+0xe/0x20 [2102.440074] [<ffffffff8107463c>] ? finish_task_switch+0x5c/0xc0 [2102.440074] [<ffffffff8163ea8c>] ? __schedule+0x34c/0x950 [2102.440074] [<ffffffff81504e12>] __sys_sendmsg+0x42/0x80 [2102.440074] [<ffffffff81504e62>] SyS_sendmsg+0x12/0x20 [2102.440074] [<ffffffff8164aed2>] system_call_fastpath+0x16/0x1b In this commit, we maintain the skb list always in the stack. Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com> Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Benjamin Poirier authored
The current reserved_tailroom calculation fails to take hlen and tlen into account. skb: [__hlen__|__data____________|__tlen___|__extra__] ^ ^ head skb_end_offset In this representation, hlen + data + tlen is the size passed to alloc_skb. "extra" is the extra space made available in __alloc_skb because of rounding up by kmalloc. We can reorder the representation like so: [__hlen__|__data____________|__extra__|__tlen___] ^ ^ head skb_end_offset The maximum space available for ip headers and payload without fragmentation is min(mtu, data + extra). Therefore, reserved_tailroom = data + extra + tlen - min(mtu, data + extra) = skb_end_offset - hlen - min(mtu, skb_end_offset - hlen - tlen) = skb_tailroom - min(mtu, skb_tailroom - tlen) ; after skb_reserve(hlen) Compare the second line to the current expression: reserved_tailroom = skb_end_offset - min(mtu, skb_end_offset) and we can see that hlen and tlen are not taken into account. The min() in the third line can be expanded into: if mtu < skb_tailroom - tlen: reserved_tailroom = skb_tailroom - mtu else: reserved_tailroom = tlen Depending on hlen, tlen, mtu and the number of multicast address records, the current code may output skbs that have less tailroom than dev->needed_tailroom or it may output more skbs than needed because not all space available is used. Fixes: 4c672e4b ("ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs") Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Igal Liberman authored
Currently, in a case of error, dev_err is using fman->dev before its initialization and "(NULL device *)" is printed. This patch fixes this issue. Signed-off-by: Igal Liberman <igal.liberman@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gabriel Fernandez authored
This patch manages the case when you have an Ethernet MAC with a "fixed link", and not connected to a normal MDIO-managed PHY device. The test of phy_bus_name was not helpful because it was never affected and replaced by the mdio test node. Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 02 Mar, 2016 9 commits
-
-
David S. Miller authored
Lars Persson says: ==================== dwc_eth_qos: stability fixes and support for CMA This series has bug fixes for the dwc_eth_qos ethernet driver. Mainly two stability fixes for problems found by Rabin Vincent: - Successive starts and stops of the interface would trigger a DMA reset timeout. - A race condition in the TX DMA handling could trigger a netdev watchdog timeout. The memory allocation was improved to support use of the CMA as DMA allocator backend. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Persson authored
This reverts the changed init order from commit 3647bc35 ("dwc_eth_qos: Reset hardware before PHY start") and makes another fix for the race. It turned out that the reset state machine of the dwceqos hardware requires PHY clocks to be present in order to complete the reset cycle. To plug the race with the phy state machine we defer link speed setting until the hardware init has finished. Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rabin Vincent authored
Since debug is hardcoded to 3, the defaults in the DWCEQOS_MSG_DEFAULT macro are never used, which does not seem to be the intended behaviour here. Set debug to -1 like other drivers so that DWCEQOS_MSG_DEFAULT is actually used by default. Signed-off-by: Rabin Vincent <rabinv@axis.com> Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rabin Vincent authored
Since we are in non-atomic context here we can pass GFP_KERNEL to dma_alloc_coherent(). This enables use of the CMA. Signed-off-by: Rabin Vincent <rabinv@axis.com> Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Persson authored
To prepare for using the CMA, we can not be in atomic context when de-allocating DMA buffers. The tx lock was needed only to protect the hw reset against the xmit handler. Now we briefly grab the tx lock while stopping the queue to make sure no thread is inside or will enter the xmit handler. Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rabin Vincent authored
The xmit handler and the tx_reclaim tasklet had a race on the tx_free variable which could lead to a tx timeout if tx_free was updated after the tx complete interrupt. Signed-off-by: Rabin Vincent <rabinv@axis.com> Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Or Gerlitz says: ==================== Mellanox 10/40G mlx4 driver fixes for 4.5-rc6 This series contains two fixes for the SRIOV HW LAG that was introduced in 4.5-rc1 and one fix that allows to revoke the administrative MAC that was assigned to VF through the PF. The VF mac fix needs to go for stable too. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jack Morgenstein authored
The VF administrative mac addresses (stored in the PF driver) are initialized to zero when the PF driver starts up. These addresses may be modified in the PF driver through ndo calls initiated by iproute2 or libvirt. While we allow the PF/host to change the VF admin mac address from zero to a valid unicast mac, we do not allow restoring the VF admin mac to zero. We currently only allow changing this mac to a different unicast mac. This leads to problems when libvirt scripts are used to deal with VF mac addresses, and libvirt attempts to revoke the mac so this host will not use it anymore. Fix this by allowing resetting a VF administrative MAC back to zero. Fixes: 8f7ba3ca ('net/mlx4: Add set VF mac address support') Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Reported-by: Moshe Levi <moshele@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Moni Shoua authored
The limit of 63 is only for virtual functions while the actual enforcement was for VFs plus physical functions, fix that. Fixes: e57968a1 ('net/mlx4_core: Support the HA mode for SRIOV VFs too') Signed-off-by: Moni Shoua <monis@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-