search for: __start_builtin_fw

> It's difficult to say without a full example, but I'm very suspicious > of those global declarations. I think the compiler would be entirely > justified in assuming you could *never* get from __start_builtin_fw to > __end_builtin_fw, let alone on the first iteration: they're distinct > array objects and by definition (within C99) can't overlap. I think this should be the root cause. Once I changed the declaration to pointers (instead of arrays): extern struct builtin_fw* __start_builtin_fw...

I was trying to build the Linux kernel with clang and observed a crash due to incorrect loop optimization: drivers/base/firmware_class.c extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; static bool fw_get_builtin_firmware(struct firmware *fw, const char *name) { struct builtin_fw *b_fw; for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { if (strcmp(name, b_fw->name) == 0) { fw->size = b_fw->size; f...

.../microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c index 86e8f0b2537b..8f021783a929 100644 --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) return *res; } -extern struct builtin_fw __start_builtin_fw[]; -extern struct builtin_fw __end_builtin_fw[]; +extern struct builtin_fw __start_builtin_fw[] __default_visibility; +extern struct builtin_fw __end_builtin_fw[] __default_visibility; bool get_builtin_firmware(struct cpio_data *cd, const char *name) { diff --git a/drivers/base/firmware_class.c...

...cky <nicholas at mxc.ca> wrote: > Chengyu Song wrote: > >> It's difficult to say without a full example, but I'm very suspicious >>> of those global declarations. I think the compiler would be entirely >>> justified in assuming you could *never* get from __start_builtin_fw to >>> __end_builtin_fw, let alone on the first iteration: they're distinct >>> array objects and by definition (within C99) can't overlap. >>> >> >> I think this should be the root cause. Once I changed the declaration to >> pointers (instead of...

...microcode/core.c > index 86e8f0b2537b..8f021783a929 100644 > --- a/arch/x86/kernel/cpu/microcode/core.c > +++ b/arch/x86/kernel/cpu/microcode/core.c > @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) > return *res; > } > > -extern struct builtin_fw __start_builtin_fw[]; > -extern struct builtin_fw __end_builtin_fw[]; > +extern struct builtin_fw __start_builtin_fw[] __default_visibility; > +extern struct builtin_fw __end_builtin_fw[] __default_visibility; > > bool get_builtin_firmware(struct cpio_data *cd, const char *name) > { <-- snip...

...microcode/core.c > index 86e8f0b2537b..8f021783a929 100644 > --- a/arch/x86/kernel/cpu/microcode/core.c > +++ b/arch/x86/kernel/cpu/microcode/core.c > @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) > return *res; > } > > -extern struct builtin_fw __start_builtin_fw[]; > -extern struct builtin_fw __end_builtin_fw[]; > +extern struct builtin_fw __start_builtin_fw[] __default_visibility; > +extern struct builtin_fw __end_builtin_fw[] __default_visibility; > > bool get_builtin_firmware(struct cpio_data *cd, const char *name) > { <-- snip...

...cky <nicholas at mxc.ca> wrote: > Chengyu Song wrote: > >> It's difficult to say without a full example, but I'm very suspicious >>> of those global declarations. I think the compiler would be entirely >>> justified in assuming you could *never* get from __start_builtin_fw to >>> __end_builtin_fw, let alone on the first iteration: they're distinct >>> array objects and by definition (within C99) can't overlap. >>> >> >> I think this should be the root cause. Once I changed the declaration to >> pointers (instead of...

...e8f0b2537b..8f021783a929 100644 >> --- a/arch/x86/kernel/cpu/microcode/core.c >> +++ b/arch/x86/kernel/cpu/microcode/core.c >> @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) >> return *res; >> } >> >> -extern struct builtin_fw __start_builtin_fw[]; >> -extern struct builtin_fw __end_builtin_fw[]; >> +extern struct builtin_fw __start_builtin_fw[] __default_visibility; >> +extern struct builtin_fw __end_builtin_fw[] __default_visibility; >> >> bool get_builtin_firmware(struct cpio_data *cd, const char *name) &g...

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

Changes: - patch v3: - Update on message to describe longer term PIE goal. - Minor change on ftrace if condition. - Changed code using xchgq. - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace