mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 50 participants
  • 21262 discussions
[PATCH openEuler-1.0-LTS] mm: vmscan: fix page cache limit work condition
by Wupeng Ma 23 Sep '25

23 Sep '25
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- Commit 92cd2e7fa82d ("mm:vmscan: add the missing check of page_cache_over_limit") add limit check for shrink_page_cache_work to stop page cache below limit. However this limit is only checked iff memory reliable is enable, since page cache limit can be enabled without memory reliable. Enable this limit check in all scenarios. Fixes: 92cd2e7fa82d ("mm:vmscan: add the missing check of page_cache_over_limit") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- mm/vmscan.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 6a649f02666f..fa08ffd043de 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4060,8 +4060,7 @@ static void shrink_page_cache_work(struct work_struct *w) if (vm_cache_reclaim_s == 0 || !vm_cache_reclaim_enable) return; - if (mem_reliable_is_enabled() && - (!vm_cache_limit_mbytes || !page_cache_over_limit())) + if (!vm_cache_limit_mbytes || !page_cache_over_limit()) return; /* It should wait more time if we hardly reclaim the page cache */ -- 2.43.0
2 1
0 0
[PATCH OLK-5.10] ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr
by Yongjian Sun 23 Sep '25

23 Sep '25
From: Theodore Ts'o <tytso(a)mit.edu> mainline inclusion from mainline-v6.17-rc1 commit 099b847ccc6c1ad2f805d13cfbcc83f5b6d4bc42 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICWGGD CVE: CVE-2025-38701 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data() when an inode had the INLINE_DATA_FL flag set but was missing the system.data extended attribute. Since this can happen due to a maiciouly fuzzed file system, we shouldn't BUG, but rather, report it as a corrupted file system. Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii ext4_create_inline_data() and ext4_inline_data_truncate(). Reported-by: syzbot+544248a761451c0df72f(a)syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/ext4/inline.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index 471f6ef77c01..2bff874f1d81 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -296,7 +296,11 @@ static int ext4_create_inline_data(handle_t *handle, if (error) goto out; - BUG_ON(!is.s.not_found); + if (!is.s.not_found) { + EXT4_ERROR_INODE(inode, "unexpected inline data xattr"); + error = -EFSCORRUPTED; + goto out; + } error = ext4_xattr_ibody_set(handle, inode, &i, &is); if (error) { @@ -347,7 +351,11 @@ static int ext4_update_inline_data(handle_t *handle, struct inode *inode, if (error) goto out; - BUG_ON(is.s.not_found); + if (is.s.not_found) { + EXT4_ERROR_INODE(inode, "missing inline data xattr"); + error = -EFSCORRUPTED; + goto out; + } len -= EXT4_MIN_INLINE_DATA_SIZE; value = kzalloc(len, GFP_NOFS); @@ -1945,7 +1953,12 @@ int ext4_inline_data_truncate(struct inode *inode, int *has_inline) if ((err = ext4_xattr_ibody_find(inode, &i, &is)) != 0) goto out_error; - BUG_ON(is.s.not_found); + if (is.s.not_found) { + EXT4_ERROR_INODE(inode, + "missing inline data xattr"); + err = -EFSCORRUPTED; + goto out_error; + } value_len = le32_to_cpu(is.s.here->e_value_size); value = kmalloc(value_len, GFP_NOFS); -- 2.39.2
2 1
0 0
[PATCH OLK-6.6] arm64/mpam: Update MB hardlimit and priority default value forcely
by Zeng Heng 23 Sep '25

23 Sep '25
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICX9YF -------------------------------- When the root group config is absent, mpam_reprogram_ris_partid() must deliver defaults setting of the hardlimit and priority explicitly. Otherwise root group would be allowed to utilize idle memory bandwidth. Fixes: ec8cf750710c ("arm64/mpam: Update QoS partition default value") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_devices.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/platform/mpam/mpam_devices.c b/drivers/platform/mpam/mpam_devices.c index 250032f58659..783f9ffb270c 100644 --- a/drivers/platform/mpam/mpam_devices.c +++ b/drivers/platform/mpam/mpam_devices.c @@ -1258,6 +1258,22 @@ static u32 mpam_cpbm_hisi_workaround(u32 cpbm, u8 cache_level) return cpbm; } +static u16 mpam_intpri_hisi_workaround(struct mpam_msc_ris *ris, u16 intpri) +{ + struct mpam_class *class = ris->comp->class; + + if (read_cpuid_implementor() != ARM_CPU_IMP_HISI) + return intpri; + + if (class->type == MPAM_CLASS_MEMORY) + return 3; + + if (class->level == 3) + return 0; + + return intpri; +} + static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid, struct mpam_config *cfg) { @@ -1325,7 +1341,7 @@ static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid, if (mpam_has_feature(mpam_feat_max_limit, cfg)) limit = cfg->max_limit; else - limit = false; + limit = true; if (limit) mpam_write_partsel_reg(msc, MBW_MAX, bwa_fract | @@ -1343,6 +1359,7 @@ static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid, intpri = 0; if (mpam_has_feature(mpam_feat_intpri_part, rprops)) { + intpri = mpam_intpri_hisi_workaround(ris, intpri); if (mpam_has_feature(mpam_feat_intpri_part, cfg)) pri_val |= FIELD_PREP(MPAMCFG_PRI_INTPRI, cfg->intpri); else -- 2.25.1
2 1
0 0
[PATCH OLK-6.6] arm64/mpam: Add quirk for hisi cpbm_wd field
by Zeng Heng 23 Sep '25

23 Sep '25
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICX9YF -------------------------------- The bit mask width indicated in the MPAMF_CPOR_IDR_CPBM_WD IDR register of MPAM is inconsistent with the actual hardware capability. This incorrectly limits the L3 capacity in real use. Therefore, software has to hard-code a workaround to align with the actual CPBM bit width. Fixes: 051d021d1c1a ("arm_mpam: Probe the hardware features resctrl supports") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_devices.c | 57 +++++++++++++++++++++++++-- drivers/platform/mpam/mpam_internal.h | 2 + drivers/platform/mpam/mpam_resctrl.c | 8 +++- 3 files changed, 62 insertions(+), 5 deletions(-) diff --git a/drivers/platform/mpam/mpam_devices.c b/drivers/platform/mpam/mpam_devices.c index 516ffc4b4a3d..250032f58659 100644 --- a/drivers/platform/mpam/mpam_devices.c +++ b/drivers/platform/mpam/mpam_devices.c @@ -562,6 +562,28 @@ static struct mpam_msc_ris *mpam_get_or_create_ris(struct mpam_msc *msc, return found; } +u16 mpam_cpbm_wd_hisi_workaround(u16 cpbm_wd, enum mpam_device_features feat, + u8 cache_level) +{ + static const struct midr_range cpus[] = { + MIDR_ALL_VERSIONS(MIDR_HISI_HIP12), + { /* sentinel */ } + }; + + if (cache_level != 3) + return cpbm_wd; + + if (is_midr_in_range_list(read_cpuid_id(), cpus)) { + if (feat == mpam_feat_cpor_part) + return 19; + else if (feat == mpam_feat_ccap_part || + feat == mpam_feat_cmin) + return 21; + } + + return cpbm_wd; +} + static void mpam_ris_hw_probe(struct mpam_msc_ris *ris) { int err; @@ -591,7 +613,9 @@ static void mpam_ris_hw_probe(struct mpam_msc_ris *ris) if (FIELD_GET(MPAMF_IDR_HAS_CPOR_PART, ris->idr)) { u32 cpor_features = mpam_read_partsel_reg(msc, CPOR_IDR); - props->cpbm_wd = FIELD_GET(MPAMF_CPOR_IDR_CPBM_WD, cpor_features); + props->cpbm_wd = mpam_cpbm_wd_hisi_workaround( + FIELD_GET(MPAMF_CPOR_IDR_CPBM_WD, cpor_features), + mpam_feat_cpor_part, class->level); if (props->cpbm_wd) mpam_set_feature(mpam_feat_cpor_part, props); } @@ -1212,6 +1236,28 @@ static void mpam_reset_msc_bitmap(struct mpam_msc *msc, u16 reg, u16 wd) __mpam_write_reg(msc, reg, bm); } +static u32 mpam_cpbm_hisi_workaround(u32 cpbm, u8 cache_level) +{ + static const struct midr_range cpus[] = { + MIDR_ALL_VERSIONS(MIDR_HISI_HIP12), + { /* sentinel */ } + }; + + if (cache_level != 3 || + !is_midr_in_range_list(read_cpuid_id(), cpus)) + return cpbm; + + if (cpbm & BIT(18)) + cpbm |= (BIT(19) | BIT(20)); + + if (cpbm & BIT(17)) + cpbm |= BIT(18); + else + cpbm &= ~BIT(18); + + return cpbm; +} + static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid, struct mpam_config *cfg) { @@ -1232,10 +1278,15 @@ static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid, if (mpam_has_feature(mpam_feat_cpor_part, rprops)) { if (mpam_has_feature(mpam_feat_cpor_part, cfg)) - mpam_write_partsel_reg(msc, CPBM, cfg->cpbm); + mpam_write_partsel_reg(msc, CPBM, + mpam_cpbm_hisi_workaround(cfg->cpbm, + ris->comp->class->level)); else mpam_reset_msc_bitmap(msc, MPAMCFG_CPBM, - rprops->cpbm_wd); + mpam_cpbm_wd_hisi_workaround( + rprops->cpbm_wd, + mpam_feat_cpor_part, + ris->comp->class->level)); } if (mpam_has_feature(mpam_feat_ccap_part, rprops)) { diff --git a/drivers/platform/mpam/mpam_internal.h b/drivers/platform/mpam/mpam_internal.h index ff1890b3a78e..204005331334 100644 --- a/drivers/platform/mpam/mpam_internal.h +++ b/drivers/platform/mpam/mpam_internal.h @@ -328,6 +328,8 @@ int mpam_resctrl_offline_cpu(unsigned int cpu); int mpam_resctrl_setup(void); void mpam_resctrl_exit(void); +u16 mpam_cpbm_wd_hisi_workaround(u16 cpbm_wd, enum mpam_device_features feat, u8 cache_level); + /* * MPAM MSCs have the following register layout. See: * Arm Architecture Reference Manual Supplement - Memory System Resource diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c index 6540b84e0f14..34fcb03c1eeb 100644 --- a/drivers/platform/mpam/mpam_resctrl.c +++ b/drivers/platform/mpam/mpam_resctrl.c @@ -691,7 +691,9 @@ static u16 percent_to_ca_max(u32 pc, u8 wd) if (read_cpuid_implementor() != ARM_CPU_IMP_HISI) return percent_to_mbw_max(pc, wd); - valid_max = l3->cache.cbm_len; + valid_max = mpam_cpbm_wd_hisi_workaround(l3->cache.cbm_len, + mpam_feat_ccap_part, + l3->cache_level); if (pc >= MAX_MBA_BW) return valid_max << (16 - wd); @@ -707,7 +709,9 @@ static u16 ca_max_to_percent(u16 ca_max, u8 wd) if (read_cpuid_implementor() != ARM_CPU_IMP_HISI) return mbw_max_to_percent(ca_max, wd); - valid_max = l3->cache.cbm_len; + valid_max = mpam_cpbm_wd_hisi_workaround(l3->cache.cbm_len, + mpam_feat_ccap_part, + l3->cache_level); ca_max = ca_max >> (16 - wd); if (ca_max >= valid_max) -- 2.25.1
2 1
0 0
[openeuler:OLK-5.10 3207/3207] include/linux/compiler_types.h:323:38: error: call to '__compiletime_assert_183' declared with attribute error: BUILD_BUG failed
by kernel test robot 23 Sep '25

23 Sep '25
Hi Marc, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 3838d60c6f0bda86f712fbcee935bfb42e07b8bb commit: 611b93b7366a1e0c9df51c4628ea51bfe6db74d9 [3207/3207] clocksource/arm_arch_timer: Add build-time guards for unhandled register accesses config: arm64-randconfig-003-20250923 (https://download.01.org/0day-ci/archive/20250923/202509231925.VzrKhKii-lkp@…) compiler: aarch64-linux-gcc (GCC) 7.5.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250923/202509231925.VzrKhKii-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202509231925.VzrKhKii-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from <command-line>:0:0: In function 'arch_timer_reg_read_cp15', inlined from 'erratum_set_next_event_tval_generic' at drivers/clocksource/arm_arch_timer.c:157:7: >> include/linux/compiler_types.h:323:38: error: call to '__compiletime_assert_183' declared with attribute error: BUILD_BUG failed _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ include/linux/compiler_types.h:304:4: note: in definition of macro '__compiletime_assert' prefix ## suffix(); \ ^~~~~~ include/linux/compiler_types.h:323:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG' #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") ^~~~~~~~~~~~~~~~ arch/arm64/include/asm/arch_timer.h:159:2: note: in expansion of macro 'BUILD_BUG' BUILD_BUG(); ^~~~~~~~~ In function 'arch_timer_reg_write_cp15', inlined from 'erratum_set_next_event_tval_generic' at drivers/clocksource/arm_arch_timer.c:122:3: include/linux/compiler_types.h:323:38: error: call to '__compiletime_assert_180' declared with attribute error: BUILD_BUG failed _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ include/linux/compiler_types.h:304:4: note: in definition of macro '__compiletime_assert' prefix ## suffix(); \ ^~~~~~ include/linux/compiler_types.h:323:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG' #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") ^~~~~~~~~~~~~~~~ arch/arm64/include/asm/arch_timer.h:130:3: note: in expansion of macro 'BUILD_BUG' BUILD_BUG(); ^~~~~~~~~ vim +/__compiletime_assert_183 +323 include/linux/compiler_types.h eb5c2d4b45e3d2d Will Deacon 2020-07-21 309 eb5c2d4b45e3d2d Will Deacon 2020-07-21 310 #define _compiletime_assert(condition, msg, prefix, suffix) \ eb5c2d4b45e3d2d Will Deacon 2020-07-21 311 __compiletime_assert(condition, msg, prefix, suffix) eb5c2d4b45e3d2d Will Deacon 2020-07-21 312 eb5c2d4b45e3d2d Will Deacon 2020-07-21 313 /** eb5c2d4b45e3d2d Will Deacon 2020-07-21 314 * compiletime_assert - break build and emit msg if condition is false eb5c2d4b45e3d2d Will Deacon 2020-07-21 315 * @condition: a compile-time constant condition to check eb5c2d4b45e3d2d Will Deacon 2020-07-21 316 * @msg: a message to emit if condition is false eb5c2d4b45e3d2d Will Deacon 2020-07-21 317 * eb5c2d4b45e3d2d Will Deacon 2020-07-21 318 * In tradition of POSIX assert, this macro will break the build if the eb5c2d4b45e3d2d Will Deacon 2020-07-21 319 * supplied condition is *false*, emitting the supplied error message if the eb5c2d4b45e3d2d Will Deacon 2020-07-21 320 * compiler has support to do so. eb5c2d4b45e3d2d Will Deacon 2020-07-21 321 */ eb5c2d4b45e3d2d Will Deacon 2020-07-21 322 #define compiletime_assert(condition, msg) \ eb5c2d4b45e3d2d Will Deacon 2020-07-21 @323 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) eb5c2d4b45e3d2d Will Deacon 2020-07-21 324 :::::: The code at line 323 was first introduced by commit :::::: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move compiletime_assert() macros into compiler_types.h :::::: TO: Will Deacon <will(a)kernel.org> :::::: CC: Will Deacon <will(a)kernel.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH OLK-5.10] nfsd: call op_release, even when op_func returns an error
by Li Lingfeng 23 Sep '25

23 Sep '25
From: Jeff Layton <jlayton(a)kernel.org> mainline inclusion from mainline-v6.3-rc6 commit 15a8b55dbb1ba154d82627547c5761cac884d810 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICY4HQ CVE: CVE-2023-53241 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- For ops with "trivial" replies, nfsd4_encode_operation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time. Have the compound processing engine always call op_release, even when op_func sets an error in op->status. With this change, we also need nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL on error to avoid a double free. Reported-by: Zhi Li <yieli(a)redhat.com> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2181403 Fixes: 34b1744c91cc ("nfsd4: define ->op_release for compound ops") Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Conflicts: fs/nfsd/blocklayout.c fs/nfsd/nfs4xdr.c [Commit 8c6aabd1c72b ("nfsd/blocklayout: use ->get_unique_id instead of sending SCSI commands") free pnfs_block_deviceaddr in the error path of nfsd4_block_get_device_info_scsi; commit 08281341be8e ("NFSD: Add tracepoints in nfsd4_decode/encode_compound()") add trace_nfsd_compound_encode_err in nfsd4_encode_operation.] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4xdr.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index 1c11042dafb8..31d56546021b 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -5183,10 +5183,8 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) __be32 *p; p = xdr_reserve_space(xdr, 8); - if (!p) { - WARN_ON_ONCE(1); - return; - } + if (!p) + goto release; *p++ = cpu_to_be32(op->opnum); post_err_offset = xdr->buf->len; @@ -5199,8 +5197,6 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) !nfsd4_enc_ops[op->opnum]); encoder = nfsd4_enc_ops[op->opnum]; op->status = encoder(resp, op->status, &op->u); - if (opdesc && opdesc->op_release) - opdesc->op_release(&op->u); xdr_commit_encode(xdr); /* nfsd4_check_resp_size guarantees enough room for error status */ @@ -5242,6 +5238,9 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) status: /* Note that op->status is already in network byte order: */ write_bytes_to_xdr_buf(xdr->buf, post_err_offset - 4, &op->status, 4); +release: + if (opdesc && opdesc->op_release) + opdesc->op_release(&op->u); } /* -- 2.46.1
2 1
0 0
[PATCH openEuler-1.0-LTS] nfsd: call op_release, even when op_func returns an error
by Li Lingfeng 23 Sep '25

23 Sep '25
From: Jeff Layton <jlayton(a)kernel.org> mainline inclusion from mainline-v6.3-rc6 commit 15a8b55dbb1ba154d82627547c5761cac884d810 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICY4HQ CVE: CVE-2023-53241 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- For ops with "trivial" replies, nfsd4_encode_operation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time. Have the compound processing engine always call op_release, even when op_func sets an error in op->status. With this change, we also need nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL on error to avoid a double free. Reported-by: Zhi Li <yieli(a)redhat.com> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2181403 Fixes: 34b1744c91cc ("nfsd4: define ->op_release for compound ops") Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Conflicts: fs/nfsd/blocklayout.c fs/nfsd/nfs4xdr.c [Commit 8c6aabd1c72b ("nfsd/blocklayout: use ->get_unique_id instead of sending SCSI commands") free pnfs_block_deviceaddr in the error path of nfsd4_block_get_device_info_scsi; commit 08281341be8e ("NFSD: Add tracepoints in nfsd4_decode/encode_compound()") add trace_nfsd_compound_encode_err in nfsd4_encode_operation.] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4xdr.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index db0beefe65ec..645a3d4807b8 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -4411,10 +4411,8 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) __be32 *p; p = xdr_reserve_space(xdr, 8); - if (!p) { - WARN_ON_ONCE(1); - return; - } + if (!p) + goto release; *p++ = cpu_to_be32(op->opnum); post_err_offset = xdr->buf->len; @@ -4427,8 +4425,6 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) !nfsd4_enc_ops[op->opnum]); encoder = nfsd4_enc_ops[op->opnum]; op->status = encoder(resp, op->status, &op->u); - if (opdesc && opdesc->op_release) - opdesc->op_release(&op->u); xdr_commit_encode(xdr); /* nfsd4_check_resp_size guarantees enough room for error status */ @@ -4470,6 +4466,9 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) status: /* Note that op->status is already in network byte order: */ write_bytes_to_xdr_buf(xdr->buf, post_err_offset - 4, &op->status, 4); +release: + if (opdesc && opdesc->op_release) + opdesc->op_release(&op->u); } /* -- 2.31.1
2 1
0 0
[PATCH openEuler-1.0-LTS] mm: vmscan: enable shrink_page_cache_work limit
by Wupeng Ma 23 Sep '25

23 Sep '25
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- Commit 92cd2e7fa82d ("mm:vmscan: add the missing check of page_cache_over_limit") add limit check for shrink_page_cache_work to stop page cache below limit. However this limit is only checked iff memory reliable is enable, since page cache limit can be enabled without memory reliable. Enable this limit check in all scenarios. Fixes: 92cd2e7fa82d ("mm:vmscan: add the missing check of page_cache_over_limit") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- mm/vmscan.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 6a649f02666f..fa08ffd043de 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4060,8 +4060,7 @@ static void shrink_page_cache_work(struct work_struct *w) if (vm_cache_reclaim_s == 0 || !vm_cache_reclaim_enable) return; - if (mem_reliable_is_enabled() && - (!vm_cache_limit_mbytes || !page_cache_over_limit())) + if (!vm_cache_limit_mbytes || !page_cache_over_limit()) return; /* It should wait more time if we hardly reclaim the page cache */ -- 2.43.0
2 1
0 0
[PATCH openEuler-1.0-LTS] mm: vmscan: enable shrink_page_cache_work limit
by Wupeng Ma 23 Sep '25

