Re: [PATCH 1/5] kexec_core: move kdump related codes from crash_core.c to kexec_core.c
On 01/06/24 at 10:58pm, kernel test robot wrote:
> Hi Baoquan,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v6.7-rc8]
> [cannot apply to powerpc/next powerpc/fixes tip/x86/core arm64/for-next/core
> next-20240105]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Baoquan-He/kexec_core-move-kdump-related-codes-from-crash_core-c-to-kexec_core-c/20240105-223735
> base: linus/master
> patch link:
> https://lore.kernel.org/r/20240105103305.557273-2-bhe%40redhat.com
> patch subject: [PATCH 1/5] kexec_core: move kdump related codes from
> crash_core.c to kexec_core.c
> config: i386-allmodconfig
> (https://download.01.org/0day-ci/archive/20240106/202401062212.lxqinfje-...@intel.com/config)
> compiler: ClangBuiltLinux clang version 17.0.6
> (https://github.com/llvm/llvm-project
> 6009708b4367171ccdbf4b5905cb6a803753fe18)
> reproduce (this is a W=1 build):
> (https://download.01.org/0day-ci/archive/20240106/202401062212.lxqinfje-...@intel.com/reproduce)
>
> 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
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202401062212.lxqinfje-...@intel.com/
>
> All errors (new ones prefixed by >>):
>
> >> arch/x86/kernel/crash.c:154:17: error: invalid application of 'sizeof' to
> >> an incomplete type 'struct crash_mem'
> 154 | cmem = vzalloc(struct_size(cmem, ranges, nr_ranges));
> |^~~~
Thanks for reporting.
I mistakenly put the struct crash_mem definition and the two function
delcarations inside CONFIG_KEXEC_FILE ifdeffery scope, so with the lkp's
config as below, the compiling failed. The code change at bottom can fix
it. Will update patch in v2.
#
# Kexec and crash features
#
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC=y
# CONFIG_KEXEC_FILE is not set
CONFIG_CRASH_DUMP=y
CONFIG_CRASH_HOTPLUG=y
CONFIG_CRASH_MAX_MEMORY_RANGES=8192
---
include/linux/kexec.h | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index be1e5c2fdbdc..4df6ef72db84 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -228,21 +228,6 @@ static inline int arch_kexec_locate_mem_hole(struct
kexec_buf *kbuf)
}
#endif
-/* Alignment required for elf header segment */
-#define ELF_CORE_HEADER_ALIGN 4096
-
-struct crash_mem {
- unsigned int max_nr_ranges;
- unsigned int nr_ranges;
- struct range ranges[] __counted_by(max_nr_ranges);
-};
-
-extern int crash_exclude_mem_range(struct crash_mem *mem,
- unsigned long long mstart,
- unsigned long long mend);
-extern int crash_prepare_elf64_headers(struct crash_mem *mem, int
need_kernel_map,
- void **addr, unsigned long *sz);
-
#ifndef arch_kexec_apply_relocations_add
/*
* arch_kexec_apply_relocations_add - apply relocations of type RELA
@@ -525,6 +510,20 @@ static inline unsigned int crash_get_elfcorehdr_size(void)
{ return 0; }
#define KEXEC_CRASH_HP_INVALID_CPU -1U
#endif
+/* Alignment required for elf header segment */
+#define ELF_CORE_HEADER_ALIGN 4096
+
+struct crash_mem {
+ unsigned int max_nr_ranges;
+ unsigned int nr_ranges;
+ struct range ranges[] __counted_by(max_nr_ranges);
+};
+
+extern int crash_exclude_mem_range(struct crash_mem *mem,
+ unsigned long long mstart,
+ unsigned long long mend);
+extern int crash_prepare_elf64_headers(struct crash_mem *mem, int
need_kernel_map,
+ void **addr, unsigned long *sz);
#else /* !CONFIG_KEXEC_CORE */
struct pt_regs;
struct task_struct;
@@ -541,6 +540,7 @@ void set_kexec_sig_enforced(void);
static inline void set_kexec_sig_enforced(void) {}
#endif
+
#endif /* !defined(__ASSEBMLY__) */
#endif /* LINUX_KEXEC_H */
--
2.41.0
Re: [PATCH 5/5] crash: clean up CRASH_DUMP
Hi Baoquan, kernel test robot noticed the following build errors: [auto build test ERROR on linus/master] [also build test ERROR on v6.7-rc8] [cannot apply to powerpc/next powerpc/fixes tip/x86/core arm64/for-next/core next-20240105] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Baoquan-He/kexec_core-move-kdump-related-codes-from-crash_core-c-to-kexec_core-c/20240105-223735 base: linus/master patch link: https://lore.kernel.org/r/20240105103305.557273-6-bhe%40redhat.com patch subject: [PATCH 5/5] crash: clean up CRASH_DUMP :: branch date: 2 days ago :: commit date: 2 days ago config: x86_64-randconfig-122-20240106 (https://download.01.org/0day-ci/archive/20240107/202401071326.52yn9ftd-...@intel.com/config) compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240107/202401071326.52yn9ftd-...@intel.com/reproduce) 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 | Closes: https://lore.kernel.org/r/202401071326.52yn9ftd-...@intel.com/ All errors (new ones prefixed by >>): >> ld.lld: error: undefined symbol: crashk_res >>> referenced by initramfs.c:638 (init/initramfs.c:638) >>> init/initramfs.o:(kexec_free_initrd) in archive vmlinux.a >>> referenced by initramfs.c:638 (init/initramfs.c:638) >>> init/initramfs.o:(kexec_free_initrd) in archive vmlinux.a >>> referenced by initramfs.c:0 (init/initramfs.c:0) >>> init/initramfs.o:(kexec_free_initrd) in archive vmlinux.a >>> referenced 77 more times -- >> ld.lld: error: undefined symbol: parse_crashkernel >>> referenced by setup.c:479 (arch/x86/kernel/setup.c:479) >>> arch/x86/kernel/setup.o:(arch_reserve_crashkernel) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: crashk_low_res >>> referenced by machine_kexec_64.c:539 (arch/x86/kernel/machine_kexec_64.c:539) >>> arch/x86/kernel/machine_kexec_64.o:(kexec_mark_crashkres) in archive vmlinux.a >>> referenced by machine_kexec_64.c:539 (arch/x86/kernel/machine_kexec_64.c:539) >>> arch/x86/kernel/machine_kexec_64.o:(kexec_mark_crashkres) in archive vmlinux.a >>> referenced by machine_kexec_64.c:539 (arch/x86/kernel/machine_kexec_64.c:539) >>> arch/x86/kernel/machine_kexec_64.o:(kexec_mark_crashkres) in archive vmlinux.a >>> referenced 36 more times -- >> ld.lld: error: undefined symbol: crash_update_vmcoreinfo_safecopy >>> referenced by kexec_core.c:522 (kernel/kexec_core.c:522) >>> kernel/kexec_core.o:(kimage_crash_copy_vmcoreinfo) in archive vmlinux.a >>> referenced by kexec_core.c:610 (kernel/kexec_core.c:610) >>> kernel/kexec_core.o:(kimage_free) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: crash_save_vmcoreinfo >>> referenced by kexec_core.c:1053 (kernel/kexec_core.c:1053) >>> kernel/kexec_core.o:(__crash_kexec) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: paddr_vmcoreinfo_note >>> referenced by kexec_core.c:1148 (kernel/kexec_core.c:1148) >>> kernel/kexec_core.o:(crash_prepare_elf64_headers) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: append_elf_note >>> referenced by kexec_core.c:1390 (kernel/kexec_core.c:1390) >>> kernel/kexec_core.o:(crash_save_cpu) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: final_note >>> referenced by kexec_core.c:1392 (kernel/kexec_core.c:1392) >>> kernel/kexec_core.o:(crash_save_cpu) in archive vmlinux.a -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH 1/5] kexec_core: move kdump related codes from crash_core.c to kexec_core.c
On 01/06/24 at 06:59pm, kernel test robot wrote: > Hi Baoquan, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on linus/master] > [also build test ERROR on v6.7-rc8] > [cannot apply to powerpc/next powerpc/fixes tip/x86/core arm64/for-next/core > next-20240105] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: > https://github.com/intel-lab-lkp/linux/commits/Baoquan-He/kexec_core-move-kdump-related-codes-from-crash_core-c-to-kexec_core-c/20240105-223735 > base: linus/master > patch link: > https://lore.kernel.org/r/20240105103305.557273-2-bhe%40redhat.com > patch subject: [PATCH 1/5] kexec_core: move kdump related codes from > crash_core.c to kexec_core.c > config: x86_64-randconfig-104-20240106 > (https://download.01.org/0day-ci/archive/20240106/202401061800.3xpsapsa-...@intel.com/config) > compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 > reproduce (this is a W=1 build): > (https://download.01.org/0day-ci/archive/20240106/202401061800.3xpsapsa-...@intel.com/reproduce) > > 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 > | Closes: > https://lore.kernel.org/oe-kbuild-all/202401061800.3xpsapsa-...@intel.com/ > > All errors (new ones prefixed by >>): > >In file included from include/linux/string.h:11, > from include/linux/bitmap.h:12, > from include/linux/cpumask.h:12, > from include/linux/smp.h:13, > from arch/x86/kernel/crash.c:18: >arch/x86/kernel/crash.c: In function 'fill_up_crash_elf_data': > >> include/linux/overflow.h:293:23: error: invalid application of 'sizeof' to > >> incomplete type 'struct crash_mem' > 293 | sizeof(*(p)) + flex_array_size(p, member, count), > \ Thanks for reporting. This is the same as the one reported and fixed in below link: https://lore.kernel.org/oe-kbuild-all/ZZpmP5QeH+VigqXw@MiWiFi-R3L-srv/
[PATCH v2 1/1] powerpc/powernv: fix non-SMP kernel compile issues
Non-SMP kernel is quite useful to silicon validation, despite
it is rare to be found in server productions. the fixes are
obvious. Not like IBM pSeries, it may be not necessary
to have powernv SMP forced. It is difficult to compile a
non-SMP kernel for pSerises as I've tried.
Signed-off-by: Luming Yu
---
v1->v2: solve powernv nx-common-powernv.c non-SMP kernel compile issue found by
lkp bot.
v0->v1: solve powernv vas driver non-SMP kernel compile issue found by lkp bot.
---
arch/powerpc/platforms/powernv/Kconfig| 1 -
arch/powerpc/platforms/powernv/opal-imc.c | 1 +
arch/powerpc/platforms/powernv/vas.c | 1 +
arch/powerpc/platforms/powernv/vas.h | 1 +
arch/powerpc/sysdev/xive/common.c | 2 ++
arch/powerpc/sysdev/xive/spapr.c | 5 -
drivers/crypto/nx/nx-common-powernv.c | 1 +
7 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/Kconfig
b/arch/powerpc/platforms/powernv/Kconfig
index 70a46acc70d6..40b1a49379de 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -15,7 +15,6 @@ config PPC_POWERNV
select CPU_FREQ
select PPC_DOORBELL
select MMU_NOTIFIER
- select FORCE_SMP
select ARCH_SUPPORTS_PER_VMA_LOCK
default y
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index 828fc4d88471..6e9e2b0a5bdc 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/arch/powerpc/platforms/powernv/vas.c
b/arch/powerpc/platforms/powernv/vas.c
index b65256a63e87..c1759135aca5 100644
--- a/arch/powerpc/platforms/powernv/vas.c
+++ b/arch/powerpc/platforms/powernv/vas.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "vas.h"
diff --git a/arch/powerpc/platforms/powernv/vas.h
b/arch/powerpc/platforms/powernv/vas.h
index 08d9d3d5a22b..313a8f2c8c7d 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
/*
* Overview of Virtual Accelerator Switchboard (VAS).
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index a289cb97c1d7..d49b12809c10 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -1497,7 +1497,9 @@ static int xive_prepare_cpu(unsigned int cpu)
GFP_KERNEL, cpu_to_node(cpu));
if (!xc)
return -ENOMEM;
+#ifdef CONFIG_SMP
xc->hw_ipi = XIVE_BAD_IRQ;
+#endif
xc->chip_id = XIVE_INVALID_CHIP_ID;
if (xive_ops->prepare_cpu)
xive_ops->prepare_cpu(cpu, xc);
diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c
index e45419264391..7298f57f8416 100644
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -81,6 +81,7 @@ static void xive_irq_bitmap_remove_all(void)
}
}
+#ifdef CONFIG_SMP
static int __xive_irq_bitmap_alloc(struct xive_irq_bitmap *xibm)
{
int irq;
@@ -126,7 +127,7 @@ static void xive_irq_bitmap_free(int irq)
}
}
}
-
+#endif
/* Based on the similar routines in RTAS */
static unsigned int plpar_busy_delay_time(long rc)
@@ -663,6 +664,7 @@ static void xive_spapr_sync_source(u32 hw_irq)
plpar_int_sync(0, hw_irq);
}
+#ifdef CONFIG_SMP
static int xive_spapr_debug_show(struct seq_file *m, void *private)
{
struct xive_irq_bitmap *xibm;
@@ -680,6 +682,7 @@ static int xive_spapr_debug_show(struct seq_file *m, void
*private)
return 0;
}
+#endif
static const struct xive_ops xive_spapr_ops = {
.populate_irq_data = xive_spapr_populate_irq_data,
diff --git a/drivers/crypto/nx/nx-common-powernv.c
b/drivers/crypto/nx/nx-common-powernv.c
index 8c859872c183..58c42677b448 100644
--- a/drivers/crypto/nx/nx-common-powernv.c
+++ b/drivers/crypto/nx/nx-common-powernv.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Dan Streetman ");
--
2.42.0.windows.2
Re: [PATCH v2 00/13] mm/gup: Unify hugetlb, part 2
Hi, Christophe, On Wed, Jan 03, 2024 at 11:14:54AM +, Christophe Leroy wrote: > > Test Done > > = > > > > This v1 went through the normal GUP smoke tests over different memory > > types on archs (using VM instances): x86_64, aarch64, ppc64le. For > > aarch64, tested over 64KB cont_pte huge pages. For ppc64le, tested over > > 16MB hugepd entries (Power8 hash MMU on 4K base page size). > > > > Can you tell how you test ? > > I'm willing to test this series on powerpc 8xx (PPC32). My apologies, for some reason I totally overlooked this email.. I only tested using run_vmtests.sh, with: $ bash ./run_vmtests.sh -t gup_test -a It should cover pretty much lots of tests of GUP using gup_test program. I think the ones that matters here is "-H" over either "-U/-b". For ppc8xx, even though kernel mapping uses hugepd, I don't expect anything should change before/after this series, because the code that I touched (slow gup only) only affects user pages, so it shouldn't change anything over kernel mappings. Said so, please feel free to smoke over whatever type of kernel hugepd mappings, and I'd trust you're the expert on how to trigger those paths. Since I got your attention, when working on this series I talked to David Gibson and just got to know that hugepd is actually a pure software idea. IIUC it means there's no PPC hardware that really understands the hugepd format at all, but only a "this is a huge page" hint for Linux. Considering that it _seems_ to play a similar role of cont_pXX here: do you think hugepd can have any chance to be implemented similarly like cont_pXX, or somehow share the code? For example, if hugepd is recognized only by Linux kernel itself, maybe there can be some special pgtable hint that can be attached to the cont_* entries, showing whether it's a "real cont_*" entry or a "hugepd" entry? IIUC it can be quite flexible because if hugepd only works for hash MMU so no hardware will even walk that radix table. But I can overlook important things here. It'll be definitely great if hugepd can be merged into some existing forms like a generic pgtable (IMHO cont_* is such case: it's the same as no cont_* entries for softwares, while hardware can accelerate with TLB hits on larger ranges). But I can be asking a very silly question here too, as I can overlook very important things. Thanks, -- Peter Xu
