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 -----
  • 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

  • 43 participants
  • 18198 discussions
[PATCH OLK-6.6] drivers/perf: hisi: Enable HiSilicon Erratum 162400501 quirk
by Yushan Wang 03 Dec '24

03 Dec '24
From: Junhao He <hejunhao3(a)huawei.com> driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IB7ONX CVE: NA ---------------------------------------------------------------------- On HiSilicon HIP10C platform, the DDRC PMU interrupt registers offset is modified, causing the interrupt handler to fail to properly handle counter overflows. This patch tries to fix this by correcting the HIP10C platform DDRC PMU interrupt registers offset (including mask/status/clear registers). Signed-off-by: Junhao He <hejunhao3(a)huawei.com> Signed-off-by: Qizhi Zhang <zhangqizhi3(a)h-partners.com> Signed-off-by: Yushan Wang <wangyushan12(a)huawei.com> --- drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 70 +++++++++++++++++-- drivers/perf/hisilicon/hisi_uncore_pmu.h | 1 + 2 files changed, 65 insertions(+), 6 deletions(-) diff --git a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c index ee020669d134..816770ace86f 100644 --- a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c +++ b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c @@ -43,6 +43,16 @@ #define DDRC_V2_EVENT_TYPE 0xe74 #define DDRC_V2_PERF_CTRL 0xeA0 +/* + * HIP10C platform v2 PMU DDRC interrupt registers definition + * On HIP10C platform, the DDRC PMU interrupt register offset is + * modified, causing the interrupt handler to fail to properly + * handle counter overflows. + */ +#define DDRC_V2_HIP10C_INT_MASK 0x534 +#define DDRC_V2_HIP10C_INT_STATUS 0x538 +#define DDRC_V2_HIP10C_INT_CLEAR 0x53C + /* DDRC has 8-counters */ #define DDRC_NR_COUNTERS 0x8 #define DDRC_V1_PERF_CTRL_EN 0x2 @@ -58,11 +68,39 @@ */ #define GET_DDRC_EVENTID(hwc) (hwc->config_base & 0x7) +#define HISI_DDRC_PMU_NORMAL_PMU 0x0 /* HiSilicon normal PMU */ +#define HISI_DDRC_PMU_INCORRECT_INT_REGS BIT(0) /* HiSilicon HIP10C PMU */ + static const u32 ddrc_reg_off[] = { DDRC_FLUX_WR, DDRC_FLUX_RD, DDRC_FLUX_WCMD, DDRC_FLUX_RCMD, DDRC_PRE_CMD, DDRC_ACT_CMD, DDRC_RNK_CHG, DDRC_RW_CHG }; +static struct acpi_platform_list hisi_uncore_plat_info[] = { + /* HiSilicon Hip10C Platform */ + {"HISI ", "HIP10C ", 0, ACPI_SIG_DSDT, greater_than_or_equal, + "Erratum #162400501", HISI_DDRC_PMU_INCORRECT_INT_REGS}, + { } +}; + +static void hisi_ddrc_pmu_check_errata(struct platform_device *pdev, struct hisi_pmu *ddrc_pmu) +{ + int idx; + + idx = acpi_match_platform_list(hisi_uncore_plat_info); + if (idx >= 0) + ddrc_pmu->errata = hisi_uncore_plat_info[idx].data; + else + ddrc_pmu->errata = HISI_DDRC_PMU_NORMAL_PMU; + + dev_dbg(ddrc_pmu->dev, "errata mask %#x\n", ddrc_pmu->errata); +} + +static bool hisi_ddrc_pmu_has_erratum(struct hisi_pmu *ddrc_pmu, u32 erratum) +{ + return !!(ddrc_pmu->errata & erratum); +} + /* * Select the counter register offset using the counter index. * In PMU v1, there are no programmable counter, the count @@ -248,21 +286,29 @@ static void hisi_ddrc_pmu_v1_disable_counter_int(struct hisi_pmu *ddrc_pmu, static void hisi_ddrc_pmu_v2_enable_counter_int(struct hisi_pmu *ddrc_pmu, struct hw_perf_event *hwc) { + u32 int_mask = DDRC_V2_INT_MASK; u32 val; - val = readl(ddrc_pmu->base + DDRC_V2_INT_MASK); + if (hisi_ddrc_pmu_has_erratum(ddrc_pmu, HISI_DDRC_PMU_INCORRECT_INT_REGS)) + int_mask = DDRC_V2_HIP10C_INT_MASK; + + val = readl(ddrc_pmu->base + int_mask); val &= ~(1 << hwc->idx); - writel(val, ddrc_pmu->base + DDRC_V2_INT_MASK); + writel(val, ddrc_pmu->base + int_mask); } static void hisi_ddrc_pmu_v2_disable_counter_int(struct hisi_pmu *ddrc_pmu, struct hw_perf_event *hwc) { + u32 int_mask = DDRC_V2_INT_MASK; u32 val; - val = readl(ddrc_pmu->base + DDRC_V2_INT_MASK); + if (hisi_ddrc_pmu_has_erratum(ddrc_pmu, HISI_DDRC_PMU_INCORRECT_INT_REGS)) + int_mask = DDRC_V2_HIP10C_INT_MASK; + + val = readl(ddrc_pmu->base + int_mask); val |= 1 << hwc->idx; - writel(val, ddrc_pmu->base + DDRC_V2_INT_MASK); + writel(val, ddrc_pmu->base + int_mask); } static u32 hisi_ddrc_pmu_v1_get_int_status(struct hisi_pmu *ddrc_pmu) @@ -278,13 +324,23 @@ static void hisi_ddrc_pmu_v1_clear_int_status(struct hisi_pmu *ddrc_pmu, static u32 hisi_ddrc_pmu_v2_get_int_status(struct hisi_pmu *ddrc_pmu) { - return readl(ddrc_pmu->base + DDRC_V2_INT_STATUS); + u32 int_status = DDRC_V2_INT_STATUS; + + if (hisi_ddrc_pmu_has_erratum(ddrc_pmu, HISI_DDRC_PMU_INCORRECT_INT_REGS)) + int_status = DDRC_V2_HIP10C_INT_STATUS; + + return readl(ddrc_pmu->base + int_status); } static void hisi_ddrc_pmu_v2_clear_int_status(struct hisi_pmu *ddrc_pmu, int idx) { - writel(1 << idx, ddrc_pmu->base + DDRC_V2_INT_CLEAR); + u32 int_clear = DDRC_V2_INT_CLEAR; + + if (hisi_ddrc_pmu_has_erratum(ddrc_pmu, HISI_DDRC_PMU_INCORRECT_INT_REGS)) + int_clear = DDRC_V2_HIP10C_INT_CLEAR; + + writel(1 << idx, ddrc_pmu->base + int_clear); } static const struct acpi_device_id hisi_ddrc_pmu_acpi_match[] = { @@ -464,6 +520,8 @@ static int hisi_ddrc_pmu_dev_probe(struct platform_device *pdev, if (ret) return ret; + hisi_ddrc_pmu_check_errata(pdev, ddrc_pmu); + if (ddrc_pmu->identifier >= HISI_PMU_V2) { ddrc_pmu->counter_bits = 48; ddrc_pmu->check_event = DDRC_V2_NR_EVENTS; diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.h b/drivers/perf/hisilicon/hisi_uncore_pmu.h index 9cf06c80acf4..eeacf2e89568 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pmu.h +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.h @@ -107,6 +107,7 @@ struct hisi_pmu { /* check event code range */ int check_event; u32 identifier; + u32 errata; }; int hisi_uncore_pmu_get_event_idx(struct perf_event *event); -- 2.33.0
2 1
0 0
[openeuler:OLK-6.6 1577/1577] drivers/ata/libahci.c:210:5: warning: no previous prototype for function 'get_ahci_em_messages'
by kernel test robot 03 Dec '24

