[PATCH] EDAC/ppc_4xx: Reorder symbols to get rid of a few forward declarations
When moving the definition of ppc4xx_edac_driver further down, the
forward declarations can just be dropped.
Do this to reduce line needless repetition.
Signed-off-by: Uwe Kleine-König
---
drivers/edac/ppc4xx_edac.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
index 0bc670778c99..046969b4e82e 100644
--- a/drivers/edac/ppc4xx_edac.c
+++ b/drivers/edac/ppc4xx_edac.c
@@ -178,11 +178,6 @@ struct ppc4xx_ecc_status {
u32 wmirq;
};
-/* Function Prototypes */
-
-static int ppc4xx_edac_probe(struct platform_device *device);
-static int ppc4xx_edac_remove(struct platform_device *device);
-
/* Global Variables */
/*
@@ -197,15 +192,6 @@ static const struct of_device_id ppc4xx_edac_match[] = {
};
MODULE_DEVICE_TABLE(of, ppc4xx_edac_match);
-static struct platform_driver ppc4xx_edac_driver = {
- .probe = ppc4xx_edac_probe,
- .remove = ppc4xx_edac_remove,
- .driver = {
- .name = PPC4XX_EDAC_MODULE_NAME,
- .of_match_table = ppc4xx_edac_match,
- },
-};
-
/*
* TODO: The row and channel parameters likely need to be dynamically
* set based on the aforementioned variant controller realizations.
@@ -1391,6 +1377,15 @@ ppc4xx_edac_opstate_init(void)
EDAC_OPSTATE_UNKNOWN_STR)));
}
+static struct platform_driver ppc4xx_edac_driver = {
+ .probe = ppc4xx_edac_probe,
+ .remove = ppc4xx_edac_remove,
+ .driver = {
+ .name = PPC4XX_EDAC_MODULE_NAME,
+ .of_match_table = ppc4xx_edac_match,
+ },
+};
+
/**
* ppc4xx_edac_init - driver/module insertion entry point
*
base-commit: 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
--
2.37.2
Re: [PATCH v2 3/7] powerpc/build: move got, toc, plt, branch_lt sections to read-only
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on linus/master v6.0-rc5 next-20220916]
[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/Nicholas-Piggin/powerpc-build-linker-improvements/20220916-121310
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-microwatt_defconfig
(https://download.01.org/0day-ci/archive/20220918/202209180437.4u3soljk-...@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project
791a7ae1ba3efd6bca96338e10ffde557ba83920)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
#
https://github.com/intel-lab-lkp/linux/commit/6c034c08f8d0addb6fecba38c9c428b1c4df7c29
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Nicholas-Piggin/powerpc-build-linker-improvements/20220916-121310
git checkout 6c034c08f8d0addb6fecba38c9c428b1c4df7c29
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=powerpc SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> ld.lld: error: ./arch/powerpc/kernel/vmlinux.lds:46: { expected, but got
>> SPECIAL
>>> .got : AT(ADDR(.got) - (0xc000 -0x)) SPECIAL {
>>> ^
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [PATCH v3 11/16] objtool: Add --mnop as an option to --mcount
Hi Sathvika, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on powerpc/topic/ppc-kvm] [also build test WARNING on linus/master v6.0-rc5] [cannot apply to powerpc/next masahiroy-kbuild/for-next next-20220916] [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/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm config: x86_64-randconfig-m001 (https://download.01.org/0day-ci/archive/20220918/202209180354.tm3z4upd-...@intel.com/config) compiler: gcc-11 (Debian 11.3.0-5) 11.3.0 reproduce (this is a W=1 build): # https://github.com/intel-lab-lkp/linux/commit/ca5e2b42c0d4438ba93623579b6860b98f3598f3 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023 git checkout ca5e2b42c0d4438ba93623579b6860b98f3598f3 # save the config file mkdir build_dir && cp config build_dir/.config make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> vmlinux.o: warning: objtool: exc_page_fault+0xe: call to >> __sanitizer_cov_trace_pc() leaves .noinstr.text section >> vmlinux.o: warning: objtool: get_cpu_entry_area+0x3: call to >> __sanitizer_cov_trace_pc() leaves .noinstr.text section >> vmlinux.o: warning: objtool: __stack_chk_fail+0x0: call to >> __sanitizer_cov_trace_pc() leaves .noinstr.text section >> vmlinux.o: warning: objtool: __ktime_get_real_seconds+0x0: call to >> __sanitizer_cov_trace_pc() leaves .noinstr.text section objdump-func vmlinux.o exc_page_fault: 20c0 : 20c0: 41 56 push %r14 0002 20c2: 41 55 push %r13 0004 20c4: 49 89 f5mov%rsi,%r13 0007 20c7: 41 54 push %r12 0009 20c9: 55 push %rbp 000a 20ca: 48 89 fdmov%rdi,%rbp 000d 20cd: 53 push %rbx 000e 20ce: e8 00 00 00 00 call 20d3 20cf: R_X86_64_PLT32__sanitizer_cov_trace_pc-0x4 0013 20d3: 41 0f 20 d4 mov%cr2,%r12 0017 20d7: 48 8b 04 25 00 00 00 00 mov0x0,%rax 20db: R_X86_64_32S current_task 001f 20df: 48 8b 80 b8 03 00 00mov0x3b8(%rax),%rax 0026 20e6: 0f 18 88 b0 00 00 00prefetcht0 0xb0(%rax) 002d 20ed: 44 8b 35 00 00 00 00mov0x0(%rip),%r14d# 20f4 20f0: R_X86_64_PC32 kvm_async_pf_enabled-0x4 0034 20f4: 31 ff xor%edi,%edi 0036 20f6: 44 89 f6mov%r14d,%esi 0039 20f9: e8 00 00 00 00 call 20fe 20fa: R_X86_64_PLT32__sanitizer_cov_trace_const_cmp4-0x4 003e 20fe: 45 85 f6test %r14d,%r14d 0041 2101: 0f 8f c9 00 00 00 jg 21d0 0047 2107: e8 00 00 00 00 call 210c 2108: R_X86_64_PLT32__sanitizer_cov_trace_pc-0x4 004c 210c: 48 89 efmov%rbp,%rdi 004f 210f: e8 00 00 00 00 call 2114 2110: R_X86_64_PLT32irqentry_enter-0x4 0054 2114: 41 89 c6mov%eax,%r14d 0057 2117: 90 nop 0058 2118: 8b 1d 00 00 00 00 mov0x0(%rip),%ebx# 211e 211a: R_X86_64_PC32 trace_pagefault_key-0x4 005e 211e: 31 ff xor%edi,%edi 0060 2120: 89 de mov%ebx,%esi 0062 2122: e8 00 00 00 00 call 2127 2123: R_X86_64_PLT32__sanitizer_cov_trace_const_cmp4-0x4 0067 2127: 85 db test %ebx,%ebx 0069 2129: 0f 8f c6 00 00 00 jg 21f5 006f 212f: e8 00 00 00 00 call 2134 2130: R_X86_64_PLT32__sanitizer_cov_trace_pc-0x4 0074 2134: 4c 89 e3mov%r12,%rbx 0077 2137: 48 c7 c7 00 00 60 ffmov$0xff60,%rdi 007e 213e: 48 81 e3 00 f0 ff ffand$0xf000,%rbx 0085 2145: 48 89 demov%rbx,%rsi 0088 2148: e8 00 00 00 00 call 214d 2149: R_X86_64_PLT32__sanitizer_cov_trace_const_cmp8-0x4 008d 214d: 48 81 fb 00 00 60 ffcmp$0xff60,%rbx 0094 2154: 74 23 je 2179 0096 2156: 48 bb ff ef ff ff ff 7f 00 00 movabs $0x7fffefff,%rbx 00a0 2160: e8 00 00 00 00 call 2165 2161: R_X86_64_PLT32
Re: [PATCH] powerpc: Save AMR/IAMR when switching tasks
On 9/17/22 03:16, Christophe Leroy wrote:
> Le 16/09/2022 à 07:05, Samuel Holland a écrit :
>> With CONFIG_PREEMPT=y (involuntary preemption enabled), it is possible
>> to switch away from a task inside copy_{from,to}_user. This left the CPU
>> with userspace access enabled until after the next IRQ or privilege
>> level switch, when AMR/IAMR got reset to AMR_KU[AE]P_BLOCKED. Then, when
>> switching back to the original task, the userspace access would fault:
>
> This is not supposed to happen. You never switch away from a task
> magically. Task switch will always happen in an interrupt, that means
> copy_{from,to}_user() get interrupted.
That makes sense, the interrupt handler is responsible for saving the
KUAP status. It looks like neither DEFINE_INTERRUPT_HANDLER_RAW nor any
of its users (performance_monitor_exception(), do_slb_fault()) do that.
Yet they still call one of the interrupt_return variants, which restores
the status from the stack.
> Whenever an interrupt is taken, kuap_save_amr_and_lock() macro is used
> to save KUAP status into the stack then lock KUAP access. At interrupt
> exit, kuap_kernel_restore() macro or function is used to restore KUAP
> access from the stack. At the time the task switch happens, KUAP access
> is expected to be locked. During task switch, the stack is switched so
> the KUAP status is taken back from the new task's stack.
What if another task calls schedule() from kernel process context, and
the scheduler switches to a task that had been preempted inside
copy_{from,to}_user()? Then there is no interrupt involved, and I don't
see where kuap_kernel_restore() would get called.
> Your fix suggests that there is some path where the KUAP status is not
> properly saved and/or restored. Did you try running with
> CONFIG_PPC_KUAP_DEBUG ? It should warn whenever a KUAP access is left
> unlocked.
>
>>
>>Kernel attempted to write user page (3fff7ab68190) - exploit attempt?
>> (uid: 65536)
>>[ cut here ]
>>Bug: Write fault blocked by KUAP!
>>WARNING: CPU: 56 PID: 4939 at arch/powerpc/mm/fault.c:228
>> ___do_page_fault+0x7b4/0xaa0
>>CPU: 56 PID: 4939 Comm: git Tainted: GW
>> 5.19.8-5-gba424747260d #1
>>NIP: c00555e4 LR: c00555e0 CTR: c079d9d0
>>REGS: c0008f507370 TRAP: 0700 Tainted: GW
>> (5.19.8-5-gba424747260d)
>>MSR: 90021033 CR: 2804 XER: 2004
>>CFAR: c0123780 IRQMASK: 3
>>NIP [c00555e4] ___do_page_fault+0x7b4/0xaa0
>>LR [c00555e0] ___do_page_fault+0x7b0/0xaa0
>>Call Trace:
>>[c0008f507610] [c00555e0] ___do_page_fault+0x7b0/0xaa0
>> (unreliable)
>>[c0008f5076c0] [c0055938] do_page_fault+0x68/0x130
>>[c0008f5076f0] [c0008914] data_access_common_virt+0x194/0x1f0
>>--- interrupt: 300 at __copy_tofrom_user_base+0x9c/0x5a4
>
> ...
>
>>
>> Fix this by saving and restoring the kernel-side AMR/IAMR values when
>> switching tasks.
>
> As explained above, KUAP access should be locked at that time, so saving
> and restoring it should not have any effect. If it does, it means
> something goes wrong somewhere else.
>
>>
>> Fixes: 890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU")
>> Signed-off-by: Samuel Holland
>> ---
>> I have no idea if this is the right change to make, and it could be
>> optimized, but my system has been stable with this patch for 5 days now.
>>
>> Without the patch, I hit the bug every few minutes when my load average
>> is <1, and I hit it immediately if I try to do a parallel kernel build.
>
> Great, then can you make a try with CONFIG_PPC_KUAP_DEBUG ?
Yes, I will try this out in the next few days.
Regards,
Samuel
Re: [PATCH] macintosh/ams: Adapt declaration of ams_i2c_remove() to earlier change
On Fri, Sep 16, 2022 at 11:08:02AM +0200, Uwe Kleine-König wrote:
> Commit ed5c2f5fd10d ("i2c: Make remove callback return void") changed
> the prototype of ams_i2c_remove() but failed to adapt the declaration.
> Catch up and fix the declaration accordingly.
>
> Fixes: ed5c2f5fd10d ("i2c: Make remove callback return void")
> Reported-by: kernel test robot
> Signed-off-by: Uwe Kleine-König
Applied to for-next, thanks!
signature.asc
Description: PGP signature
Re: [PATCH] powerpc: Save AMR/IAMR when switching tasks
Le 16/09/2022 à 07:05, Samuel Holland a écrit :
> With CONFIG_PREEMPT=y (involuntary preemption enabled), it is possible
> to switch away from a task inside copy_{from,to}_user. This left the CPU
> with userspace access enabled until after the next IRQ or privilege
> level switch, when AMR/IAMR got reset to AMR_KU[AE]P_BLOCKED. Then, when
> switching back to the original task, the userspace access would fault:
This is not supposed to happen. You never switch away from a task
magically. Task switch will always happen in an interrupt, that means
copy_{from,to}_user() get interrupted.
Whenever an interrupt is taken, kuap_save_amr_and_lock() macro is used
to save KUAP status into the stack then lock KUAP access. At interrupt
exit, kuap_kernel_restore() macro or function is used to restore KUAP
access from the stack. At the time the task switch happens, KUAP access
is expected to be locked. During task switch, the stack is switched so
the KUAP status is taken back from the new task's stack.
Your fix suggests that there is some path where the KUAP status is not
properly saved and/or restored. Did you try running with
CONFIG_PPC_KUAP_DEBUG ? It should warn whenever a KUAP access is left
unlocked.
>
>Kernel attempted to write user page (3fff7ab68190) - exploit attempt?
> (uid: 65536)
>[ cut here ]
>Bug: Write fault blocked by KUAP!
>WARNING: CPU: 56 PID: 4939 at arch/powerpc/mm/fault.c:228
> ___do_page_fault+0x7b4/0xaa0
>CPU: 56 PID: 4939 Comm: git Tainted: GW
> 5.19.8-5-gba424747260d #1
>NIP: c00555e4 LR: c00555e0 CTR: c079d9d0
>REGS: c0008f507370 TRAP: 0700 Tainted: GW
> (5.19.8-5-gba424747260d)
>MSR: 90021033 CR: 2804 XER: 2004
>CFAR: c0123780 IRQMASK: 3
>NIP [c00555e4] ___do_page_fault+0x7b4/0xaa0
>LR [c00555e0] ___do_page_fault+0x7b0/0xaa0
>Call Trace:
>[c0008f507610] [c00555e0] ___do_page_fault+0x7b0/0xaa0
> (unreliable)
>[c0008f5076c0] [c0055938] do_page_fault+0x68/0x130
>[c0008f5076f0] [c0008914] data_access_common_virt+0x194/0x1f0
>--- interrupt: 300 at __copy_tofrom_user_base+0x9c/0x5a4
...
>
> Fix this by saving and restoring the kernel-side AMR/IAMR values when
> switching tasks.
As explained above, KUAP access should be locked at that time, so saving
and restoring it should not have any effect. If it does, it means
something goes wrong somewhere else.
>
> Fixes: 890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU")
> Signed-off-by: Samuel Holland
> ---
> I have no idea if this is the right change to make, and it could be
> optimized, but my system has been stable with this patch for 5 days now.
>
> Without the patch, I hit the bug every few minutes when my load average
> is <1, and I hit it immediately if I try to do a parallel kernel build.
Great, then can you make a try with CONFIG_PPC_KUAP_DEBUG ?
>
> Because of the instability (file I/O randomly raises SIGBUS), I don't
> think anyone would run a system in this configuration, so I don't think
> this bug is exploitable.
>
> arch/powerpc/kernel/process.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 0fbda89cd1bb..69b189d63124 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1150,6 +1150,12 @@ static inline void save_sprs(struct thread_struct *t)
>*/
> t->tar = mfspr(SPRN_TAR);
> }
> + if (t->regs) {
> + if (mmu_has_feature(MMU_FTR_BOOK3S_KUAP))
> + t->regs->amr = mfspr(SPRN_AMR);
> + if (mmu_has_feature(MMU_FTR_BOOK3S_KUEP))
> + t->regs->iamr = mfspr(SPRN_IAMR);
> + }
> #endif
> }
>
> @@ -1228,6 +1234,13 @@ static inline void restore_sprs(struct thread_struct
> *old_thread,
> if (cpu_has_feature(CPU_FTR_P9_TIDR) &&
> old_thread->tidr != new_thread->tidr)
> mtspr(SPRN_TIDR, new_thread->tidr);
> + if (new_thread->regs) {
> + if (mmu_has_feature(MMU_FTR_BOOK3S_KUAP))
> + mtspr(SPRN_AMR, new_thread->regs->amr);
> + if (mmu_has_feature(MMU_FTR_BOOK3S_KUEP))
> + mtspr(SPRN_IAMR, new_thread->regs->iamr);
> + isync();
> + }
> #endif
>
> }
Re: [PATCH 1/2] powerpc/vmlinux.lds: Ensure STRICT_ALIGN_SIZE is at least page aligned
Christophe Leroy writes: > Le 16/09/2022 à 15:14, Michael Ellerman a écrit : >> Add a check that STRICT_ALIGN_SIZE is aligned to at least PAGE_SIZE. > > This cannot happen, the definitions in arch/powerpc/Kconfig don't allow > that. It can't happen yet :) There's enough combinations of DATA_SHIFT and PAGE_SIZE that it would be easy to add a new value for either and miss the implications. So I'd rather have a check. >> diff --git a/arch/powerpc/kernel/vmlinux.lds.S >> b/arch/powerpc/kernel/vmlinux.lds.S >> index fe22d940412f..4e56fc0ee42a 100644 >> --- a/arch/powerpc/kernel/vmlinux.lds.S >> +++ b/arch/powerpc/kernel/vmlinux.lds.S >> @@ -32,6 +32,10 @@ >> >> #define STRICT_ALIGN_SIZE (1 << CONFIG_DATA_SHIFT) >> >> +#if STRICT_ALIGN_SIZE < PAGE_SIZE >> +#error "CONFIG_DATA_SHIFT must be >= PAGE_SIZE" > > s/PAGE_SIZE/PAGE_SHIFT Thanks. cheers
Re: [PATCH v2 6/7] powerpc/64/build: merge .got and .toc input sections
Christophe Leroy writes:
> Le 16/09/2022 à 06:07, Nicholas Piggin a écrit :
>> Follow the binutils ld internal linker script and merge .got and .toc
>> input sections in the .got output section.
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>> arch/powerpc/kernel/vmlinux.lds.S | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/vmlinux.lds.S
>> b/arch/powerpc/kernel/vmlinux.lds.S
>> index 737825ae2ae0..3d96d51c8a5f 100644
>> --- a/arch/powerpc/kernel/vmlinux.lds.S
>> +++ b/arch/powerpc/kernel/vmlinux.lds.S
>> @@ -169,13 +169,12 @@ SECTIONS
>> }
>>
>> .got : AT(ADDR(.got) - LOAD_OFFSET) ALIGN(256) {
>> -*(.got)
>> +*(.got .toc)
>
> At the begining I was thinking that this change would jeopardise the
> below, but in fact the #ifdef below is pointless, because prom_init.o is
> built only when CONFIG_PPC_OF_BOOT_TRAMPOLINE is selected but
> CONFIG_PPC_OF_BOOT_TRAMPOLINE selects CONFIG_RELOCATABLE
>
> So all __prom_init_toc_ stuff can go away :
>
> arch/powerpc/include/asm/sections.h:extern char __prom_init_toc_start[];
> arch/powerpc/include/asm/sections.h:extern char __prom_init_toc_end[];
> arch/powerpc/kernel/prom_init_check.sh:__prom_init_toc_start
> __prom_init_toc_end btext_setup_display TOC.
> arch/powerpc/kernel/vmlinux.lds.S: __prom_init_toc_start = .;
> arch/powerpc/kernel/vmlinux.lds.S: __prom_init_toc_end = .;
Yes you're right.
Missed cleanup by me in 24d33ac5b8ff ("powerpc/64s: Make prom_init require
RELOCATABLE").
I'll send a patch tomorrow.
cheers
Re: [PATCH] macintosh/ams: Adapt declaration of ams_i2c_remove() to earlier change
Wolfram Sang writes: >> I don't know how to proceed with this fix. Squashing into the broken >> commit is out of the game as the commit is on a stable branch that is >> already merged in a few trees. Maybe let it go in via the i2c tree? > > I think it would be simplest if I put it on top of my for-next branch. Yeah please do. An ack if you need it: Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH 2/2] Discard .note.gnu.property sections in generic NOTES
Le 16/09/2022 à 21:40, Omar Sandoval a écrit :
> [Vous ne recevez pas souvent de courriers de osan...@osandov.com. D?couvrez
> pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>
> On Tue, Apr 28, 2020 at 06:21:05AM -0700, H.J. Lu wrote:
>> With the command-line option, -mx86-used-note=yes, the x86 assembler
>> in binutils 2.32 and above generates a program property note in a note
>> section, .note.gnu.property, to encode used x86 ISAs and features. But
>> kernel linker script only contains a single NOTE segment:
>>
>> PHDRS {
>> text PT_LOAD FLAGS(5);
>> data PT_LOAD FLAGS(6);
>> percpu PT_LOAD FLAGS(6);
>> init PT_LOAD FLAGS(7);
>> note PT_NOTE FLAGS(0);
>> }
>> SECTIONS
>> {
>> ...
>> .notes : AT(ADDR(.notes) - 0x8000) { __start_notes = .;
>> KEEP(*(.not
>> e.*)) __stop_notes = .; } :text :note
>> ...
>> }
>>
>> The NOTE segment generated by kernel linker script is aligned to 4 bytes.
>> But .note.gnu.property section must be aligned to 8 bytes on x86-64 and
>> we get
>>
>> [hjl@gnu-skx-1 linux]$ readelf -n vmlinux
>>
>> Displaying notes found in: .notes
>>OwnerData size Description
>>Xen 0x0006 Unknown note type: (0x0006)
>> description data: 6c 69 6e 75 78 00
>>Xen 0x0004 Unknown note type: (0x0007)
>> description data: 32 2e 36 00
>>xen-3.0 0x0005 Unknown note type: (0x006e6558)
>> description data: 08 00 00 00 03
>> readelf: Warning: note with invalid namesz and/or descsz found at offset 0x50
>> readelf: Warning: type: 0x, namesize: 0x006e6558, descsize:
>> 0x8000, alignment: 8
>> [hjl@gnu-skx-1 linux]$
>>
>> Since note.gnu.property section in kernel image is never used, this patch
>> discards .note.gnu.property sections in kernel linker script by adding
>>
>> /DISCARD/ : {
>>*(.note.gnu.property)
>> }
>>
>> before kernel NOTE segment in generic NOTES.
>>
>> Signed-off-by: H.J. Lu
>> Reviewed-by: Kees Cook
>> ---
>> include/asm-generic/vmlinux.lds.h | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/include/asm-generic/vmlinux.lds.h
>> b/include/asm-generic/vmlinux.lds.h
>> index 71e387a5fe90..95cd678428f4 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -833,7 +833,14 @@
>> #define TRACEDATA
>> #endif
>>
>> +/*
>> + * Discard .note.gnu.property sections which are unused and have
>> + * different alignment requirement from kernel note sections.
>> + */
>> #define NOTES
>> \
>> + /DISCARD/ : { \
>> + *(.note.gnu.property) \
>> + } \
>>.notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
>>__start_notes = .; \
>>KEEP(*(.note.*))\
>> --
>> 2.25.4
>>
>
> Hi, H.J.,
>
> I recently ran into this same .notes corruption when building kernels on
> Arch Linux.
>
> What ended up happening to this patch? It doesn't appear to have been
> merged, and I couldn't find any further discussion about it. I'm happy
> to resend it for you if you need a hand.
As far as I can see, ARM64 is doing something with that section, see
arch/arm64/include/asm/assembler.h
Instead of discarding that section, would it be enough to force
alignment of .notes to 8 bytes ?
Thanks
Christophe
>
> Thanks,
> Omar
