aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-30net: mvneta: fix potential double-frees in mvneta_txq_sw_deinit()Russell King (Oracle)1-0/+2
Reported on the Turris forum, mvneta provokes kernel warnings in the architecture DMA mapping code when mvneta_setup_txqs() fails to allocate memory. This happens because when mvneta_cleanup_txqs() is called in the mvneta_stop() path, we leave pointers in the structure that have been freed. Then on mvneta_open(), we call mvneta_setup_txqs(), which starts allocating memory. On memory allocation failure, mvneta_cleanup_txqs() will walk all the queues freeing any non-NULL pointers - which includes pointers that were previously freed in mvneta_stop(). Fix this by setting these pointers to NULL to prevent double-freeing of the same memory. Fixes: 2adb719d74f6 ("net: mvneta: Implement software TSO") Link: https://forum.turris.cz/t/random-kernel-exceptions-on-hbl-tos-7-0/18865/8 Signed-off-by: Russell King (Oracle) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-30net: dsa: sync unicast and multicast addresses for VLAN filters tooVladimir Oltean1-5/+116
If certain conditions are met, DSA can install all necessary MAC addresses on the CPU ports as FDB entries and disable flooding towards the CPU (we call this RX filtering). There is one corner case where this does not work. ip link add br0 type bridge vlan_filtering 1 && ip link set br0 up ip link set swp0 master br0 && ip link set swp0 up ip link add link swp0 name swp0.100 type vlan id 100 ip link set swp0.100 up && ip addr add 192.168.100.1/24 dev swp0.100 Traffic through swp0.100 is broken, because the bridge turns on VLAN filtering in the swp0 port (causing RX packets to be classified to the FDB database corresponding to the VID from their 802.1Q header), and although the 8021q module does call dev_uc_add() towards the real device, that API is VLAN-unaware, so it only contains the MAC address, not the VID; and DSA's current implementation of ndo_set_rx_mode() is only for VID 0 (corresponding to FDB entries which are installed in an FDB database which is only hit when the port is VLAN-unaware). It's interesting to understand why the bridge does not turn on IFF_PROMISC for its swp0 bridge port, and it may appear at first glance that this is a regression caused by the logic in commit 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode."). After all, a bridge port needs to have IFF_PROMISC by its very nature - it needs to receive and forward frames with a MAC DA different from the bridge ports' MAC addresses. While that may be true, when the bridge is VLAN-aware *and* it has a single port, there is no real reason to enable promiscuity even if that is an automatic port, with flooding and learning (there is nowhere for packets to go except to the BR_FDB_LOCAL entries), and this is how the corner case appears. Adding a second automatic interface to the bridge would make swp0 promisc as well, and would mask the corner case. Given the dev_uc_add() / ndo_set_rx_mode() API is what it is (it doesn't pass a VLAN ID), the only way to address that problem is to install host FDB entries for the cartesian product of RX filtering MAC addresses and VLAN RX filters. Fixes: 7569459a52c9 ("net: dsa: manage flooding on the CPU ports") Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-30net: dsa: mv88e6xxx: Enable IGMP snooping on user ports onlySteffen Bätz1-2/+7
Do not set the MV88E6XXX_PORT_CTL0_IGMP_MLD_SNOOP bit on CPU or DSA ports. This allows the host CPU port to be a regular IGMP listener by sending out IGMP Membership Reports, which would otherwise not be forwarded by the mv88exxx chip, but directly looped back to the CPU port itself. Fixes: 54d792f257c6 ("net: dsa: Centralise global and port setup code into mv88e6xxx.") Signed-off-by: Steffen Bätz <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-30Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux ↵Daniel Vetter4-56/+10
into drm-fixes - revert gpu time fdinfo support - reference leak fix on imported buffers Signed-off-by: Daniel Vetter <[email protected]> From: Lucas Stach <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-30thermal: intel: powerclamp: Fix cpumask and max_idle module parametersDavid Arcari1-1/+8
When cpumask is specified as a module parameter the value is overwritten by the module init routine. This can easily be fixed by checking to see if the mask has already been allocated in the init routine. When max_idle is specified as a module parameter a panic will occur. The problem is that the idle_injection_cpu_mask is not allocated until the module init routine executes. This can easily be fixed by allocating the cpumask if it's not already allocated. Fixes: ebf519710218 ("thermal: intel: powerclamp: Add two module parameters") Signed-off-by: David Arcari <[email protected]> Reviewed-by: Srinivas Pandruvada<[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-03-30Merge tag 'amd-drm-fixes-6.3-2023-03-30' of ↵Daniel Vetter1-1/+6
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.3-2023-03-30: amdgpu: - Hibernation regression fix Signed-off-by: Daniel Vetter <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-30Merge tag 'drm-misc-fixes-2023-03-30' of ↵Daniel Vetter10-93/+90
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Short summary of fixes pull: * various ivpu fixes * fix nouveau backlight registration * fix buddy allocator in 32-bit systems Signed-off-by: Daniel Vetter <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230330141006.GA22908@linux-uq9g
2023-03-30Merge tag 'amd-drm-fixes-6.3-2023-03-29' of ↵Daniel Vetter2-8/+58
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.3-2023-03-29: amdgpu: - Two DP MST fixes Signed-off-by: Daniel Vetter <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-30Merge tag 'drm-intel-fixes-2023-03-30' of ↵Daniel Vetter13-42/+177
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v6.3-rc5: - Fix PMU support by reusing functions with sysfs - Fix a number of issues related to color, PSR and arm/noarm - Fix state check related to ICL PHY ownership check in TC-cold state - Flush lmem contents after construction - Fix hibernate oops related to DPT BO - Fix perf stream error path wakeref balance Signed-off-by: Daniel Vetter <[email protected]> From: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-30Merge tag 'sound-6.3-rc5' of ↵Linus Torvalds9-17/+38
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes: - A potential deadlock fix for USB-audio, involving some change in PCM core side - A regression fix for probes of USB-audio devices with the vendor-specific PCM format bits - Two regression fixes for the old YMFPCI driver - A few HD-audio quirks as usual" * tag 'sound-6.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda/realtek: Add quirk for Lenovo ZhaoYang CF4620Z ALSA: ymfpci: Fix BUG_ON in probe function ALSA: ymfpci: Create card with device-managed snd_devm_card_new() ALSA: usb-audio: Fix regression on detection of Roland VS-100 ALSA: hda/realtek: Fix support for Dell Precision 3260 ALSA: usb-audio: Fix recursive locking at XRUN during syncing ALSA: hda/conexant: Partial revert of a quirk for Lenovo ALSA: hda/realtek: Add quirks for some Clevo laptops
2023-03-30Merge tag 'zonefs-6.3-rc5' of ↵Linus Torvalds1-2/+26
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs Pull zonefs fixes from Damien Le Moal: - Make sure to always invalidate the last page of an inode straddling inode->i_size to avoid data inconsistencies with appended data when the device zone write granularity does not match the page size. - Do not propagate iomap -ENOBLK error to userspace and use -EBUSY instead. * tag 'zonefs-6.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs: zonefs: Do not propagate iomap_dio_rw() ENOTBLK error to user space zonefs: Always invalidate last cached page on append write
2023-03-30Revert "drm/scheduler: track GPU active time per entity"Lucas Stach2-13/+0
This reverts commit df622729ddbf as it introduces a use-after-free, which isn't easy to fix without going back to the design drawing board. Reported-by: Danilo Krummrich <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2023-03-30Revert "drm/etnaviv: export client GPU usage statistics via fdinfo"Lucas Stach1-42/+1
This reverts commit 97804a133c68, as it builds on top of df622729ddbf ("drm/scheduler: track GPU active time per entity") which needs to be reverted, as it introduces a use-after-free. Signed-off-by: Lucas Stach <[email protected]>
2023-03-30drm/etnaviv: fix reference leak when mmaping imported bufferLucas Stach1-1/+9
drm_gem_prime_mmap() takes a reference on the GEM object, but before that drm_gem_mmap_obj() already takes a reference, which will be leaked as only one reference is dropped when the mapping is closed. Drop the extra reference when dma_buf_mmap() succeeds. Cc: [email protected] Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]>
2023-03-30drm/amdgpu: allow more APUs to do mode2 reset when go to S4Tim Huang1-1/+6
Skip mode2 reset only for IMU enabled APUs when do S4. This patch is to fix the regression issue https://gitlab.freedesktop.org/drm/amd/-/issues/2483 It is generated by commit b589626674de ("drm/amdgpu: skip ASIC reset for APUs when go to S4"). Fixes: b589626674de ("drm/amdgpu: skip ASIC reset for APUs when go to S4") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2483 Tested-by: Yuan Perry <[email protected]> Signed-off-by: Tim Huang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-03-30xhci: Free the command allocated for setting LPM if we return earlyMathias Nyman1-0/+1
The command allocated to set exit latency LPM values need to be freed in case the command is never queued. This would be the case if there is no change in exit latency values, or device is missing. Reported-by: Mirsad Goran Todorovac <[email protected]> Link: https://lore.kernel.org/linux-usb/[email protected] Tested-by: Mirsad Goran Todorovac <[email protected]> Fixes: 5c2a380a5aa8 ("xhci: Allocate separate command structures for each LPM command") Cc: <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-03-30Revert "usb: xhci-pci: Set PROBE_PREFER_ASYNCHRONOUS"Mathias Nyman1-4/+3
This reverts commit 4c2604a9a6899bab195edbee35fc8d64ce1444aa. Asynch probe caused regression in a setup with both Renesas and Intel xHC controllers. Devices connected to the Renesas disconnected shortly after boot. With Asynch probe the busnumbers got interleaved. xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 2 xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3 xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 4 Reason why this commit causes regression is still unknown, but revert it while debugging the issue. Fixes: 4c2604a9a689 ("usb: xhci-pci: Set PROBE_PREFER_ASYNCHRONOUS") Cc: stable <[email protected]> Link: https://lore.kernel.org/linux-usb/[email protected] Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-03-30xhci: also avoid the XHCI_ZERO_64B_REGS quirk with a passthrough iommuD Scott Phillips1-1/+5
Previously the quirk was skipped when no iommu was present. The same rationale for skipping the quirk also applies in the iommu.passthrough=1 case. Skip applying the XHCI_ZERO_64B_REGS quirk if the device's iommu domain is passthrough. Fixes: 12de0a35c996 ("xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers") Cc: stable <[email protected]> Signed-off-by: D Scott Phillips <[email protected]> Acked-by: Marc Zyngier <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-03-30xen/netback: use same error messages for same errorsJuergen Gross1-4/+2
Issue the same error message in case an illegal page boundary crossing has been detected in both cases where this is tested. Suggested-by: Jan Beulich <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-03-30io_uring: fix poll/netmsg alloc cachesPavel Begunkov1-0/+1
We increase cache->nr_cached when we free into the cache but don't decrease when we take from it, so in some time we'll get an empty cache with cache->nr_cached larger than IO_ALLOC_CACHE_MAX, that fails io_alloc_cache_put() and effectively disables caching. Fixes: 9b797a37c4bd8 ("io_uring: add abstraction around apoll cache") Cc: [email protected] Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2023-03-30zonefs: Do not propagate iomap_dio_rw() ENOTBLK error to user spaceDamien Le Moal1-2/+12
The call to invalidate_inode_pages2_range() in __iomap_dio_rw() may fail, in which case -ENOTBLK is returned and this error code is propagated back to user space trhough iomap_dio_rw() -> zonefs_file_dio_write() return chain. This error code is fairly obscure and may confuse the user. Avoid this and be consistent with the behavior of zonefs_file_dio_append() for similar invalidate_inode_pages2_range() errors by returning -EBUSY to user space when iomap_dio_rw() returns -ENOTBLK. Suggested-by: Christoph Hellwig <[email protected]> Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Tested-by: Hans Holmberg <[email protected]>
2023-03-30zonefs: Always invalidate last cached page on append writeDamien Le Moal1-0/+14
When a direct append write is executed, the append offset may correspond to the last page of a sequential file inode which might have been cached already by buffered reads, page faults with mmap-read or non-direct readahead. To ensure that the on-disk and cached data is consistant for such last cached page, make sure to always invalidate it in zonefs_file_dio_append(). If the invalidation fails, return -EBUSY to userspace to differentiate from IO errors. This invalidation will always be a no-op when the FS block size (device zone write granularity) is equal to the page size (e.g. 4K). Reported-by: Hans Holmberg <[email protected]> Fixes: 02ef12a663c7 ("zonefs: use REQ_OP_ZONE_APPEND for sync DIO") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Tested-by: Hans Holmberg <[email protected]>
2023-03-30wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded staFelix Fietkau1-1/+2
Avoid potential data corruption issues caused by uninitialized driver private data structures. Reported-by: Brian Coverstone <[email protected]> Fixes: 6a9d1b91f34d ("mac80211: add pre-RCU-sync sta removal driver operation") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-03-30wifi: mac80211: fix flow dissection for forwarded packetsFelix Fietkau1-1/+1
Adjust the network header to point at the correct payload offset Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-03-30wifi: mac80211: fix mesh forwardingFelix Fietkau1-0/+3
Linearize packets (needed for forwarding A-MSDU subframes). Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-03-30wifi: mac80211: fix receiving mesh packets in forwarding=0 networksFelix Fietkau1-8/+8
When forwarding is set to 0, frames are typically sent with ttl=1. Move the ttl decrement check below the check for local receive in order to fix packet drops. Reported-by: Thomas Hühn <[email protected]> Reported-by: Nick Hainke <[email protected]> Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-03-30wifi: mac80211: fix the size calculation of ieee80211_ie_len_eht_cap()Ryder Lee1-1/+1
Here should return the size of ieee80211_eht_cap_elem_fixed, so fix it. Fixes: 820acc810fb6 ("mac80211: Add EHT capabilities to association/probe request") Signed-off-by: Ryder Lee <[email protected]> Link: https://lore.kernel.org/r/06c13635fc03bcff58a647b8e03e9f01a74294bd.1679935259.git.ryder.lee@mediatek.com Signed-off-by: Johannes Berg <[email protected]>
2023-03-30wifi: mac80211: fix potential null pointer dereferenceFelix Fietkau1-2/+2
rx->sta->amsdu_mesh_control is being passed to ieee80211_amsdu_to_8023s without checking rx->sta. Since it doesn't make sense to accept A-MSDU packets without a sta, simply add a check earlier. Fixes: 6e4c0d0460bd ("wifi: mac80211: add a workaround for receiving non-standard mesh A-MSDU") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-03-30wifi: mac80211: drop bogus static keywords in A-MSDU rxFelix Fietkau1-2/+2
These were unintentional copy&paste mistakes. Cc: [email protected] Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-03-30x86/acpi/boot: Correct acpi_is_processor_usable() checkEric DeVolder1-1/+2
The logic in acpi_is_processor_usable() requires the online capable bit be set for hotpluggable CPUs. The online capable bit has been introduced in ACPI 6.3. However, for ACPI revisions < 6.3 which do not support that bit, CPUs should be reported as usable, not the other way around. Reverse the check. [ bp: Rewrite commit message. ] Fixes: e2869bd7af60 ("x86/acpi/boot: Do not register processors that cannot be onlined for x2APIC") Suggested-by: Miguel Luis <[email protected]> Suggested-by: Boris Ostrovsky <[email protected]> Signed-off-by: Eric DeVolder <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Tested-by: David R <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-03-30x86/ACPI/boot: Use FADT version to check support for online capableMario Limonciello1-1/+5
ACPI 6.3 introduced the online capable bit, and also introduced MADT version 5. Latter was used to distinguish whether the offset storing online capable could be used. However ACPI 6.2b has MADT version "45" which is for an errata version of the ACPI 6.2 spec. This means that the Linux code for detecting availability of MADT will mistakenly flag ACPI 6.2b as supporting online capable which is inaccurate as it's an ACPI 6.3 feature. Instead use the FADT major and minor revision fields to distinguish this. [ bp: Massage. ] Fixes: aa06e20f1be6 ("x86/ACPI: Don't add CPUs that are not online capable") Reported-by: Eric DeVolder <[email protected]> Reported-by: Borislav Petkov <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-03-30Merge branch 'fix-header-length-on-skb-merging'Paolo Abeni2-1/+98
Arseniy Krasnov says: ==================== fix header length on skb merging this patchset fixes appending newly arrived skbuff to the last skbuff of the socket's queue during rx path. Problem fires when we are trying to append data to skbuff which was already processed in dequeue callback at least once. Dequeue callback calls function 'skb_pull()' which changes 'skb->len'. In current implementation 'skb->len' is used to update length in header of last skbuff after new data was copied to it. This is bug, because value in header is used to calculate 'rx_bytes'/'fwd_cnt' and thus must be constant during skbuff lifetime. Here is example, we have two skbuffs: skb0 with length 10 and skb1 with length 4. 1) skb0 arrives, hdr->len == skb->len == 10, rx_bytes == 10 2) Read 3 bytes from skb0, skb->len == 7, hdr->len == 10, rx_bytes == 10 3) skb1 arrives, hdr->len == skb->len == 4, rx_bytes == 14 4) Append skb1 to skb0, skb0 now has skb->len == 11, hdr->len == 11. But value of 11 in header is invalid. 5) Read whole skb0, update rx_bytes by 11 from skb0's header. 6) At this moment rx_bytes == 3, but socket's queue is empty. This bug starts to fire since: commit 077706165717 ("virtio/vsock: don't use skbuff state to account credit") In fact, it presents before, but didn't triggered due to a little bit buggy implementation of credit calculation logic. So i'll use Fixes tag for it. I really forgot about this branch in rx path when implemented patch 077706165717. This patchset contains 3 patches: 1) Fix itself. 2) Patch with WARN_ONCE() to catch such problems in future. 3) Patch with test which triggers skb appending logic. It looks like simple test with several 'send()' and 'recv()', but it checks, that skbuff appending works ok. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-03-30test/vsock: new skbuff appending testArseniy Krasnov1-0/+90
This adds test which checks case when data of newly received skbuff is appended to the last skbuff in the socket's queue. It looks like simple test with 'send()' and 'recv()', but internally it triggers logic which appends one received skbuff to another. Test checks that this feature works correctly. This test is actual only for virtio transport. Signed-off-by: Arseniy Krasnov <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-03-30virtio/vsock: WARN_ONCE() for invalid state of socketArseniy Krasnov1-0/+7
This adds WARN_ONCE() and return from stream dequeue callback when socket's queue is empty, but 'rx_bytes' still non-zero. This allows the detection of potential bugs due to packet merging (see previous patch). Signed-off-by: Arseniy Krasnov <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-03-30virtio/vsock: fix header length on skb mergingArseniy Krasnov1-1/+1
This fixes appending newly arrived skbuff to the last skbuff of the socket's queue. Problem fires when we are trying to append data to skbuff which was already processed in dequeue callback at least once. Dequeue callback calls function 'skb_pull()' which changes 'skb->len'. In current implementation 'skb->len' is used to update length in header of the last skbuff after new data was copied to it. This is bug, because value in header is used to calculate 'rx_bytes'/'fwd_cnt' and thus must be not be changed during skbuff's lifetime. Bug starts to fire since: commit 077706165717 ("virtio/vsock: don't use skbuff state to account credit") It presents before, but didn't triggered due to a little bit buggy implementation of credit calculation logic. So use Fixes tag for it. Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit") Signed-off-by: Arseniy Krasnov <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-03-29Merge branch 'bnxt_en-3-bug-fixes'Jakub Kicinski3-4/+8
Michael Chan says: ==================== bnxt_en: 3 Bug fixes This series contains 3 small bug fixes covering ethtool self test, PCI ID string typos, and some missing 200G link speed ethtool reporting logic. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-29bnxt_en: Add missing 200G link speed reportingMichael Chan2-0/+3
bnxt_fw_to_ethtool_speed() is missing the case statement for 200G link speed reported by firmware. As a result, ethtool will report unknown speed when the firmware reports 200G link speed. Fixes: 532262ba3b84 ("bnxt_en: ethtool: support PAM4 link speeds up to 200G") Signed-off-by: Michael Chan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-29bnxt_en: Fix typo in PCI id to device description string mappingKalesh AP1-4/+4
Fix 57502 and 57508 NPAR description string entries. The typos caused these devices to not match up with lspci output. Fixes: 49c98421e6ab ("bnxt_en: Add PCI IDs for 57500 series NPAR devices.") Reviewed-by: Pavan Chebbi <[email protected]> Signed-off-by: Kalesh AP <[email protected]> Signed-off-by: Michael Chan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-29bnxt_en: Fix reporting of test result in ethtool selftestKalesh AP1-0/+1
When the selftest command fails, driver is not reporting the failure by updating the "test->flags" when bnxt_close_nic() fails. Fixes: eb51365846bc ("bnxt_en: Add basic ethtool -t selftest support.") Reviewed-by: Pavan Chebbi <[email protected]> Reviewed-by: Somnath Kotur <[email protected]> Signed-off-by: Kalesh AP <[email protected]> Signed-off-by: Michael Chan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-29i40e: fix registers dump after run ethtool adapter self testRadoslaw Tyl2-6/+7
Fix invalid registers dump from ethtool -d ethX after adapter self test by ethtool -t ethY. It causes invalid data display. The problem was caused by overwriting i40e_reg_list[].elements which is common for ethtool self test and dump. Fixes: 22dd9ae8afcc ("i40e: Rework register diagnostic") Signed-off-by: Radoslaw Tyl <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Tested-by: Arpana Arland <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-29Merge branch '100GbE' of ↵Jakub Kicinski5-8/+102
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-03-28 (ice) This series contains updates to ice driver only. Jesse fixes mismatched header documentation reported when building with W=1. Brett restricts setting of VSI context to only applicable fields for the given ICE_AQ_VSI_PROP_Q_OPT_VALID bit. Junfeng adds check when adding Flow Director filters that conflict with existing filter rules. Jakob Koschel adds interim variable for iterating to prevent possible misuse after looping. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: fix invalid check for empty list in ice_sched_assoc_vsi_to_agg() ice: add profile conflict check for AVF FDIR ice: Fix ice_cfg_rdma_fltr() to only update relevant fields ice: fix W=1 headers mismatch ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-29Merge tag 'ieee802154-for-net-2023-03-29' of ↵Jakub Kicinski2-4/+2
git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan Stefan Schmidt says: ==================== ieee802154 for net 2023-03-29 Two small fixes this time. Dongliang Mu removed an unnecessary null pointer check. Harshit Mogalapalli fixed an int comparison unsigned against signed from a recent other fix in the ca8210 driver. * tag 'ieee802154-for-net-2023-03-29' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan: net: ieee802154: remove an unnecessary null pointer check ca8210: Fix unsigned mac_len comparison with zero in ca8210_skb_tx() ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-29bnx2x: use the right build_skb() helperJakub Kicinski1-2/+14
build_skb() no longer accepts slab buffers. Since slab use is fairly uncommon we prefer the drivers to call a separate slab_build_skb() function appropriately. bnx2x uses the old semantics where size of 0 meant buffer from slab. It sets the fp->rx_frag_size to 0 for MTUs which don't fit in a page. It needs to call slab_build_skb(). This fixes the WARN_ONCE() of incorrect API use seen with bnx2x. Reported-by: Thomas Voegtle <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Fixes: ce098da1497c ("skbuff: Introduce slab_build_skb()") Reviewed-by: Leon Romanovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-29net: ipa: compute DMA pool size properlyAlex Elder1-1/+1
In gsi_trans_pool_init_dma(), the total size of a pool of memory used for DMA transactions is calculated. However the calculation is done incorrectly. For 4KB pages, this total size is currently always more than one page, and as a result, the calculation produces a positive (though incorrect) total size. The code still works in this case; we just end up with fewer DMA pool entries than we intended. Bjorn Andersson tested booting a kernel with 16KB pages, and hit a null pointer derereference in sg_alloc_append_table_from_pages(), descending from gsi_trans_pool_init_dma(). The cause of this was that a 16KB total size was going to be allocated, and with 16KB pages the order of that allocation is 0. The total_size calculation yielded 0, which eventually led to the crash. Correcting the total_size calculation fixes the problem. Reported-by: Bjorn Andersson <[email protected]> Tested-by: Bjorn Andersson <[email protected]> Fixes: 9dd441e4ed57 ("soc: qcom: ipa: GSI transactions") Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Alex Elder <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-30nvme-tcp: fix a possible UAF when failing to allocate an io queueSagi Grimberg1-20/+26
When we allocate a nvme-tcp queue, we set the data_ready callback before we actually need to use it. This creates the potential that if a stray controller sends us data on the socket before we connect, we can trigger the io_work and start consuming the socket. In this case reported: we failed to allocate one of the io queues, and as we start releasing the queues that we already allocated, we get a UAF [1] from the io_work which is running before it should really. Fix this by setting the socket ops callbacks only before we start the queue, so that we can't accidentally schedule the io_work in the initialization phase before the queue started. While we are at it, rename nvme_tcp_restore_sock_calls to pair with nvme_tcp_setup_sock_ops. [1]: [16802.107284] nvme nvme4: starting error recovery [16802.109166] nvme nvme4: Reconnecting in 10 seconds... [16812.173535] nvme nvme4: failed to connect socket: -111 [16812.173745] nvme nvme4: Failed reconnect attempt 1 [16812.173747] nvme nvme4: Reconnecting in 10 seconds... [16822.413555] nvme nvme4: failed to connect socket: -111 [16822.413762] nvme nvme4: Failed reconnect attempt 2 [16822.413765] nvme nvme4: Reconnecting in 10 seconds... [16832.661274] nvme nvme4: creating 32 I/O queues. [16833.919887] BUG: kernel NULL pointer dereference, address: 0000000000000088 [16833.920068] nvme nvme4: Failed reconnect attempt 3 [16833.920094] #PF: supervisor write access in kernel mode [16833.920261] nvme nvme4: Reconnecting in 10 seconds... [16833.920368] #PF: error_code(0x0002) - not-present page [16833.921086] Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp] [16833.921191] RIP: 0010:_raw_spin_lock_bh+0x17/0x30 ... [16833.923138] Call Trace: [16833.923271] <TASK> [16833.923402] lock_sock_nested+0x1e/0x50 [16833.923545] nvme_tcp_try_recv+0x40/0xa0 [nvme_tcp] [16833.923685] nvme_tcp_io_work+0x68/0xa0 [nvme_tcp] [16833.923824] process_one_work+0x1e8/0x390 [16833.923969] worker_thread+0x53/0x3d0 [16833.924104] ? process_one_work+0x390/0x390 [16833.924240] kthread+0x124/0x150 [16833.924376] ? set_kthread_struct+0x50/0x50 [16833.924518] ret_from_fork+0x1f/0x30 [16833.924655] </TASK> Reported-by: Yanjun Zhang <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Tested-by: Yanjun Zhang <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2023-03-29drm/amd/display: Take FEC Overhead into Timeslot CalculationFangzhi Zuo2-8/+27
8b/10b encoding needs to add 3% fec overhead into the pbn. In the Synapcis Cascaded MST hub, the first stage MST branch device needs the information to determine the timeslot count for the second stage MST branch device. Missing this overhead will leads to insufficient timeslot allocation. Cc: [email protected] Cc: Mario Limonciello <[email protected]> Reviewed-by: Hersen Wu <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Fangzhi Zuo <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-29drm/amd/display: Add DSC Support for Synaptics Cascaded MST HubFangzhi Zuo2-0/+31
Traditional synaptics hub has one MST branch device without virtual dpcd. Synaptics cascaded hub has two chained MST branch devices. DSC decoding is performed via root MST branch device, instead of the second MST branch device. Reviewed-by: Hersen Wu <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Fangzhi Zuo <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2023-03-29Merge patch series "RISC-V: Fixes for riscv_has_extension[un]likely()'s ↵Palmer Dabbelt3-30/+38
alternative dependency" Conor Dooley <[email protected]> says: Here's my attempt at fixing both the use of an FPU on XIP kernels and the issue that Jason ran into where CONFIG_FPU, which needs the alternatives frame work for has_fpu() checks, could be enabled without the alternatives actually being present. For the former, a "slow" fallback that does not use alternatives is added to riscv_has_extension_[un]likely() that can be used with XIP. Obviously, we want to make use of Jisheng's alternatives based approach where possible, so any users of riscv_has_extension_[un]likely() will want to make sure that they select RISCV_ALTERNATIVE. If they don't however, they'll hit the fallback path which (should, sparing a silly mistake from me!) behave in the same way, thus succeeding silently. Sounds like a To prevent "depends on !XIP_KERNEL; select RISCV_ALTERNATIVE" spreading like the plague through the various places that want to check for the presence of extensions, and sidestep the potential silent "success" mentioned above, all users RISCV_ALTERNATIVE are converted from selects to dependencies, with the option being selected for all !XIP_KERNEL builds. I know that the VDSO was a key place that Jisheng wanted to use the new helper rather than static branches, and I think the fallback path should not cause issues there. See the thread at [1] for the prior discussion. 1 - https://lore.kernel.org/linux-riscv/[email protected]/T/#m21390d570997145d31dd8bb95002fd61f99c6573 [Palmer: merging in the fixes as a branch as there's some features that depend on it.] * b4-shazam-merge: RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels RISC-V: add non-alternative fallback for riscv_has_extension_[un]likely() Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-03-29RISC-V: always select RISCV_ALTERNATIVE for non-xip kernelsConor Dooley2-10/+8
When moving switch_to's has_fpu() over to using riscv_has_extension_likely() rather than static branches, the FPU code gained a dependency on the alternatives framework. That dependency has now been removed, as riscv_has_extension_ikely() now contains a fallback path, using __riscv_isa_extension_available(), but if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu() checks will not benefit from the "fast path" that the alternatives framework provides. We want to ensure that alternatives are available whenever riscv_has_extension_[un]likely() is used, rather than silently falling back to the slow path, but rather than rely on selecting RISCV_ALTERNATIVE in the myriad of locations that may use riscv_has_extension_[un]likely(), select it (almost) always instead by adding it to the main RISCV config entry. xip kernels cannot make use of the alternatives framework, so it is not enabled for those configurations, although this is the status quo. All current sites that select RISCV_ALTERNATIVE are converted to dependencies on the option instead. The explicit dependencies on !XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable. Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()") Link: https://lore.kernel.org/all/[email protected]/ Reported-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-03-29RISC-V: add non-alternative fallback for riscv_has_extension_[un]likely()Conor Dooley1-20/+30
The has_fpu() check, which in turn calls riscv_has_extension_likely(), relies on alternatives to figure out whether the system has an FPU. As a result, it will malfunction on XIP kernels, as they do not support the alternatives mechanism. When alternatives support is not present, fall back to using __riscv_isa_extension_available() in riscv_has_extension_[un]likely() instead stead, which handily takes the same argument, so that kernels that do not support alternatives can accurately report the presence of FPU support. Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()") Link: https://lore.kernel.org/all/ad445951-3d13-4644-94d9-e0989cda39c3@spud/ Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.