- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] xfs: stop reclaim before pushing AIL during unmount
by Long Li 17 Jun '26

17 Jun '26

From: Yuto Ohnuki <ytohnuki(a)amazon.com> stable inclusion from stable-v5.10.252 commit e6cc490048f78b009259a5f032acead9f789c34c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14197 CVE: CVE-2026-31455 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 4f24a767e3d64a5f58c595b5c29b6063a201f1e3 ] The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable. Reported-by: syzbot+652af2b3c5569c4ab63c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=652af2b3c5569c4ab63c Fixes: 90c60e164012 ("xfs: xfs_iflush() is no longer necessary") Cc: stable(a)vger.kernel.org # v5.9 Signed-off-by: Yuto Ohnuki <ytohnuki(a)amazon.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> [ dropped xfs_inodegc_stop() call ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/xfs/xfs_mount.c [Context conflicts] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_mount.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 4983fe7eadf0..cb99ac78d904 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -687,8 +687,9 @@ xfs_ifree_unmount( * have been retrying in the background. This will prevent never-ending * retries in AIL pushing from hanging the unmount. * - * Finally, we can push the AIL to clean all the remaining dirty objects, then - * reclaim the remaining inodes that are still in memory at this point in time. + * Stop inodegc and background reclaim before pushing the AIL so that they + * are not running while the AIL is being flushed. Then push the AIL to + * clean all the remaining dirty objects and reclaim the remaining inodes. */ static void xfs_unmount_flush_inodes( @@ -700,9 +701,9 @@ xfs_unmount_flush_inodes( set_bit(XFS_OPSTATE_UNMOUNTING, &mp->m_opstate); - xfs_ail_push_all_sync(mp->m_ail); xfs_inodegc_stop(mp); cancel_delayed_work_sync(&mp->m_reclaim_work); + xfs_ail_push_all_sync(mp->m_ail); xfs_reclaim_inodes(mp); xfs_health_unmount(mp); } -- 2.52.0

2 1

[PATCH OLK-5.10 0/3] Fix CVE-2026-31453
by Long Li 17 Jun '26

17 Jun '26

Fix CVE-2026-31453. Long Li (1): Revert "xfs: fix a UAF when inode item push" Yuto Ohnuki (2): xfs: avoid dereferencing log items after push callbacks xfs: save ailp before dropping the AIL lock in push callbacks fs/xfs/xfs_dquot_item.c | 9 ++++-- fs/xfs/xfs_inode_item.c | 17 ++++++----- fs/xfs/xfs_trace.c | 1 + fs/xfs/xfs_trace.h | 63 ++++++++++++++++++++--------------------- fs/xfs/xfs_trans_ail.c | 26 ++++++++++++----- 5 files changed, 66 insertions(+), 50 deletions(-) -- 2.52.0

2 4

[PATCH OLK-5.10] xfs: delete attr leaf freemap entries when empty
by Long Li 17 Jun '26

17 Jun '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v5.10.251 commit f3c0d1fc1eadbb4adbee5ab7757d41d35f48325b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14733 CVE: CVE-2026-43187 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 6f13c1d2a6271c2e73226864a0e83de2770b6f34 ] Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time. Cc: <stable(a)vger.kernel.org> # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_attr_leaf.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index e953bc44d4d0..3954bf017c8d 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -1575,6 +1575,19 @@ xfs_attr3_leaf_add_work( min_t(uint16_t, ichdr->freemap[i].size, sizeof(xfs_attr_leaf_entry_t)); } + + /* + * Don't leave zero-length freemaps with nonzero base lying + * around, because we don't want the code in _remove that + * matches on base address to get confused and create + * overlapping freemaps. If we end up with no freemap entries + * then the next _add will compact the leaf block and + * regenerate the freemaps. + */ + if (ichdr->freemap[i].size == 0 && ichdr->freemap[i].base > 0) { + ichdr->freemap[i].base = 0; + ichdr->holes = 1; + } } ichdr->usedbytes += xfs_attr_leaf_entsize(leaf, args->index); return 0; -- 2.52.0

