summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-06-15wlcore: Fix missing function name in commentsYang Shen1-3/+3
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/ti/wlcore/cmd.c:824: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/net/wireless/ti/wlcore/cmd.c:853: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/net/wireless/ti/wlcore/cmd.c:882: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-12-shenyang39@huawei.com
2021-06-15rsi: Fix missing function name in commentsYang Shen1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/rsi/rsi_91x_mgmt.c:1550: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-10-shenyang39@huawei.com
2021-06-15rtlwifi: Fix wrong function name in commentsYang Shen1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:124: warning: expecting prototype for writeLLT(). Prototype was for rtl92c_llt_write() instead drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:154: warning: expecting prototype for rtl92c_init_LLT_table(). Prototype was for rtl92c_init_llt_table() instead Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-9-shenyang39@huawei.com
2021-06-15libertas_tf: Fix wrong function name in commentsYang Shen1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/marvell/libertas_tf/if_usb.c:56: warning: expecting prototype for if_usb_wrike_bulk_callback(). Prototype was for if_usb_write_bulk_callback() instead Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-8-shenyang39@huawei.com
2021-06-15libbpf: Set NLM_F_EXCL when creating qdiscKumar Kartikeya Dwivedi1-1/+1
This got lost during the refactoring across versions. We always use NLM_F_EXCL when creating some TC object, so reflect what the function says and set the flag. Fixes: 715c5ce454a6 ("libbpf: Add low level TC-BPF management API") Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20210612023502.1283837-3-memxor@gmail.com
2021-06-15libbpf: Remove unneeded check for flags during tc detachKumar Kartikeya Dwivedi1-2/+0
Coverity complained about this being unreachable code. It is right because we already enforce flags to be unset, so a check validating the flag value is redundant. Fixes: 715c5ce454a6 ("libbpf: Add low level TC-BPF management API") Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20210612023502.1283837-2-memxor@gmail.com
2021-06-15brcmsmac: Remove the repeated declarationShaokun Zhang1-1/+0
Function 'brcms_c_stf_phy_txant_upd' are declared twice, remove the repeated declaration. Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1621844443-38290-1-git-send-email-zhangshaokun@hisilicon.com
2021-06-15brcmsmac: mac80211_if: Fix a resource leak in an error handling pathChristophe JAILLET1-1/+7
If 'brcms_attach()' fails, we must undo the previous 'ieee80211_alloc_hw()' as already done in the remove function. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/8fbc171a1a493b38db5a6f0873c6021fca026a6c.1620852921.git.christophe.jaillet@wanadoo.fr
2021-06-15brcmsmac: Drop unnecessary NULL check after container_ofGuenter Roeck1-3/+0
The parameter passed to ai_detach() is guaranteed to never be NULL because it is checked by the caller. Consequently, the result of container_of() on it is also never NULL, and a NULL check on it is unnecessary. Even without that, the NULL check would still be unnecessary because the subsequent kfree() can handle NULL arguments. On top of all that, it is misleading to check the result of container_of() against NULL because the position of the contained element could change, which would make the check invalid. Remove it. This change was made automatically with the following Coccinelle script. @@ type t; identifier v; statement s; @@ <+... ( t v = container_of(...); | v = container_of(...); ) ... when != v - if (\( !v \| v == NULL \) ) s ...+> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511235629.1686038-1-linux@roeck-us.net
2021-06-15brcmsmac: improve readability on addresses copyÍñigo Huguet1-1/+2
A static analyzer identified as a potential bug the copy of 12 bytes from a 6 bytes array to a 6 bytes array. Both arrays are 6 bytes addresses. Although not being a real bug, it is not immediately clear why is done this way: next 6 bytes address, contiguous to the first one, must also be copied to next contiguous 6 bytes address of the destination. Copying each one separately will make both static analyzers and reviewers happier. Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511070257.7843-1-ihuguet@redhat.com
2021-06-15brcmfmac: Add clm_blob firmware files to modinfoMatthias Brugger3-8/+15
Cypress Wi-Fi chipsets include information regarding regulatory constraints. These are provided to the driver through "Country Local Matrix" (CLM) blobs. Files present in Linux firmware repository are on a generic world-wide safe version with conservative power settings which is designed to comply with regulatory but may not provide best performance on all boards. Never the less, a better functionality can be expected with the file present, so add it to the modinfo of the driver. Signed-off-by: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210607103433.21022-1-matthias.bgg@kernel.org
2021-06-15brcmfmac: Delete second brcm folder hierarchyMatthias Brugger1-2/+2
BRCMF_FW_DEFAULT_PATH already defines the brcm folder, delete the second folder to match with Linux firmware repository layout. Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo") Signed-off-by: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210602144305.4481-1-matthias.bgg@kernel.org
2021-06-15brcmfmac: Fix a double-free in brcmf_sdio_bus_resetTong Tiangen1-1/+0
brcmf_sdiod_remove has been called inside brcmf_sdiod_probe when fails, so there's no need to call another one. Otherwise, sdiodev->freezer would be double freed. Fixes: 7836102a750a ("brcmfmac: reset SDIO bus on a firmware crash") Signed-off-by: Tong Tiangen <tongtiangen@huawei.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210601100128.69561-1-tongtiangen@huawei.com
2021-06-15brcmfmac: Demote non-compliant kernel-doc headersYang Shen2-2/+2
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:2040: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:1295: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-5-shenyang39@huawei.com
2021-06-15brcmfmac: correctly report average RSSI in station infoAlvin Šipraga1-16/+20
The rx_lastpkt_rssi field provided by the firmware is suitable for NL80211_STA_INFO_{SIGNAL,CHAIN_SIGNAL}, while the rssi field is an average. Fix up the assignments and set the correct STA_INFO bits. This lets userspace know that the average RSSI is part of the station info. Fixes: cae355dc90db ("brcmfmac: Add RSSI information to get_station.") Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210506132010.3964484-2-alsi@bang-olufsen.dk
2021-06-15brcmfmac: fix setting of station info chains bitmaskAlvin Šipraga1-2/+1
The sinfo->chains field is a bitmask for filled values in chain_signal and chain_signal_avg, not a count. Treat it as such so that the driver can properly report per-chain RSSI information. Before (MIMO mode): $ iw dev wlan0 station dump ... signal: -51 [-51] dBm After (MIMO mode): $ iw dev wlan0 station dump ... signal: -53 [-53, -54] dBm Fixes: cae355dc90db ("brcmfmac: Add RSSI information to get_station.") Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210506132010.3964484-1-alsi@bang-olufsen.dk
2021-06-15brcmfmac: use ISO3166 country code and 0 rev as fallbackShawn Guo1-6/+11
Instead of aborting country code setup in firmware, use ISO3166 country code and 0 rev as fallback, when country_codes mapping table is not configured. This fallback saves the country_codes table setup for recent brcmfmac chipsets/firmwares, which just use ISO3166 code and require no revision number. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210425110200.3050-1-shawn.guo@linaro.org
2021-06-15usb: dwc3: core: fix kernel panic when do rebootPeter Chen1-1/+1
When do system reboot, it calls dwc3_shutdown and the whole debugfs for dwc3 has removed first, when the gadget tries to do deinit, and remove debugfs for its endpoints, it meets NULL pointer dereference issue when call debugfs_lookup. Fix it by removing the whole dwc3 debugfs later than dwc3_drd_exit. [ 2924.958838] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002 .... [ 2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 2925.037005] pc : inode_permission+0x2c/0x198 [ 2925.041281] lr : lookup_one_len_common+0xb0/0xf8 [ 2925.045903] sp : ffff80001276ba70 [ 2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000000 [ 2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: dead000000000100 [ 2925.063510] x23: dead000000000122 x22: 0000000000000000 x21: 0000000000000001 [ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000 [ 2925.077797] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000004 [ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030 [ 2925.092087] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : ffff8000102b2420 [ 2925.099232] x8 : 7f7f7f7f7f7f7f7f x7 : feff73746e2f6f64 x6 : 0000000000008080 [ 2925.106378] x5 : 61c8864680b583eb x4 : 209e6ec2d263dbb7 x3 : 000074756f307065 [ 2925.113523] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff8000122c6188 [ 2925.120671] Call trace: [ 2925.123119] inode_permission+0x2c/0x198 [ 2925.127042] lookup_one_len_common+0xb0/0xf8 [ 2925.131315] lookup_one_len_unlocked+0x34/0xb0 [ 2925.135764] lookup_positive_unlocked+0x14/0x50 [ 2925.140296] debugfs_lookup+0x68/0xa0 [ 2925.143964] dwc3_gadget_free_endpoints+0x84/0xb0 [ 2925.148675] dwc3_gadget_exit+0x28/0x78 [ 2925.152518] dwc3_drd_exit+0x100/0x1f8 [ 2925.156267] dwc3_remove+0x11c/0x120 [ 2925.159851] dwc3_shutdown+0x14/0x20 [ 2925.163432] platform_shutdown+0x28/0x38 [ 2925.167360] device_shutdown+0x15c/0x378 [ 2925.171291] kernel_restart_prepare+0x3c/0x48 [ 2925.175650] kernel_restart+0x1c/0x68 [ 2925.179316] __do_sys_reboot+0x218/0x240 [ 2925.183247] __arm64_sys_reboot+0x28/0x30 [ 2925.187262] invoke_syscall+0x48/0x100 [ 2925.191017] el0_svc_common.constprop.0+0x48/0xc8 [ 2925.195726] do_el0_svc+0x28/0x88 [ 2925.199045] el0_svc+0x20/0x30 [ 2925.202104] el0_sync_handler+0xa8/0xb0 [ 2925.205942] el0_sync+0x148/0x180 [ 2925.209270] Code: a9025bf5 2a0203f5 121f0056 370802b5 (79400660) [ 2925.215372] ---[ end trace 124254d8e485a58b ]--- [ 2925.220012] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 2925.227676] Kernel Offset: disabled [ 2925.231164] CPU features: 0x00001001,20000846 [ 2925.235521] Memory Limit: none [ 2925.238580] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically") Cc: Jack Pham <jackp@codeaurora.org> Tested-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20210608105656.10795-1-peter.chen@kernel.org (cherry picked from commit 2a042767814bd0edf2619f06fecd374e266ea068) Link: https://lore.kernel.org/r/20210615080847.GA10432@jackp-linux.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15ssb: use DEVICE_ATTR_ADMIN_RW() helper macroZhen Lei2-18/+14
Use DEVICE_ATTR_ADMIN_RW() helper macro instead of DEVICE_ATTR(), making it simpler and easier to read. Because the read and write function names of the sysfs attribute have been normalized, there is a natural association. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210603082218.11718-2-thunder.leizhen@huawei.com
2021-06-15ssb: remove unreachable codeTian Tao1-3/+1
The return value of ssb_bus_unregister can only be 0 or -1, so this condition if (err == -EBUSY) will not hold, so delete it. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1621306352-3632-1-git-send-email-tiantao6@hisilicon.com
2021-06-15ssb: sdio: Don't overwrite const buffer if block_write failsMichael Büsch1-1/+0
It doesn't make sense to clobber the const driver-side buffer, if a write-to-device attempt failed. All other SSB variants (PCI, PCMCIA and SoC) also don't corrupt the buffer on any failure in block_write. Therefore, remove this memset from the SDIO variant. Signed-off-by: Michael Büsch <m@bues.ch> Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210515210252.318be2ba@wiggum
2021-06-15ssb: Fix error return code in ssb_bus_scan()Zhen Lei1-0/+1
Fix to return -EINVAL from the error handling case instead of 0, as done elsewhere in this function. Fixes: 61e115a56d1a ("[SSB]: add Sonics Silicon Backplane bus support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210515072949.7151-1-thunder.leizhen@huawei.com
2021-06-15ssb: Remove redundant assignment to errYang Li1-2/+0
Variable 'err' is set to zero but this value is never read as it is overwritten with a new value later on, hence it is a redundant assignment and can be removed. Clean up the following clang-analyzer warning: drivers/ssb/main.c:1306:3: warning: Value stored to 'err' is never read [clang-analyzer-deadcode.DeadStores] drivers/ssb/main.c:1312:3: warning: Value stored to 'err' is never read [clang-analyzer-deadcode.DeadStores] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1619693230-108804-1-git-send-email-yang.lee@linux.alibaba.com
2021-06-15ssb: Fix indentation of commentShubhankar Kuranagatti1-10/+20
Shifted the closing */ to the next line This is done to maintain code uniformity. Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Shubhankar Kuranagatti <shubhankarvk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210428162907.bn5q3oh3sji6wlh4@kewl-virtual-machine
2021-06-15ssb: pcicore: Fix indentation of commentShubhankar Kuranagatti1-6/+12
Shifted the closing */ to the next line This is done to maintain code uniformity. Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Shubhankar Kuranagatti <shubhankarvk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210428161836.sdrxzcrfiekloucz@kewl-virtual-machine
2021-06-15ssb: gpio: Fix alignment of commentShubhankar Kuranagatti1-2/+4
The closing */ has been shifted to a new line This is done to maintain code uniformity. Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Shubhankar Kuranagatti <shubhankarvk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210428160747.qy23g6zpmheiacpl@kewl-virtual-machine
2021-06-15quota: finish disable quotactl_path syscallMarcin Juszkiewicz1-2/+1
In commit 5b9fedb31e47 ("quota: Disable quotactl_path syscall") Jan Kara disabled quotactl_path syscall on several architectures. This commit disables it on all architectures using unified list of system calls: - arm64 - arc - csky - h8300 - hexagon - nds32 - nios2 - openrisc - riscv (32/64) CC: Jan Kara <jack@suse.cz> CC: Christian Brauner <christian.brauner@ubuntu.com> CC: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/lkml/20210512153621.n5u43jsytbik4yze@wittgenstein Link: https://lore.kernel.org/r/20210614153712.313707-1-marcin@juszkiewicz.com.pl Fixes: 5b9fedb31e47 ("quota: Disable quotactl_path syscall") Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> Signed-off-by: Jan Kara <jack@suse.cz>
2021-06-15net/mlx5: Round-Robin EQs over IRQsShay Drory4-29/+189
Whenever users provided affinity for an EQ creation request, map the EQ to a matching IRQ. Matching IRQ=IRQ with the same affinity and type (completion/control) of the EQ created. This mapping is being done in agressive dedicated IRQ allocation scheme, which described bellow. First, we check whether there is a matching IRQ that his min threshold is not exhausted. - min_eqs_threshold = 3 for control EQ. - min_eqs_threshold = 1 for completion EQ. In case no matching IRQ was found, try to request a new IRQ. In case we can't request a new IRQ, reuse least-used matching IRQ. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Separate between public and private API of sf.hShay Drory2-36/+46
Move mlx5_sf_max_functions() and friends from the privete sf/sf.h to the public lib/sf.h. This is done in order to have one direction include paths. Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Enlarge interrupt field in CREATE_EQShay Drory1-2/+2
FW is now supporting more than 256 MSI-X per PF (up to 2K). Hence, enlarge interrupt field in CREATE_EQ to make use of the new MSI-X's. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Allocating a pool of MSI-X vectors for SFsShay Drory3-101/+209
SFs (Sub Functions) currently use IRQs from the global IRQ table their parent Physical Function have. In order to better scale, we need to allocate more IRQs and share them between different SFs. Driver will maintain 3 separated irq pools: 1. A pool that serve the PF consumer (PF's netdev, rdma stacks), similar to what the driver had before this patch. i.e, this pool will share irqs between rdma and netev, and will keep the irq indexes and allocation order. The last is important for PF netdev rmap (aRFS). 2. A pool of control IRQs for SFs. The size of this pool is the number of SFs that can be created divided by SFS_PER_IRQ. This pool will serve the control path EQs of the SFs. 3. A pool of completion data path IRQs for SFs transport queues. The size of this pool is: num_irqs_allocated - pf_pool_size - sf_ctrl_pool_size. This pool will served netdev and rdma stacks. Moreover, rmap is not supported on SFs. Sharing methodology of the SFs pools is explained in the next patch. Important note: rmap is not supported on SFs because rmap mapping cannot function correctly for IRQs that are shared for different core/netdev RX rings. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Change IRQ storage logic from static to dynamicShay Drory3-36/+58
Store newly created IRQs in the xarray DB instead of a static array, so we will be able to store only IRQs which are being used. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Moving rmap logic to EQsShay Drory3-74/+78
IRQs are being simplified in order to ease their sharing and any feature specific object will be moved to upper layer. Hence we move rmap object into eq_table. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Extend mlx5_irq_request to request IRQ from the kernelShay Drory1-71/+57
Extend mlx5_irq_request so that IRQs will be requested upon EQ creation, and not on driver boot. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Removing rmap per IRQShay Drory1-5/+12
In next patches, IRQs will be requested according to demand, instead of statically on driver boot. Also, currently, rmap is managed by the IRQ layer. rmap management will move out from the IRQ layer in future patches. Therefore, we want to remove the IRQ from the rmap, when IRQ is destroyed, instead of removing all the IRQs from the rmap when irq_table is destroyed. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Clean license text in eq.[c|h] filesLeon Romanovsky2-30/+3
The eq.[c|h] files are under major rewrite. so use this opportunity and update their copyright and license texts. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Provide cpumask at EQ creation phaseLeon Romanovsky5-90/+49
The users of EQ are running their code on different CPUs and with various affinity patterns. Move the cpumask setting close to their actual usage. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Introduce API for request and release IRQsShay Drory7-37/+68
Introduce new API that will allow IRQs users to hold a pointer to mlx5_irq. In the end of this series, IRQs will be allocated on demand. Hence, this will allow us to properly manage and use IRQs. Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Delay IRQ destruction till all users are goneLeon Romanovsky1-19/+36
Shared IRQ are consumed by multiple EQ users and in order to properly initialize and later release such IRQs, we add kref counting of IRQ structure. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Change ownership model for lagMark Bloch7-88/+154
Lag is used to combine two PCI functions of the same HCA into a single logical unit. This is a core functionality and as such should be managed by the core driver. Currently this isn't the case. While we store the lag software structure inside the lower device, its lifetime (creation / destruction) is dictated by the mlx5e part. Change the ownership model so lag is tied to the lifetime of the lower level driver instead to the mlx5e part. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Lag, Don't rescan if the device is going downMark Bloch1-2/+8
If MLX5_PRIV_FLAGS_DISABLE_ALL_ADEV is set it means the device is going down and mlx5_rescan_drivers_locked() shouldn't be called. With this patch and the previous one in the series, unbinding a PCI function when its netdev is part of a bond works and leaves the system in a working state. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15net/mlx5: Lag, refactor disable flowMark Bloch1-15/+25
When a net device is removed (can happen if the PCI function is unbound from the system) it's not enough to destroy the hardware lag. The system should recreate the original devices that were present before the lag. As the same flow is done when a net device is removed from the bond refactor and reuse the code. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-15Makefile: lto: Pass -warn-stack-size only on LLD < 13.0.0Tor Vic1-1/+4
Since LLVM commit fc018eb, the '-warn-stack-size' flag has been dropped [1], leading to the following error message when building with Clang-13 and LLD-13: ld.lld: error: -plugin-opt=-: ld.lld: Unknown command line argument '-warn-stack-size=2048'. Try: 'ld.lld --help' ld.lld: Did you mean '--asan-stack=2048'? In the same way as with commit 2398ce80152a ("x86, lto: Pass -stack-alignment only on LLD < 13.0.0") , make '-warn-stack-size' conditional on LLD < 13.0.0. [1] https://reviews.llvm.org/D103928 Fixes: 24845dcb170e ("Makefile: LTO: have linker check -Wframe-larger-than") Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1377 Signed-off-by: Tor Vic <torvic9@mailbox.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/7631bab7-a8ab-f884-ab54-f4198976125c@mailbox.org
2021-06-15net: mhi_net: Update the transmit handler prototypeSubash Abhinov Kasiviswanathan1-1/+1
Update the function prototype of mhi_ndo_xmit to match ndo_start_xmit. This otherwise leads to run time failures when CFI is enabled in kernel. Fixes: 3ffec6a14f24 ("net: Add mhi-net driver") Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-15bpf, selftests: Adjust few selftest outcomes wrt unreachable codeDaniel Borkmann8-8/+53
In almost all cases from test_verifier that have been changed in here, we've had an unreachable path with a load from a register which has an invalid address on purpose. This was basically to make sure that we never walk this path and to have the verifier complain if it would otherwise. Change it to match on the right error for unprivileged given we now test these paths under speculative execution. There's one case where we match on exact # of insns_processed. Due to the extra path, this will of course mismatch on unprivileged. Thus, restrict the test->insn_processed check to privileged-only. In one other case, we result in a 'pointer comparison prohibited' error. This is similarly due to verifying an 'invalid' branch where we end up with a value pointer on one side of the comparison. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Alexei Starovoitov <ast@kernel.org>
2021-06-15bpf: Fix leakage under speculation on mispredicted branchesDaniel Borkmann1-4/+40
The verifier only enumerates valid control-flow paths and skips paths that are unreachable in the non-speculative domain. And so it can miss issues under speculative execution on mispredicted branches. For example, a type confusion has been demonstrated with the following crafted program: // r0 = pointer to a map array entry // r6 = pointer to readable stack slot // r9 = scalar controlled by attacker 1: r0 = *(u64 *)(r0) // cache miss 2: if r0 != 0x0 goto line 4 3: r6 = r9 4: if r0 != 0x1 goto line 6 5: r9 = *(u8 *)(r6) 6: // leak r9 Since line 3 runs iff r0 == 0 and line 5 runs iff r0 == 1, the verifier concludes that the pointer dereference on line 5 is safe. But: if the attacker trains both the branches to fall-through, such that the following is speculatively executed ... r6 = r9 r9 = *(u8 *)(r6) // leak r9 ... then the program will dereference an attacker-controlled value and could leak its content under speculative execution via side-channel. This requires to mistrain the branch predictor, which can be rather tricky, because the branches are mutually exclusive. However such training can be done at congruent addresses in user space using different branches that are not mutually exclusive. That is, by training branches in user space ... A: if r0 != 0x0 goto line C B: ... C: if r0 != 0x0 goto line D D: ... ... such that addresses A and C collide to the same CPU branch prediction entries in the PHT (pattern history table) as those of the BPF program's lines 2 and 4, respectively. A non-privileged attacker could simply brute force such collisions in the PHT until observing the attack succeeding. Alternative methods to mistrain the branch predictor are also possible that avoid brute forcing the collisions in the PHT. A reliable attack has been demonstrated, for example, using the following crafted program: // r0 = pointer to a [control] map array entry // r7 = *(u64 *)(r0 + 0), training/attack phase // r8 = *(u64 *)(r0 + 8), oob address // [...] // r0 = pointer to a [data] map array entry 1: if r7 == 0x3 goto line 3 2: r8 = r0 // crafted sequence of conditional jumps to separate the conditional // branch in line 193 from the current execution flow 3: if r0 != 0x0 goto line 5 4: if r0 == 0x0 goto exit 5: if r0 != 0x0 goto line 7 6: if r0 == 0x0 goto exit [...] 187: if r0 != 0x0 goto line 189 188: if r0 == 0x0 goto exit // load any slowly-loaded value (due to cache miss in phase 3) ... 189: r3 = *(u64 *)(r0 + 0x1200) // ... and turn it into known zero for verifier, while preserving slowly- // loaded dependency when executing: 190: r3 &= 1 191: r3 &= 2 // speculatively bypassed phase dependency 192: r7 += r3 193: if r7 == 0x3 goto exit 194: r4 = *(u8 *)(r8 + 0) // leak r4 As can be seen, in training phase (phase != 0x3), the condition in line 1 turns into false and therefore r8 with the oob address is overridden with the valid map value address, which in line 194 we can read out without issues. However, in attack phase, line 2 is skipped, and due to the cache miss in line 189 where the map value is (zeroed and later) added to the phase register, the condition in line 193 takes the fall-through path due to prior branch predictor training, where under speculation, it'll load the byte at oob address r8 (unknown scalar type at that point) which could then be leaked via side-channel. One way to mitigate these is to 'branch off' an unreachable path, meaning, the current verification path keeps following the is_branch_taken() path and we push the other branch to the verification stack. Given this is unreachable from the non-speculative domain, this branch's vstate is explicitly marked as speculative. This is needed for two reasons: i) if this path is solely seen from speculative execution, then we later on still want the dead code elimination to kick in in order to sanitize these instructions with jmp-1s, and ii) to ensure that paths walked in the non-speculative domain are not pruned from earlier walks of paths walked in the speculative domain. Additionally, for robustness, we mark the registers which have been part of the conditional as unknown in the speculative path given there should be no assumptions made on their content. The fix in here mitigates type confusion attacks described earlier due to i) all code paths in the BPF program being explored and ii) existing verifier logic already ensuring that given memory access instruction references one specific data structure. An alternative to this fix that has also been looked at in this scope was to mark aux->alu_state at the jump instruction with a BPF_JMP_TAKEN state as well as direction encoding (always-goto, always-fallthrough, unknown), such that mixing of different always-* directions themselves as well as mixing of always-* with unknown directions would cause a program rejection by the verifier, e.g. programs with constructs like 'if ([...]) { x = 0; } else { x = 1; }' with subsequent 'if (x == 1) { [...] }'. For unprivileged, this would result in only single direction always-* taken paths, and unknown taken paths being allowed, such that the former could be patched from a conditional jump to an unconditional jump (ja). Compared to this approach here, it would have two downsides: i) valid programs that otherwise are not performing any pointer arithmetic, etc, would potentially be rejected/broken, and ii) we are required to turn off path pruning for unprivileged, where both can be avoided in this work through pushing the invalid branch to the verification stack. The issue was originally discovered by Adam and Ofek, and later independently discovered and reported as a result of Benedict and Piotr's research work. Fixes: b2157399cc98 ("bpf: prevent out-of-bounds speculation") Reported-by: Adam Morrison <mad@cs.tau.ac.il> Reported-by: Ofek Kirzner <ofekkir@gmail.com> Reported-by: Benedict Schlueter <benedict.schlueter@rub.de> Reported-by: Piotr Krysiuk <piotras@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Reviewed-by: Benedict Schlueter <benedict.schlueter@rub.de> Reviewed-by: Piotr Krysiuk <piotras@gmail.com> Acked-by: Alexei Starovoitov <ast@kernel.org>
2021-06-15bpf: Do not mark insn as seen under speculative path verificationDaniel Borkmann1-2/+18
... in such circumstances, we do not want to mark the instruction as seen given the goal is still to jmp-1 rewrite/sanitize dead code, if it is not reachable from the non-speculative path verification. We do however want to verify it for safety regardless. With the patch as-is all the insns that have been marked as seen before the patch will also be marked as seen after the patch (just with a potentially different non-zero count). An upcoming patch will also verify paths that are unreachable in the non-speculative domain, hence this extension is needed. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Reviewed-by: Benedict Schlueter <benedict.schlueter@rub.de> Reviewed-by: Piotr Krysiuk <piotras@gmail.com> Acked-by: Alexei Starovoitov <ast@kernel.org>
2021-06-15bpf: Inherit expanded/patched seen count from old aux dataDaniel Borkmann1-1/+3
Instead of relying on current env->pass_cnt, use the seen count from the old aux data in adjust_insn_aux_data(), and expand it to the new range of patched instructions. This change is valid given we always expand 1:n with n>=1, so what applies to the old/original instruction needs to apply for the replacement as well. Not relying on env->pass_cnt is a prerequisite for a later change where we want to avoid marking an instruction seen when verified under speculative execution path. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Reviewed-by: Benedict Schlueter <benedict.schlueter@rub.de> Reviewed-by: Piotr Krysiuk <piotras@gmail.com> Acked-by: Alexei Starovoitov <ast@kernel.org>
2021-06-15Merge tag 'for-net-2021-06-14' of ↵David S. Miller1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fix crash on SMP when debug is enabled ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-14net: wwan: Fix WWAN config symbolsLoic Poulain3-13/+8
There is not strong reason to have both WWAN and WWAN_CORE symbols, Let's build the WWAN core framework when WWAN is selected, in the same way as for other subsystems. This fixes issue with mhi_net selecting WWAN_CORE without WWAN and reported by kernel test robot: Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for WWAN_CORE Depends on NETDEVICES && WWAN Selected by - MHI_NET && NETDEVICES && NET_CORE && MHI_BUS Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 21:42:16 +0300