- Kernel - mailweb.openeuler.org

[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

[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

[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

[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

[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

[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

[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

[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

[PATCH OLK-5.10 0/3] fix CVE-2024-50278
by Zheng Qixing 03 Dec '24

03 Dec '24

Fix CVE-2024-50278. Ming-Hung Tsai (3): dm cache: fix out-of-bounds access to the dirty bitset when resizing dm cache: optimize dirty bit checking with find_next_bit when resizing dm cache: fix potential out-of-bounds access on the first resume drivers/md/dm-cache-target.c | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) -- 2.39.2

2 4

[PATCH openEuler-22.03-LTS-SP1 0/3] fix CVE-2024-50278
by Zheng Qixing 03 Dec '24

03 Dec '24

Fix CVE-2024-50278. Ming-Hung Tsai (3): dm cache: fix out-of-bounds access to the dirty bitset when resizing dm cache: optimize dirty bit checking with find_next_bit when resizing dm cache: fix potential out-of-bounds access on the first resume drivers/md/dm-cache-target.c | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) -- 2.39.2

2 4