2 1

[PATCH OLK-5.10] fuse: reject oversized dirents in page cache
by Long Li 17 Jun '26

17 Jun '26

From: Samuel Page <sam(a)bynar.io> mainline inclusion from mainline-v7.0 commit 51a8de6c50bf947c8f534cd73da4c8f0a13e7bed category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14444 CVE: CVE-2026-31694 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache. Fixes: 69e34551152a ("fuse: allow caching readdir") Cc: stable(a)vger.kernel.org # v6.16+ Assisted-by: Bynario AI Signed-off-by: Samuel Page <sam(a)bynar.io> Reported-by: Qi Tang <tpluszz77(a)gmail.com> Reported-by: Zijun Hu <nightu(a)northwestern.edu> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Link: https://patch.msgid.link/20260420090139.662772-1-mszeredi@redhat.com Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/fuse/readdir.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c index f18632027d8b..00b2fc180bc7 100644 --- a/fs/fuse/readdir.c +++ b/fs/fuse/readdir.c @@ -41,6 +41,10 @@ static void fuse_add_dirent_to_cache(struct file *file, unsigned int offset; void *addr; + /* Dirent doesn't fit in readdir cache page? Skip caching. */ + if (reclen > PAGE_SIZE) + return; + spin_lock(&fi->rdc.lock); /* * Is cache already completed? Or this entry does not go at the end of -- 2.52.0

2 1

[PATCH OLK-5.10] ntfs: ->d_compare() must not block
by Yifan Qiao 17 Jun '26

17 Jun '26