23 Sep '25
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- Commit 92cd2e7fa82d ("mm:vmscan: add the missing check of page_cache_over_limit") add limit check for shrink_page_cache_work to stop page cache below limit. However this limit is only checked iff memory reliable is enable, since page cache limit can be enabled without memory reliable. Enable this limit check in all scenarios. Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- mm/vmscan.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 6a649f02666f..fa08ffd043de 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4060,8 +4060,7 @@ static void shrink_page_cache_work(struct work_struct *w) if (vm_cache_reclaim_s == 0 || !vm_cache_reclaim_enable) return; - if (mem_reliable_is_enabled() && - (!vm_cache_limit_mbytes || !page_cache_over_limit())) + if (!vm_cache_limit_mbytes || !page_cache_over_limit()) return; /* It should wait more time if we hardly reclaim the page cache */ -- 2.43.0
2 1
0 0
[openeuler:OLK-6.6 2909/2909] drivers/gpu/drm/phytium/phytium_gem.c:174:5: sparse: sparse: symbol 'phytium_gem_prime_mmap' was not declared. Should it be static?
by kernel test robot 23 Sep '25

23 Sep '25
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: be758a5796c3d280deb877699c41fd0cd04e1deb commit: 3b4a5906fa714bdc9a15fc04374942888737eb4c [2909/2909] drm/phytium: Fix Phytium DRM build fail config: arm64-randconfig-r121-20250923 (https://download.01.org/0day-ci/archive/20250923/202509231756.bOMWC43K-lkp@…) compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project 7cbf1a2591520c2491aa35339f227775f4d3adf6) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250923/202509231756.bOMWC43K-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202509231756.bOMWC43K-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/phytium/phytium_gem.c: note: in included file (through arch/arm64/include/asm/cpufeature.h, arch/arm64/include/asm/ptrace.h, arch/arm64/include/asm/irqflags.h, ...): arch/arm64/include/asm/cputype.h:163:9: sparse: sparse: preprocessor token PHYTIUM_CPU_PART_FTC862 redefined arch/arm64/include/asm/cputype.h:110:9: sparse: this was the original definition drivers/gpu/drm/phytium/phytium_gem.c:22:5: sparse: sparse: symbol 'phytium_memory_pool_alloc' was not declared. Should it be static? drivers/gpu/drm/phytium/phytium_gem.c:37:6: sparse: sparse: symbol 'phytium_memory_pool_free' was not declared. Should it be static? drivers/gpu/drm/phytium/phytium_gem.c:161:5: sparse: sparse: symbol 'phytium_gem_prime_vmap' was not declared. Should it be static? drivers/gpu/drm/phytium/phytium_gem.c:170:6: sparse: sparse: symbol 'phytium_gem_prime_vunmap' was not declared. Should it be static? >> drivers/gpu/drm/phytium/phytium_gem.c:174:5: sparse: sparse: symbol 'phytium_gem_prime_mmap' was not declared. Should it be static? drivers/gpu/drm/phytium/phytium_gem.c:186:5: sparse: sparse: symbol 'phytium_dma_transfer' was not declared. Should it be static? vim +/phytium_gem_prime_mmap +174 drivers/gpu/drm/phytium/phytium_gem.c b80df10f845813 lishuo 2024-01-31 21 b80df10f845813 lishuo 2024-01-31 @22 int phytium_memory_pool_alloc(struct phytium_display_private *priv, void **pvaddr, b80df10f845813 lishuo 2024-01-31 23 phys_addr_t *phys_addr, uint64_t size) b80df10f845813 lishuo 2024-01-31 24 { b80df10f845813 lishuo 2024-01-31 25 unsigned long vaddr; b80df10f845813 lishuo 2024-01-31 26 b80df10f845813 lishuo 2024-01-31 27 vaddr = gen_pool_alloc(priv->memory_pool, size); b80df10f845813 lishuo 2024-01-31 28 if (!vaddr) b80df10f845813 lishuo 2024-01-31 29 return -ENOMEM; b80df10f845813 lishuo 2024-01-31 30 b80df10f845813 lishuo 2024-01-31 31 *phys_addr = gen_pool_virt_to_phys(priv->memory_pool, vaddr); b80df10f845813 lishuo 2024-01-31 32 b80df10f845813 lishuo 2024-01-31 33 *pvaddr = (void *)vaddr; b80df10f845813 lishuo 2024-01-31 34 return 0; b80df10f845813 lishuo 2024-01-31 35 } b80df10f845813 lishuo 2024-01-31 36 b80df10f845813 lishuo 2024-01-31 37 void phytium_memory_pool_free(struct phytium_display_private *priv, void *vaddr, uint64_t size) b80df10f845813 lishuo 2024-01-31 38 { b80df10f845813 lishuo 2024-01-31 39 gen_pool_free(priv->memory_pool, (unsigned long)vaddr, size); b80df10f845813 lishuo 2024-01-31 40 } b80df10f845813 lishuo 2024-01-31 41 b80df10f845813 lishuo 2024-01-31 42 int phytium_memory_pool_init(struct device *dev, struct phytium_display_private *priv) b80df10f845813 lishuo 2024-01-31 43 { b80df10f845813 lishuo 2024-01-31 44 int ret = 0; b80df10f845813 lishuo 2024-01-31 45 b80df10f845813 lishuo 2024-01-31 46 priv->memory_pool = gen_pool_create(VRAM_POOL_ALLOC_ORDER, -1); b80df10f845813 lishuo 2024-01-31 47 if (priv->memory_pool == NULL) { b80df10f845813 lishuo 2024-01-31 48 DRM_ERROR("fail to create memory pool\n"); b80df10f845813 lishuo 2024-01-31 49 ret = -1; b80df10f845813 lishuo 2024-01-31 50 goto failed_create_pool; b80df10f845813 lishuo 2024-01-31 51 } b80df10f845813 lishuo 2024-01-31 52 b80df10f845813 lishuo 2024-01-31 53 ret = gen_pool_add_virt(priv->memory_pool, (unsigned long)priv->pool_virt_addr, b80df10f845813 lishuo 2024-01-31 54 priv->pool_phys_addr, priv->pool_size, -1); b80df10f845813 lishuo 2024-01-31 55 if (ret) { b80df10f845813 lishuo 2024-01-31 56 DRM_ERROR("fail to add vram pool\n"); b80df10f845813 lishuo 2024-01-31 57 ret = -1; b80df10f845813 lishuo 2024-01-31 58 goto failed_add_pool_virt; b80df10f845813 lishuo 2024-01-31 59 } b80df10f845813 lishuo 2024-01-31 60 b80df10f845813 lishuo 2024-01-31 61 return 0; b80df10f845813 lishuo 2024-01-31 62 b80df10f845813 lishuo 2024-01-31 63 failed_add_pool_virt: b80df10f845813 lishuo 2024-01-31 64 gen_pool_destroy(priv->memory_pool); b80df10f845813 lishuo 2024-01-31 65 b80df10f845813 lishuo 2024-01-31 66 failed_create_pool: b80df10f845813 lishuo 2024-01-31 67 return ret; b80df10f845813 lishuo 2024-01-31 68 } b80df10f845813 lishuo 2024-01-31 69 b80df10f845813 lishuo 2024-01-31 70 void phytium_memory_pool_fini(struct device *dev, struct phytium_display_private *priv) b80df10f845813 lishuo 2024-01-31 71 { b80df10f845813 lishuo 2024-01-31 72 gen_pool_destroy(priv->memory_pool); b80df10f845813 lishuo 2024-01-31 73 } b80df10f845813 lishuo 2024-01-31 74 b80df10f845813 lishuo 2024-01-31 75 struct sg_table * b80df10f845813 lishuo 2024-01-31 76 phytium_gem_prime_get_sg_table(struct drm_gem_object *obj) b80df10f845813 lishuo 2024-01-31 77 { b80df10f845813 lishuo 2024-01-31 78 struct phytium_gem_object *phytium_gem_obj = to_phytium_gem_obj(obj); b80df10f845813 lishuo 2024-01-31 79 struct sg_table *sgt; b80df10f845813 lishuo 2024-01-31 80 struct drm_device *dev = obj->dev; b80df10f845813 lishuo 2024-01-31 81 int ret; b80df10f845813 lishuo 2024-01-31 82 struct page *page = NULL; b80df10f845813 lishuo 2024-01-31 83 b80df10f845813 lishuo 2024-01-31 84 sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); b80df10f845813 lishuo 2024-01-31 85 if (!sgt) { b80df10f845813 lishuo 2024-01-31 86 DRM_DEBUG_KMS("malloc sgt fail\n"); b80df10f845813 lishuo 2024-01-31 87 return ERR_PTR(-ENOMEM); b80df10f845813 lishuo 2024-01-31 88 } b80df10f845813 lishuo 2024-01-31 89 8c04aa95ffa8ae Jiakun Shuai 2024-05-20 90 if ((phytium_gem_obj->memory_type == MEMORY_TYPE_VRAM_WC) || 8c04aa95ffa8ae Jiakun Shuai 2024-05-20 91 (phytium_gem_obj->memory_type == MEMORY_TYPE_VRAM_DEVICE) || b80df10f845813 lishuo 2024-01-31 92 (phytium_gem_obj->memory_type == MEMORY_TYPE_SYSTEM_CARVEOUT)) { b80df10f845813 lishuo 2024-01-31 93 ret = sg_alloc_table(sgt, 1, GFP_KERNEL); b80df10f845813 lishuo 2024-01-31 94 if (ret) { b80df10f845813 lishuo 2024-01-31 95 DRM_ERROR("failed to allocate sg\n"); b80df10f845813 lishuo 2024-01-31 96 goto sgt_free; b80df10f845813 lishuo 2024-01-31 97 } e2cdf30a3e12bb XuYan 2025-04-09 98 page = pfn_to_page(__phys_to_pfn(phytium_gem_obj->phys_addr)); b80df10f845813 lishuo 2024-01-31 99 sg_set_page(sgt->sgl, page, PAGE_ALIGN(phytium_gem_obj->size), 0); b80df10f845813 lishuo 2024-01-31 100 } else if (phytium_gem_obj->memory_type == MEMORY_TYPE_SYSTEM_UNIFIED) { b80df10f845813 lishuo 2024-01-31 101 ret = dma_get_sgtable_attrs(dev->dev, sgt, phytium_gem_obj->vaddr, b80df10f845813 lishuo 2024-01-31 102 phytium_gem_obj->iova, phytium_gem_obj->size, b80df10f845813 lishuo 2024-01-31 103 DMA_ATTR_WRITE_COMBINE); b80df10f845813 lishuo 2024-01-31 104 if (ret) { b80df10f845813 lishuo 2024-01-31 105 DRM_ERROR("failed to allocate sgt, %d\n", ret); b80df10f845813 lishuo 2024-01-31 106 goto sgt_free; b80df10f845813 lishuo 2024-01-31 107 } b80df10f845813 lishuo 2024-01-31 108 } b80df10f845813 lishuo 2024-01-31 109 b80df10f845813 lishuo 2024-01-31 110 return sgt; b80df10f845813 lishuo 2024-01-31 111 sgt_free: b80df10f845813 lishuo 2024-01-31 112 kfree(sgt); b80df10f845813 lishuo 2024-01-31 113 return ERR_PTR(ret); b80df10f845813 lishuo 2024-01-31 114 } b80df10f845813 lishuo 2024-01-31 115 b80df10f845813 lishuo 2024-01-31 116 struct drm_gem_object * b80df10f845813 lishuo 2024-01-31 117 phytium_gem_prime_import_sg_table(struct drm_device *dev, b80df10f845813 lishuo 2024-01-31 118 struct dma_buf_attachment *attach, b80df10f845813 lishuo 2024-01-31 119 struct sg_table *sgt) b80df10f845813 lishuo 2024-01-31 120 { b80df10f845813 lishuo 2024-01-31 121 struct phytium_gem_object *phytium_gem_obj = NULL; b80df10f845813 lishuo 2024-01-31 122 struct scatterlist *s; b80df10f845813 lishuo 2024-01-31 123 dma_addr_t expected; b80df10f845813 lishuo 2024-01-31 124 int ret, i; b80df10f845813 lishuo 2024-01-31 125 b80df10f845813 lishuo 2024-01-31 126 phytium_gem_obj = kzalloc(sizeof(*phytium_gem_obj), GFP_KERNEL); b80df10f845813 lishuo 2024-01-31 127 if (!phytium_gem_obj) { b80df10f845813 lishuo 2024-01-31 128 DRM_ERROR("failed to allocate phytium_gem_obj\n"); b80df10f845813 lishuo 2024-01-31 129 ret = -ENOMEM; b80df10f845813 lishuo 2024-01-31 130 goto failed_malloc; b80df10f845813 lishuo 2024-01-31 131 } b80df10f845813 lishuo 2024-01-31 132 b80df10f845813 lishuo 2024-01-31 133 ret = drm_gem_object_init(dev, &phytium_gem_obj->base, attach->dmabuf->size); b80df10f845813 lishuo 2024-01-31 134 if (ret) { b80df10f845813 lishuo 2024-01-31 135 DRM_ERROR("failed to initialize drm gem object: %d\n", ret); b80df10f845813 lishuo 2024-01-31 136 goto failed_object_init; b80df10f845813 lishuo 2024-01-31 137 } b80df10f845813 lishuo 2024-01-31 138 b80df10f845813 lishuo 2024-01-31 139 expected = sg_dma_address(sgt->sgl); b80df10f845813 lishuo 2024-01-31 140 for_each_sg(sgt->sgl, s, sgt->nents, i) { b80df10f845813 lishuo 2024-01-31 141 if (sg_dma_address(s) != expected) { b80df10f845813 lishuo 2024-01-31 142 DRM_ERROR("sg_table is not contiguous"); b80df10f845813 lishuo 2024-01-31 143 ret = -EINVAL; b80df10f845813 lishuo 2024-01-31 144 goto failed_check_continue; b80df10f845813 lishuo 2024-01-31 145 } b80df10f845813 lishuo 2024-01-31 146 expected = sg_dma_address(s) + sg_dma_len(s); b80df10f845813 lishuo 2024-01-31 147 } b80df10f845813 lishuo 2024-01-31 148 b80df10f845813 lishuo 2024-01-31 149 phytium_gem_obj->iova = sg_dma_address(sgt->sgl); b80df10f845813 lishuo 2024-01-31 150 phytium_gem_obj->sgt = sgt; b80df10f845813 lishuo 2024-01-31 151 b80df10f845813 lishuo 2024-01-31 152 return &phytium_gem_obj->base; b80df10f845813 lishuo 2024-01-31 153 failed_check_continue: b80df10f845813 lishuo 2024-01-31 154 drm_gem_object_release(&phytium_gem_obj->base); b80df10f845813 lishuo 2024-01-31 155 failed_object_init: b80df10f845813 lishuo 2024-01-31 156 kfree(phytium_gem_obj); b80df10f845813 lishuo 2024-01-31 157 failed_malloc: b80df10f845813 lishuo 2024-01-31 158 return ERR_PTR(ret); b80df10f845813 lishuo 2024-01-31 159 } b80df10f845813 lishuo 2024-01-31 160 b80df10f845813 lishuo 2024-01-31 161 int phytium_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map) b80df10f845813 lishuo 2024-01-31 162 { b80df10f845813 lishuo 2024-01-31 163 struct phytium_gem_object *phytium_obj = to_phytium_gem_obj(obj); b80df10f845813 lishuo 2024-01-31 164 b80df10f845813 lishuo 2024-01-31 165 iosys_map_set_vaddr(map, phytium_obj->vaddr); b80df10f845813 lishuo 2024-01-31 166 b80df10f845813 lishuo 2024-01-31 167 return 0; b80df10f845813 lishuo 2024-01-31 168 } b80df10f845813 lishuo 2024-01-31 169 b80df10f845813 lishuo 2024-01-31 170 void phytium_gem_prime_vunmap(struct drm_gem_object *obj, struct iosys_map *map) b80df10f845813 lishuo 2024-01-31 171 { e2cdf30a3e12bb XuYan 2025-04-09 172 } b80df10f845813 lishuo 2024-01-31 173 e2cdf30a3e12bb XuYan 2025-04-09 @174 int phytium_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) e2cdf30a3e12bb XuYan 2025-04-09 175 { e2cdf30a3e12bb XuYan 2025-04-09 176 return phytium_gem_mmap_obj(obj, vma); b80df10f845813 lishuo 2024-01-31 177 } b80df10f845813 lishuo 2024-01-31 178 :::::: The code at line 174 was first introduced by commit :::::: e2cdf30a3e12bb55e76d60e99c0abd7db2917b5c drm/phytium: Fix some Bugs in Phytium Display Engine :::::: TO: XuYan <xuyan1481(a)phytium.com.cn> :::::: CC: xuyan <xuyan1481(a)phytium.com.cn> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • ...
  • 2127
  • Older →

HyperKitty Powered by HyperKitty