--- /dev/null
+From 5471834a96fb697874be2ca0b052e74bcf3c23d1 Mon Sep 17 00:00:00 2001
+From: Cen Zhang <zzzccc427@gmail.com>
+Date: Wed, 18 Mar 2026 15:32:53 +0800
+Subject: f2fs: add READ_ONCE() for i_blocks in f2fs_update_inode()
+
+From: Cen Zhang <zzzccc427@gmail.com>
+
+commit 5471834a96fb697874be2ca0b052e74bcf3c23d1 upstream.
+
+f2fs_update_inode() reads inode->i_blocks without holding i_lock to
+serialize it to the on-disk inode, while concurrent truncate or
+allocation paths may modify i_blocks under i_lock. Since blkcnt_t is
+u64, this risks torn reads on 32-bit architectures.
+
+Following the approach in ext4_inode_blocks_set(), add READ_ONCE() to prevent
+potential compiler-induced tearing.
+
+Fixes: 19f99cee206c ("f2fs: add core inode operations")
+Cc: stable@vger.kernel.org
+Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/inode.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/f2fs/inode.c
++++ b/fs/f2fs/inode.c
+@@ -663,7 +663,7 @@ void f2fs_update_inode(struct inode *ino
+ ri->i_uid = cpu_to_le32(i_uid_read(inode));
+ ri->i_gid = cpu_to_le32(i_gid_read(inode));
+ ri->i_links = cpu_to_le32(inode->i_nlink);
+- ri->i_blocks = cpu_to_le64(SECTOR_TO_BLOCK(inode->i_blocks) + 1);
++ ri->i_blocks = cpu_to_le64(SECTOR_TO_BLOCK(READ_ONCE(inode->i_blocks)) + 1);
+
+ if (!f2fs_is_atomic_file(inode) ||
+ is_inode_flag_set(inode, FI_ATOMIC_COMMITTED))
--- /dev/null
+From 95e159ad3e52f7478cfd22e44ec37c9f334f8993 Mon Sep 17 00:00:00 2001
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+Date: Mon, 23 Mar 2026 20:06:24 +0800
+Subject: f2fs: fix fiemap boundary handling when read extent cache is incomplete
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+
+commit 95e159ad3e52f7478cfd22e44ec37c9f334f8993 upstream.
+
+f2fs_fiemap() calls f2fs_map_blocks() to obtain the block mapping a
+file, and then merges contiguous mappings into extents. If the mapping
+is found in the read extent cache, node blocks do not need to be read.
+However, in the following scenario, a contiguous extent can be split
+into two extents:
+
+$ dd if=/dev/zero of=data.128M bs=1M count=128
+$ losetup -f data.128M
+$ mkfs.f2fs /dev/loop0 -f
+$ mount -o mode=lfs /dev/loop0 /mnt/f2fs/
+$ cd /mnt/f2fs/
+$ dd if=/dev/zero of=data.72M bs=1M count=72 && sync
+$ dd if=/dev/zero of=data.4M bs=1M count=4 && sync
+$ dd if=/dev/zero of=data.4M bs=1M count=2 seek=2 conv=notrunc && sync
+$ echo 3 > /proc/sys/vm/drop_caches
+$ dd if=/dev/zero of=data.4M bs=1M count=2 seek=0 conv=notrunc && sync
+$ dd if=/dev/zero of=data.4M bs=1M count=2 seek=0 conv=notrunc && sync
+$ f2fs_io fiemap 0 1024 data.4M
+Fiemap: offset = 0 len = 1024
+logical addr. physical addr. length flags
+0 0000000000000000 0000000006400000 0000000000200000 00001000
+1 0000000000200000 0000000006600000 0000000000200000 00001001
+
+Although the physical addresses of the ranges 0～2MB and 2M～4MB are
+contiguous, the mapping for the 2M～4MB range is not present in memory.
+When the physical addresses for the 0～2MB range are updated, no merge
+happens because the adjacent mapping is missing from the in-memory
+cache. As a result, fiemap reports two separate extents instead of a
+single contiguous one.
+
+The root cause is that the read extent cache does not guarantee that all
+blocks of an extent are present in memory. Therefore, when the extent
+length returned by f2fs_map_blocks_cached() is smaller than maxblocks,
+the remaining mappings are retrieved via f2fs_get_dnode_of_data() to
+ensure correct fiemap extent boundary handling.
+
+Cc: stable@kernel.org
+Fixes: cd8fc5226bef ("f2fs: remove the create argument to f2fs_map_blocks")
+Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/data.c | 25 ++++++++++++++++++++++---
+ 1 file changed, 22 insertions(+), 3 deletions(-)
+
+--- a/fs/f2fs/data.c
++++ b/fs/f2fs/data.c
+@@ -1564,8 +1564,26 @@ int f2fs_map_blocks(struct inode *inode,
+ if (!maxblocks)
+ return 0;
+
+- if (!map->m_may_create && f2fs_map_blocks_cached(inode, map, flag))
+- goto out;
++ if (!map->m_may_create && f2fs_map_blocks_cached(inode, map, flag)) {
++ struct extent_info ei;
++
++ /*
++ * 1. If map->m_multidev_dio is true, map->m_pblk cannot be
++ * waitted by f2fs_wait_on_block_writeback_range() and are not
++ * mergeable.
++ * 2. If pgofs hits the read extent cache, it means the mapping
++ * is already cached in the extent cache, but it is not
++ * mergeable, and there is no need to query the mapping again
++ * via f2fs_get_dnode_of_data().
++ */
++ pgofs = (pgoff_t)map->m_lblk + map->m_len;
++ if (map->m_len == maxblocks ||
++ map->m_multidev_dio ||
++ f2fs_lookup_read_extent_cache(inode, pgofs, &ei))
++ goto out;
++ ofs = map->m_len;
++ goto map_more;
++ }
+
+ map->m_bdev = inode->i_sb->s_bdev;
+ map->m_multidev_dio =
+@@ -1576,7 +1594,8 @@ int f2fs_map_blocks(struct inode *inode,
+
+ /* it only supports block size == page size */
+ pgofs = (pgoff_t)map->m_lblk;
+- end = pgofs + maxblocks;
++map_more:
++ end = (pgoff_t)map->m_lblk + maxblocks;
+
+ next_dnode:
+ if (map->m_may_create) {
--- /dev/null
+From eb2ca3ca983551a80e16a4a25df5a4ce59df8484 Mon Sep 17 00:00:00 2001
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+Date: Mon, 23 Mar 2026 20:06:22 +0800
+Subject: f2fs: fix incorrect multidevice info in trace_f2fs_map_blocks()
+
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+
+commit eb2ca3ca983551a80e16a4a25df5a4ce59df8484 upstream.
+
+When f2fs_map_blocks()->f2fs_map_blocks_cached() hits the read extent
+cache, map->m_multidev_dio is not updated, which leads to incorrect
+multidevice information being reported by trace_f2fs_map_blocks().
+
+This patch updates map->m_multidev_dio in f2fs_map_blocks_cached() when
+the read extent cache is hit.
+
+Cc: stable@kernel.org
+Fixes: 0094e98bd147 ("f2fs: factor a f2fs_map_blocks_cached helper")
+Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/data.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/f2fs/data.c
++++ b/fs/f2fs/data.c
+@@ -1509,7 +1509,8 @@ static bool f2fs_map_blocks_cached(struc
+ f2fs_wait_on_block_writeback_range(inode,
+ map->m_pblk, map->m_len);
+
+- if (f2fs_allow_multi_device_dio(sbi, flag)) {
++ map->m_multidev_dio = f2fs_allow_multi_device_dio(sbi, flag);
++ if (map->m_multidev_dio) {
+ int bidx = f2fs_target_device_index(sbi, map->m_pblk);
+ struct f2fs_dev_info *dev = &sbi->devs[bidx];
+
--- /dev/null
+From ed78aeebef05212ef7dca93bd931e4eff67c113f Mon Sep 17 00:00:00 2001
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+Date: Fri, 3 Apr 2026 22:40:17 +0800
+Subject: f2fs: fix node_cnt race between extent node destroy and writeback
+
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+
+commit ed78aeebef05212ef7dca93bd931e4eff67c113f upstream.
+
+f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing
+extent nodes. When called from f2fs_drop_inode() with I_SYNC set,
+concurrent kworker writeback can insert new extent nodes into the same
+extent tree, racing with the destroy and triggering f2fs_bug_on() in
+__destroy_extent_node(). The scenario is as follows:
+
+drop inode writeback
+ - iput
+ - f2fs_drop_inode // I_SYNC set
+ - f2fs_destroy_extent_node
+ - __destroy_extent_node
+ - while (node_cnt) {
+ write_lock(&et->lock)
+ __free_extent_tree
+ write_unlock(&et->lock)
+ - __writeback_single_inode
+ - f2fs_outplace_write_data
+ - f2fs_update_read_extent_cache
+ - __update_extent_tree_range
+ // FI_NO_EXTENT not set,
+ // insert new extent node
+ } // node_cnt == 0, exit while
+ - f2fs_bug_on(node_cnt) // node_cnt > 0
+
+Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for
+EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected.
+
+This patch set FI_NO_EXTENT under et->lock in __destroy_extent_node(),
+consistent with other callers (__update_extent_tree_range and
+__drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and
+EX_BLOCK_AGE tree.
+
+Fixes: 3fc5d5a182f6 ("f2fs: fix to shrink read extent node in batches")
+Cc: stable@vger.kernel.org
+Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/extent_cache.c | 17 ++++++++++-------
+ 1 file changed, 10 insertions(+), 7 deletions(-)
+
+--- a/fs/f2fs/extent_cache.c
++++ b/fs/f2fs/extent_cache.c
+@@ -86,9 +86,10 @@ static bool __may_extent_tree(struct ino
+ if (!__init_may_extent_tree(inode, type))
+ return false;
+
++ if (is_inode_flag_set(inode, FI_NO_EXTENT))
++ return false;
++
+ if (type == EX_READ) {
+- if (is_inode_flag_set(inode, FI_NO_EXTENT))
+- return false;
+ if (is_inode_flag_set(inode, FI_COMPRESSED_FILE) &&
+ !f2fs_sb_has_readonly(F2FS_I_SB(inode)))
+ return false;
+@@ -601,6 +602,8 @@ static unsigned int __destroy_extent_nod
+
+ while (atomic_read(&et->node_cnt)) {
+ write_lock(&et->lock);
++ if (!is_inode_flag_set(inode, FI_NO_EXTENT))
++ set_inode_flag(inode, FI_NO_EXTENT);
+ node_cnt += __free_extent_tree(sbi, et, nr_shrink);
+ write_unlock(&et->lock);
+ }
+@@ -636,12 +639,12 @@ static void __update_extent_tree_range(s
+
+ write_lock(&et->lock);
+
+- if (type == EX_READ) {
+- if (is_inode_flag_set(inode, FI_NO_EXTENT)) {
+- write_unlock(&et->lock);
+- return;
+- }
++ if (is_inode_flag_set(inode, FI_NO_EXTENT)) {
++ write_unlock(&et->lock);
++ return;
++ }
+
++ if (type == EX_READ) {
+ prev = et->largest;
+ dei.len = 0;
+
--- /dev/null
+From b635f2ecdb5ad34f9c967cabb704d6bed9382fd0 Mon Sep 17 00:00:00 2001
+From: Guangshuo Li <lgs201920130244@gmail.com>
+Date: Fri, 10 Apr 2026 20:47:26 +0800
+Subject: f2fs: fix uninitialized kobject put in f2fs_init_sysfs()
+
+From: Guangshuo Li <lgs201920130244@gmail.com>
+
+commit b635f2ecdb5ad34f9c967cabb704d6bed9382fd0 upstream.
+
+In f2fs_init_sysfs(), all failure paths after kset_register() jump to
+put_kobject, which unconditionally releases both f2fs_tune and
+f2fs_feat.
+
+If kobject_init_and_add(&f2fs_feat, ...) fails, f2fs_tune has not been
+initialized yet, so calling kobject_put(&f2fs_tune) is invalid.
+
+Fix this by splitting the unwind path so each error path only releases
+objects that were successfully initialized.
+
+Fixes: a907f3a68ee26ba4 ("f2fs: add a sysfs entry to reclaim POSIX_FADV_NOREUSE pages")
+Cc: stable@vger.kernel.org
+Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/sysfs.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/fs/f2fs/sysfs.c
++++ b/fs/f2fs/sysfs.c
+@@ -1795,24 +1795,26 @@ int __init f2fs_init_sysfs(void)
+ ret = kobject_init_and_add(&f2fs_feat, &f2fs_feat_ktype,
+ NULL, "features");
+ if (ret)
+- goto put_kobject;
++ goto unregister_kset;
+
+ ret = kobject_init_and_add(&f2fs_tune, &f2fs_tune_ktype,
+ NULL, "tuning");
+ if (ret)
+- goto put_kobject;
++ goto put_feat;
+
+ f2fs_proc_root = proc_mkdir("fs/f2fs", NULL);
+ if (!f2fs_proc_root) {
+ ret = -ENOMEM;
+- goto put_kobject;
++ goto put_tune;
+ }
+
+ return 0;
+
+-put_kobject:
++put_tune:
+ kobject_put(&f2fs_tune);
++put_feat:
+ kobject_put(&f2fs_feat);
++unregister_kset:
+ kset_unregister(&f2fs_kset);
+ return ret;
+ }
--- /dev/null
+From 5bb0aed57ba944f8c201e4e82ec066e0187e0f85 Mon Sep 17 00:00:00 2001
+From: Quentin Perret <qperret@google.com>
+Date: Fri, 24 Apr 2026 09:49:08 +0100
+Subject: KVM: arm64: Fix initialisation order in __pkvm_init_finalise()
+
+From: Quentin Perret <qperret@google.com>
+
+commit 5bb0aed57ba944f8c201e4e82ec066e0187e0f85 upstream.
+
+fix_host_ownership() walks the hypervisor's stage-1 page-table to
+adjust the host's stage-2 accordingly. Any such adjustment that
+requires cache maintenance operations depends on the per-CPU hyp
+fixmap being present. However, fix_host_ownership() is currently
+called before fix_hyp_pgtable_refcnt() and hyp_create_fixmap(), so
+the fixmap does not yet exist when it runs.
+
+This is benign today because the host stage-2 starts empty and no
+CMOs are needed, but it becomes a latent crash as soon as
+fix_host_ownership() is extended to operate on a non-empty
+page-table.
+
+Reorder the calls so that fix_hyp_pgtable_refcnt() and
+hyp_create_fixmap() complete before fix_host_ownership() is invoked.
+
+Fixes: 0d16d12eb26e ("KVM: arm64: Fix-up hyp stage-1 refcounts for all pages mapped at EL2")
+Signed-off-by: Quentin Perret <qperret@google.com>
+Signed-off-by: Fuad Tabba <tabba@google.com>
+Link: https://patch.msgid.link/20260424084908.370776-7-tabba@google.com
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/hyp/nvhe/setup.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/kvm/hyp/nvhe/setup.c
++++ b/arch/arm64/kvm/hyp/nvhe/setup.c
+@@ -307,15 +307,15 @@ void __noreturn __pkvm_init_finalise(voi
+ };
+ pkvm_pgtable.mm_ops = &pkvm_pgtable_mm_ops;
+
+- ret = fix_host_ownership();
++ ret = fix_hyp_pgtable_refcnt();
+ if (ret)
+ goto out;
+
+- ret = fix_hyp_pgtable_refcnt();
++ ret = hyp_create_pcpu_fixmap();
+ if (ret)
+ goto out;
+
+- ret = hyp_create_pcpu_fixmap();
++ ret = fix_host_ownership();
+ if (ret)
+ goto out;
+
--- /dev/null
+From a0e6ae45af17e8b27958830595799c702ffbab8d Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+Date: Tue, 7 Apr 2026 21:27:02 +0100
+Subject: KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: David Woodhouse <dwmw@amazon.co.uk>
+
+commit a0e6ae45af17e8b27958830595799c702ffbab8d upstream.
+
+The uaccess write handlers for GICD_IIDR in both GICv2 and GICv3
+extract the revision field from 'reg' (the current IIDR value read back
+from the emulated distributor) instead of 'val' (the value userspace is
+trying to write). This means userspace can never actually change the
+implementation revision — the extracted value is always the current one.
+
+Fix the FIELD_GET to use 'val' so that userspace can select a different
+revision for migration compatibility.
+
+Fixes: 49a1a2c70a7f ("KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR revision")
+Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
+Link: https://patch.msgid.link/20260407210949.2076251-2-dwmw2@infradead.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/vgic/vgic-mmio-v2.c | 2 +-
+ arch/arm64/kvm/vgic/vgic-mmio-v3.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/kvm/vgic/vgic-mmio-v2.c
++++ b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
+@@ -91,7 +91,7 @@ static int vgic_mmio_uaccess_write_v2_mi
+ * migration from old kernels to new kernels with legacy
+ * userspace.
+ */
+- reg = FIELD_GET(GICD_IIDR_REVISION_MASK, reg);
++ reg = FIELD_GET(GICD_IIDR_REVISION_MASK, val);
+ switch (reg) {
+ case KVM_VGIC_IMP_REV_2:
+ case KVM_VGIC_IMP_REV_3:
+--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
++++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+@@ -167,7 +167,7 @@ static int vgic_mmio_uaccess_write_v3_mi
+ if ((reg ^ val) & ~GICD_IIDR_REVISION_MASK)
+ return -EINVAL;
+
+- reg = FIELD_GET(GICD_IIDR_REVISION_MASK, reg);
++ reg = FIELD_GET(GICD_IIDR_REVISION_MASK, val);
+ switch (reg) {
+ case KVM_VGIC_IMP_REV_2:
+ case KVM_VGIC_IMP_REV_3:
--- /dev/null
+From 8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e Mon Sep 17 00:00:00 2001
+From: Wentao Guan <guanwentao@uniontech.com>
+Date: Mon, 4 May 2026 09:00:20 +0800
+Subject: LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()
+
+From: Wentao Guan <guanwentao@uniontech.com>
+
+commit 8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e upstream.
+
+The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and
+readl(crtc_reg) will access with random address, because the "device" is
+from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong
+when my platform inserts a discrete GPU:
+
+lspci -tv
+-[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller
+...
+ +-06.0 Loongson Technology LLC LG100 GPU
+ +-06.2 Loongson Technology LLC Device 7a37
+...
+
+Add a default switch case to fix the panic as below:
+
+ Kernel ade access[#1]:
+ CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4
+ pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0
+ a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002
+ a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001
+ t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000
+ t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0
+ t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8
+ s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000
+ s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000
+ ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210
+ ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210
+ CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
+ PRMD: 00000004 (PPLV0 +PIE -PWE)
+ EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
+ ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
+ ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1)
+ BADV: 7fffffffffffff00
+ PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)
+ Modules linked in:
+ Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____))
+ Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007
+ 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff
+ 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08
+ 0000000000000000 0000000000000000 0000000000000006 90000001002fb778
+ 90000001000530b8 90000000027af000 0000000000000000 9000000100054000
+ 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001
+ 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000
+ 0000000000000006 90000000027af000 0000000000000030 90000000027af000
+ 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560
+ 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030
+ ...
+ Call Trace:
+ [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210
+ [<9000000000eebc08>] pci_fixup_device+0x108/0x280
+ [<9000000000ebb70c>] pci_setup_device+0x24c/0x690
+ [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140
+ [<9000000000ebc684>] pci_scan_slot+0xc4/0x280
+ [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0
+ [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420
+ [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440
+ [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0
+ [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0
+ [<90000000010e200c>] device_for_each_child+0x6c/0xe0
+ [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70
+ [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0
+ [<90000000010e200c>] device_for_each_child+0x6c/0xe0
+ [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70
+ [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0
+ [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280
+ [<900000000189c028>] acpi_scan_init+0x194/0x310
+ [<900000000189bc6c>] acpi_init+0xcc/0x140
+ [<9000000000220cdc>] do_one_initcall+0x4c/0x310
+ [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4
+ [<900000000184326c>] kernel_init+0x28/0x13c
+ [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4
+
+Cc: stable@vger.kernel.org
+Fixes: 95db0c9f526d ("LoongArch: Workaround LS2K/LS7A GPU DMA hang bug")
+Link: https://gist.github.com/opsiff/ebf2dac51b4013d22462f2124c55f807
+Link: https://gist.github.com/opsiff/a62f2a73db0492b3c49bf223a339b133
+Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/pci/pci.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/loongarch/pci/pci.c
++++ b/arch/loongarch/pci/pci.c
+@@ -133,6 +133,9 @@ static void loongson_gpu_fixup_dma_hang(
+ crtc_reg = regbase;
+ crtc_offset = 0x400;
+ break;
++ default:
++ iounmap(regbase);
++ return;
+ }
+
+ for (i = 0; i < CRTC_NUM_MAX; i++, crtc_reg += crtc_offset) {
--- /dev/null
+From b3e31a6650d4cab63f0814c37c0b360372c6ee9e Mon Sep 17 00:00:00 2001
+From: Qiang Ma <maqianga@uniontech.com>
+Date: Mon, 4 May 2026 09:00:37 +0800
+Subject: LoongArch: KVM: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS
+
+From: Qiang Ma <maqianga@uniontech.com>
+
+commit b3e31a6650d4cab63f0814c37c0b360372c6ee9e upstream.
+
+It doesn't make sense to return the recommended maximum number of vCPUs
+which exceeds the maximum possible number of vCPUs.
+
+Other architectures have already done this, such as commit 57a2e13ebdda
+("KVM: MIPS: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS")
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Bibo Mao <maobibo@loongson.cn>
+Signed-off-by: Qiang Ma <maqianga@uniontech.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kvm/vm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/loongarch/kvm/vm.c
++++ b/arch/loongarch/kvm/vm.c
+@@ -91,7 +91,7 @@ int kvm_vm_ioctl_check_extension(struct
+ r = 1;
+ break;
+ case KVM_CAP_NR_VCPUS:
+- r = num_online_cpus();
++ r = min_t(unsigned int, num_online_cpus(), KVM_MAX_VCPUS);
+ break;
+ case KVM_CAP_MAX_VCPUS:
+ r = KVM_MAX_VCPUS;
--- /dev/null
+From 2433f3f5724b3af569d9fb411ba728629524738b Mon Sep 17 00:00:00 2001
+From: Bibo Mao <maobibo@loongson.cn>
+Date: Mon, 4 May 2026 09:00:48 +0800
+Subject: LoongArch: KVM: Fix HW timer interrupt lost when inject interrupt by software
+
+From: Bibo Mao <maobibo@loongson.cn>
+
+commit 2433f3f5724b3af569d9fb411ba728629524738b upstream.
+
+With passthrough HW timer, timer interrupt is injected by HW. When
+inject emulated CPU interrupt by software such SIP0/SIP1/IPI, HW timer
+interrupt may be lost.
+
+Here check whether there is timer tick value inversion before and after
+injecting emulated CPU interrupt by software, timer enabling by reading
+timer cfg register is skipped. If the timer tick value is detected with
+changing, then timer should be enabled. And inject a timer interrupt by
+software if there is.
+
+Cc: <stable@vger.kernel.org>
+Fixes: f45ad5b8aa93 ("LoongArch: KVM: Implement vcpu interrupt operations").
+Signed-off-by: Bibo Mao <maobibo@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kvm/interrupt.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/arch/loongarch/kvm/interrupt.c
++++ b/arch/loongarch/kvm/interrupt.c
+@@ -26,6 +26,7 @@ static unsigned int priority_to_irq[EXCC
+ static int kvm_irq_deliver(struct kvm_vcpu *vcpu, unsigned int priority)
+ {
+ unsigned int irq = 0;
++ unsigned long old, new;
+
+ clear_bit(priority, &vcpu->arch.irq_pending);
+ if (priority < EXCCODE_INT_NUM)
+@@ -36,7 +37,13 @@ static int kvm_irq_deliver(struct kvm_vc
+ case INT_IPI:
+ case INT_SWI0:
+ case INT_SWI1:
++ old = kvm_read_hw_gcsr(LOONGARCH_CSR_TVAL);
+ set_gcsr_estat(irq);
++ new = kvm_read_hw_gcsr(LOONGARCH_CSR_TVAL);
++
++ /* Inject TI if TVAL inverted */
++ if (new > old)
++ set_gcsr_estat(CPU_TIMER);
+ break;
+
+ case INT_HWI0 ... INT_HWI7:
+@@ -53,6 +60,7 @@ static int kvm_irq_deliver(struct kvm_vc
+ static int kvm_irq_clear(struct kvm_vcpu *vcpu, unsigned int priority)
+ {
+ unsigned int irq = 0;
++ unsigned long old, new;
+
+ clear_bit(priority, &vcpu->arch.irq_clear);
+ if (priority < EXCCODE_INT_NUM)
+@@ -63,7 +71,13 @@ static int kvm_irq_clear(struct kvm_vcpu
+ case INT_IPI:
+ case INT_SWI0:
+ case INT_SWI1:
++ old = kvm_read_hw_gcsr(LOONGARCH_CSR_TVAL);
+ clear_gcsr_estat(irq);
++ new = kvm_read_hw_gcsr(LOONGARCH_CSR_TVAL);
++
++ /* Inject TI if TVAL inverted */
++ if (new > old)
++ set_gcsr_estat(CPU_TIMER);
+ break;
+
+ case INT_HWI0 ... INT_HWI7:
--- /dev/null
+From b323a441da602dfdfc24f30d3190cac786ffebf2 Mon Sep 17 00:00:00 2001
+From: Xianglai Li <lixianglai@loongson.cn>
+Date: Mon, 4 May 2026 09:00:37 +0800
+Subject: LoongArch: KVM: Fix "unreliable stack" for kvm_exc_entry
+
+From: Xianglai Li <lixianglai@loongson.cn>
+
+commit b323a441da602dfdfc24f30d3190cac786ffebf2 upstream.
+
+Insert the appropriate UNWIND hint into the kvm_exc_entry assembly
+function to guide the generation of correct ORC table entries, thereby
+solving the timeout problem ("unreliable stack") while loading the
+livepatch-sample module on a physical machine running virtual machines
+with multiple vcpus.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kvm/switch.S | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/loongarch/kvm/switch.S
++++ b/arch/loongarch/kvm/switch.S
+@@ -112,7 +112,7 @@
+ .text
+ .cfi_sections .debug_frame
+ SYM_CODE_START(kvm_exc_entry)
+- UNWIND_HINT_UNDEFINED
++ UNWIND_HINT_END_OF_STACK
+ csrwr a2, KVM_TEMP_KS
+ csrrd a2, KVM_VCPU_KS
+ addi.d a2, a2, KVM_VCPU_ARCH
--- /dev/null
+From 5a873d77ba792410a796595a917be6a440f9b7d2 Mon Sep 17 00:00:00 2001
+From: Bibo Mao <maobibo@loongson.cn>
+Date: Mon, 4 May 2026 09:00:48 +0800
+Subject: LoongArch: KVM: Move unconditional delay into timer clear scenery
+
+From: Bibo Mao <maobibo@loongson.cn>
+
+commit 5a873d77ba792410a796595a917be6a440f9b7d2 upstream.
+
+When timer interrupt arrives in guest kernel, guest kernel clears the
+timer interrupt and program timer with the next incoming event.
+
+During this stage, timer tick is -1 and timer interrupt status is
+disabled in ESTAT register. KVM hypervisor need write zero with timer
+tick register and wait timer interrupt injection from HW side, and
+then clear timer interrupt.
+
+So there is 2 cycle delay in KVM hypervisor to emulate such scenery,
+and the delay is unnecessary if there is no need to clear the timer
+interrupt.
+
+Here move 2 cycle delay into timer clear scenery and add timer ESTAT
+checking after delay, and set max timer expire value if timer interrupt
+does not arrive still.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Bibo Mao <maobibo@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kvm/timer.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/arch/loongarch/kvm/timer.c
++++ b/arch/loongarch/kvm/timer.c
+@@ -96,15 +96,21 @@ void kvm_restore_timer(struct kvm_vcpu *
+ * and set CSR TVAL with -1
+ */
+ write_gcsr_timertick(0);
+- __delay(2); /* Wait cycles until timer interrupt injected */
+
+ /*
+ * Writing CSR_TINTCLR_TI to LOONGARCH_CSR_TINTCLR will clear
+ * timer interrupt, and CSR TVAL keeps unchanged with -1, it
+ * avoids spurious timer interrupt
+ */
+- if (!(estat & CPU_TIMER))
++ if (!(estat & CPU_TIMER)) {
++ __delay(2); /* Wait cycles until timer interrupt injected */
++
++ /* Write TVAL with max value if no TI shot */
++ estat = kvm_read_hw_gcsr(LOONGARCH_CSR_ESTAT);
++ if (!(estat & CPU_TIMER))
++ write_gcsr_timertick(CSR_TCFG_VAL);
+ gcsr_write(CSR_TINTCLR_TI, LOONGARCH_CSR_TINTCLR);
++ }
+ return;
+ }
+
--- /dev/null
+From 81e18777d61440511451866c7c80b34a8bdd6b33 Mon Sep 17 00:00:00 2001
+From: Tao Cui <cuitao@kylinos.cn>
+Date: Mon, 4 May 2026 09:00:38 +0800
+Subject: LoongArch: KVM: Use kvm_set_pte() in kvm_flush_pte()
+
+From: Tao Cui <cuitao@kylinos.cn>
+
+commit 81e18777d61440511451866c7c80b34a8bdd6b33 upstream.
+
+kvm_flush_pte() is the only caller that directly assigns *pte instead
+of using the kvm_set_pte() wrapper. Use the wrapper for consistency with
+the rest of the file.
+
+No functional change intended.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Bibo Mao <maobibo@loongson.cn>
+Signed-off-by: Tao Cui <cuitao@kylinos.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kvm/mmu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/loongarch/kvm/mmu.c
++++ b/arch/loongarch/kvm/mmu.c
+@@ -95,7 +95,7 @@ static int kvm_flush_pte(kvm_pte_t *pte,
+ else
+ kvm->stat.pages--;
+
+- *pte = ctx->invalid_entry;
++ kvm_set_pte(pte, ctx->invalid_entry);
+
+ return 1;
+ }
--- /dev/null
+From 49f33840dcc907d21313d369e34872880846b61c Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Mon, 4 May 2026 09:00:20 +0800
+Subject: LoongArch: Use per-root-bridge PCIH flag to skip mem resource fixup
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit 49f33840dcc907d21313d369e34872880846b61c upstream.
+
+When firmware enables 64-bit PCI host bridge support, some root bridges
+already provide valid 64-bit mem resource windows through ACPI.
+
+In this case, the LoongArch-specific mem resource high-bits fixup in
+acpi_prepare_root_resources() should not be applied unconditionally.
+Otherwise, the kernel may override the native resource layout derived
+from firmware, and later BAR assignment can fail to place device BARs
+into the intended 64-bit address space correctly.
+
+Add a per-root-bridge ACPI flag, PCIH, and evaluate it from the current
+root bridge device scope. When PCIH is set, skip the mem resource high-
+bits fixup path and let the kernel use the firmware-provided resource
+description directly. When PCIH is absent or cleared, keep the existing
+behavior and continue filling the high address bits from the host bridge
+address.
+
+This makes the behavior per-root-bridge configurable and avoids breaking
+valid 64-bit BAR space allocation on bridges whose 64-bit windows have
+already been fully described by firmware.
+
+Cc: stable@vger.kernel.org
+Suggested-by: Chao Li <lichao@loongson.cn>
+Tested-by: Dongyan Qian <qiandongyan@loongson.cn>
+Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/pci/acpi.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/loongarch/pci/acpi.c
++++ b/arch/loongarch/pci/acpi.c
+@@ -61,11 +61,16 @@ static void acpi_release_root_info(struc
+ static int acpi_prepare_root_resources(struct acpi_pci_root_info *ci)
+ {
+ int status;
++ unsigned long long pci_h = 0;
+ struct resource_entry *entry, *tmp;
+ struct acpi_device *device = ci->bridge;
+
+ status = acpi_pci_probe_root_resources(ci);
+ if (status > 0) {
++ acpi_evaluate_integer(device->handle, "PCIH", NULL, &pci_h);
++ if (pci_h)
++ return status;
++
+ resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
+ if (entry->res->flags & IORESOURCE_MEM) {
+ entry->offset = ci->root->mcfg_addr & GENMASK_ULL(63, 40);
--- /dev/null
+From f14d6e9c3678a067f304abba561e0c5446c7e845 Mon Sep 17 00:00:00 2001
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Mon, 27 Apr 2026 21:54:35 +0200
+Subject: mptcp: fastclose msk when linger time is 0
+
+From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+
+commit f14d6e9c3678a067f304abba561e0c5446c7e845 upstream.
+
+The SO_LINGER socket option has been supported for a while with MPTCP
+sockets [1], but it didn't cause the equivalent of a TCP reset as
+expected when enabled and its time was set to 0. This was causing some
+behavioural differences with TCP where some connections were not
+promptly stopped as expected.
+
+To fix that, an extra condition is checked at close() time before
+sending an MP_FASTCLOSE, the MPTCP equivalent of a TCP reset.
+
+Note that backporting up to [1] will be difficult as more changes are
+needed to be able to send MP_FASTCLOSE. It seems better to stop at [2],
+which was supposed to already imitate TCP.
+
+Validated with MPTCP packetdrill tests [3].
+
+Fixes: 268b12387460 ("mptcp: setsockopt: support SO_LINGER") [1]
+Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") [2]
+Cc: stable@vger.kernel.org
+Reported-by: Lance Tuller <lance@lance0.com>
+Closes: https://github.com/lance0/xfr/pull/67
+Link: https://github.com/multipath-tcp/packetdrill/pull/196 [3]
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-3-7432b7f279fa@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -3219,7 +3219,8 @@ bool __mptcp_close(struct sock *sk, long
+ goto cleanup;
+ }
+
+- if (mptcp_data_avail(msk) || timeout < 0) {
++ if (mptcp_data_avail(msk) || timeout < 0 ||
++ (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime)) {
+ /* If the msk has read data, or the caller explicitly ask it,
+ * do the MPTCP equivalent of TCP reset, aka MPTCP fastclose
+ */
--- /dev/null
+From b5c52908d52c6c8eb8933264aa6087a0600fd892 Mon Sep 17 00:00:00 2001
+From: Gang Yan <yangang@kylinos.cn>
+Date: Mon, 27 Apr 2026 21:54:34 +0200
+Subject: mptcp: fix scheduling with atomic in timestamp sockopt
+
+From: Gang Yan <yangang@kylinos.cn>
+
+commit b5c52908d52c6c8eb8933264aa6087a0600fd892 upstream.
+
+Using lock_sock_fast() (atomic context) around sock_set_timestamp()
+and sock_set_timestamping() is unsafe, as both helpers can sleep.
+
+Replace lock_sock_fast() with sleepable lock_sock()/release_sock()
+to avoid scheduling while atomic panic.
+
+Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows")
+Cc: stable@vger.kernel.org
+Reported-by: Sashiko <sashiko-bot@kernel.org>
+Closes: https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev
+Signed-off-by: Gang Yan <yangang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-2-7432b7f279fa@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/sockopt.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/net/mptcp/sockopt.c
++++ b/net/mptcp/sockopt.c
+@@ -159,10 +159,10 @@ static int mptcp_setsockopt_sol_socket_t
+ lock_sock(sk);
+ mptcp_for_each_subflow(msk, subflow) {
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+- bool slow = lock_sock_fast(ssk);
+
++ lock_sock(ssk);
+ sock_set_timestamp(ssk, optname, !!val);
+- unlock_sock_fast(ssk, slow);
++ release_sock(ssk);
+ }
+
+ release_sock(sk);
+@@ -235,10 +235,10 @@ static int mptcp_setsockopt_sol_socket_t
+
+ mptcp_for_each_subflow(msk, subflow) {
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+- bool slow = lock_sock_fast(ssk);
+
++ lock_sock(ssk);
+ sock_set_timestamping(ssk, optname, timestamping);
+- unlock_sock_fast(ssk, slow);
++ release_sock(ssk);
+ }
+
+ release_sock(sk);
--- /dev/null
+From 5f95c21fc23a7ef22b4d27d1ed9bb55557ffb926 Mon Sep 17 00:00:00 2001
+From: Gang Yan <yangang@kylinos.cn>
+Date: Mon, 27 Apr 2026 21:54:33 +0200
+Subject: mptcp: sockopt: set timestamp flags on subflow socket, not msk
+
+From: Gang Yan <yangang@kylinos.cn>
+
+commit 5f95c21fc23a7ef22b4d27d1ed9bb55557ffb926 upstream.
+
+Both mptcp_setsockopt_sol_socket_tstamp() and
+mptcp_setsockopt_sol_socket_timestamping() iterate over subflows,
+acquire the subflow socket lock, but then erroneously pass the MPTCP
+msk socket to sock_set_timestamp() / sock_set_timestamping() instead
+of the subflow ssk. As a result, the timestamp flags are set on the
+wrong socket and have no effect on the actual subflows.
+
+Pass ssk instead of sk to both helpers.
+
+Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gang Yan <yangang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-1-7432b7f279fa@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/sockopt.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/mptcp/sockopt.c
++++ b/net/mptcp/sockopt.c
+@@ -161,7 +161,7 @@ static int mptcp_setsockopt_sol_socket_t
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+ bool slow = lock_sock_fast(ssk);
+
+- sock_set_timestamp(sk, optname, !!val);
++ sock_set_timestamp(ssk, optname, !!val);
+ unlock_sock_fast(ssk, slow);
+ }
+
+@@ -237,7 +237,7 @@ static int mptcp_setsockopt_sol_socket_t
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+ bool slow = lock_sock_fast(ssk);
+
+- sock_set_timestamping(sk, optname, timestamping);
++ sock_set_timestamping(ssk, optname, timestamping);
+ unlock_sock_fast(ssk, slow);
+ }
+
--- /dev/null
+From c4a99a921949cddc590b22bb14eeb23dffcc3ba6 Mon Sep 17 00:00:00 2001
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Date: Fri, 1 May 2026 21:35:34 +0200
+Subject: mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure
+
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+
+commit c4a99a921949cddc590b22bb14eeb23dffcc3ba6 upstream.
+
+In subflow_finish_connect(), HMAC validation of the server's HMAC
+in SYN/ACK + MP_JOIN increments MPTCP_MIB_JOINACKMAC ("HMAC was
+wrong on ACK + MP_JOIN") on failure. The function processes the
+SYN/ACK, not the ACK; the matching MPTCP_MIB_JOINSYNACKMAC counter
+("HMAC was wrong on SYN/ACK + MP_JOIN") exists but is not
+incremented anywhere in the tree.
+
+The mirror site on the server, subflow_syn_recv_sock(), already
+uses JOINACKMAC correctly for ACK HMAC failure. Use JOINSYNACKMAC
+at the SYN/ACK validation site so each counter reflects the packet
+whose HMAC actually failed.
+
+Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Fixes: fc518953bc9c ("mptcp: add and use MIB counter infrastructure")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-1-b70118df778e@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -578,7 +578,7 @@ static void subflow_finish_connect(struc
+ subflow->backup);
+
+ if (!subflow_thmac_valid(subflow)) {
+- MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINACKMAC);
++ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINSYNACKMAC);
+ subflow->reset_reason = MPTCP_RST_EMPTCP;
+ goto do_reset;
+ }
--- /dev/null
+From a6da02d4c00fdda2417e42ad2b762a9209e6cc49 Mon Sep 17 00:00:00 2001
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Date: Fri, 1 May 2026 21:35:35 +0200
+Subject: mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure
+
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+
+commit a6da02d4c00fdda2417e42ad2b762a9209e6cc49 upstream.
+
+When HMAC validation fails on a received ACK + MP_JOIN in
+subflow_syn_recv_sock(), the subflow is reset with reason
+MPTCP_RST_EPROHIBIT ("Administratively prohibited"). This is
+incorrect: HMAC validation failure is an MPTCP protocol-level
+error, not an administrative policy denial.
+
+The mirror site on the client, in subflow_finish_connect(), already
+uses MPTCP_RST_EMPTCP ("MPTCP-specific error") for the same kind of
+HMAC failure on the SYN/ACK + MP_JOIN. Use the same reason on the
+server side for symmetry and accuracy.
+
+Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Fixes: 443041deb5ef ("mptcp: fix NULL pointer in can_accept_new_subflow")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-2-b70118df778e@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -910,7 +910,7 @@ create_child:
+
+ if (!subflow_hmac_valid(req, &mp_opt)) {
+ SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
+- subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
++ subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
+ goto dispose_child;
+ }
+
--- /dev/null
+From a8aeea1bf3c80cc87983689e0118770e019bd4f3 Mon Sep 17 00:00:00 2001
+From: Shuai Xue <xueshuai@linux.alibaba.com>
+Date: Wed, 11 Feb 2026 20:46:24 +0800
+Subject: PCI/AER: Clear only error bits in PCIe Device Status
+
+From: Shuai Xue <xueshuai@linux.alibaba.com>
+
+commit a8aeea1bf3c80cc87983689e0118770e019bd4f3 upstream.
+
+Currently, pcie_clear_device_status() clears the entire PCIe Device Status
+register (PCI_EXP_DEVSTA) by writing back the value read from the register,
+which affects not only the error status bits but also other writable bits.
+
+According to PCIe r7.0, sec 7.5.3.5, this register contains:
+
+ - RW1C error status bits (CED, NFED, FED, URD at bits 0-3): These are the
+ four error status bits that need to be cleared.
+
+ - Read-only bits (AUXPD at bit 4, TRPND at bit 5): Writing to these has
+ no effect.
+
+ - Emergency Power Reduction Detected (bit 6): A RW1C non-error bit
+ introduced in PCIe r5.0 (2019). This is currently the only writable
+ non-error bit in the Device Status register. Unconditionally clearing
+ this bit can interfere with other software components that rely on this
+ power management indication.
+
+ - Reserved bits (RsvdZ): These bits are required to be written as zero.
+ Writing 1s to them (as the current implementation may do) violates the
+ specification.
+
+To prevent unintended side effects, modify pcie_clear_device_status() to
+only write 1s to the four error status bits (CED, NFED, FED, URD), leaving
+the Emergency Power Reduction Detected bit and reserved bits unaffected.
+
+Fixes: ec752f5d54d7 ("PCI/AER: Clear device status bits during ERR_FATAL and ERR_NONFATAL")
+Suggested-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260211124624.49656-1-xueshuai@linux.alibaba.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -2321,10 +2321,9 @@ EXPORT_SYMBOL_GPL(pci_set_pcie_reset_sta
+ #ifdef CONFIG_PCIEAER
+ void pcie_clear_device_status(struct pci_dev *dev)
+ {
+- u16 sta;
+-
+- pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &sta);
+- pcie_capability_write_word(dev, PCI_EXP_DEVSTA, sta);
++ pcie_capability_write_word(dev, PCI_EXP_DEVSTA,
++ PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED |
++ PCI_EXP_DEVSTA_FED | PCI_EXP_DEVSTA_URD);
+ }
+ #endif
+
--- /dev/null
+From 1ab4a3c805084d752ec571efc78272295a9f2f74 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Fri, 27 Mar 2026 10:56:43 +0100
+Subject: PCI/AER: Stop ruling out unbound devices as error source
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 1ab4a3c805084d752ec571efc78272295a9f2f74 upstream.
+
+When searching for the error source, the AER driver rules out devices whose
+enable_cnt is zero. This was introduced in 2009 by commit 28eb27cf0839
+("PCI AER: support invalid error source IDs") without providing a
+rationale.
+
+Drivers typically call pci_enable_device() on probe, hence the enable_cnt
+check essentially filters out unbound devices. At the time of the commit,
+drivers had to opt in to AER by calling pci_enable_pcie_error_reporting()
+and so any AER-enabled device could be assumed to be bound to a driver.
+The check thus made sense because it allowed skipping config space accesses
+to devices which were known not to be the error source.
+
+But since 2022, AER is universally enabled on all devices when they are
+enumerated, cf. commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
+AER is native").
+
+Errors may very well be reported by unbound devices, e.g. due to link
+instability. By ruling them out as error source, errors reported by them
+are neither logged nor cleared. When they do get bound and another error
+occurs, the earlier error is reported together with the new error, which
+may confuse users. Stop doing so.
+
+Fixes: f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is native")
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Stefan Roese <stefan.roese@mailbox.org>
+Cc: stable@vger.kernel.org # v6.0+
+Link: https://patch.msgid.link/734338c2e8b669db5a5a3b45d34131b55ffebfca.1774605029.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pcie/aer.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/pci/pcie/aer.c
++++ b/drivers/pci/pcie/aer.c
+@@ -849,8 +849,6 @@ static bool is_error_source(struct pci_d
+ * 3) There are multiple errors and prior ID comparing fails;
+ * We check AER status registers to find possible reporter.
+ */
+- if (atomic_read(&dev->enable_cnt) == 0)
+- return false;
+
+ /* Check if AER is enabled */
+ pcie_capability_read_word(dev, PCI_EXP_DEVCTL, ®16);
--- /dev/null
+From cc33985d26c92a5c908c0185239c59ec35b8637c Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Mon, 16 Feb 2026 08:46:13 +0100
+Subject: PCI/ASPM: Fix pci_clear_and_set_config_dword() usage
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit cc33985d26c92a5c908c0185239c59ec35b8637c upstream.
+
+When aspm_calc_l12_info() programs the L1 PM Substates Control 1 register
+fields Common_Mode_Restore_Time, LTR_L1.2_THRESHOLD_Value and _Scale, it
+invokes pci_clear_and_set_config_dword() in an incorrect way:
+
+For the bits to clear it selects those corresponding to the field. So far
+so good. But for the bits to set it passes a full register value.
+pci_clear_and_set_config_dword() performs a boolean OR operation which
+sets all bits of that value, not just the ones that were just cleared.
+
+Thus, when setting the LTR_L1.2_THRESHOLD_Value and _Scale on the child of
+an ASPM link, aspm_calc_l12_info() also sets the Common_Mode_Restore_Time.
+That's a spec violation: PCIe r7.0 sec 7.8.3.3 says this field is RsvdP
+for Upstream Ports. On Adrià's Pixelbook Eve, Common_Mode_Restore_Time
+of the Intel 7265 "Stone Peak" wifi card is zero, yet aspm_calc_l12_info()
+does not preserve the zero bits but instead programs the value calculated
+for the Root Port into the wifi card.
+
+Likewise, when setting the Common_Mode_Restore_Time on the Root Port,
+aspm_calc_l12_info() also changes the LTR_L1.2_THRESHOLD_Value and _Scale
+from the initial 163840 nsec to 237568 nsec (due to ORing those fields),
+only to reduce it afterwards to 106496 nsec.
+
+Amend all invocations of pci_clear_and_set_config_dword() to only set bits
+which are cleared.
+
+Finally, when setting the T_POWER_ON_Value and _Scale on the Root Port and
+the wifi card, aspm_calc_l12_info() fails to preserve bits declared RsvdP
+and instead overwrites them with zeroes. Replace pci_write_config_dword()
+with pci_clear_and_set_config_dword() to avoid this.
+
+Fixes: aeda9adebab8 ("PCI/ASPM: Configure L1 substate settings")
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=220705#c22
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Tested-by: Adrià Vilanova Martínez <me@avm99963.com>
+Cc: stable@vger.kernel.org # v4.11+
+Link: https://patch.msgid.link/5c1752d7512eed0f4ea57b84b12d7ee08ca61fc5.1771226659.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pcie/aspm.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/pci/pcie/aspm.c
++++ b/drivers/pci/pcie/aspm.c
+@@ -704,22 +704,29 @@ static void aspm_calc_l12_info(struct pc
+ }
+
+ /* Program T_POWER_ON times in both ports */
+- pci_write_config_dword(parent, parent->l1ss + PCI_L1SS_CTL2, ctl2);
+- pci_write_config_dword(child, child->l1ss + PCI_L1SS_CTL2, ctl2);
++ pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL2,
++ PCI_L1SS_CTL2_T_PWR_ON_VALUE |
++ PCI_L1SS_CTL2_T_PWR_ON_SCALE, ctl2);
++ pci_clear_and_set_config_dword(child, child->l1ss + PCI_L1SS_CTL2,
++ PCI_L1SS_CTL2_T_PWR_ON_VALUE |
++ PCI_L1SS_CTL2_T_PWR_ON_SCALE, ctl2);
+
+ /* Program Common_Mode_Restore_Time in upstream device */
+ pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
+- PCI_L1SS_CTL1_CM_RESTORE_TIME, ctl1);
++ PCI_L1SS_CTL1_CM_RESTORE_TIME,
++ ctl1 & PCI_L1SS_CTL1_CM_RESTORE_TIME);
+
+ /* Program LTR_L1.2_THRESHOLD time in both ports */
+ pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
+ PCI_L1SS_CTL1_LTR_L12_TH_VALUE |
+ PCI_L1SS_CTL1_LTR_L12_TH_SCALE,
+- ctl1);
++ ctl1 & (PCI_L1SS_CTL1_LTR_L12_TH_VALUE |
++ PCI_L1SS_CTL1_LTR_L12_TH_SCALE));
+ pci_clear_and_set_config_dword(child, child->l1ss + PCI_L1SS_CTL1,
+ PCI_L1SS_CTL1_LTR_L12_TH_VALUE |
+ PCI_L1SS_CTL1_LTR_L12_TH_SCALE,
+- ctl1);
++ ctl1 & (PCI_L1SS_CTL1_LTR_L12_TH_VALUE |
++ PCI_L1SS_CTL1_LTR_L12_TH_SCALE));
+
+ if (pl1_2_enables || cl1_2_enables) {
+ pci_clear_and_set_config_dword(parent,
--- /dev/null
+From 9a44949da669708f19d29141e65b3ac774d08f5a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
+Date: Mon, 2 Mar 2026 13:32:05 +0000
+Subject: power: supply: max17042: avoid overflow when determining health
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: André Draszik <andre.draszik@linaro.org>
+
+commit 9a44949da669708f19d29141e65b3ac774d08f5a upstream.
+
+If vmax has the default value of INT_MAX (e.g. because not specified in
+DT), battery health is reported as over-voltage. This is because adding
+any value to vmax (the vmax tolerance in this case) causes it to wrap
+around, making it negative and smaller than the measured battery
+voltage.
+
+Avoid that by using size_add().
+
+Fixes: edd4ab055931 ("power: max17042_battery: add HEALTH and TEMP_* properties support")
+Cc: stable@vger.kernel.org
+Signed-off-by: André Draszik <andre.draszik@linaro.org>
+Link: https://patch.msgid.link/20260302-max77759-fg-v3-6-3c5f01dbda23@linaro.org
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/power/supply/max17042_battery.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/power/supply/max17042_battery.c
++++ b/drivers/power/supply/max17042_battery.c
+@@ -199,7 +199,7 @@ static int max17042_get_battery_health(s
+ goto out;
+ }
+
+- if (vbatt > chip->pdata->vmax + MAX17042_VMAX_TOLERANCE) {
++ if (vbatt > size_add(chip->pdata->vmax, MAX17042_VMAX_TOLERANCE)) {
+ *health = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+ goto out;
+ }
--- /dev/null
+From 6aaa978c6b6218cfac15fe1dab17c76fe229ce3f Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:40 -0300
+Subject: RDMA/mana: Fix error unwind in mana_ib_create_qp_rss()
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 6aaa978c6b6218cfac15fe1dab17c76fe229ce3f upstream.
+
+Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal
+destroy path cleans it up.
+
+Cc: stable@vger.kernel.org
+Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter")
+Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
+Link: https://patch.msgid.link/r/7-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Reviewed-by: Long Li <longli@microsoft.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mana/qp.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/mana/qp.c
++++ b/drivers/infiniband/hw/mana/qp.c
+@@ -236,13 +236,15 @@ static int mana_ib_create_qp_rss(struct
+ ibdev_dbg(&mdev->ib_dev,
+ "Failed to copy to udata create rss-qp, %d\n",
+ ret);
+- goto fail;
++ goto err_disable_vport_rx;
+ }
+
+ kfree(mana_ind_table);
+
+ return 0;
+
++err_disable_vport_rx:
++ mana_disable_vport_rx(mpc);
+ fail:
+ while (i-- > 0) {
+ ibwq = ind_tbl->ind_tbl[i];
--- /dev/null
+From 34ecf795692ee57c393109f4a24ccc313091e137 Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:39 -0300
+Subject: RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss()
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 34ecf795692ee57c393109f4a24ccc313091e137 upstream.
+
+Sashiko points out there are two bugs here in the error unwind flow, both
+related to how the WQ table is unwound.
+
+First there is a double i-- on the first failure path due to the while loop
+having a i--, remove it.
+
+Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not
+undone due to the above i--.
+
+Cc: stable@vger.kernel.org
+Fixes: c15d7802a424 ("RDMA/mana_ib: Add CQ interrupt support for RAW QP")
+Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1
+Link: https://patch.msgid.link/r/6-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Reviewed-by: Long Li <longli@microsoft.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mana/qp.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/drivers/infiniband/hw/mana/qp.c
++++ b/drivers/infiniband/hw/mana/qp.c
+@@ -194,11 +194,8 @@ static int mana_ib_create_qp_rss(struct
+
+ ret = mana_create_wq_obj(mpc, mpc->port_handle, GDMA_RQ,
+ &wq_spec, &cq_spec, &wq->rx_object);
+- if (ret) {
+- /* Do cleanup starting with index i-1 */
+- i--;
++ if (ret)
+ goto fail;
+- }
+
+ /* The GDMA regions are now owned by the WQ object */
+ wq->queue.gdma_region = GDMA_INVALID_DMA_REGION;
+@@ -218,8 +215,10 @@ static int mana_ib_create_qp_rss(struct
+
+ /* Create CQ table entry */
+ ret = mana_ib_install_cq_cb(mdev, cq);
+- if (ret)
++ if (ret) {
++ mana_destroy_wq_obj(mpc, GDMA_RQ, wq->rx_object);
+ goto fail;
++ }
+ }
+ resp.num_entries = i;
+
--- /dev/null
+From 6dd2d4ad9c8429523b1c220c5132bd551c006425 Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:37 -0300
+Subject: RDMA/mana: Validate rx_hash_key_len
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 6dd2d4ad9c8429523b1c220c5132bd551c006425 upstream.
+
+Sashiko points out that rx_hash_key_len comes from a uAPI structure and is
+blindly passed to memcpy, allowing the userspace to trash kernel
+memory. Bounds check it so the memcpy cannot overflow.
+
+Cc: stable@vger.kernel.org
+Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter")
+Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1
+Link: https://patch.msgid.link/r/4-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Reviewed-by: Long Li <longli@microsoft.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mana/qp.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/infiniband/hw/mana/qp.c
++++ b/drivers/infiniband/hw/mana/qp.c
+@@ -21,6 +21,9 @@ static int mana_ib_cfg_vport_steering(st
+
+ gc = mdev_to_gc(dev);
+
++ if (rx_hash_key_len > sizeof(req->hashkey))
++ return -EINVAL;
++
+ req_buf_size = struct_size(req, indir_tab, MANA_INDIRECT_TABLE_DEF_SIZE);
+ req = kzalloc(req_buf_size, GFP_KERNEL);
+ if (!req)
--- /dev/null
+From c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:44 -0300
+Subject: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c upstream.
+
+Sashiko points out that mlx4_srq_alloc() was not undone during error
+unwind, add the missing call to mlx4_srq_free().
+
+Cc: stable@vger.kernel.org
+Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
+Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=8
+Link: https://patch.msgid.link/r/11-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mlx4/srq.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/mlx4/srq.c
++++ b/drivers/infiniband/hw/mlx4/srq.c
+@@ -193,13 +193,15 @@ int mlx4_ib_create_srq(struct ib_srq *ib
+ if (udata)
+ if (ib_copy_to_udata(udata, &srq->msrq.srqn, sizeof (__u32))) {
+ err = -EFAULT;
+- goto err_wrid;
++ goto err_srq;
+ }
+
+ init_attr->attr.max_wr = srq->msrq.max - 1;
+
+ return 0;
+
++err_srq:
++ mlx4_srq_free(dev->dev, &srq->msrq);
+ err_wrid:
+ if (udata)
+ mlx4_ib_db_unmap_user(ucontext, &srq->db);
--- /dev/null
+From c488df06bd552bb8b6e14fa0cfd5ad986c6e9525 Mon Sep 17 00:00:00 2001
+From: Junrui Luo <moonafterrain@outlook.com>
+Date: Fri, 24 Apr 2026 13:51:02 +0800
+Subject: RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init()
+
+From: Junrui Luo <moonafterrain@outlook.com>
+
+commit c488df06bd552bb8b6e14fa0cfd5ad986c6e9525 upstream.
+
+mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When
+ib_create_srq() fails for s1, the error branch destroys s0 but falls
+through and unconditionally assigns the freed s0 and the ERR_PTR s1 to
+devr->s0 and devr->s1.
+
+This leads to several problems: the lock-free fast path checks
+"if (devr->s1) return 0;" and treats the ERR_PTR as already initialised;
+users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via
+to_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences
+the ERR_PTR and double-frees s0 on teardown.
+
+Fix by adding the same `goto unlock` in the s1 failure path.
+
+Cc: stable@vger.kernel.org
+Fixes: 5895e70f2e6e ("IB/mlx5: Allocate resources just before first QP/SRQ is created")
+Link: https://patch.msgid.link/r/SYBPR01MB7881E1E0970268BD69C0BA75AF2B2@SYBPR01MB7881.ausprd01.prod.outlook.com
+Reported-by: Yuhao Jiang <danisjiang@gmail.com>
+Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mlx5/main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/infiniband/hw/mlx5/main.c
++++ b/drivers/infiniband/hw/mlx5/main.c
+@@ -3127,6 +3127,7 @@ int mlx5_ib_dev_res_srq_init(struct mlx5
+ ret = PTR_ERR(s1);
+ mlx5_ib_err(dev, "Couldn't create SRQ 1 for res init, err=%d\n", ret);
+ ib_destroy_srq(s0);
++ goto unlock;
+ }
+
+ devr->s0 = s0;
--- /dev/null
+From 34fbf48cf3b410d2a6e8c586fa952a36331ca5ba Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:42 -0300
+Subject: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 34fbf48cf3b410d2a6e8c586fa952a36331ca5ba upstream.
+
+Sashiko points out that pd->uctx isn't initialized until late in the
+function so all these error flow references are NULL and will crash. Use
+the uctx that isn't NULL.
+
+Cc: stable@vger.kernel.org
+Fixes: fe2caefcdf58 ("RDMA/ocrdma: Add driver for Emulex OneConnect IBoE RDMA adapter")
+Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
+Link: https://patch.msgid.link/r/9-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
++++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+@@ -620,9 +620,9 @@ static int ocrdma_copy_pd_uresp(struct o
+
+ ucopy_err:
+ if (pd->dpp_enabled)
+- ocrdma_del_mmap(pd->uctx, dpp_page_addr, PAGE_SIZE);
++ ocrdma_del_mmap(uctx, dpp_page_addr, PAGE_SIZE);
+ dpp_map_err:
+- ocrdma_del_mmap(pd->uctx, db_page_addr, db_page_size);
++ ocrdma_del_mmap(uctx, db_page_addr, db_page_size);
+ return status;
+ }
+
--- /dev/null
+From 1114c87aa6f195cf07da55a27b2122ae26557b26 Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Sat, 18 Apr 2026 12:21:41 -0400
+Subject: RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+commit 1114c87aa6f195cf07da55a27b2122ae26557b26 upstream.
+
+atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c
+unconditionally dereferences 8 bytes at payload_addr(pkt):
+
+ value = *(u64 *)payload_addr(pkt);
+
+check_rkey() previously accepted an ATOMIC_WRITE request with pktlen ==
+resid == 0 because the length validation only compared pktlen against
+resid. A remote initiator that sets the RETH length to 0 therefore reaches
+atomic_write_reply() with a zero-byte logical payload, and the responder
+reads sizeof(u64) bytes from past the logical end of the packet into
+skb->head tailroom, then writes those 8 bytes into the attacker's MR via
+rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel
+tailroom per probe (the other 4 bytes are the packet's own trailing ICRC).
+
+IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is
+protocol-invalid. Hoist a strict length check into check_rkey() so the
+responder never reaches the unchecked dereference, and keep the existing
+WRITE-family length logic for the normal RDMA WRITE path.
+
+Reproduced on mainline with an unmodified rxe driver: a sustained
+zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer
+bytes into the attacker's MR, including recognisable kernel strings and
+partial kernel-direct-map pointer words. With this patch applied the
+responder rejects the PDU and the MR stays all-zero.
+
+Cc: stable@vger.kernel.org
+Fixes: 034e285f8b99 ("RDMA/rxe: Make responder support atomic write on RC service")
+Link: https://patch.msgid.link/r/20260418162141.3610201-1-michael.bommarito@gmail.com
+Assisted-by: Claude:claude-opus-4-7
+Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
+Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/sw/rxe/rxe_resp.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/sw/rxe/rxe_resp.c
++++ b/drivers/infiniband/sw/rxe/rxe_resp.c
+@@ -526,7 +526,19 @@ static enum resp_states check_rkey(struc
+ }
+
+ skip_check_range:
+- if (pkt->mask & (RXE_WRITE_MASK | RXE_ATOMIC_WRITE_MASK)) {
++ if (pkt->mask & RXE_ATOMIC_WRITE_MASK) {
++ /* IBA oA19-28: ATOMIC_WRITE payload is exactly 8 bytes.
++ * Reject any other length before the responder reads
++ * sizeof(u64) bytes from payload_addr(pkt); a shorter
++ * payload would read past the logical end of the packet
++ * into skb->head tailroom.
++ */
++ if (resid != sizeof(u64) || pktlen != sizeof(u64) ||
++ bth_pad(pkt)) {
++ state = RESPST_ERR_LENGTH;
++ goto err;
++ }
++ } else if (pkt->mask & RXE_WRITE_MASK) {
+ if (resid > mtu) {
+ if (pktlen != mtu || bth_pad(pkt)) {
+ state = RESPST_ERR_LENGTH;
--- /dev/null
+From 4c6f86d85d03cdb33addce86aa69aa795ca6c47a Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Tue, 14 Apr 2026 07:15:55 -0400
+Subject: RDMA/rxe: Reject unknown opcodes before ICRC processing
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+commit 4c6f86d85d03cdb33addce86aa69aa795ca6c47a upstream.
+
+Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC
+before payload_size() in rxe_rcv"), a single unauthenticated UDP packet
+can still trigger panic. That patch handled payload_size() underflow only
+for valid opcodes with short packets, not for packets carrying an unknown
+opcode. The unknown-opcode OOB read described below predates that commit
+and reaches back to the initial Soft RoCE driver.
+
+The check added there reads
+
+ pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE
+
+where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The
+rxe_opcode[] array has 256 entries but is only populated for defined IB
+opcodes; any other entry (for example opcode 0xff) is zero-initialized, so
+length == 0 and the check degenerates to
+
+ pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE
+
+which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes
+
+ rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES
+
+which underflows when length == 0 and passes a huge value to rxe_crc32(),
+causing an out-of-bounds read of the skb payload.
+
+Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with
+CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after
+
+ rdma link add rxe0 type rxe netdev eth0
+
+A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and
+QPN=IB_MULTICAST_QPN triggers:
+
+ BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170
+ Read of size 1 at addr ...
+ The buggy address is located 0 bytes to the right of
+ allocated 704-byte region
+ Call Trace:
+ crc32_le+0x115/0x170
+ rxe_icrc_hdr.isra.0+0x226/0x300
+ rxe_icrc_check+0x13f/0x3a0
+ rxe_rcv+0x6e1/0x16e0
+ rxe_udp_encap_recv+0x20a/0x320
+ udp_queue_rcv_one_skb+0x7ed/0x12c0
+
+Subsequent packets with the same shape fault on unmapped memory and panic
+the kernel. The trigger requires only module load and "rdma link add"; no
+QP, no connection, and no authentication.
+
+Fix this by rejecting packets whose opcode has no rxe_opcode[] entry,
+detected via the zero mask or zero length, before any length arithmetic
+runs.
+
+Cc: stable@vger.kernel.org
+Fixes: 8700e3e7c485 ("Soft RoCE driver")
+Link: https://patch.msgid.link/r/20260414111555.3386793-1-michael.bommarito@gmail.com
+Assisted-by: Claude:claude-opus-4-6
+Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
+Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/sw/rxe/rxe_recv.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/infiniband/sw/rxe/rxe_recv.c
++++ b/drivers/infiniband/sw/rxe/rxe_recv.c
+@@ -330,6 +330,17 @@ void rxe_rcv(struct sk_buff *skb)
+ pkt->qp = NULL;
+ pkt->mask |= rxe_opcode[pkt->opcode].mask;
+
++ /*
++ * Unknown opcodes have a zero-initialized rxe_opcode[] entry, so
++ * both mask and length are 0. Reject them before any length math:
++ * rxe_icrc_hdr() would otherwise compute length - RXE_BTH_BYTES
++ * and pass the underflowed value to rxe_crc32(), producing an
++ * out-of-bounds read.
++ */
++ if (unlikely(!rxe_opcode[pkt->opcode].mask ||
++ !rxe_opcode[pkt->opcode].length))
++ goto drop;
++
+ if (unlikely(pkt->paylen < header_size(pkt) + bth_pad(pkt) +
+ RXE_ICRC_SIZE))
+ goto drop;
--- /dev/null
+From e38e86995df27f1f854063dab1f0c6a513db3faf Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:43 -0300
+Subject: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit e38e86995df27f1f854063dab1f0c6a513db3faf upstream.
+
+Sashiko points out that pvrdma_uar_free() is already called within
+pvrdma_dealloc_ucontext(), so calling it before triggers a double free.
+
+Cc: stable@vger.kernel.org
+Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver")
+Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
+Link: https://patch.msgid.link/r/10-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
++++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
+@@ -350,7 +350,7 @@ int pvrdma_alloc_ucontext(struct ib_ucon
+ uresp.qp_tab_size = vdev->dsr->caps.max_qp;
+ ret = ib_copy_to_udata(udata, &uresp, sizeof(uresp));
+ if (ret) {
+- pvrdma_uar_free(vdev, &context->uar);
++ /* pvrdma_dealloc_ucontext() also frees the UAR */
+ pvrdma_dealloc_ucontext(&context->ibucontext);
+ return -EFAULT;
+ }
--- /dev/null
+From 65db7b27b90e2ea8d4966935aa9a50b6a60c31ac Mon Sep 17 00:00:00 2001
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Tue, 5 May 2026 17:00:58 +0200
+Subject: selftests: mptcp: check output: catch cmd errors
+
+From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+
+commit 65db7b27b90e2ea8d4966935aa9a50b6a60c31ac upstream.
+
+Using '${?}' inside the if-statement to check the returned value from
+the command that was evaluated as part of the if-statement is not
+correct: here, '${?}' will be linked to the previous instruction, not
+the one that is expected here (${cmd}).
+
+Instead, simply mark the error, except if an error is expected. If
+that's the case, 1 can be passed as the 4th argument of this helper.
+Three checks from pm_netlink.sh expect an error.
+
+While at it, improve the error message when the command unexpectedly
+fails or succeeds.
+
+Note that we could expect a specific returned value, but the checks
+currently expecting an error can be used with 'ip mptcp' or 'pm_nl_ctl',
+and these two tools don't return the same error code.
+
+Fixes: 2d0c1d27ea4e ("selftests: mptcp: add mptcp_lib_check_output helper")
+Cc: stable@vger.kernel.org
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-10-fca8091060a4@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/mptcp/mptcp_lib.sh | 16 ++++++++++------
+ tools/testing/selftests/net/mptcp/pm_netlink.sh | 10 ++++++----
+ 2 files changed, 16 insertions(+), 10 deletions(-)
+
+--- a/tools/testing/selftests/net/mptcp/mptcp_lib.sh
++++ b/tools/testing/selftests/net/mptcp/mptcp_lib.sh
+@@ -407,20 +407,24 @@ mptcp_lib_wait_local_port_listen() {
+ wait_local_port_listen "${@}" "tcp"
+ }
+
++# $1: error file, $2: cmd, $3: expected msg, [$4: expected error]
+ mptcp_lib_check_output() {
+ local err="${1}"
+ local cmd="${2}"
+ local expected="${3}"
++ local exp_error="${4:-0}"
+ local cmd_ret=0
+ local out
+
+- if ! out=$(${cmd} 2>"${err}"); then
+- cmd_ret=${?}
+- fi
++ out=$(${cmd} 2>"${err}") || cmd_ret=1
+
+- if [ ${cmd_ret} -ne 0 ]; then
+- mptcp_lib_pr_fail "command execution '${cmd}' stderr"
+- cat "${err}"
++ if [ "${cmd_ret}" != "${exp_error}" ]; then
++ mptcp_lib_pr_fail "unexpected returned code for '${cmd}', info:"
++ if [ "${exp_error}" = 0 ]; then
++ cat "${err}"
++ else
++ echo "${out}"
++ fi
+ return 2
+ elif [ "${out}" = "${expected}" ]; then
+ return 0
+--- a/tools/testing/selftests/net/mptcp/pm_netlink.sh
++++ b/tools/testing/selftests/net/mptcp/pm_netlink.sh
+@@ -121,10 +121,12 @@ check()
+ local cmd="$1"
+ local expected="$2"
+ local msg="$3"
++ local exp_error="$4"
+ local rc=0
+
+ mptcp_lib_print_title "$msg"
+- mptcp_lib_check_output "${err}" "${cmd}" "${expected}" || rc=${?}
++ mptcp_lib_check_output "${err}" "${cmd}" "${expected}" "${exp_error}" ||
++ rc=${?}
+ if [ ${rc} -eq 2 ]; then
+ mptcp_lib_result_fail "${msg} # error ${rc}"
+ ret=${KSFT_FAIL}
+@@ -157,13 +159,13 @@ check "show_endpoints" \
+ "3,10.0.1.3,signal backup")" "dump addrs"
+
+ del_endpoint 2
+-check "get_endpoint 2" "" "simple del addr"
++check "get_endpoint 2" "" "simple del addr" 1
+ check "show_endpoints" \
+ "$(format_endpoints "1,10.0.1.1" \
+ "3,10.0.1.3,signal backup")" "dump addrs after del"
+
+ add_endpoint 10.0.1.3 2>/dev/null
+-check "get_endpoint 4" "" "duplicate addr"
++check "get_endpoint 4" "" "duplicate addr" 1
+
+ add_endpoint 10.0.1.4 flags signal
+ check "get_endpoint 4" "$(format_endpoints "4,10.0.1.4,signal")" "id addr increment"
+@@ -172,7 +174,7 @@ for i in $(seq 5 9); do
+ add_endpoint "10.0.1.${i}" flags signal >/dev/null 2>&1
+ done
+ check "get_endpoint 9" "$(format_endpoints "9,10.0.1.9,signal")" "hard addr limit"
+-check "get_endpoint 10" "" "above hard addr limit"
++check "get_endpoint 10" "" "above hard addr limit" 1
+
+ del_endpoint 9
+ for i in $(seq 10 255); do
--- /dev/null
+From 53705ddfa18408f8e1f064331b6387509fa19f7f Mon Sep 17 00:00:00 2001
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Tue, 5 May 2026 17:00:59 +0200
+Subject: selftests: mptcp: pm: restrict 'unknown' check to pm_nl_ctl
+
+From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+
+commit 53705ddfa18408f8e1f064331b6387509fa19f7f upstream.
+
+When pm_netlink.sh is executed with '-i', 'ip mptcp' is used instead of
+'pm_nl_ctl'. IPRoute2 doesn't support the 'unknown' flag, which has only
+been added to 'pm_nl_ctl' for this specific check: to ensure that the
+kernel ignores such unsupported flag.
+
+No reason to add this flag to 'ip mptcp'. Then, this check should be
+skipped when 'ip mptcp' is used.
+
+Fixes: 0cef6fcac24d ("selftests: mptcp: ip_mptcp option for more scripts")
+Cc: stable@vger.kernel.org
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-11-fca8091060a4@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/mptcp/pm_netlink.sh | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/tools/testing/selftests/net/mptcp/pm_netlink.sh
++++ b/tools/testing/selftests/net/mptcp/pm_netlink.sh
+@@ -193,9 +193,13 @@ check "show_endpoints" \
+ flush_endpoint
+ check "show_endpoints" "" "flush addrs"
+
+-add_endpoint 10.0.1.1 flags unknown
+-check "show_endpoints" "$(format_endpoints "1,10.0.1.1")" "ignore unknown flags"
+-flush_endpoint
++# "unknown" flag is only supported by pm_nl_ctl
++if ! mptcp_lib_is_ip_mptcp; then
++ add_endpoint 10.0.1.1 flags unknown
++ check "show_endpoints" "$(format_endpoints "1,10.0.1.1")" \
++ "ignore unknown flags"
++ flush_endpoint
++fi
+
+ set_limits 9 1 2>/dev/null
+ check "get_limits" "${default_limits}" "rcv addrs above hard limit"
kvm-x86-check-for-nept-nnpt-in-slow-flush-hypercalls.patch
mm-damon-sysfs-schemes-protect-memcg_path-kfree-with-damon_sysfs_lock.patch
pci-update-saved_config_space-upon-resource-assignment.patch
+pci-aer-clear-only-error-bits-in-pcie-device-status.patch
+pci-aer-stop-ruling-out-unbound-devices-as-error-source.patch
+pci-aspm-fix-pci_clear_and_set_config_dword-usage.patch
+power-supply-max17042-avoid-overflow-when-determining-health.patch
+rdma-mana-fix-error-unwind-in-mana_ib_create_qp_rss.patch
+rdma-mana-fix-mana_destroy_wq_obj-cleanup-in-mana_ib_create_qp_rss.patch
+rdma-mana-validate-rx_hash_key_len.patch
+rdma-mlx4-fix-resource-leak-on-error-in-mlx4_ib_create_srq.patch
+rdma-mlx5-fix-error-path-fall-through-in-mlx5_ib_dev_res_srq_init.patch
+rdma-ocrdma-don-t-null-deref-uctx-on-errors-in-ocrdma_copy_pd_uresp.patch
+rdma-rxe-reject-non-8-byte-atomic_write-payloads.patch
+rdma-rxe-reject-unknown-opcodes-before-icrc-processing.patch
+rdma-vmw_pvrdma-fix-double-free-on-pvrdma_alloc_ucontext-error-path.patch
+selftests-mptcp-check-output-catch-cmd-errors.patch
+selftests-mptcp-pm-restrict-unknown-check-to-pm_nl_ctl.patch
+mptcp-fastclose-msk-when-linger-time-is-0.patch
+mptcp-use-mpjoinsynackhmacfailure-for-synack-hmac-failure.patch
+mptcp-use-mptcp_rst_emptcp-for-ack-hmac-validation-failure.patch
+mptcp-sockopt-set-timestamp-flags-on-subflow-socket-not-msk.patch
+mptcp-fix-scheduling-with-atomic-in-timestamp-sockopt.patch
+f2fs-add-read_once-for-i_blocks-in-f2fs_update_inode.patch
+f2fs-fix-fiemap-boundary-handling-when-read-extent-cache-is-incomplete.patch
+f2fs-fix-incorrect-multidevice-info-in-trace_f2fs_map_blocks.patch
+f2fs-fix-node_cnt-race-between-extent-node-destroy-and-writeback.patch
+f2fs-fix-uninitialized-kobject-put-in-f2fs_init_sysfs.patch
+kvm-arm64-vgic-fix-iidr-revision-field-extracted-from-wrong-value.patch
+kvm-arm64-fix-initialisation-order-in-__pkvm_init_finalise.patch
+loongarch-fix-potential-ade-in-loongson_gpu_fixup_dma_hang.patch
+loongarch-kvm-cap-kvm_cap_nr_vcpus-by-kvm_cap_max_vcpus.patch
+loongarch-kvm-fix-unreliable-stack-for-kvm_exc_entry.patch
+loongarch-kvm-fix-hw-timer-interrupt-lost-when-inject-interrupt-by-software.patch
+loongarch-kvm-move-unconditional-delay-into-timer-clear-scenery.patch
+loongarch-kvm-use-kvm_set_pte-in-kvm_flush_pte.patch
+loongarch-use-per-root-bridge-pcih-flag-to-skip-mem-resource-fixup.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
