- 14 May, 2020 40 commits
-
-
Jiri Benc authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a64b04d8 upstream. In ipgre mode (i.e. not gretap) with collect metadata flag set, the tunnel is incorrectly assumed to be mGRE in NBMA mode (see commit 6a5f44d7). This is not the case, we're controlling the encapsulation addresses by lwtunnel metadata. And anyway, assigning dev->header_ops in collect metadata mode does not make sense. Although it would be more user firendly to reject requests that specify both the collect metadata flag and a remote/local IP address, this would break current users of gretap or introduce ugly code and differences in handling ipgre and gretap configuration. Keep the current behavior of remote/local IP address being ignored in such case. v3: Back to v1, added explanation paragraph. v2: Reject configuration specifying both remote/local address and collect metadata flag. Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6517eb59 upstream. On 64bit kernels, device stats are 64bit wide, not 32bit. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Petri Gynther authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 7dd39913 upstream. skb_len needs to be skb_headlen(skb) in bcmgenet_xmit_single(). Fragmented skbs can have only Ethernet + IP + TCP headers (14+20+20=54 bytes) in the linear buffer, followed by the rest in fragments. Bumping skb_len to ETH_ZLEN would be incorrect for this case, as it would introduce garbage between TCP header and the fragment data. This also works with regular/non-fragmented small packets < ETH_ZLEN bytes. Successfully tested this on GENETv3 with 42-byte ARP frames. For testing, I used: ethtool -K eth0 tx-checksum-ipv4 off ethtool -K eth0 tx-checksum-ipv6 off echo 0 > /proc/sys/net/ipv4/tcp_timestamps Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
Petri Gynther <pgynther@google.com> Acked-by:
-
Hariprasad Shenai authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 8d09e6b8 upstream. The commit 637d3e99 ("cxgb4: Discard the packet if the length is greater than mtu") introduced a regression in the VLAN interface performance when Tx VLAN offload is disabled. Check if skb is tagged, regardless of whether it is hardware accelerated or not. Presently we were checking only for hardware acclereated one, which caused performance to drop to ~0.17Mbps on a 10GbE adapter for VLAN interface, when tx vlan offload is turned off using ethtool. The ethernet head length calculation was going wrong in this case, and driver ended up dropping packets. Fixes: 637d3e99 ("cxgb4: Discard the packet if the length is greater than mtu") Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
-
Simon Horman authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit bc7cc599 upstream. In the case of CHECKSUM_COMPLETE the skb checksum should be updated in {push,pop}_mpls() as they the type in the ethernet header. As suggested by Pravin Shelar. Cc: Pravin Shelar <pshelar@nicira.com> Fixes: 25cd9ba0 ("openvswitch: Add basic MPLS support to kernel") Signed-off-by:
Simon Horman <simon.horman@netronome.com> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
-
Peter Ujfalusi authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 4fa2d09c upstream. Due to changes in device and platform code drivers w/o probe will fail to load. This means that the devices for eDMA TPTCs are goign to be without driver and omap hwmod code will turn them off after the kernel finished loading: [ 3.015900] platform 49800000.tptc: omap_device_late_idle: enabled but no driver. Idling [ 3.024671] platform 49a00000.tptc: omap_device_late_idle: enabled but no driver. Idling This will prevent eDMA to work since the TPTCs are not enabled. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Fixes: 34635b1a ("dmaengine: edma: Add dummy driver skeleton for edma3-tptc") Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Tahsin Erdogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit bd9f55ea upstream. Commit d548b34b ("dm: reduce the queue delay used in dm_request_fn from 100ms to 10ms") always intended the value to be 10 msecs -- it just expressed it in jiffies because earlier commit 7eaceacc ("block: remove per-queue plugging") did. Signed-off-by:
Tahsin Erdogan <tahsin@google.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Fixes: d548b34b ("dm: reduce the queue delay used in dm_request_fn from 100ms to 10ms") Cc: stable@vger.kernel.org # 4.1+ -- stable@ backports must be applied to drivers/md/dm.c Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b3a834b1 upstream. When this_order variable in blk_mq_init_rq_map() becomes zero the code incorrectly decrements the variable and passes the result to order_to_size() helper causing undefined behaviour: UBSAN: Undefined behaviour in block/blk-mq.c:1459:27 shift exponent 4294967295 is too large for 32-bit type 'unsigned int' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc6-00072-g33656a1f #22 Fix the code by checking this_order variable for not having the zero value first. Reported-by:
Meelis Roos <mroos@linux.ee> Fixes: 320ae51f ("blk-mq: new multi-queue block IO queueing mechanism") Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Junxiao Bi authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a93a9983 upstream. Commit 4f656367 ("Move locks API users to locks_lock_inode_wait()") moved flock/posix lock identify code to locks_lock_inode_wait(), but missed to set fl_flags to FL_FLOCK which will cause kernel panic in locks_lock_inode_wait(). Fixes: 4f656367 ("Move locks API users to locks_lock_inode_wait()") Signed-off-by:
Junxiao Bi <junxiao.bi@oracle.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Vivien Didelot authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 65fa4027 upstream. Locking a port generates an hardware interrupt when a new SA address is received. This enables CPU directed learning, which is needed for 802.1X MAC authentication. To disable automatic learning on a port, the only configuration needed is to set its Port Association Vector to all zero. Clear PAV when SA learning should be disabled instead of locking a port. Fixes: 4c7ea3c0 ("net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports") Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
Viresh Kumar authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 68e80dae upstream. Earlier, when the struct freq-attr was used to represent governor attributes, the standard cpufreq show/store sysfs attribute callbacks were applied to the governor tunable attributes and they always acquire the policy->rwsem lock before carrying out the operation. That could have resulted in an ABBA deadlock if governor tunable attributes are removed under policy->rwsem while one of them is being accessed concurrently (if sysfs attributes removal wins the race, it will wait for the access to complete with policy->rwsem held while the attribute callback will block on policy->rwsem indefinitely). We attempted to address this issue by dropping policy->rwsem around governor tunable attributes removal (that is, around invocations of the ->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT) in cpufreq_set_policy(), but that opened up race conditions that had not been possible with policy->rwsem held all the time. The previous commit, "cpufreq: governor: New sysfs show/store callbacks for governor tunables", fixed the original ABBA deadlock by adding new governor specific show/store callbacks. We don't have to drop rwsem around invocations of governor event CPUFREQ_GOV_POLICY_EXIT anymore, and original fix can be reverted now. Fixes: 955ef483 (cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT) Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Reported-by:
Juri Lelli <juri.lelli@arm.com> Tested-by:
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Marcin Nowakowski authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f7a31b5e upstream. All performance counters on I6400 (odd and even) are capable of counting any of the available events, so drop current logic of using the extra bit to determine which counter to use. Signed-off-by:
Marcin Nowakowski <marcin.nowakowski@imgtec.com> Fixes: 4e88a862 ("MIPS: Add cases for CPU_I6400") Fixes: fd716fca ("MIPS: perf: Fix I6400 event numbers") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15991/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Tobias Jungel authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 414dd6fb upstream. The attribute IFLA_BOND_AD_ACTOR_SYSTEM is sent to user space having the length of sizeof(bond->params.ad_actor_system) which is 8 byte. This patch aligns the length to ETH_ALEN to have the same MAC address exposed as using sysfs. Fixes: f87fda00 ("bonding: prevent out of bound accesses") Signed-off-by:
Tobias Jungel <tobias.jungel@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 610e1ae9 upstream. The commit b56fa687 ("ALSA: fm801: detect FM-only card earlier") rearranged initialization calls, i.e. it makes snd_fm801_chip_init() to be called before we register interrupt handler and set PCI bus mastering. Somehow it prevents FM801-AU to work properly. Thus, partially revert initialization order changed by commit mentioned above. Fixes: b56fa687 ("ALSA: fm801: detect FM-only card earlier") Reported-by:
Émeric MASCHINO <emeric.maschino@gmail.com> Tested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Chuck Lever authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d698c4a0 upstream. The backchannel code uses rpcrdma_recv_buffer_put to add new reps to the free rep list. This also decrements rb_recv_count, which spoofs the receive overrun logic in rpcrdma_buffer_get_rep. Commit 9b06688b ("xprtrdma: Fix additional uses of spin_lock_irqsave(rb_lock)") replaced the original open-coded list_add with a call to rpcrdma_recv_buffer_put(), but then a year later, commit 05c97466 ("xprtrdma: Fix receive buffer accounting") added rep accounting to rpcrdma_recv_buffer_put. It was an oversight to let the backchannel continue to use this function. The fix this, let's combine the "add to free list" logic with rpcrdma_create_rep. Also, do not allocate RPCRDMA_MAX_BC_REQUESTS rpcrdma_reps in rpcrdma_buffer_create and then allocate additional rpcrdma_reps in rpcrdma_bc_setup_reps. Allocating the extra reps during backchannel set-up is sufficient. Fixes: 05c97466 ("xprtrdma: Fix receive buffer accounting") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 8cf699ec upstream. Disable BH around the call to napi_schedule() to avoid following warning [ 52.095499] NOHZ: local_softirq_pending 08 [ 52.421291] NOHZ: local_softirq_pending 08 [ 52.608313] NOHZ: local_softirq_pending 08 Fixes: 8d59de8f ("net/mlx4_en: Process all completions in RX rings after port goes up") Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
David Ahern authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit e0a31262 upstream. Hendrik reported routes in the main table using source address are not removed when the address is removed. The problem is that fib_sync_down_addr does not account for devices in the default VRF which are associated with the main table. Fix by updating the table id reference. Fixes: 5a56a0b3 ("net: Don't delete routes in different VRFs") Reported-by:
Hendrik Donner <hd@os-cillation.de> Signed-off-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Nicolas Dichtel authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 63c43787 upstream. Since commit 1625f452, vti6 is broken, all input packets are dropped (LINUX_MIB_XFRMINNOSTATES is incremented). XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip6 is set by vti6_rcv() before calling xfrm6_rcv()/xfrm6_rcv_spi(), thus we cannot set to NULL that value in xfrm6_rcv_spi(). A new function xfrm6_rcv_tnl() that enables to pass a value to xfrm6_rcv_spi() is added, so that xfrm6_rcv() is not touched (this function is used in several handlers). CC: Alexey Kodanev <alexey.kodanev@oracle.com> Fixes: 1625f452 ("net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key") Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Mark Tomlinson authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 5a56a0b3 upstream. When deleting an IP address from an interface, there is a clean-up of routes which refer to this local address. However, there was no check to see that the VRF matched. This meant that deletion wasn't confined to the VRF it should have been. To solve this, a new field has been added to fib_info to hold a table id. When removing fib entries corresponding to a local ip address, this table id is also used in the comparison. The table id is populated when the fib_info is created. This was already done in some places, but not in ip_rt_ioctl(). This has now been fixed. Fixes: 021dd3b8 ("net: Add routes to the table associated with the device") Acked-by:
David Ahern <dsa@cumulusnetworks.com> Tested-by:
Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Signed-off-by:
-
David Ahern authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9ab179d8 upstream. Vivek reported a kernel exception deleting a VRF with an active connection through it. The root cause is that the socket has a cached reference to a dst that is destroyed. Converting the dst_destroy to dst_release and letting proper reference counting kick in does not work as the dst has a reference to the device which needs to be released as well. I talked to Hannes about this at netdev and he pointed out the ipv4 and ipv6 dst handling has dst_ifdown for just this scenario. Rather than continuing with the reinvented dst wheel in VRF just remove it and leverage the ipv4 and ipv6 versions. Fixes: 193125db ("net: Introduce VRF device driver") Fixes: 35402e31 ("net: Add IPv6 support to VRF device") Signed-off-by:
-
Marcin Niestroj authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 36276129 upstream. This bug leads to: [ 1.906411] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 1.914878] pgd = c0004000 [ 1.917786] [0000000c] *pgd=00000000 [ 1.921536] Internal error: Oops: 5 [#1] SMP ARM [ 1.926357] Modules linked in: [ 1.929556] CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 4.4.5 #18 [ 1.936006] Hardware name: Generic AM33XX (Flattened Device Tree) [ 1.942383] Workqueue: events power_supply_changed_work [ 1.947842] task: de2c41c0 ti: de2c8000 task.ti: de2c8000 [ 1.953483] PC is at tps65217_ac_get_property+0x14/0x28 [ 1.958937] LR is at tps65217_ac_get_property+0x10/0x28 Driver was trying to use drv_data in property get handler. However drv_data was not set, so it caused NULL pointer dereference. This patch properly sets drv_data during probe by power_supply_config parameter, so the property get handler works as desired. Signed-off-by:
Marcin Niestroj <m.niestroj@grinn-global.com> Fixes: 3636859b ("power_supply: Add support for tps65217-charger") Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Liu Xiang authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 265b6049 upstream. Currently in bq27541 driver, the average power register address is incorrectly set to 0x76, which would result in an error: bq27xxx-battery 2-0055: error reading average power register 10: -11 According to the bq27541 datasheet, fix this problem by setting the average power register address to 0x24. Fixes: d74534c2 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices") Signed-off-by:
Liu Xiang <liu.xiang6@zte.com.cn> Acked-by:
Andrew F. Davis <afd@ti.com> Signed-off-by:
-
Sasha Levin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6b9140f3 upstream. Writing 0 length data into test_power makes it access an invalid array location and kill the system. Fixes: f17ef9b2 ("power: Make test_power driver more dynamic.") Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
H. Nikolaus Schaller authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 099867a1 upstream. bug: according to data sheet some register numbers are wrong. tested: no Fixes: d74534c2 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices") Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Acked-by:
-
H. Nikolaus Schaller authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 549d7b31 upstream. bug: the driver reports funny capacity values: root@letux:/sys/class/power_supply/bq27000-battery# cat uevent POWER_SUPPLY_NAME=bq27000-battery POWER_SUPPLY_STATUS=Charging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_VOLTAGE_NOW=3702000 POWER_SUPPLY_CURRENT_NOW=-464635 POWER_SUPPLY_CAPACITY=1536 <- over 100% is magic POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_TEMP=311 POWER_SUPPLY_TIME_TO_FULL_NOW=10440 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CHARGE_FULL=805450 POWER_SUPPLY_CHARGE_NOW=1068 POWER_SUPPLY_CHARGE_FULL_DESIGN=8844998 <- battery has just 1200 mAh POWER_SUPPLY_CYCLE_COUNT=21 POWER_SUPPLY_ENERGY_NOW=0 POWER_SUPPLY_POWER_AVG=0 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_MANUFACTURER=Texas Instruments reason: the state of charge and the design capacity register are single byte only. The design capacity returns the higer order byte. tested: GTA04 with Openmoko/FIC HF08x battery (using hdq) Fixes: d74534c2 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices") Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
-
Peter Zijlstra authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 2e636d5e upstream. Vikram reported that his ARM64 compiler managed to 'optimize' away the preempt_count manipulations in code like: preempt_enable_no_resched(); put_user(); preempt_disable(); Irrespective of that fact that that is horrible code that should be fixed for many reasons, it does highlight a deficiency in the generic preempt_count manipulators. As it is never right to combine/elide preempt_count manipulations like this. Therefore sprinkle some volatile in the two generic accessors to ensure the compiler is aware of the fact that the preempt_count is observed outside of the regular program-order view and thus cannot be optimized away like this. x86; the only arch not using the generic code is not affected as we do all this in asm in order to use the segment base per-cpu stuff. Reported-by:
Vikram Mulukutla <markivx@codeaurora.org> Tested-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: a7878709 ("sched, arch: Create asm/preempt.h") Link: http://lkml.kernel.org/r/20160516131751.GH3205@twins.programming.kicks-ass.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 695b4ec0 upstream. When fq is used on 32bit kernels, we need to lock the qdisc before copying 64bit fields. Otherwise "tc -s qdisc ..." might report bogus values. Fixes: afe4fd06 ("pkt_sched: fq: Fair Queue packet scheduler") Signed-off-by:
-
Hadar Hen Zion authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 339ba878 upstream. The current flower implementation checks the mask range and set all the keys included in that range as "used_keys", even if a specific key in the range has a zero mask. This behavior can cause a false positive return value of dissector_uses_key function and unnecessary dissection in __skb_flow_dissect. This patch checks explicitly the mask of each key and "used_keys" will be set accordingly. Fixes: 77b9900e ('tc: introduce Flower classifier') Signed-off-by:
Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Peter Zijlstra authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ea1dc6fc upstream. Commit: fde7d22e ("sched/fair: Fix overly small weight for interactive group entities") did something non-obvious but also did it buggy yet latent. The problem was exposed for real by a later commit in the v4.7 merge window: 2159197d ("sched/core: Enable increased load resolution on 64-bit kernels") ... after which tg->load_avg and cfs_rq->load.weight had different units (10 bit fixed point and 20 bit fixed point resp.). Add a comment to explain the use of cfs_rq->load.weight over the 'natural' cfs_rq->avg.load_avg and add scale_load_down() to correct for the difference in unit. Since this is (now, as per a previous commit) the only user of calc_tg_weight(), collapse it. The effects of this bug should be randomly inconsistent SMP-balancing of cgroups workloads. Reported-by:
Jirka Hladky <jhladky@redhat.com> Signed-off-by:
-
Elad Raz authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 7fb6a36b upstream. When creating an ethernet port fails, we must move the port to disable, otherwise putting the port in switch partition 0 (ETH) or 1 (IB) will always fails. Fixes: 31557f0f ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support") Signed-off-by:
Elad Raz <eladr@mellanox.com> Reviewed-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Yotam Gigi authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 251d41c5 upstream. In order to specify that the mlxsw switchx2 driver needs additional headroom for packets, there have been use of the hard_header_len field of the netdevice struct. This commit changes that to use needed_headroom instead, as this is the correct way to do that. Fixes: 31557f0f ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support") Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Acked-by:
-
Moshe Shemesh authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c9cc599a upstream. Separate QUERY_FUNC_CAP flags0 from QUERY_FUNC_CAP flags, as 'flags' is already used for another set of flags in FUNC CAP, while phv bit should be part of a different set of flags. Remove QUERY_FUNC_CAP port_flags field, as it is not in use. Fixes: 77fc29c4 ('net/mlx4_core: Preparations for 802.1ad VLAN support') Fixes: 5cc914f1 ('mlx4_core: Added FW commands and their wrappers for supporting SRIOV') Signed-off-by:
Moshe Shemesh <moshe@mellanox.com> Signed-off-by:
-
Jack Morgenstein authored
net/mlx4: Fix uninitialized fields in rule when adding promiscuous mode to device managed flow steering BugLink: https://bugs.launchpad.net/bugs/1878232 commit 44b911e7 upstream. In procedure mlx4_flow_steer_promisc_add(), several fields were left uninitialized in the rule structure. Correctly initialize these fields. Fixes: 592e49dd ("net/mlx4: Implement promiscuous mode with device managed flow-steering") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d2582a03 upstream. mlx4_en_DUMP_ETH_STATS took the *counter mutex* and then called the FW command, with WRAPPED attribute. As a result, the fw command is wrapped on the Hypervisor when it calls mlx4_en_DUMP_ETH_STATS. The FW command wrapper flow on the hypervisor takes the *slave_cmd_mutex* during processing. At the same time, a VF could be in the process of coming up, and could call mlx4_QUERY_FUNC_CAP. On the hypervisor, the command flow takes the *slave_cmd_mutex*, then executes mlx4_QUERY_FUNC_CAP_wrapper. mlx4_QUERY_FUNC_CAP wrapper calls mlx4_get_default_counter_index(), which takes the *counter mutex*. DEADLOCK. The fix is that the DUMP_ETH_STATS fw command should be called with the NATIVE attribute, so that on the hypervisor, this command does not enter the wrapper flow. Since the Hypervisor no longer goes through the wrapper code, we also simply return 0 in mlx4_DUMP_ETH_STATS_wrapper (i.e.the function succeeds, but the returned data will be all zeroes). No need to test if it is the Hypervisor going through the wrapper. Fixes: f9baff50 ("mlx4_core: Add "native" argument to mlx4_cmd ...") Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 81d18419 upstream. In the Hypervisor, there are several FW commands which are invoked before the comm channel is initialized (in mlx4_multi_func_init). These include MOD_STAT_CONFIG, QUERY_DEV_CAP, INIT_HCA, and others. If any of these commands fails, say with a timeout, the Hypervisor driver enters the internal error reset flow. In this flow, the driver attempts to notify all slaves via the comm channel that an internal error has occurred. Since the comm channel has not yet been initialized (i.e., mapped via ioremap), this will cause dereferencing a NULL pointer. To fix this, do not access the comm channel in the internal error flow if it has not yet been initialized. Fixes: 55ad3592 ("net/mlx4_core: Enable device recovery flow with SRIOV") Fixes: ab9c17a0 ("mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet") Signed-off-by:
-
Erez Shitrit authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 8d59de8f upstream. Currently there is a race between incoming traffic and initialization flow. HW is able to receive the packets after INIT_PORT is done and unicast steering is configured. Before we set priv->port_up NAPI is not scheduled and receive queues become full. Therefore we never get new interrupts about the completions. This issue could happen if running heavy traffic during bringing port up. The resolution is to schedule NAPI once port_up is set. If receive queues were full this will process all cqes and release them. Fixes: c27a02cd ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC") Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit aa0c08fe upstream. The resource type enum in the resource tracker was incorrect. RES_EQ was put in the position of RES_NPORT_ID (a FC resource). Since the remaining resources maintain their current values, and RES_EQ is not passed from slaves to the hypervisor in any FW command, this change affects only the hypervisor. Therefore, there is no backwards-compatibility issue. Fixes: 623ed84b ("mlx4_core: initial header-file changes for SRIOV support") Signed-off-by:
-
Alex Vesker authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9b022a6e upstream. Verify that the device state is registered before un-registering it. This check is required to prevent an OOPS on flows that do re-registration of the device and its previous state was unregistered. Fixes: 225c7b1f ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters") Signed-off-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
-
Kamal Heib authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 93c098af upstream. Modify mlx4_en_vlan_rx_[add/kill]_vid to return error value in case of failure. Fixes: 8e586137 ('net: make vlan ndo_vlan_rx_[add/kill]_vid return error value') Signed-off-by:
Kamal Heib <kamalh@mellanox.com> Signed-off-by:
-
Tariq Toukan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 2bb07e15 upstream. Prevent using uninitialized or negative index when handling steering entries. Fixes: b12d93d6 ('mlx4: Add support for promiscuous mode in the new steering model.') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
