aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-01-27s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidatedTony Krowiak1-21/+28
The vfio_ap device driver registers a group notifier with VFIO when the file descriptor for a VFIO mediated device for a KVM guest is opened to receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM event). When the KVM pointer is set, the vfio_ap driver takes the following actions: 1. Stashes the KVM pointer in the vfio_ap_mdev struct that holds the state of the mediated device. 2. Calls the kvm_get_kvm() function to increment its reference counter. 3. Sets the function pointer to the function that handles interception of the instruction that enables/disables interrupt processing. 4. Sets the masks in the KVM guest's CRYCB to pass AP resources through to the guest. In order to avoid memory leaks, when the notifier is called to receive notification that the KVM pointer has been set to NULL, the vfio_ap device driver should reverse the actions taken when the KVM pointer was set. Fixes: 258287c994de ("s390: vfio-ap: implement mediated device open callback") Signed-off-by: Tony Krowiak <[email protected]> Reviewed-by: Halil Pasic <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-01-27can: dev: prevent potential information leak in can_fill_info()Dan Carpenter1-1/+1
The "bec" struct isn't necessarily always initialized. For example, the mcp251xfd_get_berr_counter() function doesn't initialize anything if the interface is down. Fixes: 52c793f24054 ("can: netlink support for bus-error reporting and counters") Link: https://lore.kernel.org/r/YAkaRdRJncsJO8Ve@mwanda Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-01-27rtc: mc146818: Detect and handle broken RTCsThomas Gleixner2-0/+15
The recent fix for handling the UIP bit unearthed another issue in the RTC code. If the RTC is advertised but the readout is straight 0xFF because it's not available, the old code just proceeded with crappy values, but the new code hangs because it waits for the UIP bit to become low. Add a sanity check in the RTC CMOS probe function which reads the RTC_VALID register (Register D) which should have bit 0-6 cleared. If that's not the case then fail to register the CMOS. Add the same check to mc146818_get_time(), warn once when the condition is true and invalidate the rtc_time data. Reported-by: Mickaël Salaün <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Mickaël Salaün <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-27xen: Fix XenStore initialisation for XS_LOCALDavid Woodhouse1-0/+31
In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI") I reworked the triggering of xenbus_probe(). I tried to simplify things by taking out the workqueue based startup triggered from wake_waiting(); the somewhat poorly named xenbus IRQ handler. I missed the fact that in the XS_LOCAL case (Dom0 starting its own xenstored or xenstore-stubdom, which happens after the kernel is booted completely), that IRQ-based trigger is still actually needed. So... put it back, except more cleanly. By just spawning a xenbus_probe thread which waits on xb_waitq and runs the probe the first time it gets woken, just as the workqueue-based hack did. This is actually a nicer approach for *all* the back ends with different interrupt methods, and we can switch them all over to that without the complex conditions for when to trigger it. But not in -rc6. This is the minimal fix for the regression, although it's a step in the right direction instead of doing a partial revert and actually putting the workqueue back. It's also simpler than the workqueue. Fixes: 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI") Reported-by: Juergen Gross <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-01-26io_uring: fix wqe->lock/completion_lock deadlockPavel Begunkov1-8/+2
Joseph reports following deadlock: CPU0: ... io_kill_linked_timeout // &ctx->completion_lock io_commit_cqring __io_queue_deferred __io_queue_async_work io_wq_enqueue io_wqe_enqueue // &wqe->lock CPU1: ... __io_uring_files_cancel io_wq_cancel_cb io_wqe_cancel_pending_work // &wqe->lock io_cancel_task_cb // &ctx->completion_lock Only __io_queue_deferred() calls queue_async_work() while holding ctx->completion_lock, enqueue drained requests via io_req_task_queue() instead. Cc: [email protected] # 5.9+ Reported-by: Joseph Qi <[email protected]> Tested-by: Joseph Qi <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-01-26Merge branch 'net-fec-fix-temporary-rmii-clock-reset-on-link-up'Jakub Kicinski2-2/+9
Laurent Badel says: ==================== net: fec: Fix temporary RMII clock reset on link up v2: fixed a compilation warning The FEC drivers performs a "hardware reset" of the MAC module when the link is reported to be up. This causes a short glitch in the RMII clock due to the hardware reset clearing the receive control register which controls the MII mode. It seems that some link partners do not tolerate this glitch, and invalidate the link, which leads to a never-ending loop of negotiation-link up-link down events. This was observed with the iMX28 Soc and LAN8720/LAN8742 PHYs, with two Intel adapters I218-LM and X722-DA2 as link partners, though a number of other link partners do not seem to mind the clock glitch. Changing the hardware reset to a software reset (clearing bit 1 of the ECR register) cured the issue. Attempts to optimize fec_restart() in order to minimize the duration of the glitch were unsuccessful. Furthermore manually producing the glitch by setting MII mode and then back to RMII in two consecutive instructions, resulting in a clock glitch <10us in duration, was enough to cause the partner to invalidate the link. This strongly suggests that the root cause of the link being dropped is indeed the change in clock frequency. In an effort to minimize changes to driver, the patch proposes to use soft reset only for tested SoCs (iMX28) and only if the link is up. This preserves hardware reset in other situations, which might be required for proper setup of the MAC. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26net: fec: Fix temporary RMII clock reset on link upLaurent Badel2-2/+9
fec_restart() does a hard reset of the MAC module when the link status changes to up. This temporarily resets the R_CNTRL register which controls the MII mode of the ENET_OUT clock. In the case of RMII, the clock frequency momentarily drops from 50MHz to 25MHz until the register is reconfigured. Some link partners do not tolerate this glitch and invalidate the link causing failure to establish a stable link when using PHY polling mode. Since as per IEEE802.3 the criteria for link validity are PHY-specific, what the partner should tolerate cannot be assumed, so avoid resetting the MII clock by using software reset instead of hardware reset when the link is up. This is generally relevant only if the SoC provides the clock to an external PHY and the PHY is configured for RMII. Signed-off-by: Laurent Badel <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26net: lapb: Add locking to the lapb moduleXie He3-20/+82
In the lapb module, the timers may run concurrently with other code in this module, and there is currently no locking to prevent the code from racing on "struct lapb_cb". This patch adds locking to prevent racing. 1. Add "spinlock_t lock" to "struct lapb_cb"; Add "spin_lock_bh" and "spin_unlock_bh" to APIs, timer functions and notifier functions. 2. Add "bool t1timer_stop, t2timer_stop" to "struct lapb_cb" to make us able to ask running timers to abort; Modify "lapb_stop_t1timer" and "lapb_stop_t2timer" to make them able to abort running timers; Modify "lapb_t2timer_expiry" and "lapb_t1timer_expiry" to make them abort after they are stopped by "lapb_stop_t1timer", "lapb_stop_t2timer", and "lapb_start_t1timer", "lapb_start_t2timer". 3. Let lapb_unregister wait for other API functions and running timers to stop. 4. The lapb_device_event function calls lapb_disconnect_request. In order to avoid trying to hold the lock twice, add a new function named "__lapb_disconnect_request" which assumes the lock is held, and make it called by lapb_disconnect_request and lapb_device_event. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Martin Schiller <[email protected]> Signed-off-by: Xie He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26ARM: zImage: atags_to_fdt: Fix node names on added root nodesRob Herring1-1/+2
Commit 7536c7e03e74 ("of/fdt: Remove redundant kbasename function call") exposed a bug creating DT nodes in the ATAGS to DT fixup code. Non-existent nodes would mistaken get created with a leading '/'. The problem was fdt_path_offset() takes a full path while creating a node with fdt_add_subnode() takes just the basename. Since this we only add root child nodes, we can just skip over the '/'. Fixes: 7536c7e03e74 ("of/fdt: Remove redundant kbasename function call") Reported-by: Chris Packham <[email protected]> Cc: Qi Zheng <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Rob Herring <[email protected]> Tested-by: Chris Packham <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-26team: protect features update by RCU to avoid deadlockIvan Vecera1-3/+3
Function __team_compute_features() is protected by team->lock mutex when it is called from team_compute_features() used when features of an underlying device is changed. This causes a deadlock when NETDEV_FEAT_CHANGE notifier for underlying device is fired due to change propagated from team driver (e.g. MTU change). It's because callbacks like team_change_mtu() or team_vlan_rx_{add,del}_vid() protect their port list traversal by team->lock mutex. Example (r8169 case where this driver disables TSO for certain MTU values): ... [ 6391.348202] __mutex_lock.isra.6+0x2d0/0x4a0 [ 6391.358602] team_device_event+0x9d/0x160 [team] [ 6391.363756] notifier_call_chain+0x47/0x70 [ 6391.368329] netdev_update_features+0x56/0x60 [ 6391.373207] rtl8169_change_mtu+0x14/0x50 [r8169] [ 6391.378457] dev_set_mtu_ext+0xe1/0x1d0 [ 6391.387022] dev_set_mtu+0x52/0x90 [ 6391.390820] team_change_mtu+0x64/0xf0 [team] [ 6391.395683] dev_set_mtu_ext+0xe1/0x1d0 [ 6391.399963] do_setlink+0x231/0xf50 ... In fact team_compute_features() called from team_device_event() does not need to be protected by team->lock mutex and rcu_read_lock() is sufficient there for port list traversal. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Cc: Saeed Mahameed <[email protected]> Signed-off-by: Ivan Vecera <[email protected]> Reviewed-by: Cong Wang <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26MAINTAINERS: add David Ahern to IPv4/IPv6 maintainersJakub Kicinski1-0/+1
David has been the de-facto maintainer for much of the IP code for the last couple of years, let's make it official. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26net/mlx5: CT: Fix incorrect removal of tuple_nat_node from nat rhashtablePaul Blakey1-7/+13
If a non nat tuple entry is inserted just to the regular tuples rhashtable (ct_tuples_ht) and not to natted tuples rhashtable (ct_nat_tuples_ht). Commit bc562be9674b ("net/mlx5e: CT: Save ct entries tuples in hashtables") mixed up the return labels and names sot that on cleanup or failure we still try to remove for the natted tuples rhashtable. Fix that by correctly checking if a natted tuples insertion before removing it. While here make it more readable. Fixes: bc562be9674b ("net/mlx5e: CT: Save ct entries tuples in hashtables") Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Paul Blakey <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Revert parameters on errors when changing MTU and LRO state ↵Maxim Mikityanskiy1-9/+21
without reset Sometimes, channel params are changed without recreating the channels. It happens in two basic cases: when the channels are closed, and when the parameter being changed doesn't affect how channels are configured. Such changes invoke a hardware command that might fail. The whole operation should be reverted in such cases, but the code that restores the parameters' values in the driver was missing. This commit adds this handling. Fixes: 2e20a151205b ("net/mlx5e: Fail safe mtu and lro setting") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Revert parameters on errors when changing trust state without resetMaxim Mikityanskiy1-5/+8
Trust state may be changed without recreating the channels. It happens when the channels are closed, and when channel parameters (min inline mode) stay the same after changing the trust state. Changing the trust state is a hardware command that may fail. The current code didn't restore the channel parameters to their old values if an error happened and the channels were closed. This commit adds handling for this case. Fixes: 6e0504c69811 ("net/mlx5e: Change inline mode correctly when changing trust state") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Correctly handle changing the number of queues when the interface ↵Maxim Mikityanskiy2-1/+14
is down This commit addresses two issues related to changing the number of queues when the channels are closed: 1. Missing call to mlx5e_num_channels_changed to update real_num_tx_queues when the number of TCs is changed. 2. When mlx5e_num_channels_changed returns an error, the channel parameters must be reverted. Two Fixes: tags correspond to the first commits where these two issues were introduced. Fixes: 3909a12e7913 ("net/mlx5e: Fix configuration of XPS cpumasks and netdev queues in corner cases") Fixes: fa3748775b92 ("net/mlx5e: Handle errors from netif_set_real_num_{tx,rx}_queues") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Fix CT rule + encap slow path offload and deletionPaul Blakey1-0/+7
Currently, if a neighbour isn't valid when offloading tunnel encap rules, we offload the original match and replace the original action with "goto slow path" action. For this we use a temporary flow attribute based on the original flow attribute and then change the action. Flow flags, which among those is the CT flag, are still shared for the slow path rule offload, so we end up parsing this flow as a CT + goto slow path rule. Besides being unnecessary, CT action offload saves extra information in the passed flow attribute, such as created ct_flow and mod_hdr, which is lost onces the temporary flow attribute is freed. When a neigh is updated and is valid, we offload the original CT rule with original CT action, which again creates a ct_flow and mod_hdr and saves it in the flow's original attribute. Then we delete the slow path rule with a temporary flow attribute based on original updated flow attribute, and we free the relevant ct_flow and mod_hdr. Then when tc deletes this flow, we try to free the ct_flow and mod_hdr on the flow's attribute again. To fix the issue, skip all furture proccesing (CT/Sample/Split rules) in offload/unoffload of slow path rules. Call trace: [ 758.850525] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000218 [ 758.952987] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 758.964170] Modules linked in: act_csum(E) act_pedit(E) act_tunnel_key(E) act_ct(E) nf_flow_table(E) xt_nat(E) ip6table_filter(E) ip6table_nat(E) xt_comment(E) ip6_tables(E) xt_conntrack(E) xt_MASQUERADE(E) nf_conntrack_netlink(E) xt_addrtype(E) iptable_filter(E) iptable_nat(E) bpfilter(E) br_netfilter(E) bridge(E) stp(E) llc(E) xfrm_user(E) overlay(E) act_mirred(E) act_skbedit(E) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) esp6_offload(E) esp6(E) esp4_offload(E) esp4(E) xfrm_algo(E) mlx5_ib(OE) ib_uverbs(OE) geneve(E) ip6_udp_tunnel(E) udp_tunnel(E) nfnetlink_cttimeout(E) nfnetlink(E) mlx5_core(OE) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_conncount(E) nf_nat(E) mlxfw(OE) psample(E) nf_conntrack(E) nf_defrag_ipv4(E) vfio_mdev(E) mdev(E) ib_core(OE) mlx_compat(OE) crct10dif_ce(E) uio_pdrv_genirq(E) uio(E) i2c_mlx(E) mlxbf_pmc(E) sbsa_gwdt(E) mlxbf_gige(E) gpio_mlxbf2(E) mlxbf_pka(E) mlx_trio(E) mlx_bootctl(E) bluefield_edac(E) knem(O) [ 758.964225] ip_tables(E) mlxbf_tmfifo(E) ipv6(E) crc_ccitt(E) nf_defrag_ipv6(E) [ 759.154186] CPU: 5 PID: 122 Comm: kworker/u16:1 Tainted: G OE 5.4.60-mlnx.52.gde81e85 #1 [ 759.172870] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.5.0-2-gc1b5d64 Jan 4 2021 [ 759.195466] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core] [ 759.207344] pstate: a0000005 (NzCv daif -PAN -UAO) [ 759.217003] pc : mlx5_del_flow_rules+0x5c/0x160 [mlx5_core] [ 759.228229] lr : mlx5_del_flow_rules+0x34/0x160 [mlx5_core] [ 759.405858] Call trace: [ 759.410804] mlx5_del_flow_rules+0x5c/0x160 [mlx5_core] [ 759.421337] __mlx5_eswitch_del_rule.isra.43+0x5c/0x1c8 [mlx5_core] [ 759.433963] mlx5_eswitch_del_offloaded_rule_ct+0x34/0x40 [mlx5_core] [ 759.446942] mlx5_tc_rule_delete_ct+0x68/0x74 [mlx5_core] [ 759.457821] mlx5_tc_ct_delete_flow+0x160/0x21c [mlx5_core] [ 759.469051] mlx5e_tc_unoffload_fdb_rules+0x158/0x168 [mlx5_core] [ 759.481325] mlx5e_tc_encap_flows_del+0x140/0x26c [mlx5_core] [ 759.492901] mlx5e_rep_update_flows+0x11c/0x1ec [mlx5_core] [ 759.504127] mlx5e_rep_neigh_update+0x160/0x200 [mlx5_core] [ 759.515314] process_one_work+0x178/0x400 [ 759.523350] worker_thread+0x58/0x3e8 [ 759.530685] kthread+0x100/0x12c [ 759.537152] ret_from_fork+0x10/0x18 [ 759.544320] Code: 97ffef55 51000673 3100067f 54ffff41 (b9421ab3) [ 759.556548] ---[ end trace fab818bb1085832d ]--- Fixes: 4c3844d9e97e ("net/mlx5e: CT: Introduce connection tracking") Signed-off-by: Paul Blakey <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Reviewed-by: Vlad Buslov <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Disable hw-tc-offload when MLX5_CLS_ACT config is disabledMaor Dickman2-1/+3
The cited commit introduce new CONFIG_MLX5_CLS_ACT kconfig variable to control compilation of TC hardware offloads implementation. When this configuration is disabled the driver is still wrongly reports in ethtool that hw-tc-offload is supported. Fixed by reporting hw-tc-offload is supported only when CONFIG_MLX5_CLS_ACT is enabled. Fixes: d956873f908c ("net/mlx5e: Introduce kconfig var for TC support") Signed-off-by: Maor Dickman <[email protected]> Reviewed-by: Vlad Buslov <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5: Maintain separate page trees for ECPF and PF functionsDaniel Jurgens1-24/+34
Pages for the host PF and ECPF were stored in the same tree, so the ECPF pages were being freed along with the host PF's when the host driver unloaded. Combine the function ID and ECPF flag to use as an index into the x-array containing the trees to get a different tree for the host PF and ECPF. Fixes: c6168161f693 ("net/mlx5: Add support for release all pages event") Signed-off-by: Daniel Jurgens <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Fix IPSEC statsMaxim Mikityanskiy1-2/+2
When IPSEC offload isn't active, the number of stats is not zero, but the strings are not filled, leading to exposing stats with empty names. Fix this by using the same condition for NUM_STATS and FILL_STRS. Fixes: 0aab3e1b04ae ("net/mlx5e: IPSec, Expose IPsec HW stat only for supporting HW") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Raed Salem <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Reduce tc unsupported key print levelMaor Dickman1-2/+2
"Unsupported key used:" appears in kernel log when flows with unsupported key are used, arp fields for example. OpenVSwitch was changed to match on arp fields by default that caused this warning to appear in kernel log for every arp rule, which can be a lot. Fix by lowering print level from warning to debug. Fixes: e3a2b7ed018e ("net/mlx5e: Support offload cls_flower with drop action") Signed-off-by: Maor Dickman <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Reviewed-by: Saeed Mahameed <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: free page before returnPan Bian1-1/+1
Instead of directly return, goto the error handling label to free allocated page. Fixes: 5f29458b77d5 ("net/mlx5e: Support dump callback in TX reporter") Signed-off-by: Pan Bian <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: E-switch, Fix rate calculation for overflowParav Pandit1-3/+8
rate_bytes_ps is a 64-bit field. It passed as 32-bit field to apply_police_params(). Due to this when police rate is higher than 4Gbps, 32-bit calculation ignores the carry. This results in incorrect rate configurationn the device. Fix it by performing 64-bit calculation. Fixes: fcb64c0f5640 ("net/mlx5: E-Switch, add ingress rate support") Signed-off-by: Parav Pandit <[email protected]> Reviewed-by: Eli Cohen <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5: Fix memory leak on flow table creation error flowRoi Dayan1-0/+1
When we create the ft object we also init rhltable in ft->fgs_hash. So in error flow before kfree of ft we need to destroy that rhltable. Fixes: 693c6883bbc4 ("net/mlx5: Add hash table for flow groups in flow table") Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Maor Dickman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26Merge tag 'mac80211-for-net-2021-01-26' of ↵Jakub Kicinski7-18/+26
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== A couple of fixes: * fix 160 MHz channel switch in mac80211 * fix a staging driver to not deadlock due to some recent cfg80211 changes * fix NULL-ptr deref if cfg80211 returns -EINPROGRESS to wext (syzbot) * pause TX in mac80211 in type change to prevent crashes (syzbot) * tag 'mac80211-for-net-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211: staging: rtl8723bs: fix wireless regulatory API misuse mac80211: pause TX while changing interface type wext: fix NULL-ptr-dereference with cfg80211's lack of commit() mac80211: 160MHz with extended NSS BW in CSA ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26Merge tag 'wireless-drivers-2021-01-26' of ↵Jakub Kicinski24-141/+264
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for v5.11 Second set of fixes for v5.11. Like in last time we again have more fixes than usual Actually a bit too much for my liking in this state of the cycle, but due to unrelated challenges I was only able to submit them now. We have few important crash fixes, iwlwifi modifying read-only data being the most reported issue, and also smaller fixes to iwlwifi. mt76 * fix a clang warning about enum usage * fix rx buffer refcounting crash mt7601u * fix rx buffer refcounting crash * fix crash when unbplugging the device iwlwifi * fix a crash where we were modifying read-only firmware data * lots of smaller fixes all over the driver * tag 'wireless-drivers-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers: (24 commits) mt7601u: fix kernel crash unplugging the device iwlwifi: queue: bail out on invalid freeing iwlwifi: mvm: guard against device removal in reprobe iwlwifi: Fix IWL_SUBDEVICE_NO_160 macro to use the correct bit. iwlwifi: mvm: clear IN_D3 after wowlan status cmd iwlwifi: pcie: add rules to match Qu with Hr2 iwlwifi: mvm: invalidate IDs of internal stations at mvm start iwlwifi: mvm: fix the return type for DSM functions 1 and 2 iwlwifi: pcie: reschedule in long-running memory reads iwlwifi: pcie: use jiffies for memory read spin time limit iwlwifi: pcie: fix context info memory leak iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap iwlwifi: pcie: set LTR on more devices iwlwifi: queue: don't crash if txq->entries is NULL iwlwifi: fix the NMI flow for old devices iwlwifi: pnvm: don't try to load after failures iwlwifi: pnvm: don't skip everything when not reloading iwlwifi: pcie: avoid potential PNVM leaks iwlwifi: mvm: take mutex for calling iwl_mvm_get_sync_time() iwlwifi: mvm: skip power command when unbinding vif during CSA ... ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26iwlwifi: provide gso_type to GSO packetsEric Dumazet1-0/+3
net/core/tso.c got recent support for USO, and this broke iwlfifi because the driver implemented a limited form of GSO. Providing ->gso_type allows for skb_is_gso_tcp() to provide a correct result. Fixes: 3d5b459ba0e3 ("net: tso: add UDP segmentation support") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Ben Greear <[email protected]> Tested-by: Ben Greear <[email protected]> Cc: Luca Coelho <[email protected]> Cc: Johannes Berg <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209913 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26bpf, preload: Fix build when $(O) points to a relative pathQuentin Monnet1-1/+4
Building the kernel with CONFIG_BPF_PRELOAD, and by providing a relative path for the output directory, may fail with the following error: $ make O=build bindeb-pkg ... /.../linux/tools/scripts/Makefile.include:5: *** O=build does not exist. Stop. make[7]: *** [/.../linux/kernel/bpf/preload/Makefile:9: kernel/bpf/preload/libbpf.a] Error 2 make[6]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf/preload] Error 2 make[5]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf] Error 2 make[4]: *** [/.../linux/Makefile:1799: kernel] Error 2 make[4]: *** Waiting for unfinished jobs.... In the case above, for the "bindeb-pkg" target, the error is produced by the "dummy" check in Makefile.include, called from libbpf's Makefile. This check changes directory to $(PWD) before checking for the existence of $(O). But at this step we have $(PWD) pointing to "/.../linux/build", and $(O) pointing to "build". So the Makefile.include tries in fact to assert the existence of a directory named "/.../linux/build/build", which does not exist. Note that the error does not occur for all make targets and architectures combinations. This was observed on x86 for "bindeb-pkg", or for a regular build for UML [0]. Here are some details. The root Makefile recursively calls itself once, after changing directory to $(O). The content for the variable $(PWD) is preserved across recursive calls to make, so it is unchanged at this step. For "bindeb-pkg", $(PWD) is eventually updated because the target writes a new Makefile (as debian/rules) and calls it indirectly through dpkg-buildpackage. This script does not preserve $(PWD), which is reset to the current working directory when the target in debian/rules is called. Although not investigated, it seems likely that something similar causes UML to change its value for $(PWD). Non-trivial fixes could be to remove the use of $(PWD) from the "dummy" check, or to make sure that $(PWD) and $(O) are preserved or updated to always play well and form a valid $(PWD)/$(O) path across the different targets and architectures. Instead, we take a simpler approach and just update $(O) when calling libbpf's Makefile, so it points to an absolute path which should always resolve for the "dummy" check run (through includes) by that Makefile. David Gow previously posted a slightly different version of this patch as a RFC [0], two months ago or so. [0] https://lore.kernel.org/bpf/[email protected]/t/#u Fixes: d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.") Reported-by: David Gow <[email protected]> Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Cc: Brendan Higgins <[email protected]> Cc: Masahiro Yamada <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-01-26igc: fix link speed advertisingCorinna Vinschen1-6/+18
Link speed advertising in igc has two problems: - When setting the advertisement via ethtool, the link speed is converted to the legacy 32 bit representation for the intel PHY code. This inadvertently drops ETHTOOL_LINK_MODE_2500baseT_Full_BIT (being beyond bit 31). As a result, any call to `ethtool -s ...' drops the 2500Mbit/s link speed from the PHY settings. Only reloading the driver alleviates that problem. Fix this by converting the ETHTOOL_LINK_MODE_2500baseT_Full_BIT to the Intel PHY ADVERTISE_2500_FULL bit explicitly. - Rather than checking the actual PHY setting, the .get_link_ksettings function always fills link_modes.advertising with all link speeds the device is capable of. Fix this by checking the PHY autoneg_advertised settings and report only the actually advertised speeds up to ethtool. Fixes: 8c5ad0dae93c ("igc: Add ethtool support") Signed-off-by: Corinna Vinschen <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2021-01-26um: time: fix initialization in time-travel modeJohannes Berg1-19/+31
In time-travel mode, since my previous patch, the start time was initialized too late, so that the system would read it before we set it, thus always starting system time at 0 (1970-01-01). This happens because timekeeping_init() reads the time and is called before time_init(). Unfortunately, I didn't see this before because I was testing it only with the RTC patch applied (and enabled), and then the time is read again by the RTC a little - after time_init() this time. Fix this by just doing the initialization whenever necessary. Fixes: 2701c1bd91dd ("um: time: Fix read_persistent_clock64() in time-travel") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26um: fix os_idle_sleep() to not hangJohannes Berg1-1/+14
Changing os_idle_sleep() to use pause() (I accidentally described it as an empty select() in the commit log because I had changed it from that to pause() in a later revision) exposed a race condition in the idle code. The following can happen: timer_settime(0, 0, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=624017}}, NULL) = 0 ... <SIGALRM is delivered but we're already on the way to idle> pause() and we now hang forever. This was previously possible as well, but it could never cause UML to hang for more than a second since we could only sleep for that much, so at most you'd notice a "hiccup" in the UML. Obviously, any sort of external interrupt also "saves" it and interrupts pause(). Fix this by properly handling the race, rather than papering over it again: - first, block SIGALRM, and obtain the old signal set - check the timer - suspend, waiting for any signal out of the old set, if, and only if, the timer will fire in the future - restore the old signal mask This ensures race-free operation: as it's blocked, the signal won't be delivered while we're looking at the timer even if it were to be triggered right _after_ we've returned from timer_gettime() with a non-zero value (telling us the timer will trigger). Thus, despite getting to sigsuspend() because timer_gettime() told us we're still waiting, we'll not hang because sigsuspend() will return immediately due to the pending signal. Fixes: 49da38a3ef33 ("um: Simplify os_idle_sleep() and sleep longer") Signed-off-by: Johannes Berg <[email protected]> Acked-By: Anton Ivanov <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26Revert "um: support some of ARCH_HAS_SET_MEMORY"Johannes Berg4-59/+0
This reverts commit 963285b0b47a ("um: support some of ARCH_HAS_SET_MEMORY"), as it turns out that it's not only not working (due to um never using the protection bits in the page tables) but also corrupts the page tables if used on a non-vmalloc page, since um never allocates proper page tables for the 'physmem' in the first place. Fixing all this will take more effort, so for now revert it. Reported-by: Benjamin Berg <[email protected]> Fixes: 963285b0b47a ("um: support some of ARCH_HAS_SET_MEMORY") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26Revert "um: allocate a guard page to helper threads"Johannes Berg4-11/+8
This reverts commit ef4459a6da09 ("um: allocate a guard page to helper threads"), it's broken in multiple ways: 1) the free no longer matches the alloc; and 2) more importantly, the set_memory_ro() causes allocation of page tables for the normal memory that doesn't have any, and that later causes corruption and crashes (usually but not always in vfree()). We could fix the first bug and use vmalloc() to work around the second, but set_memory_ro() actually doesn't do anything either so I'll just revert that as well. Reported-by: Benjamin Berg <[email protected]> Fixes: ef4459a6da09 ("um: allocate a guard page to helper threads") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26um: virtio: free vu_dev only with the contained struct deviceJohannes Berg1-1/+2
Since struct device is refcounted, we shouldn't free the vu_dev immediately when it's removed from the platform device, but only when the references actually all go away. Move the freeing to the release to accomplish that. Fixes: 5d38f324993f ("um: drivers: Add virtio vhost-user driver") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26um: kmsg_dumper: always dump when not tty consoleThomas Meyer1-2/+7
With the addition of the ttynull console driver, the chance that a console driver was already registerd did increase. Refine the logic when to dump the kernel message buffer: always dump the buffer, when the UML stdio console driver is not active and the preferred console. Signed-off-by: Thomas Meyer <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26um: stdio_console: Make preferred consoleThomas Meyer1-3/+19
The addition of the "ttynull" console driver did break the ordering of the UML stdio console driver. The UML stdio console driver is added in late_initcall (7), whereby the ttynull driver is added in device_initcall (6), which always does make the ttynull driver the default console. Fix it by explicitly adding the UML stdio console as the preferred console, in case no 'console=' command line option was specified. Signed-off-by: Thomas Meyer <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26um: return error from ioremap()Johannes Berg1-1/+1
Back a few years ago, ioremap() was added to UML so that we'd not break the build for everything all the time. However, for some reason, v1 of the patch got applied, rather than the v2 that returned NULL, which was discussed here: https://lore.kernel.org/lkml/[email protected]/ Fix that now. Signed-off-by: Johannes Berg <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26um: ubd: fix command line handling of ubdHajime Tazaki1-2/+2
This commit fixes a regression to handle command line parameters of ubd. With a simple line "./linux ubd0="./disk-ext4.img", it fails at ubd_setup_common(). The commit adds additional checks to the variables in order to properly parse the paremeters which previously worked. Fixes: ef3ba87cb7c9 ("um: ubd: Set device serial attribute from cmdline") Cc: Christopher Obbard <[email protected]> Signed-off-by: Hajime Tazaki <[email protected]> Acked-by: Christopher Obbard <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2021-01-26Merge tag 'qcom-arm64-defconfig-fixes-for-5.11' of ↵Arnd Bergmann1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm ARM64 defconfig fixes for v5.11 Devicetree patches for SDM845 introduced in v5.11 requires the platform's interconnect driver to be buildin, or the kernel will fail to provide a valid console when we hit userspace. * tag 'qcom-arm64-defconfig-fixes-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: defconfig: Make INTERCONNECT_QCOM_SDM845 builtin Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2021-01-26Merge tag 'qcom-arm64-fixes-for-5.11' of ↵Arnd Bergmann2-10/+8
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm ARM64 fixes for 5.11 This fixes a regression in Lenovo Yoga C630, where the touchpad in some units stopped working, by re-enabling the "tsc2" device. It also marks the LPASS related clocks as protected to allow DB845c and the Lenovo Yoga C630 to boot even if CONFIG_SDM_LPASSCC_845 is enabled. * tag 'qcom-arm64-fixes-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: dts: qcom: sdm845: Reserve LPASS clocks in gcc arm64: dts: qcom: c630: keep both touchpad devices enabled Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2021-01-26Merge tag 'amlogic-fixes' of ↵Arnd Bergmann1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/fixes arm64: dts: amlogic: fixes for v5.11-rc - meson-g12: Set FL-adj property value * tag 'amlogic-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: arm64: dts: amlogic: meson-g12: Set FL-adj property value Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2021-01-26Merge tag 'stm32-dt-for-v5.11-fixes-1' of ↵Arnd Bergmann3-8/+15
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into arm/fixes STM32 DT fixes for v5.11, round 1 Highlights: ----------- -Fixes are for DHCOM/DHCOR boards: - Fix DRC02 uSD card detect polarity - use uSD card detect on DHCOM - Disable uSD WP on DHCOM - Disable TSC2004 on DRC02 - Fix GPIO hogs on DHCOM boards * tag 'stm32-dt-for-v5.11-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: ARM: dts: stm32: Fix GPIO hog flags on DHCOM DRC02 ARM: dts: stm32: Fix GPIO hog flags on DHCOM PicoITX ARM: dts: stm32: Fix GPIO hog names on DHCOM ARM: dts: stm32: Disable optional TSC2004 on DRC02 board ARM: dts: stm32: Disable WP on DHCOM uSD slot ARM: dts: stm32: Connect card-detect signal on DHCOM ARM: dts: stm32: Fix polarity of the DH DRC02 uSD card detect Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2021-01-26mailmap: remove the "repo-abbrev" commentÆvar Arnfjörð Bjarmason1-3/+0
Remove the magical "repo-abbrev" comment added when this file was introduced in e0ab1ec9fcd3 ([PATCH] add .mailmap for proper git-shortlog output, 2007-02-14). It's been an undocumented feature of git-shortlog(1), originally added to git for Linus's use. Since then he's no longer using it[1], and I've removed the feature in git.git's 4e168333a87 (shortlog: remove unused(?) "repo-abbrev" feature, 2021-01-12). It's on the "master" branch, but not yet in a release version. Let's also remove it from linux.git, both as a heads-up to any potential users of it in linux.git whose use would be broken sooner than later by git itself, and because it'll eventually be entirely redundant. 1. https://lore.kernel.org/git/CAHk-=wixHyBKZVUcxq+NCWMbkrX0xnppb7UCopRWw1+oExYpYw@mail.gmail.com/ Acked-by: Linus Torvalds <[email protected]> Signed-off-by: Ævar Arnfjörð Bjarmason <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-01-26parisc: Enable -mlong-calls gcc option by default when !CONFIG_MODULESHelge Deller2-6/+12
When building a kernel without module support, the CONFIG_MLONGCALL option needs to be enabled in order to reach symbols which are outside of a 22-bit branch. This patch changes the autodetection in the Kconfig script to always enable CONFIG_MLONGCALL when modules are disabled and uses a far call to preempt_schedule_irq() in intr_do_preempt() to reach the symbol in all cases. Signed-off-by: Helge Deller <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: [email protected] # v5.6+
2021-01-26Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds15-112/+172
Pull kvm fixes from Paolo Bonzini: - x86 bugfixes - Documentation fixes - Avoid performance regression due to SEV-ES patches - ARM: - Don't allow tagged pointers to point to memslots - Filter out ARMv8.1+ PMU events on v8.0 hardware - Hide PMU registers from userspace when no PMU is configured - More PMU cleanups - Don't try to handle broken PSCI firmware - More sys_reg() to reg_to_encoding() conversions * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: allow KVM_REQ_GET_NESTED_STATE_PAGES outside guest mode for VMX KVM: x86: Revert "KVM: x86: Mark GPRs dirty when written" KVM: SVM: Unconditionally sync GPRs to GHCB on VMRUN of SEV-ES guest KVM: nVMX: Sync unsync'd vmcs02 state to vmcs12 on migration kvm: tracing: Fix unmatched kvm_entry and kvm_exit events KVM: Documentation: Update description of KVM_{GET,CLEAR}_DIRTY_LOG KVM: x86: get smi pending status correctly KVM: x86/pmu: Fix HW_REF_CPU_CYCLES event pseudo-encoding in intel_arch_events[] KVM: x86/pmu: Fix UBSAN shift-out-of-bounds warning in intel_pmu_refresh() KVM: x86: Add more protection against undefined behavior in rsvd_bits() KVM: Documentation: Fix spec for KVM_CAP_ENABLE_CAP_VM KVM: Forbid the use of tagged userspace addresses for memslots KVM: arm64: Filter out v8.1+ events on v8.0 HW KVM: arm64: Compute TPIDR_EL2 ignoring MTE tag KVM: arm64: Use the reg_to_encoding() macro instead of sys_reg() KVM: arm64: Allow PSCI SYSTEM_OFF/RESET to return KVM: arm64: Simplify handling of absent PMU system registers KVM: arm64: Hide PMU registers from userspace when not available
2021-01-26Merge tag 'spi-fix-v5.11-rc5' of ↵Linus Torvalds2-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "One new device ID here, plus an error handling fix - nothing remarkable in either" * tag 'spi-fix-v5.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spidev: Add cisco device compatible spi: altera: Fix memory leak on error path
2021-01-26Merge tag 'regulator-fix-v5.11-rc5' of ↵Linus Torvalds2-11/+63
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "The main thing here is a change to make sure that we don't try to double resolve the supply of a regulator if we have two probes going on simultaneously, plus an incremental fix on top of that to resolve a lockdep issue it introduced. There's also a patch from Dmitry Osipenko adding stubs for some functions to avoid build issues in consumers in some configurations" * tag 'regulator-fix-v5.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: Fix lockdep warning resolving supplies regulator: consumer: Add missing stubs to regulator/consumer.h regulator: core: avoid regulator_resolve_supply() race condition
2021-01-26parisc: Remove leftover reference to the power_taskletDavidlohr Bueso1-3/+0
This was removed long ago, back in: 6e16d9409e1 ([PARISC] Convert soft power switch driver to kthread) Signed-off-by: Davidlohr Bueso <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2021-01-26i40e: acquire VSI pointer only after VF is initializedStefan Assmann1-7/+4
This change simplifies the VF initialization check and also minimizes the delay between acquiring the VSI pointer and using it. As known by the commit being fixed, there is a risk of the VSI pointer getting changed. Therefore minimize the delay between getting and using the pointer. Fixes: 9889707b06ac ("i40e: Fix crash caused by stress setting of VF MAC addresses") Signed-off-by: Stefan Assmann <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Tested-by: Konrad Jankowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2021-01-26ice: Fix MSI-X vector fallback logicBrett Creeley3-12/+14
The current MSI-X enablement logic tries to enable best-case MSI-X vectors and if that fails we only support a bare-minimum set. This includes a single MSI-X for 1 Tx and 1 Rx queue and a single MSI-X for the OICR interrupt. Unfortunately, the driver fails to load when we don't get as many MSI-X as requested for a couple reasons. First, the code to allocate MSI-X in the driver tries to allocate num_online_cpus() MSI-X for LAN traffic without caring about the number of MSI-X actually enabled/requested from the kernel for LAN traffic. So, when calling ice_get_res() for the PF VSI, it returns failure because the number of available vectors is less than requested. Fix this by not allowing the PF VSI to allocation more than pf->num_lan_msix MSI-X vectors and pf->num_lan_msix Rx/Tx queues. Limiting the number of queues is done because we don't want more than 1 Tx/Rx queue per interrupt due to performance conerns. Second, the driver assigns pf->num_lan_msix = 2, to account for LAN traffic and the OICR. However, pf->num_lan_msix is only meant for LAN MSI-X. This is causing a failure when the PF VSI tries to allocate/reserve the minimum pf->num_lan_msix because the OICR MSI-X has already been reserved, so there may not be enough MSI-X vectors left. Fix this by setting pf->num_lan_msix = 1 for the failure case. Then the ICE_MIN_MSIX accounts for the LAN MSI-X and the OICR MSI-X needed for the failure case. Update the related defines used in ice_ena_msix_range() to align with the above behavior and remove the unused RDMA defines because RDMA is currently not supported. Also, remove the now incorrect comment. Fixes: 152b978a1f90 ("ice: Rework ice_ena_msix_range") Signed-off-by: Brett Creeley <[email protected]> Tested-by: Tony Brelinski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2021-01-26ice: Don't allow more channels than LAN MSI-X availableBrett Creeley1-4/+4
Currently users could create more channels than LAN MSI-X available. This is happening because there is no check against pf->num_lan_msix when checking the max allowed channels and will cause performance issues if multiple Tx and Rx queues are tied to a single MSI-X. Fix this by not allowing more channels than LAN MSI-X available in pf->num_lan_msix. Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") Signed-off-by: Brett Creeley <[email protected]> Tested-by: Tony Brelinski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.