5.10.250-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 5.10.250-rc1 review
This is the start of the stable review cycle for the 5.10.250 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.250-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.10.250-rc1
Varun Prakash <[email protected]>
nvmet-tcp: pass iov_len instead of sg->length to bvec_set_page()
Max Yuan <[email protected]>
gve: Correct ethtool rx_dropped calculation
Steven Rostedt <[email protected]>
tracing: Fix ftrace event field alignments
Debarghya Kundu <[email protected]>
gve: Fix stats report corruption on queue count change
Kaushlendra Kumar <[email protected]>
platform/x86: intel_telemetry: Fix swapped arrays in PSS output
Chris Bainbridge <[email protected]>
ASoC: amd: fix memory leak in acp3x pdm dma ops
YunJe Shin <[email protected]>
nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec
Fabio M. De Francesco <[email protected]>
nvmet-tcp: don't map pages which can't come from HIGHMEM
Sagi Grimberg <[email protected]>
nvmet-tcp: fix regression in data_digest calculation
Maurizio Lombardi <[email protected]>
nvmet-tcp: fix memory leak when performing a controller reset
Maurizio Lombardi <[email protected]>
nvmet-tcp: add an helper to free the cmd buffers
Arnd Bergmann <[email protected]>
hwmon: (occ) Mark occ_init_attribute() as __printf
Daniel Hodges <[email protected]>
tipc: use kfree_sensitive() for session key material
Eric Dumazet <[email protected]>
macvlan: fix error recovery in macvlan_common_newlink()
Zilin Guan <[email protected]>
net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanup
Zilin Guan <[email protected]>
net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanup
Zilin Guan <[email protected]>
net: liquidio: Initialize netdev pointer before queue setup
Kaushlendra Kumar <[email protected]>
platform/x86: intel_telemetry: Fix PSS event register mask
Rafael J. Wysocki <[email protected]>
platform/x86: toshiba_haps: Fix memory leaks in add/remove routines
Miri Korenblit <[email protected]>
wifi: mac80211: don't increment crypto_tx_tailroom_needed_cnt twice
Maurizio Lombardi <[email protected]>
scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()
Maurizio Lombardi <[email protected]>
scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()
Veerendranath Jakkam <[email protected]>
wifi: cfg80211: Fix bitrate calculation overflow for HE rates
Dimitrios Katsaros <[email protected]>
ASoC: tlv320adcx140: Propagate error codes during probe
Kery Qi <[email protected]>
ASoC: davinci-evm: Fix reference leak in davinci_evm_probe
Baochen Qiang <[email protected]>
wifi: mac80211: collect station statistics earlier when disconnect
Wupeng Ma <[email protected]>
ring-buffer: Avoid softlockup in ring_buffer_resize() during memory free
Rodrigo Lugathe da Conceição Alves <[email protected]>
HID: Apply quirk HID_QUIRK_ALWAYS_POLL to Edifier QR30 (2d99:a101)
Chris Chiu <[email protected]>
HID: quirks: Add another Chicony HP 5MP Cameras to hid_ignore_list
Ruslan Krupitsa <[email protected]>
ALSA: hda/realtek: add HP Laptop 15s-eq1xxx mute LED quirk
Zhang Lixu <[email protected]>
HID: intel-ish-hid: Reset enum_devices_done before enumeration
DaytonCL <[email protected]>
HID: multitouch: add MT_QUIRK_STICKY_FINGERS to MT_CLS_VTL
shechenglong <[email protected]>
block,bfq: fix aux stat accumulation destination
Ethan Nelson-Moore <[email protected]>
net: usb: sr9700: support devices with virtual driver CD
Peter Åstrand <[email protected]>
wifi: wlcore: ensure skb headroom before skb_push
Moon Hee Lee <[email protected]>
wifi: mac80211: ocb: skip rx_no_sta when interface is not joined
Carlos Llamas <[email protected]>
binderfs: fix ida_alloc_max() upper bound
Pablo Neira Ayuso <[email protected]>
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Sean Christopherson <[email protected]>
KVM: Don't clobber irqfd routing type when deassigning irqfd
Thomas Weissschuh <[email protected]>
ARM: 9468/1: fix memset64() on big-endian
Ilya Dryomov <[email protected]>
rbd: check for EOD after exclusive lock is ensured to be held
-------------
Diffstat:
Makefile | 4 +- arch/arm/include/asm/string.h | 5 +- block/bfq-cgroup.c | 2 +- drivers/android/binderfs.c | 8 +- drivers/block/rbd.c | 33 ++++--- drivers/hid/hid-ids.h | 4 + drivers/hid/hid-multitouch.c | 1 + drivers/hid/hid-quirks.c | 2 + drivers/hid/intel-ish-hid/ishtp-hid-client.c | 1 + drivers/hwmon/occ/common.c | 1 + drivers/net/ethernet/cavium/liquidio/lio_main.c | 39 ++++---- drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 4 +- drivers/net/ethernet/google/gve/gve_ethtool.c | 46 ++++++---- drivers/net/ethernet/google/gve/gve_main.c | 4 +- drivers/net/macvlan.c | 5 +- drivers/net/usb/sr9700.c | 5 ++ drivers/net/wireless/ti/wlcore/tx.c | 5 ++ drivers/nvme/target/tcp.c | 100 ++++++++++----------- drivers/platform/x86/intel_telemetry_debugfs.c | 4 +- drivers/platform/x86/intel_telemetry_pltdrv.c | 2 +- drivers/platform/x86/toshiba_haps.c | 2 +- drivers/target/iscsi/iscsi_target_util.c | 10 ++- kernel/trace/ring_buffer.c | 2 + kernel/trace/trace.h | 7 +- kernel/trace/trace_entries.h | 14 +-- kernel/trace/trace_export.c | 21 +++-- net/mac80211/key.c | 3 +- net/mac80211/ocb.c | 3 + net/mac80211/sta_info.c | 7 +- net/netfilter/nft_set_pipapo.c | 8 ++ net/tipc/crypto.c | 4 +- net/wireless/util.c | 8 +- sound/pci/hda/patch_realtek.c | 1 + sound/soc/amd/renoir/acp3x-pdm-dma.c | 2 + sound/soc/codecs/tlv320adcx140.c | 3 + sound/soc/ti/davinci-evm.c | 39 ++++++-- virt/kvm/eventfd.c | 34 +++---- 37 files changed, 272 insertions(+), 171 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/41 rbd: check for EOD after exclusive lock is ensured to be held
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit bd3884a204c3b507e6baa9a4091aa927f9af5404 upstream.
Similar to commit 870611e4877e ("rbd: get snapshot context after exclusive lock is ensured to be held"), move the "beyond EOD" check into the image request state machine so that it's performed after exclusive lock is ensured to be held. This avoids various race conditions which can arise when the image is shrunk under I/O (in practice, mostly readahead). In one such scenario
rbd_assert(objno < rbd_dev->object_map_size);
can be triggered if a close-to-EOD read gets queued right before the shrink is initiated and the EOD check is performed against an outdated mapping_size. After the resize is done on the server side and exclusive lock is (re)acquired bringing along the new (now shrunk) object map, the read starts going through the state machine and rbd_obj_may_exist() gets invoked on an object that is out of bounds of rbd_dev->object_map array.
--- drivers/block/rbd.c | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-)
drivers/block/rbd.c +21 -12
@@ -3560,11 +3560,29 @@ static void rbd_img_object_requests(strurbd_assert (!need_exclusive_lock (img_req) ||__rbd_is_lock_owner (rbd_dev)); -if (rbd_img_is_write (img_req)) { -rbd_assert (!img_req->snapc); +if (test_bit (IMG_REQ_CHILD , &img_req->flags)) { +rbd_assert (!rbd_img_is_write (img_req)); + }else { +struct request *rq =blk_mq_rq_from_pdu (img_req); +u64 off = (u64 )blk_rq_pos (rq) <<SECTOR_SHIFT ; +u64 len =blk_rq_bytes (rq); +u64 mapping_size; +down_read (&rbd_dev->header_rwsem); - img_req->snapc =ceph_get_snap_context (rbd_dev->header.snapc); + mapping_size = rbd_dev->mapping.size; +if (rbd_img_is_write (img_req)) { +rbd_assert (!img_req->snapc); + img_req->snapc = +ceph_get_snap_context (rbd_dev->header.snapc); + }up_read (&rbd_dev->header_rwsem); + +if (unlikely (off + len > mapping_size)) { +rbd_warn (rbd_dev,"beyond EOD (%llu~%llu > %llu)" , + off, len, mapping_size); + img_req->pending.result = -EIO ; +return ; + } }for_each_obj_request (img_req, obj_req) {
@@ -4781,7 +4799,6 @@ static void rbd_queue_workfn(struct workstruct request *rq =blk_mq_rq_from_pdu (img_request);u64 offset = (u64 )blk_rq_pos (rq) <<SECTOR_SHIFT ;u64 length =blk_rq_bytes (rq); -u64 mapping_size;int result;/* Ignore/skip any zero-length requests */
@@ -4794,17 +4811,9 @@ static void rbd_queue_workfn(struct workblk_mq_start_request (rq);down_read (&rbd_dev->header_rwsem); - mapping_size = rbd_dev->mapping.size;rbd_img_capture_header (img_request);up_read (&rbd_dev->header_rwsem); -if (offset + length > mapping_size) { -rbd_warn (rbd_dev,"beyond EOD (%llu~%llu > %llu)" , offset, - length, mapping_size); - result = -EIO ; - goto err_img_request; - } -dout ("%s rbd_dev %p img_req %p %s %llu~%llu\n" , __func__, rbd_dev, img_request,obj_op_name (op_type), offset, length);
Greg Kroah-Hartman
maintainerPATCH 2/41 ARM: 9468/1: fix memset64() on big-endian
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Weissschuh <[email protected]>
commit 23ea2a4c72323feb6e3e025e8a6f18336513d5ad upstream.
On big-endian systems the 32-bit low and high halves need to be swapped for the underlying assembly implementation to work correctly.
--- arch/arm/include/asm/string.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
arch/arm/include/asm/string.h +4 -1
@@ -36,7 +36,10 @@ static inline void *memset32(uint32_t *pextern void *__memset64 (uint64_t *,uint32_t low,__kernel_size_t ,uint32_t hi);static inline void *memset64 (uint64_t *p,uint64_t v,__kernel_size_t n) { -return __memset64 (p, v, n *8 , v >>32 ); +if (IS_ENABLED (CONFIG_CPU_LITTLE_ENDIAN )) +return __memset64 (p, v, n *8 , v >>32 ); +else +return __memset64 (p, v >>32 , n *8 , v); }#endif
Re: [PATCH 5.10 02/41] ARM: 9468/1: fix memset64() on big-endian
Quoted 10 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Weissschuh <[email protected]>
commit
23ea2a4c72323feb6e3e025e8a6f18336513d5adupstream.On big-endian systems the 32-bit low and high halves need to be swapped for the underlying assembly implementation to work correctly.
Now it's broken on little-endian, because CONFIG_CPU_LITTLE_ENDIAN was only introduced in 5.19.
For 5.10 and 5.15, please revert this or change the condition to !IS_ENABLED(CONFIG_CPU_BIG_ENDIAN).
Ben.
Quoted 28 lines
Fixes fd1d362600e2 ("ARM: implement memset32 & memset64")Signed-off-by Thomas Weißschuh <[email protected]>Reviewed-by Matthew Wilcox (Oracle) <[email protected]>Reviewed-by Arnd Bergmann <[email protected]>Signed-off-by Russell King (Oracle) <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- arch/arm/include/asm/string.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)arch/arm/include/asm/string.h +4
-1@@ -36,7 +36,10 @@ static inline void *memset32(uint32_t *pextern void *__memset64 (uint64_t *,uint32_t low,__kernel_size_t ,uint32_t hi);static inline void *memset64 (uint64_t *p,uint64_t v,__kernel_size_t n) { -return __memset64 (p, v, n *8 , v >>32 ); +if (IS_ENABLED (CONFIG_CPU_LITTLE_ENDIAN )) +return __memset64 (p, v, n *8 , v >>32 ); +else +return __memset64 (p, v >>32 , n *8 , v); }#endif
Signature · 2 lines
Ben Hutchings Who are all these weirdos? - David Bowie, on joining IRC
Re: [PATCH 5.10 02/41] ARM: 9468/1: fix memset64() on big-endian
Quoted 9 lines · Ben Hutchings
Quoted 8 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Weissschuh <[email protected]>
commit
23ea2a4c72323feb6e3e025e8a6f18336513d5adupstream.
Quoted 8 lines
Quoted 2 lines
On big-endian systems the 32-bit low and high halves need to be swapped for the underlying assembly implementation to work correctly.
Now it's broken on little-endian, because
CONFIG_CPU_LITTLE_ENDIANwas only introduced in 5.19.For 5.10 and 5.15, please revert this or change the condition to !IS_ENABLED(CONFIG_CPU_BIG_ENDIAN).
Probably best to pull in the version Linus preferred:
Greg Kroah-Hartman
maintainerPATCH 3/41 KVM: Dont clobber irqfd routing type when deassigning irqfd
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit b4d37cdb77a0015f51fee083598fa227cc07aaf1 upstream.
When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone.
As a bonus, checking that the irqfd is active provides a convenient location for documenting _why_ KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens *before* the eventfd is detached), it will no longer receive updates via kvm_irq_routing_update(), and so KVM could deliver an event using stale routing information (relative to KVM_SET_GSI_ROUTING returning to userspace).
As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information.
As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd.
Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irq_bypass_data being NULL when read by avic_update_iommu_vcpu_affinity():
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0
Oops: Oops: 0000 [#1] SMP
CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test
Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE
Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025
RIP: 0010:amd_iommu_update_ga+0x19/0xe0
Call Trace:
<TASK>
avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]
__avic_vcpu_load+0xf4/0x130 [kvm_amd]
kvm_arch_vcpu_load+0x89/0x210 [kvm]
vcpu_load+0x30/0x40 [kvm]
kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]
kvm_vcpu_ioctl+0x571/0x6a0 [kvm]
__se_sys_ioctl+0x6d/0xb0
do_syscall_64+0x6f/0x9d0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x46893b
</TASK>
---[ end trace 0000000000000000 ]---If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment.
list_add corruption. next->prev should be prev (ffff8d474d5cd588),
but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: <TASK> avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypass] kvm_irqfd+0x4c6/0x540 [kvm] kvm_vm_ioctl+0x118/0x5d0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
On Intel and arm64, the bug is less noisy, as the end result is that the device keeps posting IRQs to the vCPU even after it's been deassigned.
Note, the worst of the breakage can be traced back to commit cb210737675e ("KVM: Pass new routing entries and irqfd when updating IRTEs"), as before that commit KVM would pull the routing information from the per-VM routing table. But as above, similar bugs have existed since support for IRQ bypass was added. E.g. if a routing change finished before irq_shutdown() invoked kvm_arch_irq_bypass_del_producer(), VMX and SVM would see stale routing information and potentially leave the irqfd in bypass mode.
Alternatively, x86 could be fixed by explicitly checking irq_bypass_vcpu instead of irq_entry.type in kvm_arch_irq_bypass_del_producer(), and arm64 could be modified to utilize irq_bypass_vcpu in a similar manner. But (a) that wouldn't fix the routing updates bug, and (b) fixing core code doesn't preclude x86 (or arm64) from adding such code as a sanity check (spoiler alert).
--- virt/kvm/eventfd.c | 34 ++++++++++++++-------------------- 1 file changed, 14 insertions(+), 20 deletions(-)
virt/kvm/eventfd.c +14 -20
@@ -147,21 +147,18 @@ irqfd_shutdown(struct work_struct *work) } -/* assumes kvm->irqfds.lock is held */ -static bool -irqfd_is_active (struct kvm_kernel_irqfd *irqfd) +static bool irqfd_is_active (struct kvm_kernel_irqfd *irqfd) {return list_empty (&irqfd->list) ? false : true; }/* * Mark the irqfd as inactive and schedule it for removal -* -* assumes kvm->irqfds.lock is held */ -static void -irqfd_deactivate (struct kvm_kernel_irqfd *irqfd) +static void irqfd_deactivate (struct kvm_kernel_irqfd *irqfd) { +lockdep_assert_held (&irqfd->kvm->irqfds.lock); +BUG_ON (!irqfd_is_active (irqfd));list_del_init (&irqfd->list);
@@ -198,8 +195,15 @@ irqfd_wakeup(wait_queue_entry_t *wait, u seq =read_seqcount_begin (&irqfd->irq_entry_sc); irq = irqfd->irq_entry; }while (read_seqcount_retry (&irqfd->irq_entry_sc, seq)); -/* An event has been signaled, inject an interrupt */ -if (kvm_arch_set_irq_inatomic (&irq, kvm, + +/* +* An event has been signaled, inject an interrupt unless the +* irqfd is being deassigned (isn't active), in which case the +* routing information may be stale (once the irqfd is removed +* from the list, it will stop receiving routing updates). +*/ +if (unlikely (!irqfd_is_active (irqfd)) || +kvm_arch_set_irq_inatomic (&irq, kvm,KVM_USERSPACE_IRQ_SOURCE_ID ,1 , false) == -EWOULDBLOCK )schedule_work (&irqfd->inject);
@@ -536,18 +540,8 @@ kvm_irqfd_deassign(struct kvm *kvm, struspin_lock_irq (&kvm->irqfds.lock);list_for_each_entry_safe (irqfd, tmp, &kvm->irqfds.items, list) { -if (irqfd->eventfd == eventfd && irqfd->gsi == args->gsi) { -/* -* This clearing of irq_entry.type is needed for when -* another thread calls kvm_irq_routing_update before -* we flush workqueue below (we synchronize with -* kvm_irq_routing_update using irqfds.lock). -*/ -write_seqcount_begin (&irqfd->irq_entry_sc); - irqfd->irq_entry.type =0 ; -write_seqcount_end (&irqfd->irq_entry_sc); +if (irqfd->eventfd == eventfd && irqfd->gsi == args->gsi)irqfd_deactivate (irqfd); - } }spin_unlock_irq (&kvm->irqfds.lock);
Greg Kroah-Hartman
maintainerPATCH 4/41 netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit b85e3367a5716ed3662a4fe266525190d2af76df upstream.
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")
--- net/netfilter/nft_set_pipapo.c | 8 ++++++++ 1 file changed, 8 insertions(+)
net/netfilter/nft_set_pipapo.c +8 -0
@@ -665,6 +665,11 @@ static int pipapo_resize(struct nft_pipa } mt: +if (rules > (INT_MAX /sizeof (*new_mt))) { +kvfree (new_lt); +return -ENOMEM ; + } + new_mt =kvmalloc (rules *sizeof (*new_mt),GFP_KERNEL );if (!new_mt) {kvfree (new_lt);
@@ -1358,6 +1363,9 @@ static struct nft_pipapo_match *pipapo_c src->bsize *sizeof (*dst->lt) * src->groups * NFT_PIPAPO_BUCKETS(src->bb)); +if (src->rules > (INT_MAX /sizeof (*src->mt))) + goto out_mt; + dst->mt =kvmalloc (src->rules *sizeof (*src->mt),GFP_KERNEL );if (!dst->mt) goto out_mt;
Greg Kroah-Hartman
maintainerPATCH 5/41 binderfs: fix ida_alloc_max() upper bound
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Carlos Llamas <[email protected]>
commit ec4ddc90d201d09ef4e4bef8a2c6d9624525ad68 upstream.
The 'max' argument of ida_alloc_max() takes the maximum valid ID and not the "count". Using an ID of BINDERFS_MAX_MINOR (1 << 20) for dev->minor would exceed the limits of minor numbers (20-bits). Fix this off-by-one error by subtracting 1 from the 'max'.
--- drivers/android/binderfs.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/android/binderfs.c +4 -4
@@ -122,8 +122,8 @@ static int binderfs_binder_device_createmutex_lock (&binderfs_minors_mutex);if (++info->device_count <= info->mount_opts.max) minor =ida_alloc_max (&binderfs_minors, - use_reserve ?BINDERFS_MAX_MINOR : -BINDERFS_MAX_MINOR_CAPPED , + use_reserve ?BINDERFS_MAX_MINOR -1 : +BINDERFS_MAX_MINOR_CAPPED -1 ,GFP_KERNEL );else minor = -ENOSPC ;
@@ -423,8 +423,8 @@ static int binderfs_binder_ctl_create(st/* Reserve a new minor number for the new device. */ mutex_lock (&binderfs_minors_mutex); minor =ida_alloc_max (&binderfs_minors, - use_reserve ?BINDERFS_MAX_MINOR : -BINDERFS_MAX_MINOR_CAPPED , + use_reserve ?BINDERFS_MAX_MINOR -1 : +BINDERFS_MAX_MINOR_CAPPED -1 ,GFP_KERNEL );mutex_unlock (&binderfs_minors_mutex);if (minor <0 ) {
Greg Kroah-Hartman
maintainerPATCH 6/41 wifi: mac80211: ocb: skip rx_no_sta when interface is not joined
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Moon Hee Lee <[email protected]>
[ Upstream commit ff4071c60018a668249dc6a2df7d16330543540e ]
ieee80211_ocb_rx_no_sta() assumes a valid channel context, which is only present after JOIN_OCB.
RX may run before JOIN_OCB is executed, in which case the OCB interface is not operational. Skip RX peer handling when the interface is not joined to avoid warnings in the RX path.
--- net/mac80211/ocb.c | 3 +++ 1 file changed, 3 insertions(+)
net/mac80211/ocb.c +3 -0
@@ -47,6 +47,9 @@ void ieee80211_ocb_rx_no_sta(struct ieee80211_sub_if_data *sdata,struct sta_info *sta;int band; +if (!ifocb->joined) +return ; +/* XXX: Consider removing the least recently used entry and * allow new one to be added. */
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 7/41 wifi: wlcore: ensure skb headroom before skb_push
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Åstrand <[email protected]>
[ Upstream commit e75665dd096819b1184087ba5718bd93beafff51 ]
This avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom is less than needed (typically 110 - 94 = 16 bytes).
--- drivers/net/wireless/ti/wlcore/tx.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/wireless/ti/wlcore/tx.c +5 -0
@@ -210,6 +210,11 @@ static int wl1271_tx_allocate(struct wl1271 *wl, struct wl12xx_vif *wlvif, total_blocks =wlcore_hw_calc_tx_blocks (wl, total_len, spare_blocks);if (total_blocks <= wl->tx_blocks_available) { +if (skb_headroom (skb) < (total_len - skb->len) && +pskb_expand_head (skb, (total_len - skb->len),0 ,GFP_ATOMIC )) { +wl1271_free_tx_id (wl, id); +return -EAGAIN ; + } desc =skb_push (skb, total_len - skb->len); wlcore_hw_set_tx_desc_blocks(wl, desc, total_blocks,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 8/41 net: usb: sr9700: support devices with virtual driver CD
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ethan Nelson-Moore <[email protected]>
[ Upstream commit bf4172bd870c3a34d3065cbb39192c22cbd7b18d ]
Some SR9700 devices have an SPI flash chip containing a virtual driver CD, in which case they appear as a device with two interfaces and product ID 0x9702. Interface 0 is the driver CD and interface 1 is the Ethernet device.
--- drivers/net/usb/sr9700.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/usb/sr9700.c +5 -0
@@ -538,6 +538,11 @@ static const struct usb_device_id products[] = { USB_DEVICE(0x0fe6, 0x9700), /* SR9700 device */ .driver_info = (unsigned long)&sr9700_driver_info, }, + { +/* SR9700 with virtual driver CD-ROM - interface 0 is the CD-ROM device */ + USB_DEVICE_INTERFACE_NUMBER(0x0fe6, 0x9702, 1), + .driver_info = (unsigned long)&sr9700_driver_info, + }, {}, /* END */ };
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 9/41 block,bfq: fix aux stat accumulation destination
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: shechenglong <[email protected]>
[ Upstream commit 04bdb1a04d8a2a89df504c1e34250cd3c6e31a1c ]
Route bfqg_stats_add_aux() time accumulation into the destination stats object instead of the source, aligning with other stat fields.
--- block/bfq-cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
block/bfq-cgroup.c +1 -1
@@ -387,7 +387,7 @@ static void bfqg_stats_add_aux(struct bfqg_stats *to, struct bfqg_stats *from)blkg_rwstat_add_aux (&to->merged, &from->merged);blkg_rwstat_add_aux (&to->service_time, &from->service_time);blkg_rwstat_add_aux (&to->wait_time, &from->wait_time); -bfq_stat_add_aux (&from->time, &from->time); +bfq_stat_add_aux (&to->time, &from->time);bfq_stat_add_aux (&to->avg_queue_size_sum, &from->avg_queue_size_sum);bfq_stat_add_aux (&to->avg_queue_size_samples, &from->avg_queue_size_samples);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 10/41 HID: multitouch: add MT_QUIRK_STICKY_FINGERS to MT_CLS_VTL
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: DaytonCL <[email protected]>
[ Upstream commit ff3f234ff1dcd6d626a989151db067a1b7f0f215 ]
Some VTL-class touchpads (e.g. TOPS0102:00 35CC:0104) intermittently fail to release a finger contact. A previous slot remains logically active, accompanied by stale BTN_TOOL_DOUBLETAP state, causing gestures to stay latched and resulting in stuck two-finger scrolling and false right-clicks.
Apply MT_QUIRK_STICKY_FINGERS to handle the unreleased contact correctly.
--- drivers/hid/hid-multitouch.c | 1 + 1 file changed, 1 insertion(+)
drivers/hid/hid-multitouch.c +1 -0
@@ -349,6 +349,7 @@ static const struct mt_class mt_classes[] = { { .name = MT_CLS_VTL, .quirks = MT_QUIRK_ALWAYS_VALID | MT_QUIRK_CONTACT_CNT_ACCURATE | + MT_QUIRK_STICKY_FINGERS | MT_QUIRK_FORCE_GET_FEATURE, }, { .name = MT_CLS_GOOGLE,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 11/41 HID: intel-ish-hid: Reset enum_devices_done before enumeration
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Lixu <[email protected]>
[ Upstream commit 56e230723e3a818373bd62331bccb1c6d2b3881b ]
Some systems have enabled ISH without any sensors. In this case sending HOSTIF_DM_ENUM_DEVICES results in 0 sensors. This triggers ISH hardware reset on subsequent enumeration after S3/S4 resume.
The enum_devices_done flag was not reset before sending the HOSTIF_DM_ENUM_DEVICES command. On subsequent enumeration calls (such as after S3/S4 resume), this flag retains its previous true value, causing the wait loop to be skipped and returning prematurely to hid_ishtp_cl_init(). If 0 HID devices are found, hid_ishtp_cl_init() skips getting HID device descriptors and sets init_done to true. When the delayed enumeration response arrives with init_done already true, the driver treats it as a bad packet and triggers an ISH hardware reset.
Set enum_devices_done to false before sending the enumeration command, consistent with similar functions like ishtp_get_hid_descriptor() and ishtp_get_report_descriptor() which reset their respective flags.
--- drivers/hid/intel-ish-hid/ishtp-hid-client.c | 1 + 1 file changed, 1 insertion(+)
drivers/hid/intel-ish-hid/ishtp-hid-client.c +1 -0
@@ -488,6 +488,7 @@ static int ishtp_enum_enum_devices(struct ishtp_cl *hid_ishtp_cl)int rv;/* Send HOSTIF_DM_ENUM_DEVICES */ + client_data->enum_devices_done = false;memset (&msg,0 ,sizeof (struct hostif_msg )); msg.hdr.command =HOSTIF_DM_ENUM_DEVICES ; rv = ishtp_cl_send(hid_ishtp_cl, (unsigned char *)&msg,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 12/41 ALSA: hda/realtek: add HP Laptop 15s-eq1xxx mute LED quirk
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ruslan Krupitsa <[email protected]>
[ Upstream commit 9ed7a28225af02b74f61e7880d460db49db83758 ]
HP Laptop 15s-eq1xxx with ALC236 codec does not enable the mute LED automatically. This patch adds a quirk entry for subsystem ID 0x8706 using the ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup, enabling correct mute LED behavior.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -9270,6 +9270,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {SND_PCI_QUIRK (0x103c ,0x863e ,"HP Spectre x360 15-df1xxx" ,ALC285_FIXUP_HP_SPECTRE_X360_DF1 ),SND_PCI_QUIRK (0x103c ,0x86e8 ,"HP Spectre x360 15-eb0xxx" ,ALC285_FIXUP_HP_SPECTRE_X360_EB1 ),SND_PCI_QUIRK (0x103c ,0x86f9 ,"HP Spectre x360 13-aw0xxx" ,ALC285_FIXUP_HP_SPECTRE_X360_MUTE_LED ), +SND_PCI_QUIRK (0x103c ,0x8706 ,"HP Laptop 15s-eq1xxx" ,ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 ),SND_PCI_QUIRK (0x103c ,0x8716 ,"HP Elite Dragonfly G2 Notebook PC" ,ALC285_FIXUP_HP_GPIO_AMP_INIT ),SND_PCI_QUIRK (0x103c ,0x8720 ,"HP EliteBook x360 1040 G8 Notebook PC" ,ALC285_FIXUP_HP_GPIO_AMP_INIT ), SND_PCI_QUIRK(0x103c, 0x8724, "HP EliteBook 850 G7", ALC285_FIXUP_HP_GPIO_LED),
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 13/41 HID: quirks: Add another Chicony HP 5MP Cameras to hid_ignore_list
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Chiu <[email protected]>
[ Upstream commit c06bc3557542307b9658fbd43cc946a14250347b ]
Another Chicony Electronics HP 5MP Camera with USB ID 04F2:B882 reports a HID sensor interface that is not actually implemented.
Add the device to the HID ignore list so the bogus sensor is never exposed to userspace. Then the system won't hang when runtime PM tries to wake the unresponsive device.
--- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-quirks.c | 1 + 2 files changed, 2 insertions(+)
drivers/hid/hid-ids.h +1 -0
@@ -280,6 +280,7 @@#define USB_DEVICE_ID_CHICONY_ACER_SWITCH12 0x1421#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA 0xb824#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2 0xb82c +#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3 0xb882#define USB_VENDOR_ID_CHUNGHWAT 0x2247#define USB_DEVICE_ID_CHUNGHWAT_MULTITOUCH 0x0001
drivers/hid/hid-quirks.c +1 -0
@@ -738,6 +738,7 @@ static const struct hid_device_id hid_ignore_list[] = { { HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD) }, { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA) }, { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2) }, + { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3) }, { HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) }, { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_RADIO_SI470X) }, { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 14/41 HID: Apply quirk HID_QUIRK_ALWAYS_POLL to Edifier QR30 (2d99:a101)
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rodrigo Lugathe da Conceição Alves <[email protected]>
[ Upstream commit 85a866809333cd2bf8ddac93d9a3e3ba8e4f807d ]
The USB speaker has a bug that causes it to reboot when changing the brightness using the physical knob.
Add a new vendor and product ID entry in hid-ids.h, and register the corresponding device in hid-quirks.c with the required quirk.
--- drivers/hid/hid-ids.h | 3 +++ drivers/hid/hid-quirks.c | 1 + 2 files changed, 4 insertions(+)
drivers/hid/hid-ids.h +3 -0
@@ -397,6 +397,9 @@#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001 0xa001#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002 0xc002 +#define USB_VENDOR_ID_EDIFIER 0x2d99 +#define USB_DEVICE_ID_EDIFIER_QR30 0xa101/* EDIFIER Hal0 2.0 SE */ +#define USB_VENDOR_ID_ELAN 0x04f3#define USB_DEVICE_ID_TOSHIBA_CLICK_L9W 0x0401#define USB_DEVICE_ID_HP_X2 0x074d
drivers/hid/hid-quirks.c +1 -0
@@ -81,6 +81,7 @@ static const struct hid_device_id hid_quirks[] = { { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_PS3), HID_QUIRK_MULTI_INPUT }, { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU), HID_QUIRK_MULTI_INPUT }, { HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER), HID_QUIRK_MULTI_INPUT | HID_QUIRK_NOGET }, + { HID_USB_DEVICE(USB_VENDOR_ID_EDIFIER, USB_DEVICE_ID_EDIFIER_QR30), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_ELAN, HID_ANY_ID), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700), HID_QUIRK_NOGET }, { HID_USB_DEVICE(USB_VENDOR_ID_EMS, USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II), HID_QUIRK_MULTI_INPUT },
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 15/41 ring-buffer: Avoid softlockup in ring_buffer_resize() during memory free
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wupeng Ma <[email protected]>
[ Upstream commit 6435ffd6c7fcba330dfa91c58dc30aed2df3d0bf ]
When user resize all trace ring buffer through file 'buffer_size_kb', then in ring_buffer_resize(), kernel allocates buffer pages for each cpu in a loop.
If the kernel preemption model is PREEMPT_NONE and there are many cpus and there are many buffer pages to be freed, it may not give up cpu for a long time and finally cause a softlockup.
To avoid it, call cond_resched() after each cpu buffer free as Commit f6bd2c92488c ("ring-buffer: Avoid softlockup in ring_buffer_resize()") does.
Detailed call trace as follow:
rcu: INFO: rcu_sched self-detected stall on CPU rcu: 24-....: (14837 ticks this GP) idle=521c/1/0x4000000000000000 softirq=230597/230597 fqs=5329 rcu: (t=15004 jiffies g=26003221 q=211022 ncpus=96) CPU: 24 UID: 0 PID: 11253 Comm: bash Kdump: loaded Tainted: G EL 6.18.2+ #278 NONE pc : arch_local_irq_restore+0x8/0x20 arch_local_irq_restore+0x8/0x20 (P) free_frozen_page_commit+0x28c/0x3b0 __free_frozen_pages+0x1c0/0x678 ___free_pages+0xc0/0xe0 free_pages+0x3c/0x50 ring_buffer_resize.part.0+0x6a8/0x880 ring_buffer_resize+0x3c/0x58 __tracing_resize_ring_buffer.part.0+0x34/0xd8 tracing_resize_ring_buffer+0x8c/0xd0 tracing_entries_write+0x74/0xd8 vfs_write+0xcc/0x288 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38
--- kernel/trace/ring_buffer.c | 2 ++ 1 file changed, 2 insertions(+)
kernel/trace/ring_buffer.c +2 -0
@@ -2255,6 +2255,8 @@ int ring_buffer_resize(struct trace_buffer *buffer, unsigned long size, list) {list_del_init (&bpage->list);free_buffer_page (bpage); + +cond_resched (); } } out_err_unlock:
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 16/41 wifi: mac80211: collect station statistics earlier when disconnect
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baochen Qiang <[email protected]>
[ Upstream commit a203dbeeca15a9b924f0d51f510921f4bae96801 ]
In __sta_info_destroy_part2(), station statistics are requested after the IEEE80211_STA_NONE -> IEEE80211_STA_NOTEXIST transition. This is problematic because the driver may be unable to handle the request due to the STA being in the NOTEXIST state (i.e. if the driver destroys the underlying data when transitioning to NOTEXIST).
Move the statistics collection to before the state transition to avoid this issue.
--- net/mac80211/sta_info.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/mac80211/sta_info.c +4 -3
@@ -1105,6 +1105,10 @@ static void __sta_info_destroy_part2(struct sta_info *sta) } } + sinfo =kzalloc (sizeof (*sinfo),GFP_KERNEL ); +if (sinfo) +sta_set_sinfo (sta, sinfo, true); +if (sta->uploaded) { ret =drv_sta_state (local, sdata, sta,IEEE80211_STA_NONE ,IEEE80211_STA_NOTEXIST );
@@ -1113,9 +1117,6 @@ static void __sta_info_destroy_part2(struct sta_info *sta)sta_dbg (sdata,"Removed STA %pM\n" , sta->sta.addr); - sinfo =kzalloc (sizeof (*sinfo),GFP_KERNEL ); -if (sinfo) -sta_set_sinfo (sta, sinfo, true);cfg80211_del_sta_sinfo (sdata->dev, sta->sta.addr, sinfo,GFP_KERNEL );kfree (sinfo);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 17/41 ASoC: davinci-evm: Fix reference leak in davinci_evm_probe
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kery Qi <[email protected]>
[ Upstream commit 5b577d214fcc109707bcb77b4ae72a31cfd86798 ]
The davinci_evm_probe() function calls of_parse_phandle() to acquire device nodes for "ti,audio-codec" and "ti,mcasp-controller". These functions return device nodes with incremented reference counts.
However, in several error paths (e.g., when the second of_parse_phandle(), snd_soc_of_parse_card_name(), or devm_snd_soc_register_card() fails), the function returns directly without releasing the acquired nodes, leading to reference leaks.
This patch adds an error handling path 'err_put' to properly release the device nodes using of_node_put() and clean up the pointers when an error occurs.
--- sound/soc/ti/davinci-evm.c | 39 ++++++++++++++++++++++++++++++-------- 1 file changed, 31 insertions(+), 8 deletions(-)
sound/soc/ti/davinci-evm.c +31 -8
@@ -405,27 +405,32 @@ static int davinci_evm_probe(struct platform_device *pdev)return -EINVAL ; dai->cpus->of_node =of_parse_phandle (np,"ti,mcasp-controller" ,0 ); -if (!dai->cpus->of_node) -return -EINVAL ; +if (!dai->cpus->of_node) { + ret = -EINVAL ; + goto err_put; + } dai->platforms->of_node = dai->cpus->of_node; evm_soc_card.dev = &pdev->dev; ret =snd_soc_of_parse_card_name (&evm_soc_card,"ti,model" );if (ret) -return ret; + goto err_put; mclk =devm_clk_get (&pdev->dev,"mclk" );if (PTR_ERR (mclk) == -EPROBE_DEFER ) { -return -EPROBE_DEFER ; + ret = -EPROBE_DEFER ; + goto err_put; }else if (IS_ERR (mclk)) {dev_dbg (&pdev->dev,"mclk not found.\n" ); mclk =NULL ; } drvdata =devm_kzalloc (&pdev->dev,sizeof (*drvdata),GFP_KERNEL ); -if (!drvdata) -return -ENOMEM ; +if (!drvdata) { + ret = -ENOMEM ; + goto err_put; + } drvdata->mclk = mclk;
@@ -435,7 +440,8 @@ static int davinci_evm_probe(struct platform_device *pdev)if (!drvdata->mclk) {dev_err (&pdev->dev,"No clock or clock rate defined.\n" ); -return -EINVAL ; + ret = -EINVAL ; + goto err_put; } drvdata->sysclk =clk_get_rate (drvdata->mclk); }else if (drvdata->mclk) {
@@ -451,8 +457,25 @@ static int davinci_evm_probe(struct platform_device *pdev)snd_soc_card_set_drvdata (&evm_soc_card, drvdata); ret =devm_snd_soc_register_card (&pdev->dev, &evm_soc_card); -if (ret) +if (ret) {dev_err (&pdev->dev,"snd_soc_register_card failed (%d)\n" , ret); + goto err_put; + } + +return ret; + +err_put: + dai->platforms->of_node =NULL ; + +if (dai->cpus->of_node) { +of_node_put (dai->cpus->of_node); + dai->cpus->of_node =NULL ; + } + +if (dai->codecs->of_node) { +of_node_put (dai->codecs->of_node); + dai->codecs->of_node =NULL ; + }return ret; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 18/41 ASoC: tlv320adcx140: Propagate error codes during probe
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dimitrios Katsaros <[email protected]>
[ Upstream commit d89aad92cfd15edbd704746f44c98fe687f9366f ]
When scanning for the reset pin, we could get an -EPROBE_DEFER. The driver would assume that no reset pin had been defined, which would mean that the chip would never be powered.
Now we both respect any error we get from devm_gpiod_get_optional. We also now properly report the missing GPIO definition when 'gpio_reset' is NULL.
--- sound/soc/codecs/tlv320adcx140.c | 3 +++ 1 file changed, 3 insertions(+)
sound/soc/codecs/tlv320adcx140.c +3 -0
@@ -1096,6 +1096,9 @@ static int adcx140_i2c_probe(struct i2c_client *i2c, adcx140->gpio_reset =devm_gpiod_get_optional (adcx140->dev,"reset" ,GPIOD_OUT_LOW );if (IS_ERR (adcx140->gpio_reset)) +return dev_err_probe (&i2c->dev,PTR_ERR (adcx140->gpio_reset), +"Failed to get Reset GPIO\n" ); +if (!adcx140->gpio_reset)dev_info (&i2c->dev,"Reset GPIO not defined\n" ); adcx140->supply_areg = devm_regulator_get_optional(adcx140->dev,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 19/41 wifi: cfg80211: Fix bitrate calculation overflow for HE rates
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Veerendranath Jakkam <[email protected]>
[ Upstream commit a3034bf0746d88a00cceda9541534a5721445a24 ]
An integer overflow occurs in cfg80211_calculate_bitrate_he() when calculating bitrates for high throughput HE configurations. For example, with 160 MHz bandwidth, HE-MCS 13, HE-NSS 4, and HE-GI 0, the multiplication (result * rate->nss) overflows the 32-bit 'result' variable before division by 8, leading to significantly underestimated bitrate values.
The overflow occurs because the NSS multiplication operates on a 32-bit integer that cannot accommodate intermediate values exceeding 4,294,967,295. When overflow happens, the value wraps around, producing incorrect bitrates for high MCS and NSS combinations.
Fix this by utilizing the 64-bit 'tmp' variable for the NSS multiplication and subsequent divisions via do_div(). This approach preserves full precision throughout the entire calculation, with the final value assigned to 'result' only after completing all operations.
--- net/wireless/util.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
net/wireless/util.c +5 -3
@@ -1389,12 +1389,14 @@ static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate) tmp = result; tmp *=SCALE ;do_div (tmp, mcs_divisors[rate->mcs]); - result = tmp;/* and take NSS, DCM into account */ - result = (result * rate->nss) /8 ; + tmp *= rate->nss; +do_div (tmp,8 );if (rate->he_dcm) - result /=2 ; +do_div (tmp,2 ); + + result = tmp;return result /10000 ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 20/41 scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maurizio Lombardi <[email protected]>
[ Upstream commit 84dc6037390b8607c5551047d3970336cb51ba9a ]
In iscsit_dec_session_usage_count(), the function calls complete() while holding the sess->session_usage_lock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsit_session structure immediately.
This creates a race condition where the current thread may attempt to execute spin_unlock_bh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.
To resolve this, release the session_usage_lock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.
--- drivers/target/iscsi/iscsi_target_util.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/target/iscsi/iscsi_target_util.c +4 -1
@@ -801,8 +801,11 @@ void iscsit_dec_session_usage_count(struct iscsi_session *sess)spin_lock_bh (&sess->session_usage_lock); sess->session_usage_count--; -if (!sess->session_usage_count && sess->session_waiting_on_uc) +if (!sess->session_usage_count && sess->session_waiting_on_uc) { +spin_unlock_bh (&sess->session_usage_lock);complete (&sess->session_waiting_on_uc_comp); +return ; + }spin_unlock_bh (&sess->session_usage_lock); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 21/41 scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maurizio Lombardi <[email protected]>
[ Upstream commit 9411a89e9e7135cc459178fa77a3f1d6191ae903 ]
In iscsit_dec_conn_usage_count(), the function calls complete() while holding the conn->conn_usage_lock. As soon as complete() is invoked, the waiter (such as iscsit_close_connection()) may wake up and proceed to free the iscsit_conn structure.
If the waiter frees the memory before the current thread reaches spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function attempts to release a lock within the already-freed connection structure.
Fix this by releasing the spinlock before calling complete().
--- drivers/target/iscsi/iscsi_target_util.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/target/iscsi/iscsi_target_util.c +4 -1
@@ -873,8 +873,11 @@ void iscsit_dec_conn_usage_count(struct iscsi_conn *conn)spin_lock_bh (&conn->conn_usage_lock); conn->conn_usage_count--; -if (!conn->conn_usage_count && conn->conn_waiting_on_uc) +if (!conn->conn_usage_count && conn->conn_waiting_on_uc) { +spin_unlock_bh (&conn->conn_usage_lock);complete (&conn->conn_waiting_on_uc_comp); +return ; + }spin_unlock_bh (&conn->conn_usage_lock); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 22/41 wifi: mac80211: dont increment crypto_tx_tailroom_needed_cnt twice
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miri Korenblit <[email protected]>
[ Upstream commit 3f3d8ff31496874a69b131866f62474eb24ed20a ]
In reconfig, in case the driver asks to disconnect during the reconfig, all the keys of the interface are marked as tainted.
Then ieee80211_reenable_keys will loop over all the interface keys, and for each one it will
a) increment crypto_tx_tailroom_needed_cnt
b) call ieee80211_key_enable_hw_accel, which in turn will detect that this key is tainted, so it will mark it as "not in hardware", which is paired with crypto_tx_tailroom_needed_cnt incrementation, so we get two incrementations for each tainted key.
Then we get a warning in ieee80211_free_keys.
To fix it, don't increment the count in ieee80211_reenable_keys for tainted keys
--- net/mac80211/key.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/mac80211/key.c +2 -1
@@ -910,7 +910,8 @@ void ieee80211_reenable_keys(struct ieee80211_sub_if_data *sdata)if (ieee80211_sdata_running (sdata)) {list_for_each_entry (key, &sdata->key_list, list) { -increment_tailroom_need_count (sdata); +if (!(key->flags &KEY_FLAG_TAINTED )) +increment_tailroom_need_count (sdata);ieee80211_key_enable_hw_accel (key); } }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 23/41 platform/x86: toshiba_haps: Fix memory leaks in add/remove routines
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit 128497456756e1b952bd5a912cd073836465109d ]
toshiba_haps_add() leaks the haps object allocated by it if it returns an error after allocating that object successfully.
toshiba_haps_remove() does not free the object pointed to by toshiba_haps before clearing that pointer, so it becomes unreachable allocated memory.
Address these memory leaks by using devm_kzalloc() for allocating the memory in question.
--- drivers/platform/x86/toshiba_haps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/platform/x86/toshiba_haps.c +1 -1
@@ -185,7 +185,7 @@ static int toshiba_haps_add(struct acpi_device *acpi_dev)pr_info ("Toshiba HDD Active Protection Sensor device\n" ); - haps =kzalloc (sizeof (struct toshiba_haps_dev ),GFP_KERNEL ); + haps =devm_kzalloc (&acpi_dev->dev,sizeof (*haps),GFP_KERNEL );if (!haps)return -ENOMEM ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 24/41 platform/x86: intel_telemetry: Fix PSS event register mask
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kaushlendra Kumar <[email protected]>
[ Upstream commit 39e9c376ac42705af4ed4ae39eec028e8bced9b4 ]
The PSS telemetry info parsing incorrectly applies TELEM_INFO_SRAMEVTS_MASK when extracting event register count from firmware response. This reads bits 15-8 instead of the correct bits 7-0, causing misdetection of hardware capabilities.
The IOSS path correctly uses TELEM_INFO_NENABLES_MASK for register count. Apply the same mask to PSS parsing for consistency.
--- drivers/platform/x86/intel_telemetry_pltdrv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/platform/x86/intel_telemetry_pltdrv.c +1 -1
@@ -610,7 +610,7 @@ static int telemetry_setup(struct platform_device *pdev)/* Get telemetry Info */ events = (read_buf &TELEM_INFO_SRAMEVTS_MASK ) >>TELEM_INFO_SRAMEVTS_SHIFT ; - event_regs = read_buf &TELEM_INFO_SRAMEVTS_MASK ; + event_regs = read_buf &TELEM_INFO_NENABLES_MASK ;if ((events <TELEM_MAX_EVENTS_SRAM ) || (event_regs <TELEM_MAX_EVENTS_SRAM )) {dev_err (&pdev->dev,"PSS:Insufficient Space for SRAM Trace\n" );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 25/41 net: liquidio: Initialize netdev pointer before queue setup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zilin Guan <[email protected]>
[ Upstream commit 926ede0c85e1e57c97d64d9612455267d597bb2c ]
In setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq(). However, the pointer to this structure is stored in oct->props[i].netdev only after the calls to netif_set_real_num_rx_queues() and netif_set_real_num_tx_queues().
If either of these functions fails, setup_nic_devices() returns an error without freeing the allocated netdev. Since oct->props[i].netdev is still NULL at this point, the cleanup function liquidio_destroy_nic_device() will fail to find and free the netdev, resulting in a memory leak.
Fix this by initializing oct->props[i].netdev before calling the queue setup functions. This ensures that the netdev is properly accessible for cleanup in case of errors.
Compile tested only. Issue found using a prototype static analysis tool and code review.
--- .../net/ethernet/cavium/liquidio/lio_main.c | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-)
drivers/net/ethernet/cavium/liquidio/lio_main.c +17 -17
@@ -3531,6 +3531,23 @@ static int setup_nic_devices(struct octeon_device *octeon_dev)*/ netdev->netdev_ops = &lionetdevops; + lio =GET_LIO (netdev); + +memset (lio,0 ,sizeof (struct lio )); + + lio->ifidx = ifidx_or_pfnum; + + props = &octeon_dev->props[i]; + props->gmxport = resp->cfg_info.linfo.gmxport; + props->netdev = netdev; + +/* Point to the properties for octeon device to which this +* interface belongs. +*/ + lio->oct_dev = octeon_dev; + lio->octprops = props; + lio->netdev = netdev; + retval =netif_set_real_num_rx_queues (netdev, num_oqueues);if (retval) { dev_err(&octeon_dev->pci_dev->dev,
@@ -3547,16 +3564,6 @@ static int setup_nic_devices(struct octeon_device *octeon_dev) goto setup_nic_dev_free; } - lio =GET_LIO (netdev); - -memset (lio,0 ,sizeof (struct lio )); - - lio->ifidx = ifidx_or_pfnum; - - props = &octeon_dev->props[i]; - props->gmxport = resp->cfg_info.linfo.gmxport; - props->netdev = netdev; - lio->linfo.num_rxpciq = num_oqueues; lio->linfo.num_txpciq = num_iqueues;for (j =0 ; j < num_oqueues; j++) {
@@ -3622,13 +3629,6 @@ static int setup_nic_devices(struct octeon_device *octeon_dev) netdev->min_mtu =LIO_MIN_MTU_SIZE ; netdev->max_mtu =LIO_MAX_MTU_SIZE ; -/* Point to the properties for octeon device to which this -* interface belongs. -*/ - lio->oct_dev = octeon_dev; - lio->octprops = props; - lio->netdev = netdev; -dev_dbg (&octeon_dev->pci_dev->dev,"if%d gmx: %d hw_addr: 0x%llx\n" , i, lio->linfo.gmxport,CVM_CAST64 (lio->linfo.hw_addr));
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 26/41 net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zilin Guan <[email protected]>
[ Upstream commit 8558aef4e8a1a83049ab906d21d391093cfa7e7f ]
In setup_nic_devices(), the initialization loop jumps to the label setup_nic_dev_free on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak.
Fix this by changing the loop to iterate from the current index i down to 0.
Also, decrement i in the devlink_alloc failure path to point to the last successfully allocated index.
Compile tested only. Issue found using code review.
--- drivers/net/ethernet/cavium/liquidio/lio_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/ethernet/cavium/liquidio/lio_main.c +3 -2
@@ -3773,6 +3773,7 @@ static int setup_nic_devices(struct octeon_device *octeon_dev) sizeof(struct lio_devlink_priv));if (!devlink) {dev_err (&octeon_dev->pci_dev->dev,"devlink alloc failed\n" ); + i--; goto setup_nic_dev_free; }
@@ -3793,11 +3794,11 @@ static int setup_nic_devices(struct octeon_device *octeon_dev) setup_nic_dev_free: -while (i--) { +do {dev_err (&octeon_dev->pci_dev->dev,"NIC ifidx:%d Setup failed\n" , i);liquidio_destroy_nic_device (octeon_dev, i); - } + }while (i--); setup_nic_dev_done:
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 27/41 net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zilin Guan <[email protected]>
[ Upstream commit 6cbba46934aefdfb5d171e0a95aec06c24f7ca30 ]
In setup_nic_devices(), the initialization loop jumps to the label setup_nic_dev_free on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak.
Fix this by changing the loop to iterate from the current index i down to 0.
Compile tested only. Issue found using code review.
--- drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c +2 -2
@@ -2232,11 +2232,11 @@ static int setup_nic_devices(struct octeon_device *octeon_dev) setup_nic_dev_free: -while (i--) { +do {dev_err (&octeon_dev->pci_dev->dev,"NIC ifidx:%d Setup failed\n" , i);liquidio_destroy_nic_device (octeon_dev, i); - } + }while (i--); setup_nic_dev_done:
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 28/41 macvlan: fix error recovery in macvlan_common_newlink()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit f8db6475a83649689c087a8f52486fcc53e627e9 ]
valis provided a nice repro to crash the kernel:
ip link add p1 type veth peer p2
ip link set address 00:00:00:00:00:20 dev p1
ip link set up dev p1
ip link set up dev p2
ip link add mv0 link p2 type macvlan mode source
ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20
ping -c1 -I p1 1.2.3.4
He also gave a very detailed analysis:
<quote valis>
The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name).
In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink():
This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry.
vlan is a pointer to the priv data of the link that is being created.
When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create():
if (ops->newlink)
err = ops->newlink(dev, ¶ms, extack);
else
err = register_netdevice(dev);
if (err < 0) {
free_netdev(dev);
goto out;
}and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port.
Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
</quote valis>
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever "goto destroy_macvlan_port;" path is taken.
Many thanks to valis for following up on this issue.
--- drivers/net/macvlan.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/macvlan.c +3 -2
@@ -1519,9 +1519,10 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,/* the macvlan port may be freed by macvlan_uninit when fail to register. * so we destroy the macvlan port only when it's valid. */ -if (create &&macvlan_port_get_rtnl (lowerdev)) { +if (macvlan_port_get_rtnl (lowerdev)) {macvlan_flush_sources (port, vlan); -macvlan_port_destroy (port->dev); +if (create) +macvlan_port_destroy (port->dev); }return err; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 29/41 tipc: use kfree_sensitive() for session key material
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Hodges <[email protected]>
[ Upstream commit 74d9391e8849e70ded5309222d09b0ed0edbd039 ]
The rx->skey field contains a struct tipc_aead_key with GCM-AES encryption keys used for TIPC cluster communication. Using plain kfree() leaves this sensitive key material in freed memory pages where it could potentially be recovered.
Switch to kfree_sensitive() to ensure the key material is zeroed before the memory is freed.
--- net/tipc/crypto.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/tipc/crypto.c +2 -2
@@ -1223,7 +1223,7 @@ void tipc_crypto_key_flush(struct tipc_crypto *c) rx = c; tx =tipc_net (rx->net)->crypto_tx;if (cancel_delayed_work (&rx->work)) { -kfree (rx->skey); +kfree_sensitive (rx->skey); rx->skey =NULL ;atomic_xchg (&rx->key_distr,0 );tipc_node_put (rx->node);
@@ -2398,7 +2398,7 @@ static void tipc_crypto_work_rx(struct work_struct *work)break ;default :synchronize_rcu (); -kfree (rx->skey); +kfree_sensitive (rx->skey); rx->skey =NULL ;break ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 30/41 hwmon: (occ) Mark occ_init_attribute() as __printf
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 831a2b27914cc880130ffe8fb8d1e65a5324d07f ]
This is a printf-style function, which gcc -Werror=suggest-attribute=format correctly points out:
drivers/hwmon/occ/common.c: In function 'occ_init_attribute':drivers/hwmon/occ/common.c:761:9: error: function 'occ_init_attribute' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
Add the attribute to avoid this warning and ensure any incorrect format strings are detected here.
--- drivers/hwmon/occ/common.c | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/occ/common.c +1 -0
@@ -755,6 +755,7 @@ static ssize_t occ_show_extended(struct device *dev,* are dynamically allocated, we cannot use the existing kernel macros which * stringify the name argument. */ +__printf(7, 8) static void occ_init_attribute(struct occ_attribute *attr, int mode, ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf), ssize_t (*store)(struct device *dev, struct device_attribute *attr,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 31/41 nvmet-tcp: add an helper to free the cmd buffers
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maurizio Lombardi <[email protected]>
[ Upstream commit 69b85e1f1d1d1e49601ec3e85d2031188657cca2 ]
Makes the code easier to read and to debug.
Sets the freed pointers to NULL, it will be useful when destroying the queues to understand if the commands' buffers have been released already or not.
Stable-dep-of: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec")
--- drivers/nvme/target/tcp.c | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-)
drivers/nvme/target/tcp.c +19 -9
@@ -155,6 +155,8 @@ static struct workqueue_struct *nvmet_tcp_wq;static const struct nvmet_fabrics_ops nvmet_tcp_ops;static void nvmet_tcp_free_cmd (struct nvmet_tcp_cmd *c);static void nvmet_tcp_finish_cmd (struct nvmet_tcp_cmd *cmd); +static void nvmet_tcp_free_cmd_buffers (struct nvmet_tcp_cmd *cmd); +static void nvmet_tcp_unmap_pdu_iovec (struct nvmet_tcp_cmd *cmd);static inline u16 nvmet_tcp_cmd_tag (struct nvmet_tcp_queue *queue,struct nvmet_tcp_cmd *cmd)
@@ -286,6 +288,16 @@ static int nvmet_tcp_check_ddgst(struct nvmet_tcp_queue *queue, void *pdu)return 0 ; } +static void nvmet_tcp_free_cmd_buffers (struct nvmet_tcp_cmd *cmd) +{ +WARN_ON (unlikely (cmd->nr_mapped >0 )); + +kfree (cmd->iov); +sgl_free (cmd->req.sg); + cmd->iov =NULL ; + cmd->req.sg =NULL ; +} +static void nvmet_tcp_unmap_pdu_iovec (struct nvmet_tcp_cmd *cmd) {struct scatterlist *sg;
@@ -295,6 +307,8 @@ static void nvmet_tcp_unmap_pdu_iovec(struct nvmet_tcp_cmd *cmd)for (i =0 ; i < cmd->nr_mapped; i++)kunmap (sg_page (&sg[i])); + + cmd->nr_mapped =0 ; }static void nvmet_tcp_map_pdu_iovec (struct nvmet_tcp_cmd *cmd)
@@ -377,7 +391,7 @@ static int nvmet_tcp_map_data(struct nvmet_tcp_cmd *cmd)return 0 ; err: -sgl_free (cmd->req.sg); +nvmet_tcp_free_cmd_buffers (cmd);return NVME_SC_INTERNAL ; }
@@ -628,10 +642,8 @@ static int nvmet_try_send_data(struct nvmet_tcp_cmd *cmd, bool last_in_batch) } } -if (queue->nvme_sq.sqhd_disabled) { -kfree (cmd->iov); -sgl_free (cmd->req.sg); - } +if (queue->nvme_sq.sqhd_disabled) +nvmet_tcp_free_cmd_buffers (cmd);return 1 ;
@@ -660,8 +672,7 @@ static int nvmet_try_send_response(struct nvmet_tcp_cmd *cmd,if (left)return -EAGAIN ; -kfree (cmd->iov); -sgl_free (cmd->req.sg); +nvmet_tcp_free_cmd_buffers (cmd); cmd->queue->snd_cmd =NULL ;nvmet_tcp_put_cmd (cmd);return 1 ;
@@ -1422,8 +1433,7 @@ static void nvmet_tcp_finish_cmd(struct nvmet_tcp_cmd *cmd) {nvmet_req_uninit (&cmd->req);nvmet_tcp_unmap_pdu_iovec (cmd); -kfree (cmd->iov); -sgl_free (cmd->req.sg); +nvmet_tcp_free_cmd_buffers (cmd); }static void nvmet_tcp_uninit_data_in_cmds (struct nvmet_tcp_queue *queue)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 32/41 nvmet-tcp: fix memory leak when performing a controller reset
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maurizio Lombardi <[email protected]>
[ Upstream commit af21250bb503a02e705b461886321e394b300524 ]
If a reset controller is executed while the initiator is performing some I/O the driver may leak the memory allocated for the commands' iovec.
Make sure that nvmet_tcp_uninit_data_in_cmds() releases all the memory.
Stable-dep-of: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec")
--- drivers/nvme/target/tcp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/nvme/target/tcp.c +4 -1
@@ -1443,7 +1443,10 @@ static void nvmet_tcp_uninit_data_in_cmds(struct nvmet_tcp_queue *queue)for (i =0 ; i < queue->nr_cmds; i++, cmd++) {if (nvmet_tcp_need_data_in (cmd)) -nvmet_tcp_finish_cmd (cmd); +nvmet_req_uninit (&cmd->req); + +nvmet_tcp_unmap_pdu_iovec (cmd); +nvmet_tcp_free_cmd_buffers (cmd); }if (!queue->nr_cmds &&nvmet_tcp_need_data_in (&queue->connect)) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 33/41 nvmet-tcp: fix regression in data_digest calculation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sagi Grimberg <[email protected]>
[ Upstream commit ed0691cf55140ce0f3fb100225645d902cce904b ]
Data digest calculation iterates over command mapped iovec. However since commit bac04454ef9f we unmap the iovec before we handle the data digest, and since commit 69b85e1f1d1d we clear nr_mapped when we unmap the iov.
Instead of open-coding the command iov traversal, simply call crypto_ahash_digest with the command sg that is already allocated (we already do that for the send path). Rename nvmet_tcp_send_ddgst to nvmet_tcp_calc_ddgst and call it from send and recv paths.
Stable-dep-of: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec")
--- drivers/nvme/target/tcp.c | 23 +++-------------------- 1 file changed, 3 insertions(+), 20 deletions(-)
drivers/nvme/target/tcp.c +3 -20
@@ -395,7 +395,7 @@ static int nvmet_tcp_map_data(struct nvmet_tcp_cmd *cmd)return NVME_SC_INTERNAL ; } -static void nvmet_tcp_send_ddgst (struct ahash_request *hash, +static void nvmet_tcp_calc_ddgst (struct ahash_request *hash,struct nvmet_tcp_cmd *cmd) { ahash_request_set_crypt(hash, cmd->req.sg,
@@ -403,23 +403,6 @@ static void nvmet_tcp_send_ddgst(struct ahash_request *hash,crypto_ahash_digest (hash); } -static void nvmet_tcp_recv_ddgst (struct ahash_request *hash, -struct nvmet_tcp_cmd *cmd) -{ -struct scatterlist sg; -struct kvec *iov; -int i; - -crypto_ahash_init (hash); -for (i =0 , iov = cmd->iov; i < cmd->nr_mapped; i++, iov++) { -sg_init_one (&sg, iov->iov_base, iov->iov_len); -ahash_request_set_crypt (hash, &sg,NULL , iov->iov_len); -crypto_ahash_update (hash); - } -ahash_request_set_crypt (hash,NULL , (void *)&cmd->exp_ddgst,0 ); -crypto_ahash_final (hash); -} -static void nvmet_setup_c2h_data_pdu (struct nvmet_tcp_cmd *cmd) {struct nvme_tcp_data_pdu *pdu = cmd->data_pdu;
@@ -444,7 +427,7 @@ static void nvmet_setup_c2h_data_pdu(struct nvmet_tcp_cmd *cmd)if (queue->data_digest) { pdu->hdr.flags |=NVME_TCP_F_DDGST ; -nvmet_tcp_send_ddgst (queue->snd_hash, cmd); +nvmet_tcp_calc_ddgst (queue->snd_hash, cmd); }if (cmd->queue->hdr_digest) {
@@ -1156,7 +1139,7 @@ static void nvmet_tcp_prep_recv_ddgst(struct nvmet_tcp_cmd *cmd) {struct nvmet_tcp_queue *queue = cmd->queue; -nvmet_tcp_recv_ddgst (queue->rcv_hash, cmd); +nvmet_tcp_calc_ddgst (queue->rcv_hash, cmd); queue->offset =0 ; queue->left =NVME_TCP_DIGEST_LENGTH ; queue->rcv_state =NVMET_TCP_RECV_DDGST ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 34/41 nvmet-tcp: dont map pages which cant come from HIGHMEM
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fabio M. De Francesco <[email protected]>
[ Upstream commit 5bfaba275ae6486700194cad962574e3eb7ae60d ]
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]/
Stable-dep-of: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec")
--- drivers/nvme/target/tcp.c | 44 ++++++++++++--------------------------- 1 file changed, 13 insertions(+), 31 deletions(-)
drivers/nvme/target/tcp.c +13 -31
@@ -68,9 +68,8 @@ struct nvmet_tcp_cmd {u32 pdu_len;u32 pdu_recv;int sg_idx; -int nr_mapped;struct msghdr recv_msg; -struct kvec *iov; +struct bio_vec *iov;u32 flags;struct list_head entry;
@@ -156,7 +155,6 @@ static const struct nvmet_fabrics_ops nvmet_tcp_ops;static void nvmet_tcp_free_cmd (struct nvmet_tcp_cmd *c);static void nvmet_tcp_finish_cmd (struct nvmet_tcp_cmd *cmd);static void nvmet_tcp_free_cmd_buffers (struct nvmet_tcp_cmd *cmd); -static void nvmet_tcp_unmap_pdu_iovec (struct nvmet_tcp_cmd *cmd);static inline u16 nvmet_tcp_cmd_tag (struct nvmet_tcp_queue *queue,struct nvmet_tcp_cmd *cmd)
@@ -290,35 +288,21 @@ static int nvmet_tcp_check_ddgst(struct nvmet_tcp_queue *queue, void *pdu)static void nvmet_tcp_free_cmd_buffers (struct nvmet_tcp_cmd *cmd) { -WARN_ON (unlikely (cmd->nr_mapped >0 )); -kfree (cmd->iov);sgl_free (cmd->req.sg); cmd->iov =NULL ; cmd->req.sg =NULL ; } -static void nvmet_tcp_unmap_pdu_iovec (struct nvmet_tcp_cmd *cmd) -{ -struct scatterlist *sg; -int i; - - sg = &cmd->req.sg[cmd->sg_idx]; - -for (i =0 ; i < cmd->nr_mapped; i++) -kunmap (sg_page (&sg[i])); - - cmd->nr_mapped =0 ; -} - -static void nvmet_tcp_map_pdu_iovec (struct nvmet_tcp_cmd *cmd) +static void nvmet_tcp_build_pdu_iovec (struct nvmet_tcp_cmd *cmd) { -struct kvec *iov = cmd->iov; +struct bio_vec *iov = cmd->iov;struct scatterlist *sg;u32 length, offset, sg_offset; +int nr_pages; length = cmd->pdu_len; - cmd->nr_mapped =DIV_ROUND_UP (length,PAGE_SIZE ); + nr_pages =DIV_ROUND_UP (length,PAGE_SIZE ); offset = cmd->rbytes_done; cmd->sg_idx = offset /PAGE_SIZE ; sg_offset = offset %PAGE_SIZE ;
@@ -327,8 +311,9 @@ static void nvmet_tcp_map_pdu_iovec(struct nvmet_tcp_cmd *cmd)while (length) {u32 iov_len =min_t (u32, length, sg->length - sg_offset); - iov->iov_base =kmap (sg_page (sg)) + sg->offset + sg_offset; - iov->iov_len = iov_len; + iov->bv_page =sg_page (sg); + iov->bv_len = sg->length; + iov->bv_offset = sg->offset + sg_offset; length -= iov_len; sg =sg_next (sg);
@@ -336,8 +321,8 @@ static void nvmet_tcp_map_pdu_iovec(struct nvmet_tcp_cmd *cmd) sg_offset =0 ; } -iov_iter_kvec (&cmd->recv_msg.msg_iter,READ , cmd->iov, - cmd->nr_mapped, cmd->pdu_len); +iov_iter_bvec (&cmd->recv_msg.msg_iter,READ , cmd->iov, + nr_pages, cmd->pdu_len); }static void nvmet_tcp_fatal_error (struct nvmet_tcp_queue *queue)
@@ -913,7 +898,7 @@ static void nvmet_tcp_handle_req_failure(struct nvmet_tcp_queue *queue, } queue->rcv_state =NVMET_TCP_RECV_DATA ; -nvmet_tcp_map_pdu_iovec (cmd); +nvmet_tcp_build_pdu_iovec (cmd); cmd->flags |=NVMET_TCP_F_INIT_FAILED ; }
@@ -966,7 +951,7 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue) goto err_proto; } cmd->pdu_recv =0 ; -nvmet_tcp_map_pdu_iovec (cmd); +nvmet_tcp_build_pdu_iovec (cmd); queue->cmd = cmd; queue->rcv_state =NVMET_TCP_RECV_DATA ;
@@ -1040,7 +1025,7 @@ static int nvmet_tcp_done_recv_pdu(struct nvmet_tcp_queue *queue)if (nvmet_tcp_need_data_in (queue->cmd)) {if (nvmet_tcp_has_inline_data (queue->cmd)) { queue->rcv_state =NVMET_TCP_RECV_DATA ; -nvmet_tcp_map_pdu_iovec (queue->cmd); +nvmet_tcp_build_pdu_iovec (queue->cmd);return 0 ; }/* send back R2T */
@@ -1160,7 +1145,6 @@ static int nvmet_tcp_try_recv_data(struct nvmet_tcp_queue *queue) cmd->rbytes_done += ret; } -nvmet_tcp_unmap_pdu_iovec (cmd);if (queue->data_digest) {nvmet_tcp_prep_recv_ddgst (cmd);return 0 ;
@@ -1415,7 +1399,6 @@ static void nvmet_tcp_restore_socket_callbacks(struct nvmet_tcp_queue *queue)static void nvmet_tcp_finish_cmd (struct nvmet_tcp_cmd *cmd) {nvmet_req_uninit (&cmd->req); -nvmet_tcp_unmap_pdu_iovec (cmd);nvmet_tcp_free_cmd_buffers (cmd); }
@@ -1428,7 +1411,6 @@ static void nvmet_tcp_uninit_data_in_cmds(struct nvmet_tcp_queue *queue)if (nvmet_tcp_need_data_in (cmd))nvmet_req_uninit (&cmd->req); -nvmet_tcp_unmap_pdu_iovec (cmd);nvmet_tcp_free_cmd_buffers (cmd); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 35/41 nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: YunJe Shin <[email protected]>
[ Upstream commit 52a0a98549344ca20ad81a4176d68d28e3c05a5c ]
nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.
--- drivers/nvme/target/tcp.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
drivers/nvme/target/tcp.c +18 -0
@@ -294,11 +294,14 @@ static void nvmet_tcp_free_cmd_buffers(s cmd->req.sg =NULL ; } +static void nvmet_tcp_fatal_error (struct nvmet_tcp_queue *queue); +static void nvmet_tcp_build_pdu_iovec (struct nvmet_tcp_cmd *cmd) {struct bio_vec *iov = cmd->iov;struct scatterlist *sg;u32 length, offset, sg_offset; +unsigned int sg_remaining;int nr_pages; length = cmd->pdu_len;
@@ -306,17 +309,32 @@ static void nvmet_tcp_build_pdu_iovec(st offset = cmd->rbytes_done; cmd->sg_idx = offset /PAGE_SIZE ; sg_offset = offset %PAGE_SIZE ; +if (!cmd->req.sg_cnt || cmd->sg_idx >= cmd->req.sg_cnt) { +nvmet_tcp_fatal_error (cmd->queue); +return ; + } sg = &cmd->req.sg[cmd->sg_idx]; + sg_remaining = cmd->req.sg_cnt - cmd->sg_idx;while (length) {u32 iov_len =min_t (u32, length, sg->length - sg_offset); +if (!sg_remaining) { +nvmet_tcp_fatal_error (cmd->queue); +return ; + } +if (!sg->length || sg->length <= sg_offset) { +nvmet_tcp_fatal_error (cmd->queue); +return ; + } + iov->bv_page =sg_page (sg); iov->bv_len = sg->length; iov->bv_offset = sg->offset + sg_offset; length -= iov_len; sg =sg_next (sg); + sg_remaining--; iov++; sg_offset =0 ; }
Greg Kroah-Hartman
maintainerPATCH 36/41 ASoC: amd: fix memory leak in acp3x pdm dma ops
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Bainbridge <[email protected]>
[ Upstream commit 7f67ba5413f98d93116a756e7f17cd2c1d6c2bd6 ]
--- sound/soc/amd/renoir/acp3x-pdm-dma.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/amd/renoir/acp3x-pdm-dma.c +2 -0
@@ -308,9 +308,11 @@ static int acp_pdm_dma_close(struct snd_soc_component *component, struct snd_pcm_substream *substream) {struct pdm_dev_data *adata =dev_get_drvdata (component->dev); +struct pdm_stream_instance *rtd = substream->runtime->private_data;disable_pdm_interrupts (adata->acp_base); adata->capture_stream =NULL ; +kfree (rtd);return 0 ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 37/41 platform/x86: intel_telemetry: Fix swapped arrays in PSS output
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kaushlendra Kumar <[email protected]>
[ Upstream commit 25e9e322d2ab5c03602eff4fbf4f7c40019d8de2 ]
The LTR blocking statistics and wakeup event counters are incorrectly cross-referenced during debugfs output rendering. The code populates pss_ltr_blkd[] with LTR blocking data and pss_s0ix_wakeup[] with wakeup data, but the display loops reference the wrong arrays.
This causes the "LTR Blocking Status" section to print wakeup events and the "Wakes Status" section to print LTR blockers, misleading power management analysis and S0ix residency debugging.
Fix by aligning array usage with the intended output section labels.
--- drivers/platform/x86/intel_telemetry_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/platform/x86/intel_telemetry_debugfs.c +2 -2
@@ -449,7 +449,7 @@ static int telem_pss_states_show(structfor (index =0 ; index < debugfs_conf->pss_ltr_evts; index++) {seq_printf (s,"%-32s\t%u\n" , debugfs_conf->pss_ltr_data[index].name, - pss_s0ix_wakeup[index]); + pss_ltr_blkd[index]); }seq_puts (s,"\n--------------------------------------\n" );
@@ -459,7 +459,7 @@ static int telem_pss_states_show(structfor (index =0 ; index < debugfs_conf->pss_wakeup_evts; index++) {seq_printf (s,"%-32s\t%u\n" , debugfs_conf->pss_wakeup[index].name, - pss_ltr_blkd[index]); + pss_s0ix_wakeup[index]); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 38/41 gve: Fix stats report corruption on queue count change
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Debarghya Kundu <[email protected]>
[ Upstream commit 7b9ebcce0296e104a0d82a6b09d68564806158ff ]
The driver and the NIC share a region in memory for stats reporting. The NIC calculates its offset into this region based on the total size of the stats region and the size of the NIC's stats.
When the number of queues is changed, the driver's stats region is resized. If the queue count is increased, the NIC can write past the end of the allocated stats region, causing memory corruption. If the queue count is decreased, there is a gap between the driver and NIC stats, leading to incorrect stats reporting.
This change fixes the issue by allocating stats region with maximum size, and the offset calculation for NIC stats is changed to match with the calculation of the NIC.
--- drivers/net/ethernet/google/gve/gve_ethtool.c | 42 +++++++++++++++++--------- drivers/net/ethernet/google/gve/gve_main.c | 4 +- 2 files changed, 31 insertions(+), 15 deletions(-)
drivers/net/ethernet/google/gve/gve_ethtool.c +29 -13
@@ -140,7 +140,8 @@ gve_get_ethtool_stats(struct net_device tmp_rx_desc_err_dropped_pkt, tmp_tx_pkts, tmp_tx_bytes;u64 rx_buf_alloc_fail, rx_desc_err_dropped_pkt, rx_pkts, rx_skb_alloc_fail, rx_bytes, tx_pkts, tx_bytes; -int stats_idx, base_stats_idx, max_stats_idx; +int rx_base_stats_idx, max_rx_stats_idx, max_tx_stats_idx; +int stats_idx, stats_region_len, nic_stats_len;struct stats *report_stats;int *rx_qid_to_stats_idx;int *tx_qid_to_stats_idx;
@@ -226,14 +227,33 @@ gve_get_ethtool_stats(struct net_device data[i++] = priv->stats_report_trigger_cnt; i =GVE_MAIN_STATS_LEN ; -/* For rx cross-reporting stats, start from nic rx stats in report */ - base_stats_idx =GVE_TX_STATS_REPORT_NUM * priv->tx_cfg.num_queues + -GVE_RX_STATS_REPORT_NUM * priv->rx_cfg.num_queues; - max_stats_idx =NIC_RX_STATS_REPORT_NUM * priv->rx_cfg.num_queues + - base_stats_idx; + rx_base_stats_idx =0 ; + max_rx_stats_idx =0 ; + max_tx_stats_idx =0 ; + stats_region_len = priv->stats_report_len - +sizeof (struct gve_stats_report ); + nic_stats_len = (NIC_RX_STATS_REPORT_NUM * priv->rx_cfg.num_queues + +NIC_TX_STATS_REPORT_NUM * priv->tx_cfg.num_queues) * +sizeof (struct stats ); +if (unlikely ((stats_region_len - + nic_stats_len) %sizeof (struct stats ))) { +net_err_ratelimited ("Starting index of NIC stats should be multiple of stats size" ); + }else { +/* For rx cross-reporting stats, +* start from nic rx stats in report +*/ + rx_base_stats_idx = (stats_region_len - nic_stats_len) / +sizeof (struct stats ); + max_rx_stats_idx =NIC_RX_STATS_REPORT_NUM * + priv->rx_cfg.num_queues + + rx_base_stats_idx; + max_tx_stats_idx =NIC_TX_STATS_REPORT_NUM * + priv->tx_cfg.num_queues + + max_rx_stats_idx; + }/* Preprocess the stats report for rx, map queue id to start index */ skip_nic_stats = false; -for (stats_idx = base_stats_idx; stats_idx < max_stats_idx; +for (stats_idx = rx_base_stats_idx; stats_idx < max_rx_stats_idx; stats_idx +=NIC_RX_STATS_REPORT_NUM ) {u32 stat_name =be32_to_cpu (report_stats[stats_idx].stat_name);u32 queue_id =be32_to_cpu (report_stats[stats_idx].queue_id);
@@ -286,13 +306,9 @@ gve_get_ethtool_stats(struct net_device i += priv->rx_cfg.num_queues *NUM_GVE_RX_CNTS ; } -/* For tx cross-reporting stats, start from nic tx stats in report */ - base_stats_idx = max_stats_idx; - max_stats_idx =NIC_TX_STATS_REPORT_NUM * priv->tx_cfg.num_queues + - max_stats_idx; -/* Preprocess the stats report for tx, map queue id to start index */ skip_nic_stats = false; -for (stats_idx = base_stats_idx; stats_idx < max_stats_idx; +/* NIC TX stats start right after NIC RX stats */ +for (stats_idx = max_rx_stats_idx; stats_idx < max_tx_stats_idx; stats_idx +=NIC_TX_STATS_REPORT_NUM ) {u32 stat_name =be32_to_cpu (report_stats[stats_idx].stat_name);u32 queue_id =be32_to_cpu (report_stats[stats_idx].queue_id);
drivers/net/ethernet/google/gve/gve_main.c +2 -2
@@ -124,9 +124,9 @@ static int gve_alloc_stats_report(structint tx_stats_num, rx_stats_num; tx_stats_num = (GVE_TX_STATS_REPORT_NUM +NIC_TX_STATS_REPORT_NUM ) * - priv->tx_cfg.num_queues; + priv->tx_cfg.max_queues; rx_stats_num = (GVE_RX_STATS_REPORT_NUM +NIC_RX_STATS_REPORT_NUM ) * - priv->rx_cfg.num_queues; + priv->rx_cfg.max_queues; priv->stats_report_len =struct_size (priv->stats_report, stats,size_add (tx_stats_num, rx_stats_num)); priv->stats_report =
Greg Kroah-Hartman
maintainerPATCH 39/41 tracing: Fix ftrace event field alignments
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
[ Upstream commit 033c55fe2e326bea022c3cc5178ecf3e0e459b82 ]
The fields of ftrace specific events (events used to save ftrace internal events like function traces and trace_printk) are generated similarly to how normal trace event fields are generated. That is, the fields are added to a trace_events_fields array that saves the name, offset, size, alignment and signness of the field. It is used to produce the output in the format file in tracefs so that tooling knows how to parse the binary data of the trace events.
The issue is that some of the ftrace event structures are packed. The function graph exit event structures are one of them. The 64 bit calltime and rettime fields end up 4 byte aligned, but the algorithm to show to userspace shows them as 8 byte aligned.
The macros that create the ftrace events has one for embedded structure fields. There's two macros for theses fields:
__field_desc() and __field_packed()
The difference of the latter macro is that it treats the field as packed.
Rename that field to __field_desc_packed() and create replace the __field_packed() to be a normal field that is packed and have the calltime and rettime use those.
This showed up on 32bit architectures for function graph time fields. It had:
~# cat /sys/kernel/tracing/events/ftrace/funcgraph_exit/format
[..]
field:unsigned long func; offset:8; size:4; signed:0;
field:unsigned int depth; offset:12; size:4; signed:0;
field:unsigned int overrun; offset:16; size:4; signed:0;
field:unsigned long long calltime; offset:24; size:8; signed:0;
field:unsigned long long rettime; offset:32; size:8; signed:0;Notice that overrun is at offset 16 with size 4, where in the structure calltime is at offset 20 (16 + 4), but it shows the offset at 24. That's because it used the alignment of unsigned long long when used as a declaration and not as a member of a structure where it would be aligned by word size (in this case 4).
By using the proper structure alignment, the format has it at the correct offset:
~# cat /sys/kernel/tracing/events/ftrace/funcgraph_exit/format
[..]
field:unsigned long func; offset:8; size:4; signed:0;
field:unsigned int depth; offset:12; size:4; signed:0;
field:unsigned int overrun; offset:16; size:4; signed:0;
field:unsigned long long calltime; offset:20; size:8; signed:0;
field:unsigned long long rettime; offset:28; size:8; signed:0;--- kernel/trace/trace.h | 7 +++++-- kernel/trace/trace_entries.h | 14 +++++++------- kernel/trace/trace_export.c | 21 +++++++++++++++------ 3 files changed, 27 insertions(+), 15 deletions(-)
kernel/trace/trace.h +5 -2
@@ -56,14 +56,17 @@ enum trace_type {#undef __field_fn#define __field_fn (type, item) type item; +#undef __field_packed +#define __field_packed (type, item) type item; +#undef __field_struct#define __field_struct (type, item) __field(type, item)#undef __field_desc#define __field_desc (type, container, item) -#undef __field_packed -#define __field_packed (type, container, item) +#undef __field_desc_packed +#define __field_desc_packed (type, container, item)#undef __array#define __array (type, item, size) type item[size];
kernel/trace/trace_entries.h +7 -7
@@ -78,8 +78,8 @@ FTRACE_ENTRY_PACKED(funcgraph_entry, ftr F_STRUCT( __field_struct( struct ftrace_graph_ent, graph_ent ) - __field_packed( unsigned long, graph_ent, func ) - __field_packed( int, graph_ent, depth ) + __field_desc_packed( unsigned long, graph_ent, func ) + __field_desc_packed( int, graph_ent, depth ) ), F_printk("--> %ps (%d)", (void *)__entry->func, __entry->depth)
@@ -92,11 +92,11 @@ FTRACE_ENTRY_PACKED(funcgraph_exit, ftra F_STRUCT( __field_struct( struct ftrace_graph_ret, ret ) - __field_packed( unsigned long, ret, func ) - __field_packed( unsigned long, ret, overrun ) - __field_packed( unsigned long long, ret, calltime) - __field_packed( unsigned long long, ret, rettime ) - __field_packed( int, ret, depth ) + __field_desc_packed( unsigned long, ret, func ) + __field_desc_packed( unsigned long, ret, overrun ) + __field_desc_packed( unsigned long long, ret, calltime) + __field_desc_packed( unsigned long long, ret, rettime ) + __field_desc_packed( int, ret, depth ) ), F_printk("<-- %ps (%d) (start: %llx end: %llx) over: %d",
kernel/trace/trace_export.c +15 -6
@@ -42,11 +42,14 @@ static int ftrace_event_register(struct#undef __field_fn#define __field_fn (type, item) type item; +#undef __field_packed +#define __field_packed (type, item) type item; +#undef __field_desc#define __field_desc (type, container, item) type item; -#undef __field_packed -#define __field_packed (type, container, item) type item; +#undef __field_desc_packed +#define __field_desc_packed (type, container, item) type item;#undef __array#define __array (type, item, size) type item[size];
@@ -101,11 +104,14 @@ static void __always_unused ____ftrace_c#undef __field_fn#define __field_fn (_type, _item) __field_ext(_type, _item, FILTER_TRACE_FN) +#undef __field_packed +#define __field_packed (_type, _item) __field_ext_packed(_type, _item, FILTER_OTHER) +#undef __field_desc#define __field_desc (_type, _container, _item) __field_ext(_type, _item, FILTER_OTHER) -#undef __field_packed -#define __field_packed (_type, _container, _item) __field_ext_packed(_type, _item, FILTER_OTHER) +#undef __field_desc_packed +#define __field_desc_packed (_type, _container, _item) __field_ext_packed(_type, _item, FILTER_OTHER)#undef __array#define __array (_type, _item, _len) { \
@@ -139,11 +145,14 @@ static struct trace_event_fields ftrace_#undef __field_fn#define __field_fn (type, item) +#undef __field_packed +#define __field_packed (type, item) +#undef __field_desc#define __field_desc (type, container, item) -#undef __field_packed -#define __field_packed (type, container, item) +#undef __field_desc_packed +#define __field_desc_packed (type, container, item)#undef __array#define __array (type, item, len)
Greg Kroah-Hartman
maintainerPATCH 40/41 gve: Correct ethtool rx_dropped calculation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Yuan <[email protected]>
[ Upstream commit c7db85d579a1dccb624235534508c75fbf2dfe46 ]
The gve driver's "rx_dropped" statistic, exposed via ethtool -S, incorrectly includes rx_buf_alloc_fail counts. These failures represent an inability to allocate receive buffers, not true packet drops where a received packet is discarded. This misrepresentation can lead to inaccurate diagnostics.
This patch rectifies the ethtool "rx_dropped" calculation. It removes rx_buf_alloc_fail from the total and adds xdp_tx_errors and xdp_redirect_errors, which represent legitimate packet drops within the XDP path.
--- drivers/net/ethernet/google/gve/gve_ethtool.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/net/ethernet/google/gve/gve_ethtool.c +1 -3
@@ -210,8 +210,7 @@ gve_get_ethtool_stats(struct net_device data[i++] = rx_bytes; data[i++] = tx_bytes;/* total rx dropped packets */ - data[i++] = rx_skb_alloc_fail + rx_buf_alloc_fail + - rx_desc_err_dropped_pkt; + data[i++] = rx_skb_alloc_fail + rx_desc_err_dropped_pkt;/* Skip tx_dropped */ i++;
@@ -285,7 +284,6 @@ gve_get_ethtool_stats(struct net_device data[i++] = tmp_rx_bytes;/* rx dropped packets */ data[i++] = tmp_rx_skb_alloc_fail + - tmp_rx_buf_alloc_fail + tmp_rx_desc_err_dropped_pkt; data[i++] = rx->rx_copybreak_pkt; data[i++] = rx->rx_copied_pkt;
Greg Kroah-Hartman
maintainerPATCH 41/41 nvmet-tcp: pass iov_len instead of sg->length to bvec_set_page()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Varun Prakash <[email protected]>
commit 1f0bbf28940cf5edad90ab57b62aa8197bf5e836 upstream.
iov_len is the valid data length, so pass iov_len instead of sg->length to bvec_set_page().
--- drivers/nvme/target/tcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/nvme/target/tcp.c +1 -1
@@ -329,7 +329,7 @@ static void nvmet_tcp_build_pdu_iovec(st } iov->bv_page =sg_page (sg); - iov->bv_len = sg->length; + iov->bv_len = iov_len; iov->bv_offset = sg->offset + sg_offset; length -= iov_len;
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 5.10.250-rc1-00042-g58ef7f63a0dc #1 SMP Mon Feb 9 17:03:27 -00 2026 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.250 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.250-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
80 tests: 80 pass, 0 failLinux version: 5.10.250-rc1-g58ef7f63a0dc
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.250 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.250-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.250 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
On i386: builts OK, boots OK, no new dmesg issues.
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.250 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.250 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.250-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Tested on an amd64 laptop (Lenovo ThinkPad T14 Gen 1). Working well, no regressions observed.
Signature · 1 line
-Barry K. Nathan <[email protected]>
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.250 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.250-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Tested on an amd64 laptop (Lenovo ThinkPad T14 Gen 1). Working well, no regressions observed.
(I forgot the Tested-by line in my previous email, sorry.)
Signature · 1 line
-Barry K. Nathan <[email protected]>
hello,
dmesg stuff...
-----------------err-------------------------
$sudo dmesg -l err
[ 10.122028] snd_pci_acp3x 0000:04:00.5: Invalid ACP audio mode : 1
$
------------------err------------------------
--
software engineer
rajagiri school of engineering and technology