- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] ext4: avoid infinite loops caused by residual data
by Lai Zewei 18 Aug '26

18 Aug '26

mainline inclusion from mainline-v7.0-rc6 commit 5422fe71d26d42af6c454ca9527faaad4e677d6c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14191 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously. The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1]. If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases: 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case. 2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks. [1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline] Reported-by: syzbot+512459401510e2a9a39f(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7 Tested-by: syzbot+1659aaaaa8d9d11265d7(a)syzkaller.appspotmail.com Reported-by: syzbot+1659aaaaa8d9d11265d7(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f Tested-by: syzbot+1659aaaaa8d9d11265d7(a)syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Tested-by: syzbot+512459401510e2a9a39f(a)syzkaller.appspotmail.com Link: https://patch.msgid.link/tencent_43696283A68450B761D76866C6F360E36705@qq.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)kernel.org Conflicts: fs/ext4/extents.c [ctx conflicts] Signed-off-by: Lai Zewei <laizewei3(a)huawei.com> --- fs/ext4/extents.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 5f2654bfe2f1..2db5289dc52f 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4673,14 +4673,22 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode, &newex, flags); if (err && free_on_err) { - int fb_flags = flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE ? - EXT4_FREE_BLOCKS_NO_QUOT_UPDATE : 0; - /* free data blocks we just allocated */ - /* not a good idea to call discard here directly, - * but otherwise we'd need to call it every free() */ - ext4_discard_preallocations(inode); - ext4_free_blocks(handle, inode, NULL, newblock, - EXT4_C2B(sbi, allocated_clusters), fb_flags); + /* + * Gracefully handle out of space conditions. If the filesystem + * is inconsistent, we'll just leak allocated blocks to avoid + * causing even more damage. + */ + if (err == -EDQUOT || err == -ENOSPC) { + int fb_flags = flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE ? + EXT4_FREE_BLOCKS_NO_QUOT_UPDATE : 0; + /* free data blocks we just allocated. + * not a good idea to call discard here directly, + * but otherwise we'd need to call it every free(). + */ + ext4_discard_preallocations(inode); + ext4_free_blocks(handle, inode, NULL, newblock, + EXT4_C2B(sbi, allocated_clusters), fb_flags); + } goto out2; } -- 2.52.0

2 1

[PATCH OLK-6.6 v2 0/8] irqbypass: Cleanups and a perf improvement
by Qiqi Li 18 Aug '26

18 Aug '26

From: Qiqi Li <liqiqi23(a)huawei.com> The two primary goals of this series are to make the irqbypass concept easier to understand, and to address the terrible performance that can result from using a list to track connections. Provides additional adaptation for the ub vfio device in openEuler. Sean Christopherson (8): irqbypass: Drop pointless and misleading THIS_MODULE get/put irqbypass: Drop superfluous might_sleep() annotations irqbypass: Take ownership of producer/consumer token tracking irqbypass: Explicitly track producer and consumer bindings irqbypass: Use paired consumer/producer to disconnect during unregister irqbypass: Use guard(mutex) in lieu of manual lock+unlock irqbypass: Use xarray to track producers and consumers irqbypass: Require producers to pass in Linux IRQ number during registration arch/x86/kvm/x86.c | 4 +- drivers/vfio/pci/vfio_pci_intrs.c | 10 +- drivers/vfio/ubus/vfio_ub_intrs.c | 11 +- drivers/vhost/vdpa.c | 10 +- include/linux/irqbypass.h | 46 +++---- virt/kvm/eventfd.c | 7 +- virt/lib/irqbypass.c | 192 +++++++++++------------------- 7 files changed, 112 insertions(+), 168 deletions(-) -- 2.43.0

2 9

[PATCH OLK-6.6] cifs: Fix busy dentry used during umounting
by Zizhi Wo 18 Aug '26

18 Aug '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9783 -------------------------------- Commit 3b11912af75f ("[Backport] cifs: Fix busy dentry used after unmounting") fixed the issue in cifs where deferred close of a file led to a dentry reference count not being released in umount, by flushing deferredclose_wq in cifs_kill_sb to solve it. However, the cifs DIO path suffers from the same busy-dentry problem caused by a delayed dentry reference-count release: process A[dio] process B[cifsd] process C[close] cifs_direct_writev ... smb2_writev_callback wait_for_completion_killable queue_work(cifsiod_wq, xx)[1] cifs_uncached_writev_complete complete(&ctx->done)[2] kref_put(&ctx->refcount, xxx) // write done! cifs_close _cifsFileInfo_put[3] --cfile->count // count = 1 kref_put(&wdata->refcount, xx) ... _cifsFileInfo_put --cfile->count // count = 0 queue_work(fileinfo_put_wq, xx)[4] cifsFileInfo_put_work cifsFileInfo_put_final dput At [1] the work is queued onto cifsiod_wq. At [2] the foreground thread waiting on the write is woken up; after the write path exits and closes the file, at [3] the cfile reference count has not yet dropped to 0, so the final dput is not called synchronously. The cifsiod worker then drops the cfile reference count to 0 and calls the final dput on fileinfo_put_wq at [4]. If the umount path is triggered before [4], it results in the following warning: BUG: Dentry 00000000eab1f070{i=9a917b66ae404fec,n=test} still in use (1) [unmount of cifs cifs] Therefore, cifsiod_wq/fileinfo_put_wq/serverclose_wq need to be flushed. Fixes: b28b211c8d8f ("cifs: open files should not hold ref on superblock") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/smb/client/cifsfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c index a2887b978dc8..f6d74e961414 100644 --- a/fs/smb/client/cifsfs.c +++ b/fs/smb/client/cifsfs.c @@ -298,10 +298,13 @@ static void cifs_kill_sb(struct super_block *sb) /* Wait for all pending oplock breaks to complete */ flush_workqueue(cifsoplockd_wq); /* Wait for all opened files to release */ flush_workqueue(deferredclose_wq); + flush_workqueue(cifsiod_wq); + flush_workqueue(serverclose_wq); + flush_workqueue(fileinfo_put_wq); /* finally release root dentry */ dput(cifs_sb->root); cifs_sb->root = NULL; } -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS] ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
by Pan Taixi 18 Aug '26

18 Aug '26

From: Bryam Vargas <hexlabsecurity(a)proton.me> mainline inclusion from mainline-v7.2-rc5 commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/16967 CVE: CVE-2026-68160 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path. Cc: stable(a)vger.kernel.org Fixes: a8599bd821d0 ("ceph: capability management") Signed-off-by: Bryam Vargas <hexlabsecurity(a)proton.me> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko(a)ibm.com> Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Conflicts: fs/ceph/caps.c [Context conflicts unmerged commit 8ea412e18131 ("ceph: improve caps debugging output")] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- fs/ceph/caps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index b631719941c2..80591f37dd77 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -3765,10 +3765,11 @@ void ceph_handle_caps(struct ceph_mds_session *session, seq = le32_to_cpu(h->seq); mseq = le32_to_cpu(h->migrate_seq); snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); + ceph_decode_need(&snaptrace, end, snaptrace_len, bad); p = snaptrace + snaptrace_len; if (msg_version >= 2) { u32 flock_len; ceph_decode_32_safe(&p, end, flock_len, bad); -- 2.34.1

2 1

[PATCH OLK-5.10] ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
by Pan Taixi 18 Aug '26

18 Aug '26

From: Bryam Vargas <hexlabsecurity(a)proton.me> mainline inclusion from mainline-v7.2-rc5 commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/16967 CVE: CVE-2026-68160 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path. Cc: stable(a)vger.kernel.org Fixes: a8599bd821d0 ("ceph: capability management") Signed-off-by: Bryam Vargas <hexlabsecurity(a)proton.me> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko(a)ibm.com> Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Conflicts: fs/ceph/caps.c [Context conflicts unmerged commit 8ea412e18131 ("ceph: improve caps debugging output")] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- fs/ceph/caps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index 8c1dd9e80e7e..31e5d87ec945 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -4124,10 +4124,11 @@ void ceph_handle_caps(struct ceph_mds_session *session, seq = le32_to_cpu(h->seq); mseq = le32_to_cpu(h->migrate_seq); snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); + ceph_decode_need(&snaptrace, end, snaptrace_len, bad); p = snaptrace + snaptrace_len; if (msg_version >= 2) { u32 flock_len; ceph_decode_32_safe(&p, end, flock_len, bad); -- 2.34.1

2 1

[PATCH OLK-6.6] cdrom: fix stack out-of-bounds read in CDROMVOLCTRL
by Fanhua Li 18 Aug '26

18 Aug '26

From: Xu Rao <raoxu(a)uniontech.com> stable inclusion from stable-v6.6.148 commit 7344c84e32413e5c8832f74b8a612b0194e5c051 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17022 CVE: CVE-2026-68184 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit b27e195d4db8dea263050bdbeb11881b2999c9c6 upstream. mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Xu Rao <raoxu(a)uniontech.com> Signed-off-by: Phillip Potter <phil(a)philpotter.co.uk> Link: https://patch.msgid.link/20260720194421.1497-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/cdrom/cdrom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index 2283fd91ff5f8..c638f6a9bc7d6 100644 --- a/drivers/cdrom/cdrom.c +++ b/drivers/cdrom/cdrom.c @@ -3191,6 +3191,7 @@ static noinline int mmc_ioctl_cdrom_volume(struct cdrom_device_info *cdi, /* set volume */ cgc->buffer = buffer + offset - 8; + cgc->buflen -= offset - 8; memset(cgc->buffer, 0, 8); return cdrom_mode_select(cdi, cgc); } -- 2.43.0

2 1

[PATCH OLK-6.6] openeuler_defconfig: Enable Landlock (testing)
by GONG Ruiqi 18 Aug '26

18 Aug '26

hulk inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/9681 -------------------------------- Test only. Do NOT merge. Signed-off-by: GONG Ruiqi <gongruiqi1(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 4 ++-- arch/x86/configs/openeuler_defconfig | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index 9c6d128276cd..1816509a5041 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -7482,7 +7482,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y @@ -7539,7 +7539,7 @@ CONFIG_EVM_X509_PATH="/etc/keys/x509_evm.der" CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_DAC is not set -CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" # # Kernel hardening options diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index 685c32d1e7af..ec621167398d 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -8667,7 +8667,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y @@ -8724,7 +8724,7 @@ CONFIG_EVM_X509_PATH="/etc/keys/x509_evm.der" CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_DAC is not set -CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" # # Kernel hardening options -- 2.43.0

2 1

[PATCH OLK-6.6 0/8] irqbypass: Cleanups and a perf improvement
by Qiqi Li 17 Aug '26

17 Aug '26

From: Qiqi Li <liqiqi23(a)huawei.com> The two primary goals of this series are to make the irqbypass concept easier to understand, and to address the terrible performance that can result from using a list to track connections. Provides additional adaptation for the ub vfio device in openEuler. Sean Christopherson (8): irqbypass: Drop pointless and misleading THIS_MODULE get/put irqbypass: Drop superfluous might_sleep() annotations irqbypass: Take ownership of producer/consumer token tracking irqbypass: Explicitly track producer and consumer bindings irqbypass: Use paired consumer/producer to disconnect during unregister irqbypass: Use guard(mutex) in lieu of manual lock+unlock irqbypass: Use xarray to track producers and consumers irqbypass: Require producers to pass in Linux IRQ number during registration arch/x86/kvm/x86.c | 4 +- drivers/vfio/pci/vfio_pci_intrs.c | 10 +- drivers/vfio/ubus/vfio_ub_intrs.c | 11 +- drivers/vhost/vdpa.c | 10 +- include/linux/irqbypass.h | 46 ++++---- virt/kvm/eventfd.c | 7 +- virt/lib/irqbypass.c | 190 +++++++++++------------------- 7 files changed, 111 insertions(+), 167 deletions(-) -- 2.43.0

2 9

[PATCH OLK-6.6 0/8] irqbypass: Cleanups and a perf improvement
by Qiqi Li 17 Aug '26

17 Aug '26

From: Qiqi Li <liqiqi23(a)huawei.com> The two primary goals of this series are to make the irqbypass concept easier to understand, and to address the terrible performance that can result from using a list to track connections. Provides additional adaptation for the ub vfio device in openEuler. Sean Christopherson (8): irqbypass: Drop pointless and misleading THIS_MODULE get/put irqbypass: Drop superfluous might_sleep() annotations irqbypass: Take ownership of producer/consumer token tracking irqbypass: Explicitly track producer and consumer bindings irqbypass: Use paired consumer/producer to disconnect during unregister irqbypass: Use guard(mutex) in lieu of manual lock+unlock irqbypass: Use xarray to track producers and consumers irqbypass: Require producers to pass in Linux IRQ number during registration arch/x86/kvm/x86.c | 4 +- drivers/vfio/pci/vfio_pci_intrs.c | 10 +- drivers/vfio/ubus/vfio_ub_intrs.c | 11 +- drivers/vhost/vdpa.c | 10 +- include/linux/irqbypass.h | 46 ++++---- virt/kvm/eventfd.c | 7 +- virt/lib/irqbypass.c | 190 +++++++++++------------------- 7 files changed, 111 insertions(+), 167 deletions(-) -- 2.43.0

2 9

[PATCH OLK-6.6] openeuler_defconfig: Enable Landlock (kABI testing)
by GONG Ruiqi 17 Aug '26

17 Aug '26

hulk inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/9681 -------------------------------- KABI test only. Do NOT merge. Signed-off-by: GONG Ruiqi <gongruiqi1(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 4 ++-- arch/x86/configs/openeuler_defconfig | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index 9c6d128276cd..1816509a5041 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -7482,7 +7482,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y @@ -7539,7 +7539,7 @@ CONFIG_EVM_X509_PATH="/etc/keys/x509_evm.der" CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_DAC is not set -CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" # # Kernel hardening options diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index 685c32d1e7af..ec621167398d 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -8667,7 +8667,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y @@ -8724,7 +8724,7 @@ CONFIG_EVM_X509_PATH="/etc/keys/x509_evm.der" CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_DAC is not set -CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" # # Kernel hardening options -- 2.43.0

2 1