03 Dec '24
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: d72146e885adc1fe1f656075dccd9344d0024041 commit: fb43492008c11fe89e510dd63383a2d37ea3cf8e [1577/1577] ata: ahci: Add support for AHCI SGPIO Enclosure Management config: x86_64-buildonly-randconfig-001-20241203 (https://download.01.org/0day-ci/archive/20241203/202412031924.l8eOZ6vd-lkp@…) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241203/202412031924.l8eOZ6vd-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/202412031924.l8eOZ6vd-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from drivers/ata/libahci.c:24: In file included from include/linux/blkdev.h:9: In file included from include/linux/blk_types.h:10: In file included from include/linux/bvec.h:10: In file included from include/linux/highmem.h:8: In file included from include/linux/cacheflush.h:5: In file included from arch/x86/include/asm/cacheflush.h:5: In file included from include/linux/mm.h:2235: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ >> drivers/ata/libahci.c:210:5: warning: no previous prototype for function 'get_ahci_em_messages' [-Wmissing-prototypes] 210 | int get_ahci_em_messages(void) | ^ drivers/ata/libahci.c:210:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 210 | int get_ahci_em_messages(void) | ^ | static 6 warnings generated. vim +/get_ahci_em_messages +210 drivers/ata/libahci.c 209 > 210 int get_ahci_em_messages(void) 211 { 212 return ahci_em_messages; 213 } 214 EXPORT_SYMBOL_GPL(get_ahci_em_messages); 215 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-5.10 2516/2516] drivers/ub/urma/uburma/uburma_cmd.c:144:6: warning: no previous prototype for 'uburma_jfc_event_cb'
by kernel test robot 03 Dec '24

03 Dec '24
Hi Yizhen, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: f030ffc8e0c6dac3503bebddbf49cc339003fcdb commit: c4cd0655c0c898569c0a70162f36258fd5c50eeb [2516/2516] ub: uburma add cmd create jfc implementation. config: arm64-randconfig-003-20241203 (https://download.01.org/0day-ci/archive/20241203/202412031918.JBUCfUTV-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241203/202412031918.JBUCfUTV-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/202412031918.JBUCfUTV-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/ub/urma/uburma/uburma_cmd.c:144:6: warning: no previous prototype for 'uburma_jfc_event_cb' [-Wmissing-prototypes] 144 | void uburma_jfc_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/urma/uburma/uburma_cmd.c:156:6: warning: no previous prototype for 'uburma_jfs_event_cb' [-Wmissing-prototypes] 156 | void uburma_jfs_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/urma/uburma/uburma_cmd.c:168:6: warning: no previous prototype for 'uburma_jfr_event_cb' [-Wmissing-prototypes] 168 | void uburma_jfr_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ vim +/uburma_jfc_event_cb +144 drivers/ub/urma/uburma/uburma_cmd.c 143 > 144 void uburma_jfc_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) 145 { 146 struct uburma_jfc_uobj *jfc_uobj; 147 148 if (event->element.jfc == NULL) 149 return; 150 151 jfc_uobj = (struct uburma_jfc_uobj *)event->element.jfc->jfc_cfg.jfc_context; 152 uburma_write_async_event(ctx, event->element.jfc->urma_jfc, event->event_type, 153 &jfc_uobj->async_event_list, &jfc_uobj->async_events_reported); 154 } 155 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH OLK-6.6] xfs: Fix data overflow in xfs_mod_fdblocks()
by Zizhi Wo 03 Dec '24

03 Dec '24
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB7V02 -------------------------------- If the xfs reserve block related ioctl takes a large input value, the input reserved size is still assigned to mp->m_resblks in xfs_reserve_blocks() even if the requested size is larger than the total free size in the filesystem. This is because the subsequent xfs_mod_fdblocks() will handle the adjustment. However, in the current code, xfs_mod_fdblocks() calculates mp->m_resblks - mp->m_resblks_avail and casts the result to a long long type, while both mp->m_resblks and mp->m_resblks_avail are of type unsigned long long. If the difference between these two values is very large, and the most significant bit (MSB) is set to 1 (indicating a large unsigned value), the result of the cast becomes a large negative value. This causes mp->m_fdblocks to be updated to a very large value. As a result, xfs will incorrectly determine that there is always free space during foreground writes, while background writebacks may fail due to lack of space. Modify the relevant data types in xfs_mod_fdblocks() to address this issue. Fixes: 0d485ada404b ("xfs: use generic percpu counters for free block counter") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/xfs/xfs_mount.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 78c72d0aa0a6..8f938db6bc6b 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -1151,7 +1151,7 @@ xfs_mod_freecounter( bool rsvd) { int64_t lcounter; - long long res_used; + uint64_t res_used; uint64_t set_aside = 0; s32 batch; bool has_resv_pool; @@ -1173,9 +1173,9 @@ xfs_mod_freecounter( } spin_lock(&mp->m_sb_lock); - res_used = (long long)(mp->m_resblks - mp->m_resblks_avail); + res_used = mp->m_resblks - mp->m_resblks_avail; - if (res_used > delta) { + if (res_used > (uint64_t)delta) { mp->m_resblks_avail += delta; } else { delta -= res_used; -- 2.46.1
2 1
0 0
[openeuler:OLK-5.10 2516/2516] fs/proc/base.c:1454:6: warning: no previous prototype for 'pbha_bit0_hide_file'
by kernel test robot 03 Dec '24

03 Dec '24
Hi Ma, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: f86196bf02fd9bea8511335c45bf10b6b0a3ea13 commit: bea38841945a52bd03004240eb0da6a5115bae21 [2516/2516] arm64: mm: Hide pbha_bit0 in procfs if pbha is not enabled config: arm64-randconfig-002-20241203 (https://download.01.org/0day-ci/archive/20241203/202412031640.QjUBley5-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241203/202412031640.QjUBley5-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/202412031640.QjUBley5-lkp@intel.com/ All warnings (new ones prefixed by >>): >> fs/proc/base.c:1454:6: warning: no previous prototype for 'pbha_bit0_hide_file' [-Wmissing-prototypes] 1454 | bool pbha_bit0_hide_file(const char *name) | ^~~~~~~~~~~~~~~~~~~ Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for HARDLOCKUP_DETECTOR Depends on [n]: DEBUG_KERNEL [=n] && !S390 && (HAVE_HARDLOCKUP_DETECTOR_PERF [=n] || HAVE_HARDLOCKUP_DETECTOR_ARCH [=y]) Selected by [y]: - SDEI_WATCHDOG [=y] && ARM64 [=y] && ARM_SDE_INTERFACE [=y] && !HARDLOCKUP_CHECK_TIMESTAMP [=n] WARNING: unmet direct dependencies detected for PGP_PRELOAD Depends on [n]: CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=n] Selected by [y]: - PGP_PRELOAD_PUBLIC_KEYS [=y] && CRYPTO [=y] vim +/pbha_bit0_hide_file +1454 fs/proc/base.c 1453 > 1454 bool pbha_bit0_hide_file(const char *name) 1455 { 1456 if (!system_support_pbha_bit0() && !strncmp("pbha_bit0", name, 9)) 1457 return true; 1458 1459 return false; 1460 } 1461 #else 1462 static bool pbha_bit0_hide_file(const char *name) { return false; } 1463 #endif 1464 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-5.10 2516/2516] drivers/ub/urma/uburma/uburma_cmd.c:156:6: warning: no previous prototype for 'uburma_jfr_event_cb'
by kernel test robot 03 Dec '24

03 Dec '24
Hi Yizhen, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 930fc4e0720aefe8131ce1113fc933a6a695f82e commit: 79b60243a9ff771b76add8e16cfe55cc4f5edef2 [2516/2516] ub: uburma add cmd create jfr implementation. config: arm64-randconfig-003-20241203 (https://download.01.org/0day-ci/archive/20241203/202412031613.U2IyZ3gY-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241203/202412031613.U2IyZ3gY-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/202412031613.U2IyZ3gY-lkp@intel.com/ All warnings (new ones prefixed by >>): drivers/ub/urma/uburma/uburma_cmd.c:144:6: warning: no previous prototype for 'uburma_jfs_event_cb' [-Wmissing-prototypes] 144 | void uburma_jfs_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/uburma/uburma_cmd.c:156:6: warning: no previous prototype for 'uburma_jfr_event_cb' [-Wmissing-prototypes] 156 | void uburma_jfr_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ vim +/uburma_jfr_event_cb +156 drivers/ub/urma/uburma/uburma_cmd.c 143 > 144 void uburma_jfs_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) 145 { 146 struct uburma_jfs_uobj *jfs_uobj; 147 148 if (event->element.jfs == NULL) 149 return; 150 151 jfs_uobj = (struct uburma_jfs_uobj *)event->element.jfs->jfs_cfg.jfs_context; 152 uburma_write_async_event(ctx, event->element.jfs->urma_jfs, event->event_type, 153 &jfs_uobj->async_event_list, &jfs_uobj->async_events_reported); 154 } 155 > 156 void uburma_jfr_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) 157 { 158 struct uburma_jfr_uobj *jfr_uobj; 159 160 if (event->element.jfr == NULL) 161 return; 162 163 jfr_uobj = (struct uburma_jfr_uobj *)event->element.jfr->jfr_cfg.jfr_context; 164 uburma_write_async_event(ctx, event->element.jfr->urma_jfr, event->event_type, 165 &jfr_uobj->async_event_list, &jfr_uobj->async_events_reported); 166 } 167 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH OLK-5.10] xfs: Fix data overflow in xfs_mod_fdblocks()
by Zizhi Wo 03 Dec '24

03 Dec '24
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB7V02 -------------------------------- If the xfs reserve block related ioctl takes a large input value, the input reserved size is still assigned to mp->m_resblks in xfs_reserve_blocks() even if the requested size is larger than the total free size in the filesystem. This is because the subsequent xfs_mod_fdblocks() will handle the adjustment. However, in the current code, xfs_mod_fdblocks() calculates mp->m_resblks - mp->m_resblks_avail and casts the result to a long long type, while both mp->m_resblks and mp->m_resblks_avail are of type unsigned long long. If the difference between these two values is very large, and the most significant bit (MSB) is set to 1 (indicating a large unsigned value), the result of the cast becomes a large negative value. This causes mp->m_fdblocks to be updated to a very large value. As a result, xfs will incorrectly determine that there is always free space during foreground writes, while background writebacks may fail due to lack of space. Modify the relevant data types in xfs_mod_fdblocks() to address this issue. Fixes: 0d485ada404b ("xfs: use generic percpu counters for free block counter") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/xfs/xfs_mount.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 04b347fe1b59..4983fe7eadf0 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -1259,8 +1259,8 @@ xfs_mod_fdblocks( bool rsvd) { int64_t lcounter; - long long res_used; s32 batch; + uint64_t res_used; uint64_t set_aside; if (delta > 0) { @@ -1274,7 +1274,7 @@ xfs_mod_fdblocks( } spin_lock(&mp->m_sb_lock); - res_used = (long long)(mp->m_resblks - mp->m_resblks_avail); + res_used = mp->m_resblks - mp->m_resblks_avail; if (res_used > delta) { mp->m_resblks_avail += delta; -- 2.46.1
2 1
0 0
[PATCH OLK-6.6 0/1] Backport fs optimizing patch from mainline
by Zheng Zengkai 03 Dec '24

03 Dec '24
64 bits in open_fds are mapped to a common bit in full_fds_bits. It is very likely that a bit in full_fds_bits has been cleared before in __clear_open_fds()'s operation. Check the clear bit in full_fds_bits before clearing to avoid unnecessary write and cache bouncing. See commit fc90888d07b8 ("vfs: conditionally clear close-on-exec flag") for a similar optimization. take stock kernel with patch 1 as baseline, it improves pts/blogbench-1.1.0 read for 13%, and write for 5% on Intel ICX 160 cores configuration with v6.10-rc7. Yu Ma (1): fs/file.c: conditionally clear full_fds fs/file.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.20.1
2 2
0 0
[PATCH openEuler-22.03-LTS-SP1] xfs: Fix data overflow in xfs_mod_fdblocks()
by Zizhi Wo 03 Dec '24

03 Dec '24
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB7V02 -------------------------------- If the xfs reserve block related ioctl takes a large input value, the input reserved size is still assigned to mp->m_resblks in xfs_reserve_blocks() even if the requested size is larger than the total free size in the filesystem. This is because the subsequent xfs_mod_fdblocks() will handle the adjustment. However, in the current code, xfs_mod_fdblocks() calculates mp->m_resblks - mp->m_resblks_avail and casts the result to a long long type, while both mp->m_resblks and mp->m_resblks_avail are of type unsigned long long. If the difference between these two values is very large, and the most significant bit (MSB) is set to 1 (indicating a large unsigned value), the result of the cast becomes a large negative value. This causes mp->m_fdblocks to be updated to a very large value. As a result, xfs will incorrectly determine that there is always free space during foreground writes, while background writebacks may fail due to lack of space. Modify the relevant data types in xfs_mod_fdblocks() to address this issue. Fixes: 0d485ada404b ("xfs: use generic percpu counters for free block counter") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/xfs/xfs_mount.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 04b347fe1b59..4983fe7eadf0 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -1259,8 +1259,8 @@ xfs_mod_fdblocks( bool rsvd) { int64_t lcounter; - long long res_used; s32 batch; + uint64_t res_used; uint64_t set_aside; if (delta > 0) { @@ -1274,7 +1274,7 @@ xfs_mod_fdblocks( } spin_lock(&mp->m_sb_lock); - res_used = (long long)(mp->m_resblks - mp->m_resblks_avail); + res_used = mp->m_resblks - mp->m_resblks_avail; if (res_used > delta) { mp->m_resblks_avail += delta; -- 2.46.1
2 1
0 0
[openeuler:OLK-5.10 2516/2516] kernel/sched/relationship.c:46:39: error: no member named 'mems_allowed' in 'struct task_struct'
by kernel test robot 03 Dec '24

03 Dec '24
tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: f86196bf02fd9bea8511335c45bf10b6b0a3ea13 commit: 2ac826b258e9aceefd719f7b0c3e3a9e73901ce5 [2516/2516] sched: Introduce task relationship by net and memory config: x86_64-randconfig-r063-20241203 (https://download.01.org/0day-ci/archive/20241203/202412031643.JKJ5FFhF-lkp@…) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241203/202412031643.JKJ5FFhF-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/202412031643.JKJ5FFhF-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from kernel/sched/relationship.c:19: In file included from include/linux/bpf_sched.h:5: In file included from include/linux/bpf.h:21: In file included from include/linux/kallsyms.h:12: In file included from include/linux/mm.h:1581: include/linux/vmstat.h:417:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 417 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 418 | item]; | ~~~~ include/linux/vmstat.h:424:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 424 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 425 | NR_VM_NUMA_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:431:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 431 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:436:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 436 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 437 | NR_VM_NUMA_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:445:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 445 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 446 | NR_VM_NUMA_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ In file included from kernel/sched/relationship.c:22: kernel/sched/sched.h:1838:15: warning: cast from 'void (*)(struct rq *)' to 'void (*)(struct callback_head *)' converts to incompatible function type [-Wcast-function-type-strict] 1838 | head->func = (void (*)(struct callback_head *))func; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> kernel/sched/relationship.c:46:39: error: no member named 'mems_allowed' in 'struct task_struct' 46 | !nodes_subset(node_online_map, tsk->mems_allowed) || | ~~~ ^ include/linux/nodemask.h:218:30: note: expanded from macro 'nodes_subset' 218 | __nodes_subset(&(src1), &(src2), MAX_NUMNODES) | ^~~~ 6 warnings and 1 error generated. vim +46 kernel/sched/relationship.c 38 39 bool task_relationship_supported(struct task_struct *tsk) 40 { 41 if (!task_relationship_used()) 42 return false; 43 44 if (!tsk->rship || !tsk->mm || 45 !cpumask_subset(cpu_online_mask, tsk->cpus_ptr) || > 46 !nodes_subset(node_online_map, tsk->mems_allowed) || 47 get_task_policy(tsk)->mode == MPOL_BIND || 48 get_task_policy(tsk)->mode == MPOL_INTERLEAVE) 49 return false; 50 51 return true; 52 } 53 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • ...
  • 1820
  • Older →

HyperKitty Powered by HyperKitty