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

  • 41 participants
  • 19766 discussions
[PATCH OLK-5.10] powerpc/xive/spapr: correct bitmap allocation size
by Bowen You 12 Aug '25

12 Aug '25
From: Nathan Lynch <nathanl(a)linux.ibm.com> mainline inclusion from mainline-v5.19-rc5 commit 19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP6KY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------ kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency. Signed-off-by: Nathan Lynch <nathanl(a)linux.ibm.com> Reviewed-by: Cédric Le Goater <clg(a)kaod.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20220623182509.3985625-1-nathanl@linux.ibm.com Conflicts: arch/powerpc/sysdev/xive/spapr.c [context conflict, xive_irq_bitmap_remove_all function not merged.] Signed-off-by: Bowen You <youbowen2(a)huawei.com> --- arch/powerpc/sysdev/xive/spapr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c index 53cf14349d5e..4c95bfe8813b 100644 --- a/arch/powerpc/sysdev/xive/spapr.c +++ b/arch/powerpc/sysdev/xive/spapr.c @@ -55,7 +55,7 @@ static int xive_irq_bitmap_add(int base, int count) spin_lock_init(&xibm->lock); xibm->base = base; xibm->count = count; - xibm->bitmap = kzalloc(xibm->count, GFP_KERNEL); + xibm->bitmap = bitmap_zalloc(xibm->count, GFP_KERNEL); if (!xibm->bitmap) { kfree(xibm); return -ENOMEM; -- 2.34.1
2 1
0 0
[openeuler:OLK-6.6 2669/2669] drivers/net/ethernet/huawei/bma/edma_drv/edma_queue.c:330:5: warning: no previous prototype for function 'wait_done_dma_queue'
by kernel test robot 12 Aug '25

12 Aug '25
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 68ac72c2610cc9a280d47c6f733db0eff92efc15 commit: 85502a982830072aff2efa8b65f75c240b4d6181 [2669/2669] Huawei iBMA: Added support for Hi1712 Chip config: loongarch-allmodconfig (https://download.01.org/0day-ci/archive/20250812/202508121628.Gr4EiznB-lkp@…) compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121628.Gr4EiznB-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/202508121628.Gr4EiznB-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/net/ethernet/huawei/bma/edma_drv/edma_queue.c:330:5: warning: no previous prototype for function 'wait_done_dma_queue' [-Wmissing-prototypes] 330 | s32 wait_done_dma_queue(unsigned long timeout) | ^ drivers/net/ethernet/huawei/bma/edma_drv/edma_queue.c:330:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 330 | s32 wait_done_dma_queue(unsigned long timeout) | ^ | static 1 warning generated. vim +/wait_done_dma_queue +330 drivers/net/ethernet/huawei/bma/edma_drv/edma_queue.c 329 > 330 s32 wait_done_dma_queue(unsigned long timeout) 331 { 332 struct dma_ch_cq_s *p_cur_last_cq; 333 struct dma_ch_cq_s *p_dma_cq; 334 unsigned long end; 335 u32 sq_tail; 336 u32 sq_valid; 337 u32 cq_tail; 338 u32 cq_valid; 339 340 p_dma_cq = (struct dma_ch_cq_s *)((&get_bma_dev()->edma_host)->edma_cq_addr); 341 end = jiffies + timeout; 342 343 while (time_before(jiffies, end)) { 344 (void)get_dma_queue_sq_tail(&sq_tail); 345 (void)get_dma_queue_cq_tail(&cq_tail); 346 347 cq_valid = (cq_tail + CQ_DEPTH - 1) % (CQ_DEPTH); 348 p_cur_last_cq = &p_dma_cq[cq_valid]; 349 sq_valid = (sq_tail + SQ_DEPTH - 1) % (SQ_DEPTH); 350 BMA_LOG(DLOG_DEBUG, 351 "sq_tail %d, cq_tail %d, cq_valid %d, sq_valid %d, p_cur_last_cq->sqhd %d\n", 352 sq_tail, cq_tail, cq_valid, sq_valid, p_cur_last_cq->sqhd); 353 if (p_cur_last_cq->sqhd == sq_valid) { 354 set_dma_queue_cq_head(cq_valid); 355 return 0; 356 } 357 } 358 359 return -ETIMEDOUT; 360 } 361 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-6.6 2669/2669] kernel/sched/debug.c:102:12: warning: no previous prototype for function 'is_prefer_numa'
by kernel test robot 12 Aug '25

12 Aug '25
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 263cf8eeb5316aeebd9d692e9966df029f65889f commit: 0f22304e62d360fce47988586d599e33895ccb01 [2669/2669] sched: Support NUMA parallel scheduling for multiple processes config: x86_64-buildonly-randconfig-001-20250812 (https://download.01.org/0day-ci/archive/20250812/202508121611.xU3A9CdS-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121611.xU3A9CdS-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/202508121611.xU3A9CdS-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from kernel/sched/build_utility.c:73: >> kernel/sched/debug.c:102:12: warning: no previous prototype for function 'is_prefer_numa' [-Wmissing-prototypes] 102 | int __weak is_prefer_numa(void) | ^ kernel/sched/debug.c:102:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 102 | int __weak is_prefer_numa(void) | ^ | static In file included from kernel/sched/build_utility.c:105: kernel/sched/isolation.c:134:46: error: use of undeclared identifier 'setup_max_cpus' 134 | if (first_cpu >= nr_cpu_ids || first_cpu >= setup_max_cpus) { | ^ 1 warning and 1 error generated. vim +/is_prefer_numa +102 kernel/sched/debug.c 101 > 102 int __weak is_prefer_numa(void) 103 { 104 return 0; 105 } 106 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH OLK-5.10] powerpc/xive/spapr: correct bitmap allocation size
by Bowen You 12 Aug '25

12 Aug '25
From: Nathan Lynch <nathanl(a)linux.ibm.com> mainline inclusion from mainline-v5.19-rc5 commit 19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP6KY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------ kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency. Signed-off-by: Nathan Lynch <nathanl(a)linux.ibm.com> Reviewed-by: Cédric Le Goater <clg(a)kaod.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20220623182509.3985625-1-nathanl@linux.ibm.com Conflicts: arch/powerpc/sysdev/xive/spapr.c [context conflict, xive_irq_bitmap_remove_all function not merged.] Signed-off-by: Bowen You <youbowen2(a)huawei.com> --- arch/powerpc/sysdev/xive/spapr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c index 53cf14349d5e..4c95bfe8813b 100644 --- a/arch/powerpc/sysdev/xive/spapr.c +++ b/arch/powerpc/sysdev/xive/spapr.c @@ -55,7 +55,7 @@ static int xive_irq_bitmap_add(int base, int count) spin_lock_init(&xibm->lock); xibm->base = base; xibm->count = count; - xibm->bitmap = kzalloc(xibm->count, GFP_KERNEL); + xibm->bitmap = bitmap_zalloc(xibm->count, GFP_KERNEL); if (!xibm->bitmap) { kfree(xibm); return -ENOMEM; -- 2.34.1
2 1
0 0
[openeuler:openEuler-1.0-LTS 1755/1755] drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'VRM' not described in enum 'rpmh_regulator_type'
by kernel test robot 12 Aug '25

12 Aug '25
tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: a7892155ca524e224cb2da85c85cc1bd4303179d commit: 46fc033eba42f5a4fb583b2ab53f0a9918468452 [1755/1755] regulator: add QCOM RPMh regulator driver config: x86_64-buildonly-randconfig-2002-20250811 (https://download.01.org/0day-ci/archive/20250812/202508121032.93R4tKQv-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121032.93R4tKQv-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/202508121032.93R4tKQv-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'VRM' not described in enum 'rpmh_regulator_type' >> drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'XOB' not described in enum 'rpmh_regulator_type' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'vreg' not described in 'rpmh_regulator_init_vreg' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'dev' not described in 'rpmh_regulator_init_vreg' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'node' not described in 'rpmh_regulator_init_vreg' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'pmic_id' not described in 'rpmh_regulator_init_vreg' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'pmic_rpmh_data' not described in 'rpmh_regulator_init_vreg' vim +33 drivers/regulator/qcom-rpmh-regulator.c 22 23 /** 24 * enum rpmh_regulator_type - supported RPMh accelerator types 25 * %VRM: RPMh VRM accelerator which supports voting on enable, voltage, 26 * and mode of LDO, SMPS, and BOB type PMIC regulators. 27 * %XOB: RPMh XOB accelerator which supports voting on the enable state 28 * of PMIC regulators. 29 */ 30 enum rpmh_regulator_type { 31 VRM, 32 XOB, > 33 }; 34 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 1750/1750] drivers/i2c/busses/.tmp_i2c-zhaoxin.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 12 Aug '25

12 Aug '25
tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: a7892155ca524e224cb2da85c85cc1bd4303179d commit: 735c81b4d33c46ea097f6437f63ea624ccf6dee1 [1750/1750] i2c: Add Zhaoxin I2C driver config: x86_64-buildonly-randconfig-2004-20250805 (https://download.01.org/0day-ci/archive/20250812/202508121006.nLfkti1W-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121006.nLfkti1W-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/202508121006.nLfkti1W-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/i2c/busses/.tmp_i2c-zhaoxin.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 1755/1755] drivers/mailbox/mtk-cmdq-mailbox.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 12 Aug '25

12 Aug '25
tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: a7892155ca524e224cb2da85c85cc1bd4303179d commit: 623a6143a845bd485b00ba684f0ccef11835edab [1755/1755] mailbox: mediatek: Add Mediatek CMDQ driver config: x86_64-buildonly-randconfig-2004-20250811 (https://download.01.org/0day-ci/archive/20250812/202508121002.xxDFTqIT-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121002.xxDFTqIT-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/202508121002.xxDFTqIT-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/mailbox/mtk-cmdq-mailbox.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH OLK-6.6 V1 0/3] sched-ebpf-add-for-exec-init
by Cheng Yu 12 Aug '25

12 Aug '25
sched-ebpf-add-for-exec-init Cheng Yu (3): sched/ebpf: Add bpf_sched_cfs_exec_set_cpumask hook sched/ebpf: Add kfunc to set the preferred NUMA node for the task sched/bpf: Fix kabi breakage for including sched bpf header file fs/exec.c | 9 +++++++++ include/linux/sched_hook_defs.h | 1 + kernel/sched/bpf_sched.c | 34 ++++++++++++++++++++++----------- 3 files changed, 33 insertions(+), 11 deletions(-) -- 2.25.1
2 4
0 0
[openeuler:OLK-6.6 2665/2665] arch/arm64/kvm/rme.c:740:6: warning: variable 'tmp_page' is used uninitialized whenever 'if' condition is true
by kernel test robot 12 Aug '25

12 Aug '25
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 263cf8eeb5316aeebd9d692e9966df029f65889f commit: a74f93b7e7c0d8a2114055ed0c652cc735a7a07b [2665/2665] [backport]rme: populate guest memory region without guest_memfd config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20250812/202508121448.yD6lHdJT-lkp@…) compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121448.yD6lHdJT-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/202508121448.yD6lHdJT-lkp@intel.com/ All warnings (new ones prefixed by >>): >> arch/arm64/kvm/rme.c:740:6: warning: variable 'tmp_page' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] 740 | if (memslot->base_gfn + memslot->npages < end_gfn) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm64/kvm/rme.c:789:14: note: uninitialized use occurs here 789 | __free_page(tmp_page); | ^~~~~~~~ include/linux/gfp.h:333:41: note: expanded from macro '__free_page' 333 | #define __free_page(page) __free_pages((page), 0) | ^~~~ arch/arm64/kvm/rme.c:740:2: note: remove the 'if' if its condition is always false 740 | if (memslot->base_gfn + memslot->npages < end_gfn) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 741 | ret = -EINVAL; | ~~~~~~~~~~~~~~ 742 | goto out; | ~~~~~~~~~ 743 | } | ~ arch/arm64/kvm/rme.c:734:6: warning: variable 'tmp_page' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] 734 | if (!memslot) { | ^~~~~~~~ arch/arm64/kvm/rme.c:789:14: note: uninitialized use occurs here 789 | __free_page(tmp_page); | ^~~~~~~~ include/linux/gfp.h:333:41: note: expanded from macro '__free_page' 333 | #define __free_page(page) __free_pages((page), 0) | ^~~~ arch/arm64/kvm/rme.c:734:2: note: remove the 'if' if its condition is always false 734 | if (!memslot) { | ^~~~~~~~~~~~~~~ 735 | ret = -EFAULT; | ~~~~~~~~~~~~~~ 736 | goto out; | ~~~~~~~~~ 737 | } | ~ arch/arm64/kvm/rme.c:726:23: note: initialize the variable 'tmp_page' to silence this warning 726 | struct page *tmp_page; | ^ | = NULL arch/arm64/kvm/rme.c:798:16: warning: variable 'data_flags' set but not used [-Wunused-but-set-variable] 798 | unsigned long data_flags = 0; | ^ 3 warnings generated. vim +740 arch/arm64/kvm/rme.c e216f77846eeb7 Steven Price 2025-06-14 715 e216f77846eeb7 Steven Price 2025-06-14 716 static int populate_region(struct kvm *kvm, e216f77846eeb7 Steven Price 2025-06-14 717 phys_addr_t ipa_base, e216f77846eeb7 Steven Price 2025-06-14 718 phys_addr_t ipa_end, e216f77846eeb7 Steven Price 2025-06-14 719 unsigned long data_flags) e216f77846eeb7 Steven Price 2025-06-14 720 { e216f77846eeb7 Steven Price 2025-06-14 721 struct realm *realm = &kvm->arch.realm; e216f77846eeb7 Steven Price 2025-06-14 722 struct kvm_memory_slot *memslot; e216f77846eeb7 Steven Price 2025-06-14 723 gfn_t base_gfn, end_gfn; e216f77846eeb7 Steven Price 2025-06-14 724 int idx; e216f77846eeb7 Steven Price 2025-06-14 725 phys_addr_t ipa = ipa_base; a74f93b7e7c0d8 Steven Price 2025-06-14 726 struct page *tmp_page; e216f77846eeb7 Steven Price 2025-06-14 727 int ret = 0; e216f77846eeb7 Steven Price 2025-06-14 728 e216f77846eeb7 Steven Price 2025-06-14 729 base_gfn = gpa_to_gfn(ipa_base); e216f77846eeb7 Steven Price 2025-06-14 730 end_gfn = gpa_to_gfn(ipa_end); e216f77846eeb7 Steven Price 2025-06-14 731 e216f77846eeb7 Steven Price 2025-06-14 732 idx = srcu_read_lock(&kvm->srcu); e216f77846eeb7 Steven Price 2025-06-14 733 memslot = gfn_to_memslot(kvm, base_gfn); e216f77846eeb7 Steven Price 2025-06-14 734 if (!memslot) { e216f77846eeb7 Steven Price 2025-06-14 735 ret = -EFAULT; e216f77846eeb7 Steven Price 2025-06-14 736 goto out; e216f77846eeb7 Steven Price 2025-06-14 737 } e216f77846eeb7 Steven Price 2025-06-14 738 e216f77846eeb7 Steven Price 2025-06-14 739 /* We require the region to be contained within a single memslot */ e216f77846eeb7 Steven Price 2025-06-14 @740 if (memslot->base_gfn + memslot->npages < end_gfn) { e216f77846eeb7 Steven Price 2025-06-14 741 ret = -EINVAL; e216f77846eeb7 Steven Price 2025-06-14 742 goto out; e216f77846eeb7 Steven Price 2025-06-14 743 } e216f77846eeb7 Steven Price 2025-06-14 744 a74f93b7e7c0d8 Steven Price 2025-06-14 745 tmp_page = alloc_page(GFP_KERNEL); a74f93b7e7c0d8 Steven Price 2025-06-14 746 if (!tmp_page) { a74f93b7e7c0d8 Steven Price 2025-06-14 747 ret = -ENOMEM; e216f77846eeb7 Steven Price 2025-06-14 748 goto out; e216f77846eeb7 Steven Price 2025-06-14 749 } e216f77846eeb7 Steven Price 2025-06-14 750 a74f93b7e7c0d8 Steven Price 2025-06-14 751 mmap_read_lock(current->mm); a74f93b7e7c0d8 Steven Price 2025-06-14 752 e216f77846eeb7 Steven Price 2025-06-14 753 while (ipa < ipa_end) { e216f77846eeb7 Steven Price 2025-06-14 754 struct vm_area_struct *vma; e216f77846eeb7 Steven Price 2025-06-14 755 unsigned long hva; e216f77846eeb7 Steven Price 2025-06-14 756 struct page *page; e216f77846eeb7 Steven Price 2025-06-14 757 kvm_pfn_t pfn; e216f77846eeb7 Steven Price 2025-06-14 758 e216f77846eeb7 Steven Price 2025-06-14 759 hva = gfn_to_hva_memslot(memslot, gpa_to_gfn(ipa)); e216f77846eeb7 Steven Price 2025-06-14 760 vma = vma_lookup(current->mm, hva); e216f77846eeb7 Steven Price 2025-06-14 761 if (!vma) { e216f77846eeb7 Steven Price 2025-06-14 762 ret = -EFAULT; e216f77846eeb7 Steven Price 2025-06-14 763 break; e216f77846eeb7 Steven Price 2025-06-14 764 } e216f77846eeb7 Steven Price 2025-06-14 765 a74f93b7e7c0d8 Steven Price 2025-06-14 766 pfn = gfn_to_pfn_memslot(memslot, gpa_to_gfn(ipa)); e216f77846eeb7 Steven Price 2025-06-14 767 e216f77846eeb7 Steven Price 2025-06-14 768 if (is_error_pfn(pfn)) { e216f77846eeb7 Steven Price 2025-06-14 769 ret = -EFAULT; e216f77846eeb7 Steven Price 2025-06-14 770 break; e216f77846eeb7 Steven Price 2025-06-14 771 } e216f77846eeb7 Steven Price 2025-06-14 772 a74f93b7e7c0d8 Steven Price 2025-06-14 773 page = pfn_to_page(pfn); e216f77846eeb7 Steven Price 2025-06-14 774 e216f77846eeb7 Steven Price 2025-06-14 775 ret = realm_create_protected_data_page(realm, ipa, a74f93b7e7c0d8 Steven Price 2025-06-14 776 page, a74f93b7e7c0d8 Steven Price 2025-06-14 777 tmp_page, e216f77846eeb7 Steven Price 2025-06-14 778 data_flags); a74f93b7e7c0d8 Steven Price 2025-06-14 779 if (ret) { e216f77846eeb7 Steven Price 2025-06-14 780 kvm_release_page_clean(page); e216f77846eeb7 Steven Price 2025-06-14 781 break; a74f93b7e7c0d8 Steven Price 2025-06-14 782 } e216f77846eeb7 Steven Price 2025-06-14 783 e216f77846eeb7 Steven Price 2025-06-14 784 ipa += PAGE_SIZE; a74f93b7e7c0d8 Steven Price 2025-06-14 785 kvm_release_pfn_dirty(pfn); e216f77846eeb7 Steven Price 2025-06-14 786 } e216f77846eeb7 Steven Price 2025-06-14 787 out: a74f93b7e7c0d8 Steven Price 2025-06-14 788 mmap_read_unlock(current->mm); a74f93b7e7c0d8 Steven Price 2025-06-14 789 __free_page(tmp_page); e216f77846eeb7 Steven Price 2025-06-14 790 srcu_read_unlock(&kvm->srcu, idx); e216f77846eeb7 Steven Price 2025-06-14 791 return ret; e216f77846eeb7 Steven Price 2025-06-14 792 } e216f77846eeb7 Steven Price 2025-06-14 793 :::::: The code at line 740 was first introduced by commit :::::: e216f77846eeb7062baa345cea2be0978dea94cc [v8-19-43]arm64: RME: Allow populating initial contents :::::: TO: Steven Price <steven.price(a)arm.com> :::::: CC: Xu Raoqing <xuraoqing(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 1750/1750] arch/x86/mm/.tmp_maccess.o: warning: objtool: missing symbol for section .text
by kernel test robot 12 Aug '25

12 Aug '25
tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: a7892155ca524e224cb2da85c85cc1bd4303179d commit: 22058d2bdaf6b0526395ceec2736c72c3b5f435a [1750/1750] uaccess: Add strict non-pagefault kernel-space read function config: x86_64-buildonly-randconfig-2004-20250805 (https://download.01.org/0day-ci/archive/20250812/202508120725.n4YJFfFe-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508120725.n4YJFfFe-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/202508120725.n4YJFfFe-lkp@intel.com/ All warnings (new ones prefixed by >>): >> arch/x86/mm/.tmp_maccess.o: warning: objtool: missing symbol for section .text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • ...
  • 1977
  • Older →

HyperKitty Powered by HyperKitty