[Deepin-Kernel-SIG] [linux 6.6-y] [Upstream] Update kernel base to 6.6.128#1529
Closed
opsiff wants to merge 683 commits intodeepin-community:linux-6.6.yfrom
Closed
[Deepin-Kernel-SIG] [linux 6.6-y] [Upstream] Update kernel base to 6.6.128#1529opsiff wants to merge 683 commits intodeepin-community:linux-6.6.yfrom
opsiff wants to merge 683 commits intodeepin-community:linux-6.6.yfrom
Conversation
[ Upstream commit 7f852de ] For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-4-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit f73528f140f17c230b4bc4dc7fd0c14983897e95) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 03e9d91 ] Add missing READ_ONCE() when reading sysctl values. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260115094141.3124990-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 55170230de661cd2301f57b222e4eb5913620af4) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 978b67d ] Following four sysctls can change under us, add missing READ_ONCE(). - ipv6.sysctl.max_dst_opts_len - ipv6.sysctl.max_dst_opts_cnt - ipv6.sysctl.max_hbh_opts_len - ipv6.sysctl.max_hbh_opts_cnt Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260115094141.3124990-8-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 46ed4e9c8d30019d780695ae069db0417a0020d2) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 89b4336 ] Fast commits only log operations that have dedicated replay support. Online resize via EXT4_IOC_GROUP_ADD updates the superblock and group descriptor metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when ext4_ioctl_group_add() adds new block groups. This forces those transactions to fall back to a full commit, ensuring that the filesystem geometry updates are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_ADD safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize 2. Ran a helper that issues EXT4_IOC_GROUP_ADD on the mounted filesystem and checked the resize ineligible reason: ./group_add_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows "Resize": > 0. 3. Fsynced a file on the resized filesystem and verified that the fast commit stats report at least one ineligible commit: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info shows fc stats ineligible > 0. Signed-off-by: Li Chen <me@linux.beauty> Link: https://patch.msgid.link/20251211115146.897420-5-me@linux.beauty Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 83b074b690226cd274cbf7a6f0a8db53a090442b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 2705645 ] When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the `DOUBLE_CHECK` macro defined, the following panic is triggered: ================================================================== EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty deepin-community#1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above. Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20251209133116.731350-1-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 0d5fcb063cdabb9aeaa8554b7fedad2092c4150e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 1f8dd81 ] Fast commits only log operations that have dedicated replay support. EXT4_IOC_GROUP_EXTEND grows the filesystem to the end of the last block group and updates the same on-disk metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when EXT4_IOC_GROUP_EXTEND grows the filesystem. This forces those transactions to fall back to a full commit, ensuring that the group extension changes are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_EXTEND safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize 2. Extended the filesystem to the end of the last block group using a helper that calls EXT4_IOC_GROUP_EXTEND on the mounted filesystem and checked fc_info: ./group_extend_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows the "Resize" ineligible reason increased. 3. Fsynced a file on the resized filesystem and confirmed that the fast commit ineligible counter incremented for the resize transaction: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info Signed-off-by: Li Chen <me@linux.beauty> Link: https://patch.msgid.link/20251211115146.897420-6-me@linux.beauty Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 99c75e53cec021b6cc5f66e77ace14079f9a8540) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 8a49fc8 ] The upstream commit, 71d8c47 ("netfilter: conntrack: introduce clash resolution on insertion race"), sets allow_clash=true in the UDP/UDPLITE protocol handler but does not set it in the generic protocol handler. As a result, packets composed of connectionless protocols at each layer, such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion. To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic. Signed-off-by: Yuto Hamaguchi <Hamaguchi.Yuto@da.MitsubishiElectric.co.jp> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 89f50775d88394ccaa7ec475fc04ef2e6f62c587) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 735ee85 ] Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload). Reported-by: sungzii <sungzii@pm.me> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 07a9b32eaae792ff7d0fcac14d8920c937c0a9c3) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 0dfffa5 ] When compiling a driver written for MIPS on OpenRISC that uses the nop() function, it fails due to the following error: drivers/watchdog/pic32-wdt.c: Assembler messages: drivers/watchdog/pic32-wdt.c:125: Error: unrecognized instruction `nop' The driver currently uses the generic version of nop() from include/asm-generic/barrier.h: #ifndef nop #define nop() asm volatile ("nop") #endif Let's fix this on OpenRISC by defining an architecture-specific version of nop(). This was tested by performing an allmodconfig openrisc cross compile on an aarch64 host. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601180236.BVy480We-lkp@intel.com/ Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Stafford Horne <shorne@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit f4bf64072c3669501969045eb081cd6bdea21e23) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 833dcd7 ] When the TX queue length reaches the threshold, the netdev watchdog immediately detects a TX queue timeout. This patch updates the trans_start timestamp of the transmit queue on every asynchronous USB URB submission along the transmit path, ensuring that the network watchdog accurately reflects ongoing transmission activity. Signed-off-by: Mingj Ye <insyelu@gmail.com> Reviewed-by: Hayes Wang <hayeswang@realtek.com> Link: https://patch.msgid.link/20260120015949.84996-1-insyelu@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 116bc0980e9193d806efb74fa847f21a6d17e53c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 1e3fb3c ] Validate iwl_probe_resp_data_notif::noa_attr::len_low since we are using its value to determine the noa_len, which is later used for the NoA attribute. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20251110150012.99b663d9b424.I206fd54c990ca9e1160b9b94fa8be44e67bcc1b9@changeid Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit db62e9f4483890631d037aee15f14a6f90a5fab0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit ad22d24 ] RDS connections carry a state "rds_conn_path::cp_state" and transitions from one state to another and are conditional upon an expected state: "rds_conn_path_transition." There is one exception to this conditionality, which is "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop" regardless of what state the condition is currently in. But as soon as a connection enters state "RDS_CONN_ERROR", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING" via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change"). A subsequent "rds_tcp_reset_callbacks" can then transition the state to "RDS_CONN_RESETTING" with a shutdown-worker queued. That'll trip up "rds_conn_init_shutdown", which was never adjusted to handle "RDS_CONN_RESETTING" and subsequently drops the connection with the dreaded "DR_INV_CONN_STATE", which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever. So we do two things here: a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code. b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again." Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com> Signed-off-by: Allison Henderson <allison.henderson@oracle.com> Link: https://patch.msgid.link/20260122055213.83608-2-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit f0f729bdffb08af32e0f54521b81b8a9e0321f16) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit cbe4136 ] Replace the BUG_ON() which never fired with a DEBUG_NET_WARN_ON_ONCE() $ scripts/bloat-o-meter -t vmlinux.1 vmlinux.2 add/remove: 2/2 grow/shrink: 1/1 up/down: 370/-254 (116) Function old new delta gro_try_pull_from_frag0 - 196 +196 napi_gro_frags 771 929 +158 __pfx_gro_try_pull_from_frag0 - 16 +16 __pfx_gro_pull_from_frag0 16 - -16 dev_gro_receive 1514 1464 -50 gro_pull_from_frag0 188 - -188 Total: Before=22565899, After=22566015, chg +0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260122045720.1221017-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit ab2848d3783ac35c64459105a3ae82d7c9ae501c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit e4faaf6 ] idev->mr_maxdelay is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While we are at it, make this field an u32. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260122172247.2429403-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit d5cd3bb7794e2b08a922724e1388c6610e45e8f3) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 878406d ] Currently, HCLGE_FD_AD_QID has only 10 bits and supports a maximum of 1023 queues. However, there are actually scenarios where the queue_id exceeds 1023. This patch adds an additional bit to HCLGE_FD_AD_QID to ensure that queue_id greater than 1023 are supported. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260123094756.3718516-2-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 2ace7ac88cb05fd850a6b122a3af116df4636c57) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit e31fa69 ] il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 941e3066441ce3d27c7f9cacf905877fd05b49c5) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…ent() [ Upstream commit 4dd1dda ] il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 31d4bb68f436d4a69767a0a220a9afe1222830c9) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 6e84fc3 ] syzbot reported that struct fib_alias.fa_state can be modified locklessly by RCU readers. [0] Let's use READ_ONCE()/WRITE_ONCE() properly. [0]: BUG: KCSAN: data-race in fib_table_lookup / fib_table_lookup write to 0xffff88811b06a7fa of 1 bytes by task 4167 on cpu 0: fib_alias_accessed net/ipv4/fib_lookup.h:32 [inline] fib_table_lookup+0x361/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811b06a7fa of 1 bytes by task 4168 on cpu 1: fib_alias_accessed net/ipv4/fib_lookup.h:31 [inline] fib_table_lookup+0x338/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 4168 Comm: syz.4.206 Not tainted syzkaller #0 PREEMPT(voluntary) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Reported-by: syzbot+d24f940f770afda885cf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69783ead.050a0220.c9109.0013.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260127043528.514160-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9eaeba5600e576c82ba0a3c023b3b2a253ddd761) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 4bb0910 ] The connection link policy is only set when establishing an outgoing ACL connection causing connection idle modes not to be available on incoming connections. Move the setting of the link policy to the creation of the connection so all ACL connection will use the link policy set on the HCI device. Signed-off-by: Stefan Sørensen <ssorensen@roku.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit c06dbfd954c9b500467afeeef20fc40bfce6b41a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 49d0901 ] hci_conn_enter_active_mode() uses queue_delayed_work() with the intention that the work will run after the given timeout. However, queue_delayed_work() does nothing if the work is already queued, so depending on the link policy we may end up putting the connection into idle mode every hdev->idle_timeout ms. Use mod_delayed_work() instead so the work is queued if not already queued, and the timeout is updated otherwise. Signed-off-by: Stefan Sørensen <ssorensen@roku.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 07960da05c0d6e72fbbe47d50cae3285de0c80a9) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit d9f7c39 ] Add VID:PID 13d3:3612 to the quirks_table. This ID pair is found in the Realtek RTL8852CE PCIe module in an ASUS TUF A14 2025 (FA401KM) laptop. Tested on aforementioned laptop. The device info from /sys/kernel/debug/usb/devices is listed as below. T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3612 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Shell Chen <w27@sorz.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit c051ef2f61f4636b16f99dea025012695c2790f8) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit cc6383d ] Add USB device ID 0x2c0a:0x8761 to the btusb driver fo the Realtek RTL8761BU Bluetooth adapter. Reference: https://www.startech.com/en-us/networking-io/av53c1-usb-bluetooth Signed-off-by: Jacopo Scannella <code@charlie.cat> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 37f4e6804d98256150673f506dc3f76c6a611bba) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 70e9a57 ] NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations. Signed-off-by: Geetha sowjanya <gakula@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260127125147.1642-1-gakula@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit d9b549b6951ba178ec14339a031cae65f4e43fe1) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit af1e822 ] The LDO (Low Dropout Regulator) setting is missing after suspend/resume in some platforms, and it will cause card loss. Therefore, reconfigure this setting to avoid it. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260127085036.44060-6-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit b015d4c70c9a95228b0967ac5fb3efa86d9d7926) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…te_chg() [ Upstream commit 820ba7d ] ath10k_wmi_event_peer_sta_ps_state_chg() uses lockdep_assert_held() to assert that ar->data_lock should be held by the caller, but neither ath10k_wmi_10_2_op_rx() nor ath10k_wmi_10_4_op_rx() acquire this lock before calling this function. The field arsta->peer_ps_state is documented as protected by ar->data_lock in core.h, and other accessors (ath10k_peer_ps_state_disable, ath10k_dbg_sta_read_peer_ps_state) properly acquire this lock. Add spin_lock_bh()/spin_unlock_bh() around the peer_ps_state update, and remove the lockdep_assert_held() to be aligned with new locking, following the pattern used by other WMI event handlers in the driver. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260123175611.767731-1-n7l8m4@u.northwestern.edu [removed excess blank line] Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 87465580215c48e9a6fabd4166d98a2e8aa134d9) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 9a9424c ] Several registers referenced in this driver's source code do not actually exist (they are not writable and read as zero in my testing). They exist in this driver because it originated as a copy of the dm9601 driver. Notably, these include the multicast filter registers - this causes the driver to not support multicast packets correctly. Remove the multicast filter code and register definitions. Instead, set the chip to receive all multicast filter packets when any multicast addresses are in the list. Reviewed-by: Simon Horman <horms@kernel.org> (from v1) Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260203013924.28582-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 7a8acafd45a990033c3267ace9ae3b2140e3e6fe) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit e25dbf5 ] The gcc-16.0.1 snapshot produces a false-positive warning that turns into a build failure with CONFIG_WERROR: In file included from arch/x86/include/asm/string.h:6, from net/vmw_vsock/vmci_transport.c:10: In function 'vmci_transport_packet_init', inlined from '__vmci_transport_send_control_pkt.constprop' at net/vmw_vsock/vmci_transport.c:198:2: arch/x86/include/asm/string_32.h:150:25: error: argument 2 null where non-null expected because argument 3 is nonzero [-Werror=nonnull] 150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ arch/x86/include/asm/string_32.h:150:25: note: in a call to built-in function '__builtin_memcpy' net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ This seems relatively harmless, and it so far the only instance of this warning I have found. The __vmci_transport_send_control_pkt function is called either with wait=NULL or with one of the type values that pass 'wait' into memcpy() here, but not from the same caller. Replacing the memcpy with a struct assignment is otherwise the same but avoids the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Bryan Tan <bryan-bt.tan@broadcom.com> Link: https://patch.msgid.link/20260203163406.2636463-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit f713dcd2ce83b7e3215150818d89e10f833b3e7a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit b89fc7c ] When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever. Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> Signed-off-by: Allison Henderson <allison.henderson@oracle.com> Link: https://patch.msgid.link/20260203055723.1085751-6-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 391200c274e90c34071b909ba12e3390b81b767f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit beb2f81 ] User forums report issues when assigning ASM1164 SATA controllers to VMs, especially in configurations with multiple controllers. Logs show the device fails to retrain after bus reset. Reports suggest this is an issue across multiple platforms. The device indicates support for PM reset, therefore the device still has a viable function level reset mechanism. The reporting user confirms the device is well behaved in this use case with bus reset disabled. Reported-by: Patrick Bianchi <patrick.w.bianchi@gmail.com> Link: https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-two-identical-devices.149003/ Signed-off-by: Alex Williamson <alex.williamson@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260109000211.398300-1-alex.williamson@nvidia.com Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit f5ea62163a78f6b220460c09f56c05375370dfb2) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Conflicts: drivers/pci/quirks.c
[ Upstream commit 1f5e57c ] Like pci_bus_lock(), pci_slot_lock() needs to lock the bridge device to prevent warnings like: pcieport 0000:e2:05.0: unlocked secondary bus reset via: pciehp_reset_slot+0x55/0xa0 Take and release the lock for the bridge providing the slot for the lock/trylock and unlock routines. Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://patch.msgid.link/20260130165953.751063-3-kbusch@meta.com Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a2376e912723c8dbd732d4ca699cdcdbdf5f8c12) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 14f66f4 ] In several places in the code, we have a label to signify the start of the code where a request can be replayed if necessary. However, some of these places were missing the necessary reinitializations of certain local variables before replay. This change makes sure that these variables get initialized after the label. Cc: stable@vger.kernel.org Reported-by: Yuchan Nam <entropy1110@gmail.com> Tested-by: Yuchan Nam <entropy1110@gmail.com> Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit c854ab481ece4b3e5f4c2e8b22824f015ff874a5) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit ff9cadd ] The ASUS Vivobook Pro 15X (M6501RR) with AMD Ryzen 9 6900HX has an internal DMIC that is not detected without a DMI quirk entry, as the BIOS does not set the AcpDmicConnected ACPI _DSD property. Adding the DMI entry enables the ACP6x DMIC machine driver to probe successfully. Cc: stable@vger.kernel.org Signed-off-by: Gustavo Salvini <guspatagonico@gmail.com> Link: https://patch.msgid.link/20260210155156.29079-1-guspatagonico@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 6ccfcad1b5822e514d8244c40488e3701535323e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit ffe68c3 ] dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys. Fixes: 6af55ff ("Driver for Beckhoff CX5020 EtherCAT master module.") Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://patch.msgid.link/20260213164340.77272-2-fourier.thomas@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 1e300c33ef3cc544c2b9c693778fe9490cfe9184) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit be054cc ] Commit 38a6f08 ("net: sched: support hash selecting tx queue") added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is computed as: mapping_mod = queue_mapping_max - queue_mapping + 1; The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcf_skbedit_hash() could trigger a divide-by-zero: queue_mapping += skb_get_hash(skb) % params->mapping_mod; Compute mapping_mod in a wider type and reject ranges larger than U16_MAX to prevent params->mapping_mod from becoming 0 and avoid the crash. Fixes: 38a6f08 ("net: sched: support hash selecting tx queue") Cc: stable@vger.kernel.org # 6.12+ Signed-off-by: Ruitong Liu <cnitlrt@gmail.com> Link: https://patch.msgid.link/20260213175948.1505257-1-cnitlrt@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9c735a7d98c982a786b0db71eb6566ee00aaa04f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit e00ac9e ] Dave reports that kexec may fail when the first kernel boots via the EFI stub but without EFI runtime services, as in that case, the RSDP address field in struct bootparams is never assigned. Kexec copies this value into the version of struct bootparams that it provides to the incoming kernel, which may have no other means to locate the ACPI root pointer. So take the value from the EFI config tables if no root pointer has been set in the first kernel's struct bootparams. Fixes: a1b87d5 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Cc: <stable@vger.kernel.org> # v6.1 Reported-by: Dave Young <dyoung@redhat.com> Tested-by: Dave Young <dyoung@redhat.com> Link: https://lore.kernel.org/linux-efi/aZQg_tRQmdKNadCg@darkstar.users.ipa.redhat.com/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit ad36408959566309ec135d352dcc2ac698585632) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 29cc0f3 ] Quentin forwards a report from Hyesoo Yu, describing an interesting problem with the use of WFxT in __delay() when a vcpu is loaded and that KVM is *not* in VHE mode (either nVHE or hVHE). In this case, CNTVOFF_EL2 is set to a non-zero value to reflect the state of the guest virtual counter. At the same time, __delay() is using get_cycles() to read the counter value, which is indirected to reading CNTPCT_EL0. The core of the issue is that WFxT is using the *virtual* counter, while the kernel is using the physical counter, and that the offset introduces a really bad discrepancy between the two. Fix this by forcing the use of CNTVCT_EL0, making __delay() consistent irrespective of the value of CNTVOFF_EL2. Reported-by: Hyesoo Yu <hyesoo.yu@samsung.com> Reported-by: Quentin Perret <qperret@google.com> Reviewed-by: Quentin Perret <qperret@google.com> Fixes: 7d26b05 ("arm64: Use WFxT for __delay() when possible") Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/ktosachvft2cgqd5qkukn275ugmhy6xrhxur4zqpdxlfr3qh5h@o3zrfnsq63od Cc: stable@vger.kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit dc99b25ed4f71e5fe1b2f66a518f820e46356028) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 571dcbe ] Since commit 9c328f5 ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). Fixes: 9c328f5 ("net: nfc: nci: Add parameter validation for packet data") Cc: stable@vger.kernel.org Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at> Reported-by: syzbot+740e04c2a93467a0f8c8@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260218083000.301354-1-michael.thalmeier@hale.at Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit ad058a4317db7fdb3f09caa6ed536d24a62ce6a0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit f0a0da1 ] The event_hist_open() and event_hist_poll() functions currently retrieve a trace_event_file pointer from a file struct by invoking event_file_data(), which simply returns file->f_inode->i_private. The functions then check if the pointer is NULL to determine whether the event is still valid. This approach is flawed because i_private is assigned when an eventfs inode is allocated and remains set throughout its lifetime. Instead, the code should call event_file_file(), which checks for EVENT_FILE_FL_FREED. Using the incorrect access function may result in the code potentially opening a hist file for an event that is being removed or becoming stuck while polling on this file. Correct the access method to event_file_file() in both functions. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Tom Zanussi <zanussi@kernel.org> Link: https://patch.msgid.link/20260219162737.314231-2-petr.pavlu@suse.com Fixes: 1bd13ed ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e4e5026252b4e03c0f31511b2de97d0ec6ffb7aa) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 9678e53 ] The event_hist_poll() function attempts to verify whether an event file is being removed, but this check may not occur or could be unnecessarily delayed. This happens because hist_poll_wakeup() is currently invoked only from event_hist_trigger() when a hist command is triggered. If the event file is being removed, no associated hist command will be triggered and a waiter will be woken up only after an unrelated hist command is triggered. Fix the issue by adding a call to hist_poll_wakeup() in remove_event_file_dir() after setting the EVENT_FILE_FL_FREED flag. This ensures that a task polling on a hist file is woken up and receives EPOLLERR. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Tom Zanussi <zanussi@kernel.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Link: https://patch.msgid.link/20260219162737.314231-3-petr.pavlu@suse.com Fixes: 1bd13ed ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 1cdff5d564fe8ec12717921e89d220a07f522d26) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 6a4b505 ] The buffer used for "qp%d" was only 4 bytes, which truncates names like "qp10" to "qp1" and causes multiple queues to share the same directory. Enlarge the buffer and use sizeof() to avoid truncation. Fixes: fce8a7b ("PCI-Express Non-Transparent Bridge Support") Cc: <stable@vger.kernel.org> # v3.9+ Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Jon Mason <jdmason@kudzu.us> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit fe418ef21efdcdc4f0959b837fe8517a2d269990) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 524696a ] Commit 469c1c9 ("kernel-doc: Issue warnings that were silently discarded") started emitting warnings for cases that were previously silently discarded. One such case is in intel_wakeref.h: Warning: drivers/gpu/drm/i915/intel_wakeref.h:156 expecting prototype for __intel_wakeref_put(). Prototype was for INTEL_WAKEREF_PUT_ASYNC() instead Arguably kernel-doc should be able to handle this, as it's valid C, but having the flags defined between the function declarator and the body is just asking for trouble. Move the INTEL_WAKEREF_PUT_* macros away from there, making kernel-doc's life easier. While at it, reduce the unnecessary abstraction levels by removing the enum, and append _MASK to INTEL_WAKEREF_PUT_DELAY for clarity. Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251215120908.3515578-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 18845fb30921dc2bacbbb2ad6113d5fd4d0ceb17) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit e5cb94b ] Ben reports that when running with CONFIG_DEBUG_PREEMPT, using __arch_counter_get_cntvct_stable() results in well deserves warnings, as we access a per-CPU variable without preemption disabled. Fix the issue by disabling preemption on reading the counter. We can probably do a lot better by not disabling preemption on systems that do not require horrible workarounds to return a valid counter value, but this plugs the issue for the time being. Fixes: 29cc0f3 ("arm64: Force the use of CNTVCT_EL0 in __delay()") Reported-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com Tested-by: Ben Horgan <ben.horgan@arm.com> Tested-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 0ac0e02183c52b26a77b2db2fae835cd908f03df) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Sasha Levin <sashal@kernel.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Reviewed-by: Mark Brown <broonie@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Tested-by: Francesco Dolcini <francesco.dolcini@toradex.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> (cherry picked from commit 682d8e2f892b73c2f574684c8dd6b625361b4c03) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
deepin-ci-robot
requested review from
Avenger-285714,
Ink-Paper and
hello666888999
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
added 2 commits
March 6, 2026 18:02
…buffer" This reverts commit c5489d0. The commit introduces a call to ima_validate_range() in arch/x86/kernel/setup.c, but the function declaration is not available in the 6.12 stable tree, resulting in build failures due to implicit function declaration errors across multiple stable branches. Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit acf7c8972775a35be318744cc436bdb20b65cebe) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 4fc00fe35d46b4fc8dac2eb543a0e3d44bb15f47) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
This was referenced Mar 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Update kernel base to 6.6.128,6.6.129.
git log --oneline v6.6.128..v6.6.129 |wc
2 16 119
git log --oneline v6.6.127..v6.6.128 | wc
683 5896 49032