aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-20drm/i915/gem: Flush contexts on driver releaseJanusz Krzysztofik1-1/+2
Due to i915_perf assuming that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration, we need to defer removal of the context from the list until last reference to the context is put. However, there is a risk of triggering kernel warning on contexts list not empty at driver release time if we deleagate that task to a worker for i915_gem_context_release_work(), unless that work is flushed first. Unfortunately, it is not flushed on driver release. Fix it. Instead of additionally calling flush_workqueue(), either directly or via a new dedicated wrapper around it, replace last call to i915_gem_drain_freed_objects() with existing i915_gem_drain_workqueue() that performs both tasks. Fixes: 75eefd82581f ("drm/i915: Release i915_gem_context from a worker") Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Janusz Krzysztofik <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Cc: [email protected] # v5.16+ Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1cec34442408a77ba5396b19725fed2c398005c3) Signed-off-by: Rodrigo Vivi <[email protected]>
2022-09-20Revert "block: freeze the queue earlier in del_gendisk"Christoph Hellwig1-1/+2
This reverts commit a09b314005f3a0956ebf56e01b3b80339df577cc. Dusty Mabe reported consistent hang during CoreOS shutdown with a MD RAID1 setup. Although apparently similar hangs happened before, and this patch most likely is not the root cause it made it much more severe. Revert it until we can figure out what is going on with the md driver. Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-09-20gpio: ftgpio010: Make irqchip immutableLinus Walleij1-9/+13
This turns the FTGPIO010 irqchip immutable. Tested on the D-Link DIR-685. Cc: Marc Zyngier <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Acked-by: Marc Zyngier <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2022-09-20gpio: mockup: Fix potential resource leakage when register a chipAndy Shevchenko1-1/+3
If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path. Fixes: 6fda593f3082 ("gpio: mockup: Convert to use software nodes") Cc: [email protected] Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2022-09-20gpio: mockup: fix NULL pointer dereference when removing debugfsBartosz Golaszewski1-1/+1
We now remove the device's debugfs entries when unbinding the driver. This now causes a NULL-pointer dereference on module exit because the platform devices are unregistered *after* the global debugfs directory has been recursively removed. Fix it by unregistering the devices first. Fixes: 303e6da99429 ("gpio: mockup: remove gpio debugfs when remove device") Cc: Wei Yongjun <[email protected]> Cc: [email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
2022-09-20Merge tag 'nvme-6.1-2022-09-20' of git://git.infradead.org/nvme into ↵Jens Axboe12-91/+176
for-6.1/block Pull NVMe updates from Christoph: "nvme updates for Linux 6.1 - handle number of queue changes in the TCP and RDMA drivers (Daniel Wagner) - allow changing the number of queues in nvmet (Daniel Wagner) - also consider host_iface when checking ip options (Daniel Wagner) - don't map pages which can't come from HIGHMEM (Fabio M. De Francesco) - avoid unnecessary flush bios in nvmet (Guixin Liu) - shrink and better pack the nvme_iod structure (Keith Busch) - add comment for unaligned "fake" nqn (Linjun Bao) - print actual source IP address through sysfs "address" attr (Martin Belanger) - various cleanups (Jackie Liu, Wolfram Sang, Genjian Zhang)" * tag 'nvme-6.1-2022-09-20' of git://git.infradead.org/nvme: nvme-tcp: print actual source IP address through sysfs "address" attr nvmet-tcp: don't map pages which can't come from HIGHMEM nvme-pci: move iod dma_len fill gaps nvme-pci: iod npages fits in s8 nvme-pci: iod's 'aborted' is a bool nvme-pci: remove nvme_queue from nvme_iod nvme: consider also host_iface when checking ip options nvme-rdma: handle number of queue changes nvme-tcp: handle number of queue changes nvmet: expose max queues to configfs nvmet: avoid unnecessary flush bio nvmet-auth: remove redundant parameters req nvmet-auth: clean up with done_kfree nvme-auth: remove the redundant req->cqe->result.u16 assignment operation nvme: move from strlcpy with unused retval to strscpy nvme: add comment for unaligned "fake" nqn
2022-09-20tcp: read multiple skbs in tcp_read_skb()Cong Wang1-10/+19
Before we switched to ->read_skb(), ->read_sock() was passed with desc.count=1, which technically indicates we only read one skb per ->sk_data_ready() call. However, for TCP, this is not true. TCP at least has sk_rcvlowat which intentionally holds skb's in receive queue until this watermark is reached. This means when ->sk_data_ready() is invoked there could be multiple skb's in the queue, therefore we have to read multiple skbs in tcp_read_skb() instead of one. Fixes: 965b57b469a5 ("net: Introduce a new proto_ops ->read_skb()") Reported-by: Peilin Ye <[email protected]> Cc: John Fastabend <[email protected]> Cc: Jakub Sitnicki <[email protected]> Cc: Eric Dumazet <[email protected]> Signed-off-by: Cong Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-09-20Revert "ALSA: usb-audio: Split endpoint setups for hw_params and prepare"Takashi Iwai3-23/+20
This reverts commit ff878b408a03bef5d610b7e2302702e16a53636e. Unfortunately the recent fix seems bringing another regressions with PulseAudio / pipewire, at least for Steinberg and MOTU devices. As a temporary solution, do a straight revert. The issue for Android will be revisited again later by another different fix (if any). Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare") Cc: <[email protected]> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216500 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2022-09-20Merge branch 'revert-fec-ptp-changes'Paolo Abeni3-96/+31
Francesco Dolcini says: ==================== Revert fec PTP changes Revert the last 2 FEC PTP changes from Csókás Bence, they are causing multiple issues and we are at 6.0-rc5. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-09-20Revert "net: fec: Use a spinlock to guard `fep->ptp_clk_on`"Francesco Dolcini3-19/+27
This reverts commit b353b241f1eb9b6265358ffbe2632fdcb563354f, this is creating multiple issues, just not ready to be merged yet. Link: https://lore.kernel.org/all/CAHk-=wj1obPoTu1AHj9Bd_BGYjdjDyPP+vT5WMj8eheb3A9WHw@mail.gmail.com/ Link: https://lore.kernel.org/all/[email protected]/ Fixes: b353b241f1eb ("net: fec: Use a spinlock to guard `fep->ptp_clk_on`") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Tested-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2022-09-20Revert "fec: Restart PPS after link state change"Francesco Dolcini3-77/+4
This reverts commit f79959220fa5fbda939592bf91c7a9ea90419040, this is creating multiple issues, just not ready to be merged yet. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/all/CAHk-=wj1obPoTu1AHj9Bd_BGYjdjDyPP+vT5WMj8eheb3A9WHw@mail.gmail.com/ Fixes: f79959220fa5 ("fec: Restart PPS after link state change") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Tested-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2022-09-20net: dsa: microchip: lan937x: fix maximum frame length checkRakesh Sankaranarayanan1-4/+0
Maximum frame length check is enabled in lan937x switch on POR, But it is found to be disabled on driver during port setup operation. Due to this, packets are not dropped when transmitted with greater than configured value. For testing, setup made for lan1->lan2 transmission and configured lan1 interface with a frame length (less than 1500 as mentioned in documentation) and transmitted packets with greater than configured value. Expected no packets at lan2 end, but packets observed at lan2. Based on the documentation, packets should get discarded if the actual packet length doesn't match the frame length configured. Frame length check should be disabled only for cascaded ports due to tailtags. This feature was disabled on ksz9477 series due to ptp issue, which is not in lan937x series. But since lan937x took ksz9477 as base, frame length check disabled here as well. Patch added to remove this portion from port setup so that maximum frame length check will be active for normal ports. Fixes: 55ab6ffaf378 ("net: dsa: microchip: add DSA support for microchip LAN937x") Signed-off-by: Rakesh Sankaranarayanan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-09-20open: always initialize ownership fieldsTetsuo Handa1-0/+2
Beginning of the merge window we introduced the vfs{g,u}id_t types in b27c82e12965 ("attr: port attribute changes to new types") and changed various codepaths over including chown_common(). During that change we forgot to account for the case were the passed ownership value is -1. In this case the ownership fields in struct iattr aren't initialized but we rely on them being initialized by the time we generate the ownership to pass down to the LSMs. All the major LSMs don't care about the ownership values at all. Only Tomoyo uses them and so it took a while for syzbot to unearth this issue. Fix this by initializing the ownership fields and do it within the retry_deleg block. While notify_change() doesn't alter the ownership fields currently we shouldn't rely on it. Since no kernel has been released with these changes this does not needed to be backported to any stable kernels. [Christian Brauner (Microsoft) <[email protected]>] * rewrote commit message * use INVALID_VFS{G,U}ID macros Fixes: b27c82e12965 ("attr: port attribute changes to new types") # mainline only Reported-and-tested-by: [email protected] Signed-off-by: Tetsuo Handa <[email protected]> Reviewed-by: Seth Forshee (DigitalOcean) <[email protected]> Signed-off-by: Christian Brauner (Microsoft) <[email protected]>
2022-09-20drm/hisilicon: Add depends on MMURandy Dunlap1-0/+1
The Kconfig symbol depended on MMU but was dropped by the commit acad3fe650a5 ("drm/hisilicon: Removed the dependency on the mmu") because it already had as a dependency ARM64 that already selects MMU. But later, commit a0f25a6bb319 ("drm/hisilicon/hibmc: Allow to be built if COMPILE_TEST is enabled") allowed the driver to be built for non-ARM64 when COMPILE_TEST is set but that could lead to unmet direct dependencies and linking errors. Prevent a kconfig warning when MMU is not enabled by making DRM_HISI_HIBMC depend on MMU. WARNING: unmet direct dependencies detected for DRM_TTM Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n] Selected by [m]: - DRM_TTM_HELPER [=m] && HAS_IOMEM [=y] && DRM [=m] - DRM_HISI_HIBMC [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && (ARM64 || COMPILE_TEST [=y]) Fixes: acad3fe650a5 ("drm/hisilicon: Removed the dependency on the mmu") Signed-off-by: Randy Dunlap <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Xinliang Liu <[email protected]> Cc: Tian Tao <[email protected]> Cc: John Stultz <[email protected]> Cc: Xinwei Kong <[email protected]> Cc: Chen Feng <[email protected]> Cc: Christian Koenig <[email protected]> Cc: Huang Rui <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-20drm/mgag200: Force 32 bpp on the consoleThomas Zimmermann1-1/+5
G200ER does not seem to support 24 bpp, so force the console to use 32 bpp. The problem got introduced when commit 73f54d5d9682 ("drm/mgag200: Remove special case for G200SE with <2 MiB") changed the preferred color depth from 32 bit to 24 bit. A setting of 24 is the correct color depth, but G200ER doesn't seem to be able to use the respective RGB888 color format. Using 24-bit color with forced 32 bpp works around the problem. Reported-by: Wang Yugui <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Tested-by: Wang Yugui <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Fixes: 73f54d5d9682 ("drm/mgag200: Remove special case for G200SE with <2 MiB") Cc: Thomas Zimmermann <[email protected]> Cc: Jocelyn Falempe <[email protected]> Cc: Dave Airlie <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-19gve: Fix GFP flags when allocing pagesShailend Chand1-1/+1
Use GFP_ATOMIC when allocating pages out of the hotpath, continue to use GFP_KERNEL when allocating pages during setup. GFP_KERNEL will allow blocking which allows it to succeed more often in a low memory enviornment but in the hotpath we do not want to allow the allocation to block. Fixes: 9b8dd5e5ea48b ("gve: DQO: Add RX path") Signed-off-by: Shailend Chand <[email protected]> Signed-off-by: Jeroen de Borst <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19bnxt_en: fix flags to check for supported fw versionVadim Fedorenko1-2/+2
The warning message of unsupported FW appears every time RX timestamps are disabled on the interface. The patch fixes the flags to correct set for the check. Fixes: 66ed81dcedc6 ("bnxt_en: Enable packet timestamping for all RX packets") Cc: Richard Cochran <[email protected]> Signed-off-by: Vadim Fedorenko <[email protected]> Reviewed-by: Andy Gospodarek <[email protected]> Reviewed-by: Michael Chan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19Merge tag 'wireless-2022-09-19' of ↵Jakub Kicinski4-4/+6
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.0 Late stage fixes for v6.0. Temporarily mark iwlwifi's mei code broken as it breaks suspend for iwd users and also don't spam nss trimming messages. mt76 has fixes for aggregation sequence numbers and a regression related to the VHT extended NSS BW feature. * tag 'wireless-2022-09-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: mt76: fix 5 GHz connection regression on mt76x0/mt76x2 wifi: mt76: fix reading current per-tid starting sequence number for aggregation wifi: iwlwifi: Mark IWLMEI as broken wifi: iwlwifi: don't spam logs with NSS>2 messages ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19Merge tag 'batadv-net-pullrequest-20220916' of ↵Jakub Kicinski1-0/+4
git://git.open-mesh.org/linux-merge Simon Wunderlich says: ==================== Here is a batman-adv bugfix: - Fix hang up with small MTU hard-interface, by Shigeru Yoshida * tag 'batadv-net-pullrequest-20220916' of git://git.open-mesh.org/linux-merge: batman-adv: Fix hang up with small MTU hard-interface ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19sfc: fix null pointer dereference in efx_hard_start_xmitÍñigo Huguet1-1/+1
Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] Fixes: 12804793b17c ("sfc: decouple TXQ type from label") Reported-by: Tianhao Zhao <[email protected]> Signed-off-by: Íñigo Huguet <[email protected]> Acked-by: Edward Cree <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19sfc: fix TX channel offset when using legacy interruptsÍñigo Huguet1-1/+1
In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] Fixes: c308dfd1b43e ("sfc: fix wrong tx channel offset with efx_separate_tx_channels") Reported-by: Tianhao Zhao <[email protected]> Signed-off-by: Íñigo Huguet <[email protected]> Acked-by: Edward Cree <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19Merge tag 'for-net-2022-09-09' of ↵Jakub Kicinski1-2/+0
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fix HCIGETDEVINFO regression * tag 'for-net-2022-09-09' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: Fix HCIGETDEVINFO regression ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19net: ethernet: mtk_eth_soc: enable XDP support just for MT7986 SoCLorenzo Bianconi1-1/+1
Disable page_pool/XDP support for MT7621 SoC in order fix a regression introduce adding XDP for MT7986 SoC. There is no a real use case for XDP on MT7621 since it is a low-end cpu. Moreover this patch reduces the memory footprint. Tested-by: Sergio Paracuellos <[email protected]> Tested-by: Arınç ÜNAL <[email protected]> Fixes: 23233e577ef9 ("net: ethernet: mtk_eth_soc: rely on page_pool for single page buffers") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://lore.kernel.org/r/2bf31e27b888c43228b0d84dd2ef5033338269e2.1663074002.git.lorenzo@kernel.org Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19net: mana: Add rmb after checking owner bitsHaiyang Zhang1-0/+10
Per GDMA spec, rmb is necessary after checking owner_bits, before reading EQ or CQ entries. Add rmb in these two places to comply with the specs. Cc: [email protected] Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Reported-by: Sinan Kaya <[email protected]> Signed-off-by: Haiyang Zhang <[email protected]> Reviewed-by: Dexuan Cui <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19MAINTAINERS: gve: update developersJeroen de Borst1-2/+2
Updating active developers. Signed-off-by: Jeroen de Borst <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19netdevsim: Fix hwstats debugfs file permissionsIdo Schimmel1-3/+3
The hwstats debugfs files are only writeable, but they are created with read and write permissions, causing certain selftests to fail [1]. Fix by creating the files with write permission only. [1] # ./test_offload.py Test destruction of generic XDP... Traceback (most recent call last): File "/home/idosch/code/linux/tools/testing/selftests/bpf/./test_offload.py", line 810, in <module> simdev = NetdevSimDev() [...] Exception: Command failed: cat /sys/kernel/debug/netdevsim/netdevsim0//ports/0/dev/hwstats/l3/disable_ifindex cat: /sys/kernel/debug/netdevsim/netdevsim0//ports/0/dev/hwstats/l3/disable_ifindex: Invalid argument Fixes: 1a6d7ae7d63c ("netdevsim: Introduce support for L3 offload xstats") Reported-by: Jie2x Zhou <[email protected]> Tested-by: Jie2x Zhou <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Petr Machata <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19i40e: Fix set max_tx_rate when it is lower than 1 MbpsMichal Jaron1-6/+26
While converting max_tx_rate from bytes to Mbps, this value was set to 0, if the original value was lower than 125000 bytes (1 Mbps). This would cause no transmission rate limiting to occur. This happened due to lack of check of max_tx_rate against the 1 Mbps value for max_tx_rate and the following division by 125000. Fix this issue by adding a helper i40e_bw_bytes_to_mbits() which sets max_tx_rate to minimum usable value of 50 Mbps, if its value is less than 1 Mbps, otherwise do the required conversion by dividing by 125000. Fixes: 5ecae4120a6b ("i40e: Refactor VF BW rate limiting") Signed-off-by: Michal Jaron <[email protected]> Signed-off-by: Andrii Staikov <[email protected]> Tested-by: Bharathi Sreenivas <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2022-09-19i40e: Fix VF set max MTU sizeMichal Jaron1-0/+20
Max MTU sent to VF is set to 0 during memory allocation. It cause that max MTU on VF is changed to IAVF_MAX_RXBUFFER and does not depend on data from HW. Set max_mtu field in virtchnl_vf_resource struct to inform VF in GET_VF_RESOURCES msg what size should be max frame. Fixes: dab86afdbbd1 ("i40e/i40evf: Change the way we limit the maximum frame size for Rx") Signed-off-by: Michal Jaron <[email protected]> Signed-off-by: Mateusz Palczewski <[email protected]> Tested-by: Konrad Jankowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2022-09-19iavf: Fix set max MTU size with port VLAN and jumbo framesMichal Jaron1-2/+5
After setting port VLAN and MTU to 9000 on VF with ice driver there was an iavf error "PF returned error -5 (IAVF_ERR_PARAM) to our request 6". During queue configuration, VF's max packet size was set to IAVF_MAX_RXBUFFER but on ice max frame size was smaller by VLAN_HLEN due to making some space for port VLAN as VF is not aware whether it's in a port VLAN. This mismatch in sizes caused ice to reject queue configuration with ERR_PARAM error. Proper max_mtu is sent from ice PF to VF with GET_VF_RESOURCES msg but VF does not look at this. In iavf change max_frame from IAVF_MAX_RXBUFFER to max_mtu received from pf with GET_VF_RESOURCES msg to make vf's max_frame_size dependent from pf. Add check if received max_mtu is not in eligible range then set it to IAVF_MAX_RXBUFFER. Fixes: dab86afdbbd1 ("i40e/i40evf: Change the way we limit the maximum frame size for Rx") Signed-off-by: Michal Jaron <[email protected]> Signed-off-by: Mateusz Palczewski <[email protected]> Tested-by: Konrad Jankowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2022-09-19mlxbf_gige: clear MDIO gateway lock after readDavid Thompson1-0/+6
The MDIO gateway (GW) lock in BlueField-2 GIGE logic is set after read. This patch adds logic to make sure the lock is always cleared at the end of each MDIO transaction. Fixes: f92e1869d74e ("Add Mellanox BlueField Gigabit Ethernet driver") Reviewed-by: Asmaa Mnebhi <[email protected]> Signed-off-by: David Thompson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-19iavf: Fix bad page stateNorbert Zulinski1-2/+2
Fix bad page state, free inappropriate page in handling dummy descriptor. iavf_build_skb now has to check not only if rx_buffer is NULL but also if size is zero, same thing in iavf_clean_rx_irq. Without this patch driver would free page that will be used by napi_build_skb. Fixes: a9f49e006030 ("iavf: Fix handling of dummy receive descriptors") Signed-off-by: Norbert Zulinski <[email protected]> Signed-off-by: Mateusz Palczewski <[email protected]> Tested-by: Konrad Jankowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2022-09-19um: Prevent KASAN splats in dump_stack()Vincent Whitchurch1-1/+2
Use READ_ONCE_NOCHECK() when reading the stack to prevent KASAN splats when dump_stack() is used. Fixes: 5b301409e8bc5d7fad ("UML: add support for KASAN under x86_64") Signed-off-by: Vincent Whitchurch <[email protected]> Reviewed-by: Dmitry Vyukov <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2022-09-19um: fix default console kernel parameterChristian Lamparter1-1/+1
OpenWrt's UML with 5.15 was producing odd errors/warnings during preinit part of the early userspace portion: |[ 0.000000] Kernel command line: ubd0=root.img root=98:0 console=tty |[...] |[ 0.440000] random: jshn: uninitialized urandom read (4 bytes read) |[ 0.460000] random: jshn: uninitialized urandom read (4 bytes read) |/etc/preinit: line 47: can't create /dev/tty: No such device or address |/etc/preinit: line 48: can't create /dev/tty: No such device or address |/etc/preinit: line 58: can't open /dev/tty: No such device or address |[...] repeated many times That "/dev/tty" came from the command line (which is automatically added if no console= parameter was specified for the uml binary). The TLDP project tells the following about the /dev/tty: <https://tldp.org/HOWTO/Text-Terminal-HOWTO-7.html#ss7.3> | /dev/tty stands for the controlling terminal (if any) for the current | process.[...] | /dev/tty is something like a link to the actually terminal device[..] The "(if any)" is important here, since it's possible for processes to not have a controlling terminal. I think this was a simple typo and the author wanted tty0 there. CC: Thomas Meyer <[email protected]> Fixes: d7ffac33631b ("um: stdio_console: Make preferred console") Signed-off-by: Christian Lamparter <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2022-09-19um: Cleanup compiler warning in arch/x86/um/tls_32.cLukas Straub1-6/+0
arch.tls_array is statically allocated so checking for NULL doesn't make sense. This causes the compiler warning below. Remove the checks to silence these warnings. ../arch/x86/um/tls_32.c: In function 'get_free_idx': ../arch/x86/um/tls_32.c:68:13: warning: the comparison will always evaluate as 'true' for the address of 'tls_array' will never be NULL [-Waddress] 68 | if (!t->arch.tls_array) | ^ In file included from ../arch/x86/um/asm/processor.h:10, from ../include/linux/rcupdate.h:30, from ../include/linux/rculist.h:11, from ../include/linux/pid.h:5, from ../include/linux/sched.h:14, from ../arch/x86/um/tls_32.c:7: ../arch/x86/um/asm/processor_32.h:22:31: note: 'tls_array' declared here 22 | struct uml_tls_struct tls_array[GDT_ENTRY_TLS_ENTRIES]; | ^~~~~~~~~ ../arch/x86/um/tls_32.c: In function 'get_tls_entry': ../arch/x86/um/tls_32.c:243:13: warning: the comparison will always evaluate as 'true' for the address of 'tls_array' will never be NULL [-Waddress] 243 | if (!t->arch.tls_array) | ^ ../arch/x86/um/asm/processor_32.h:22:31: note: 'tls_array' declared here 22 | struct uml_tls_struct tls_array[GDT_ENTRY_TLS_ENTRIES]; | ^~~~~~~~~ Signed-off-by: Lukas Straub <[email protected]> Acked-by: Randy Dunlap <[email protected]> # build-tested Signed-off-by: Richard Weinberger <[email protected]>
2022-09-19um: Cleanup syscall_handler_t cast in syscalls_32.hLukas Straub1-3/+2
Like in f4f03f299a56ce4d73c5431e0327b3b6cb55ebb9 "um: Cleanup syscall_handler_t definition/cast, fix warning", remove the cast to to fix the compiler warning. Signed-off-by: Lukas Straub <[email protected]> Acked-by: Randy Dunlap <[email protected]> # build-tested Signed-off-by: Richard Weinberger <[email protected]>
2022-09-19bcache: fix set_at_max_writeback_rate() for multiple attached devicesColy Li1-21/+52
Inside set_at_max_writeback_rate() the calculation in following if() check is wrong, if (atomic_inc_return(&c->idle_counter) < atomic_read(&c->attached_dev_nr) * 6) Because each attached backing device has its own writeback thread running and increasing c->idle_counter, the counter increates much faster than expected. The correct calculation should be, (counter / dev_nr) < dev_nr * 6 which equals to, counter < dev_nr * dev_nr * 6 This patch fixes the above mistake with correct calculation, and helper routine idle_counter_exceeded() is added to make code be more clear. Reported-by: Mingzhe Zou <[email protected]> Signed-off-by: Coly Li <[email protected]> Acked-by: Mingzhe Zou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-09-19bcache:: fix repeated words in commentsJilin Yuan1-1/+1
Delete the redundant word 'we'. Signed-off-by: Jilin Yuan <[email protected]> Signed-off-by: Coly Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-09-19bcache: bset: Fix comment typosJules Maselbas1-1/+1
Remove the redundant word `by`, correct the typo `creaated`. CC: Kent Overstreet <[email protected]> CC: [email protected] Signed-off-by: Jules Maselbas <[email protected]> Signed-off-by: Coly Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-09-19bcache: remove unused bch_mark_cache_readahead function def in stats.hLin Feng1-1/+0
This is a cleanup for commit 1616a4c2ab1a ("bcache: remove bcache device self-defined readahead")', currently no user for bch_mark_cache_readahead() since that commit. Signed-off-by: Lin Feng <[email protected]> Signed-off-by: Coly Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-09-19bcache: remove unnecessary flush_workqueueLi Lei1-3/+2
All pending works will be drained by destroy_workqueue(), no need to call flush_workqueue() explicitly. Signed-off-by: Li Lei <[email protected]> Signed-off-by: Coly Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-09-19KVM: arm64: Use kmemleak_free_part_phys() to unregister hyp_mem_baseZenghui Yu1-1/+1
With commit 0c24e061196c ("mm: kmemleak: add rbtree and store physical address for objects allocated with PA"), kmemleak started to put the objects allocated with physical address onto object_phys_tree_root tree. The kmemleak_free_part() therefore no longer worked as expected on physically allocated objects (hyp_mem_base in this case) as it attempted to search and remove things in object_tree_root tree. Fix it by using kmemleak_free_part_phys() to unregister hyp_mem_base. This fixes an immediate crash when booting a KVM host in protected mode with kmemleak enabled. Signed-off-by: Zenghui Yu <[email protected]> Acked-by: Catalin Marinas <[email protected]> Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-19s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroupStefan Haberland1-2/+7
Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer with lcu->lock held. Cc: <[email protected]> # 2.6.25+ Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1") Signed-off-by: Stefan Haberland <[email protected]> Reviewed-by: Jan Hoeppner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-09-19nvme-tcp: print actual source IP address through sysfs "address" attrMartin Belanger1-1/+20
TCP transport relies on the routing table to determine which source address and interface to use when making a connection. Currently, there is no way to tell from userspace where a connection was made. This patch exposes the actual source address using a new field named "src_addr=" in the "address" attribute. This is needed to diagnose and identify connectivity issues. With the source address we can infer the interface associated with each connection. This was tested with nvme-cli 2.0 to verify it does not have any adverse effect. The new "src_addr=" field will simply be displayed in the output of the "list-subsys" or "list -v" commands as shown here. $ nvme list-subsys nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress.discovery \ +- nvme0 tcp traddr=192.168.56.1,trsvcid=8009,src_addr=192.168.56.101 live Signed-off-by: Martin Belanger <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-09-19nvmet-tcp: don't map pages which can't come from HIGHMEMFabio M. De Francesco1-31/+13
kmap() is being deprecated in favor of kmap_local_page().[1] There are two main problems with kmap(): (1) It comes with an overhead as mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. The pages which will be mapped are allocated in nvmet_tcp_map_data(), using the GFP_KERNEL flag. This assures that they cannot come from HIGHMEM. This imply that a straight page_address() can replace the kmap() of sg_page(sg) in nvmet_tcp_map_pdu_iovec(). As a side effect, we might also delete the field "nr_mapped" from struct "nvmet_tcp_cmd" because, after removing the kmap() calls, there would be no longer any need of it. In addition, there is no reason to use a kvec for the command receive data buffers iovec, use a bio_vec instead and let iov_iter handle the buffer mapping and data copy. Test with blktests on a QEMU/KVM x86_32 VM, 6GB RAM, booting a kernel with HIGHMEM64GB enabled. [1] "[PATCH] checkpatch: Add kmap and kmap_atomic to the deprecated list" https://lore.kernel.org/all/[email protected]/ Cc: Chaitanya Kulkarni <[email protected]> Cc: Keith Busch <[email protected]> Suggested-by: Ira Weiny <[email protected]> Signed-off-by: Fabio M. De Francesco <[email protected]> Suggested-by: Christoph Hellwig <[email protected]> Suggested-by: Al Viro <[email protected]> [sagi: added bio_vec plus minor naming changes] Signed-off-by: Sagi Grimberg <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-09-19nvme-pci: move iod dma_len fill gapsKeith Busch1-1/+1
The 32-bit field, dma_len, packs better in the iod struct above the dma_addr_t on 64-bit systems. Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-09-19nvme-pci: iod npages fits in s8Keith Busch1-13/+16
The largest allowed transfer is 4MB, which can use at most 1025 PRPs. Each PRP is 8 bytes, so the maximum number of 4k nvme pages needed for the iod_list is 3, which fits in an 's8' type. While modifying this field, change the name to "nr_allocations" to better represent that this is referring to the number of units allocated from a dma_pool. Also introduce a BUILD_BUG_ON to ensure we never accidently increase the largest transfer limit beyond 127 chained prp lists. Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-09-19nvme-pci: iod's 'aborted' is a boolKeith Busch1-3/+3
It's only true or false, so make this a bool to reflect that and save some space in nvme_iod. Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-09-19nvme-pci: remove nvme_queue from nvme_iodKeith Busch1-15/+13
We can get the nvme_queue from the req just as easily, so remove the duplicate path to the same structure to save some space. Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-09-19nvme: consider also host_iface when checking ip optionsDaniel Wagner1-5/+18
It's perfectly fine to use the same traddr and trsvcid more than once as long we use different host interface. This is used in setups where the host has more than one interface but the target exposes only one traddr/trsvcid combination. Use the same acceptance rules for host_iface as we have for host_traddr. Signed-off-by: Daniel Wagner <[email protected]> Reviewed-by: Chao Leng <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-09-19nvme-rdma: handle number of queue changesDaniel Wagner1-5/+21
On reconnect, the number of queues might have changed. In the case where we have more queues available than previously we try to access queues which are not initialized yet. The other case where we have less queues than previously, the connection attempt will fail because the target doesn't support the old number of queues and we end up in a reconnect loop. Thus, only start queues which are currently present in the tagset limited by the number of available queues. Then we update the tagset and we can start any new queue. Signed-off-by: Daniel Wagner <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.