From: Al Viro <viro(a)zeniv.linux.org.uk> mainline inclusion from mainline-v7.0-rc1 commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14789 CVE: CVE-2026-43245 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/ntfs3/dir.c | 5 ++--- fs/ntfs3/inode.c | 12 ++++++------ fs/ntfs3/namei.c | 9 ++++----- fs/ntfs3/xattr.c | 4 ++-- 4 files changed, 14 insertions(+), 16 deletions(-) diff --git a/fs/ntfs3/dir.c b/fs/ntfs3/dir.c index fb438d604040..27713367aa64 100644 --- a/fs/ntfs3/dir.c +++ b/fs/ntfs3/dir.c @@ -390,8 +390,7 @@ static int ntfs_readdir(struct file *file, struct dir_context *ctx) if (!dir_emit_dots(file, ctx)) return 0; - /* Allocate PATH_MAX bytes. */ - name = __getname(); + name = kmalloc(PATH_MAX, GFP_KERNEL); if (!name) return -ENOMEM; @@ -470,7 +469,7 @@ static int ntfs_readdir(struct file *file, struct dir_context *ctx) out: - __putname(name); + kfree(name); put_indx_node(node); if (err == -ENOENT) { diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c index b1849c4c48e1..c582eb08d5f8 100644 --- a/fs/ntfs3/inode.c +++ b/fs/ntfs3/inode.c @@ -1280,7 +1280,7 @@ struct inode *ntfs_create_inode(struct user_namespace *mnt_userns, fa |= FILE_ATTRIBUTE_READONLY; /* Allocate PATH_MAX bytes. */ - new_de = __getname(); + new_de = kzalloc(PATH_MAX, GFP_KERNEL); if (!new_de) { err = -ENOMEM; goto out1; @@ -1653,7 +1653,7 @@ struct inode *ntfs_create_inode(struct user_namespace *mnt_userns, ntfs_mark_rec_free(sbi, ino); out2: - __putname(new_de); + kfree(new_de); kfree(rp); out1: @@ -1676,7 +1676,7 @@ int ntfs_link_inode(struct inode *inode, struct dentry *dentry) struct ATTR_FILE_NAME *de_name; /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kzalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -1699,7 +1699,7 @@ int ntfs_link_inode(struct inode *inode, struct dentry *dentry) err = ni_add_name(ntfs_i(d_inode(dentry->d_parent)), ni, de); out: - __putname(de); + kfree(de); return err; } @@ -1723,7 +1723,7 @@ int ntfs_unlink_inode(struct inode *dir, const struct dentry *dentry) return -EINVAL; /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kzalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -1761,7 +1761,7 @@ int ntfs_unlink_inode(struct inode *dir, const struct dentry *dentry) out: ni_unlock(ni); - __putname(de); + kfree(de); return err; } diff --git a/fs/ntfs3/namei.c b/fs/ntfs3/namei.c index 18330d982b07..49f5246abfdd 100644 --- a/fs/ntfs3/namei.c +++ b/fs/ntfs3/namei.c @@ -66,7 +66,7 @@ static struct dentry *ntfs_lookup(struct inode *dir, struct dentry *dentry, u32 flags) { struct ntfs_inode *ni = ntfs_i(dir); - struct cpu_str *uni = __getname(); + struct cpu_str *uni = kmalloc(PATH_MAX, GFP_KERNEL); struct inode *inode; int err; @@ -83,7 +83,7 @@ static struct dentry *ntfs_lookup(struct inode *dir, struct dentry *dentry, inode = dir_search_u(dir, uni, NULL); ni_unlock(ni); } - __putname(uni); + kfree(uni); } return d_splice_alias(inode, dentry); @@ -280,8 +280,7 @@ static int ntfs_rename(struct inode *dir, return err; } - /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kmalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -325,7 +324,7 @@ static int ntfs_rename(struct inode *dir, ni_unlock(ni); ni_unlock(dir_ni); out: - __putname(de); + kfree(de); return err; } diff --git a/fs/ntfs3/xattr.c b/fs/ntfs3/xattr.c index 24d739000c80..ddec586d4de6 100644 --- a/fs/ntfs3/xattr.c +++ b/fs/ntfs3/xattr.c @@ -533,7 +533,7 @@ static struct posix_acl *ntfs_get_acl_ex(struct user_namespace *mnt_userns, void *buf; /* Allocate PATH_MAX bytes. */ - buf = __getname(); + buf = kmalloc(PATH_MAX, GFP_KERNEL); if (!buf) return ERR_PTR(-ENOMEM); @@ -566,7 +566,7 @@ static struct posix_acl *ntfs_get_acl_ex(struct user_namespace *mnt_userns, if (!IS_ERR(acl)) set_cached_acl(inode, type, acl); - __putname(buf); + kfree(buf); return acl; } -- 2.52.0

2 1

社区update版本合入截止时间和构建时间调整公示
by Xushanshan(Sassa,openEuler) 16 Jun '26

16 Jun '26

Add kernel sig 发件人: Xushanshan(Sassa,openEuler) <xushanshan3(a)huawei.com> 发送时间: 2026年6月16日 23:17 收件人: release(a)openeuler.org 抄送: tc(a)openeuler.org; qa(a)openeuler.org; dev(a)openeuler.org; cicd(a)openeuler.org; kernel(a)openeuler.org 主题: [Dev] 社区update版本合入截止时间和构建时间调整公示 Hi ALL：经RM sig评审，update 版本的构建时间调整为周一合入，周三发布；整体触发背景和结论如下，如有相关的意见，可在06/22前反馈。一：变更背景：社区构建资源紧张，内核&用户态等PR集中提交的情况下，资源冲突，PR高峰期合入要等待2-3小时，构建出包10+小时。从工程能力和版本发布周期等维度讨论了部分优化措施，过程中识别到主干Next分支和update版本发布时间存在重叠（周三12点截止PR合入，周五出版本），资源抢占较多，影响两个版本，因此申请错开两个版本。其他优化措施见四；二：决策结论：社区update版本的PR截止合入时间，调整为周一16点，版本发布时间调整为周三晚；update变更开始执行时间：0622 三：修改后的合入时间建议：版本类型版本 PR截止合入时间版本发布时间内核用户态源码仓制品仓源码仓制品仓开发分支（保持不变） Next主干开发分支(当前24.03 LTS SP4) 周三16：00 周三18：00 / 周三18：00 周五晚维护版本 24.03 LTS SP3 update 周一16:00 周一18：00 / 周一18:00 周三晚 24.03 LTS SP1 update 22.03 LTS SP4 update 20.03 LTS SP4 四：其他工程能力优化措施和进展：问题改进措施进展内核源码编译门禁执行时间长 1、新增蓝区arm物理机集群，对接oe社区Jenkins 2、该集群用于内核源码编译，并根据负载情况进行扩缩容 done 检查类门禁（trigger门禁）排队时间长 1、增加trigger机器资源(done) 2、能自动停止同一个pr中已经失效的但还在排队或者执行中的任务目标730 多个版本集中在同一时间构建，导致EulerMaker负载大，调度慢 1、update版本和SP版本严格管控合入时间，按天错开构建时间(done) 2、EulerMaker进行重构，从架构层面解决调度问题目标930 构建流程存在断连，每个步骤都通过定时触发，而不是前后依赖触发，导致端到端构建总时间过长（20点开始包构建，凌晨6点左右出包，端到端需要10小时） 1、通过Jenkins流水线能力连编排EulerMaker everyting工程构建，ISO镜像构建，EulerMaker epol工程构建，docker镜像和虚拟机镜像构建，openQA测试等全流程，端到端时间缩短到4-6小时 done

1 0

[PATCH OLK-6.6 0/1] ACPI: CPPC: Move reference performance to capabilities
by Pengjie Zhang 16 Jun '26

16 Jun '26

From: Hongye Lin <linhongye(a)h-partners.com> mainline inclusion from mainline-v7.1-rc1 commit 8505bfb4e4eca28ef1b20d3369435ec2d6a125c6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9163 CVE: NA Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… ---------------------------------------------------------------------- Currently, the Reference Performance register is read every time the CPU frequency is sampled in cppc_get_perf_ctrs(). This function is on the hot path of the cpufreq driver. Reference Performance indicates the performance level that corresponds to the Reference Counter incrementing and is not expected to change dynamically during runtime (unlike the Delivered and Reference counters). Reading this register in the hot path incurs unnecessary overhead, particularly on platforms where CPC registers are located in the PCC (Platform Communication Channel) subspace. This patch moves reference_perf from the dynamic feedback counters structure (cppc_perf_fb_ctrs) to the static capabilities structure (cppc_perf_caps). Pengjie Zhang (1): ACPI: CPPC: Move reference performance to capabilities drivers/acpi/cppc_acpi.c | 41 ++++++++++++++++++---------------- drivers/cpufreq/cppc_cpufreq.c | 2 +- include/acpi/cppc_acpi.h | 2 +- 3 files changed, 24 insertions(+), 21 deletions(-) -- 2.33.0

2 2

[PATCH OLK-6.6] Revert "!20376 [OLK-6.6] Support 1G hugetlb for CSV3 and other CSV3 optimizations."
by Tengda Wu 16 Jun '26

16 Jun '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9430 -------------------------------- This reverts commit 14e583ccc8af52f03a29ea704970e8e4b28966c2, reversing changes made to adbe47b6cb32f8ea1644528dc0efce88d043f126. It introduces a x86_64 check_build error: In file included from drivers/char/tpm/tpm_hygon.c:18: ./include/linux/psp-hygon.h:51:9: error: redeclaration of enumerator ‘CSV3_CMD_LAUNCH_FINISH_EX’ 51 | CSV3_CMD_LAUNCH_FINISH_EX = 0x204, | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/psp-hygon.h:48:9: note: previous definition of ‘CSV3_CMD_LAUNCH_FINISH_EX’ with type ‘int’ 48 | CSV3_CMD_LAUNCH_FINISH_EX = 0x204, | ^~~~~~~~~~~~~~~~~~~~~~~~~ Revert it to avoid compilation issues. Fixes: 78d3389e7d6b ("crypto: ccp: Define CSV3 LAUNCH_FINISH_EX command id") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- drivers/crypto/ccp/hygon/csv-dev.c | 1 - include/linux/psp-hygon.h | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/crypto/ccp/hygon/csv-dev.c b/drivers/crypto/ccp/hygon/csv-dev.c index 03f7e6db0e39..adf6bd89304f 100644 --- a/drivers/crypto/ccp/hygon/csv-dev.c +++ b/drivers/crypto/ccp/hygon/csv-dev.c @@ -65,7 +65,6 @@ int csv_cmd_buffer_len(int cmd) case CSV3_CMD_RECEIVE_ENCRYPT_DATA: return sizeof(struct csv3_data_receive_encrypt_data); case CSV3_CMD_RECEIVE_ENCRYPT_CONTEXT: - case CSV3_CMD_LAUNCH_FINISH_EX: return sizeof(struct csv3_data_launch_finish_ex); return sizeof(struct csv3_data_receive_encrypt_context); case CSV3_CMD_LAUNCH_FINISH_EX: return sizeof(struct csv3_data_launch_finish_ex); default: return 0; diff --git a/include/linux/psp-hygon.h b/include/linux/psp-hygon.h index 29f63bbfa1e1..0b81edaf2d56 100644 --- a/include/linux/psp-hygon.h +++ b/include/linux/psp-hygon.h @@ -45,7 +45,6 @@ enum csv3_cmd { CSV3_CMD_SET_GUEST_PRIVATE_MEMORY = 0x200, CSV3_CMD_LAUNCH_ENCRYPT_DATA = 0x201, CSV3_CMD_LAUNCH_ENCRYPT_VMCB = 0x202, - CSV3_CMD_LAUNCH_FINISH_EX = 0x204, /* Guest NPT(Nested Page Table) management commands */ CSV3_CMD_UPDATE_NPT = 0x203, CSV3_CMD_LAUNCH_FINISH_EX = 0x204, -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] ACPI: CPPC: Move reference performance to capabilities
by Pengjie Zhang 16 Jun '26

16 Jun '26

From: Hongye Lin <linhongye(a)h-partners.com> mainline inclusion from mainline-v7.1-rc1 commit 8505bfb4e4eca28ef1b20d3369435ec2d6a125c6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9163 CVE: NA Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… ---------------------------------------------------------------------- Currently, the Reference Performance register is read every time the CPU frequency is sampled in cppc_get_perf_ctrs(). This function is on the hot path of the cpufreq driver. Reference Performance indicates the performance level that corresponds to the Reference Counter incrementing and is not expected to change dynamically during runtime (unlike the Delivered and Reference counters). Reading this register in the hot path incurs unnecessary overhead, particularly on platforms where CPC registers are located in the PCC (Platform Communication Channel) subspace. This patch moves reference_perf from the dynamic feedback counters structure (cppc_perf_fb_ctrs) to the static capabilities structure (cppc_perf_caps). Pengjie Zhang (1): ACPI: CPPC: Move reference performance to capabilities drivers/acpi/cppc_acpi.c | 41 ++++++++++++++++++---------------- drivers/cpufreq/cppc_cpufreq.c | 2 +- include/acpi/cppc_acpi.h | 2 +- 3 files changed, 24 insertions(+), 21 deletions(-) -- 2.33.0

1 1

回复：[kernel] 驱动 Hht2dr 内核合入申请
by 刘俊豪 16 Jun '26

16 Jun '26

尊敬的 openEuler SIG 团队：您好！我司华澜微电子股份有限公司申请将 Hst2dr驱动（用于SAS HBA）加入 openEuler 内核，便于后续业务部署。烦请协助推进驱动合入相关事宜。如需要补充任何信息或材料，请随时与我联系。联系人：刘俊豪电子邮箱：junhao.liu(a)sage-micro.com.cn 感谢您的支持！华澜微电子股份有限公司 2026 年 06 月 11 日

2 1