Re: gicv3-its driver crashes in crash dump kernel
On 06/06/2019 02:07 PM, Bhupesh Sharma wrote: > Hi, > > On Thu, Jun 6, 2019 at 3:45 AM Jonathan Richardson > wrote: >> >> Hi, >> >> As of the 5.0 kernel we're seeing the crash dump kernel crash when the >> gicv3-its driver calls gic_reserve_range(): >> >> root@bcm958804a8040c:~# echo c > /proc/sysrq-trigger >> [ 2285.405357] sysrq: SysRq : Trigger a crash >> [ 2285.409592] Kernel panic - not syncing: sysrq triggered crash >> [ 2285.415521] CPU: 0 PID: 4064 Comm: sh Kdump: loaded Tainted: G O 5.0.0 #1 >> [ 2285.423867] Hardware name: BRCM BRCM-SR/BRCM-SR, BIOS 0.1 Apr 26 2019 >> [ 2285.430510] Call trace: >> [ 2285.433041] dump_backtrace+0x0/0x1a0 >> [ 2285.436818] show_stack+0x14/0x20 >> [ 2285.440237] dump_stack+0x90/0xb4 >> [ 2285.443657] panic+0x13c/0x2ec >> [ 2285.446807] sysrq_handle_crash+0x14/0x18 >> [ 2285.450942] __handle_sysrq+0xa4/0x190 >> [ 2285.454808] write_sysrq_trigger+0x64/0x80 >> [ 2285.459034] proc_reg_write+0x60/0xa8 >> [ 2285.462812] __vfs_write+0x30/0x180 >> [ 2285.466409] vfs_write+0xa4/0x1b8 >> [ 2285.469827] ksys_write+0x60/0xd8 >> [ 2285.473246] __arm64_sys_write+0x14/0x20 >> [ 2285.477292] el0_svc_common+0x60/0x100 >> [ 2285.481158] el0_svc_handler+0x2c/0x88 >> [ 2285.485025] el0_svc+0x8/0xc >> [ 2285.488001] SMP: stopping secondary CPUs >> [ 2285.492349] Starting crashdump kernel... >> [ 2285.496395] Bye! >> [ 0.00] Booting Linux on physical CPU 0x00 [0x410fd083] >> [ 0.00] Linux version 5.0.0 (oe-user@oe-host) (gcc version 7.3.0 (GCC)) >> #1 SMP Fri Apr 26 03:06:15 UTC9 >> [ 0.00] Machine model: Stingray PS1100R (BCM958804A8040) >> [ 0.00] earlycon: uart8250_log0 at MMIO32 0x68a1 (options '') >> [ 0.00] printk: bootconsole [uart8250_log0] enabled >> [ 0.00] Malformed early option 'loglevel' >> [ 0.00] efi: Getting EFI parameters from FDT: >> [ 0.00] efi: EFI v2.70 by EDK II >> [ 0.00] efi: SMBIOS=0x85cd SMBIOS 3.0=0x85a2 ACPI 2.0=0x85d9 >> MEMATTR=0x89352018 MEMRE >> [ 0.00] cannot allocate crashkernel (size:0x2000) >> [ 0.00] Reserving 2KB of memory at 0xffdff000 for elfcorehdr >> [ 0.00] cma: Failed to reserve 1024 MiB >> [ 0.00] psci: probing for conduit method from DT. >> I: GICv3 without legacy support detected. ARM GICV3 driver initialized in EL3 >> 0.00] psci: PSCIv1.1 detected in firmware. >> [ 0.00] psci: Using standard PSCI v0.2 function IDs >> [ 0.00] psci: MIGRATE_INFO_TYPE not supported. >> [ 0.00] psci: SMC Calling Convention v1.1 >> [ 0.00] random: get_random_bytes called from start_kernel+0xa8/0x3ec >> with crng_init=0 >> [ 0.00] percpu: Embedded 23 pages/cpu @(ptrval) s53784 r8192 >> d32232 u94208 >> [ 0.00] Detected PIPT I-cache on CPU0 >> [ 0.00] CPU features: detected: EL2 vector hardening >> [ 0.00] Speculative Store Bypass Disable mitigation not required >> [ 0.00] Built 1 zonelists, mobility grouping on. Total pages: 130974 >> [ 0.00] Kernel command line: FS2:\Image.1 root=/dev/mmcblk0p3 rw >> rootwait earlycon=uart8250_log,mmio1 >> [ 0.00] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) >> [ 0.00] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) >> [ 0.00] Memory: 472776K/532212K available (9340K kernel code, 734K >> rwdata, 3412K rodata, 832K init, 35) >> [ 0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 >> [ 0.00] rcu: Hierarchical RCU implementation. >> [ 0.00] rcu: RCU event tracing is enabled. >> [ 0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 >> jiffies. >> [ 0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 >> [ 0.00] GICv3: GIC: Using split EOI/Deactivate mode >> [ 0.00] GICv3: Distributor has no Range Selector support >> [ 0.00] GICv3: no VLPI support, no direct LPI support >> [ 0.00] GICv3: CPU0: found redistributor 0 region 0:0x63e0 >> [ 0.00] ITS [mem 0x63c2-0x63c2] >> [ 0.00] ITS@0x63c2: allocated 65536 Devices @fd48 (flat, >> esz 8, psz 64K, shr 0) >> [ 0.00] ITS: using cache flushing for cmd queue >> [ 0.00] Unable to handle kernel paging request at virtual address >> 800975c36004 >> [ 0.00] Mem abort info: >> [ 0.00] ESR = 0x9605 >> [ 0.00] Exception class = DABT (current EL), IL = 32 bits >> [ 0.00] SET = 0, FnV = 0 >> [ 0.00] EA = 0, S1PTW = 0 >> [ 0.00] Data abort info: >> [ 0.00] ISV = 0, ISS = 0x0005 >> [ 0.00] CM = 0, WnR = 0 >> [ 0.00] swapper pgtable: 4k pages, 48-bit VAs, pgdp = (ptrval) >> [ 0.00] [800975c36004] pgd=ffdf8003, pud= >> [ 0.00] Internal error: Oops: 9605 [#1] SMP >> [ 0.00] Modules linked in: >> [ 0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.0.0 #1 >> [ 0.00] Hardware name: Stingray PS1100R (BCM958804A8040) (DT) >> [ 0.00] pstate: 6085 (nZCv daIf -PAN -UAO) >> [ 0.00] pc :
Re: gicv3-its driver crashes in crash dump kernel
Hi, On Thu, Jun 6, 2019 at 3:45 AM Jonathan Richardson wrote: > > Hi, > > As of the 5.0 kernel we're seeing the crash dump kernel crash when the > gicv3-its driver calls gic_reserve_range(): > > root@bcm958804a8040c:~# echo c > /proc/sysrq-trigger > [ 2285.405357] sysrq: SysRq : Trigger a crash > [ 2285.409592] Kernel panic - not syncing: sysrq triggered crash > [ 2285.415521] CPU: 0 PID: 4064 Comm: sh Kdump: loaded Tainted: G O 5.0.0 #1 > [ 2285.423867] Hardware name: BRCM BRCM-SR/BRCM-SR, BIOS 0.1 Apr 26 2019 > [ 2285.430510] Call trace: > [ 2285.433041] dump_backtrace+0x0/0x1a0 > [ 2285.436818] show_stack+0x14/0x20 > [ 2285.440237] dump_stack+0x90/0xb4 > [ 2285.443657] panic+0x13c/0x2ec > [ 2285.446807] sysrq_handle_crash+0x14/0x18 > [ 2285.450942] __handle_sysrq+0xa4/0x190 > [ 2285.454808] write_sysrq_trigger+0x64/0x80 > [ 2285.459034] proc_reg_write+0x60/0xa8 > [ 2285.462812] __vfs_write+0x30/0x180 > [ 2285.466409] vfs_write+0xa4/0x1b8 > [ 2285.469827] ksys_write+0x60/0xd8 > [ 2285.473246] __arm64_sys_write+0x14/0x20 > [ 2285.477292] el0_svc_common+0x60/0x100 > [ 2285.481158] el0_svc_handler+0x2c/0x88 > [ 2285.485025] el0_svc+0x8/0xc > [ 2285.488001] SMP: stopping secondary CPUs > [ 2285.492349] Starting crashdump kernel... > [ 2285.496395] Bye! > [ 0.00] Booting Linux on physical CPU 0x00 [0x410fd083] > [ 0.00] Linux version 5.0.0 (oe-user@oe-host) (gcc version 7.3.0 (GCC)) > #1 SMP Fri Apr 26 03:06:15 UTC9 > [ 0.00] Machine model: Stingray PS1100R (BCM958804A8040) > [ 0.00] earlycon: uart8250_log0 at MMIO32 0x68a1 (options '') > [ 0.00] printk: bootconsole [uart8250_log0] enabled > [ 0.00] Malformed early option 'loglevel' > [ 0.00] efi: Getting EFI parameters from FDT: > [ 0.00] efi: EFI v2.70 by EDK II > [ 0.00] efi: SMBIOS=0x85cd SMBIOS 3.0=0x85a2 ACPI 2.0=0x85d9 > MEMATTR=0x89352018 MEMRE > [ 0.00] cannot allocate crashkernel (size:0x2000) > [ 0.00] Reserving 2KB of memory at 0xffdff000 for elfcorehdr > [ 0.00] cma: Failed to reserve 1024 MiB > [ 0.00] psci: probing for conduit method from DT. > I: GICv3 without legacy support detected. ARM GICV3 driver initialized in EL3 > 0.00] psci: PSCIv1.1 detected in firmware. > [ 0.00] psci: Using standard PSCI v0.2 function IDs > [ 0.00] psci: MIGRATE_INFO_TYPE not supported. > [ 0.00] psci: SMC Calling Convention v1.1 > [ 0.00] random: get_random_bytes called from start_kernel+0xa8/0x3ec with > crng_init=0 > [ 0.00] percpu: Embedded 23 pages/cpu @(ptrval) s53784 r8192 > d32232 u94208 > [ 0.00] Detected PIPT I-cache on CPU0 > [ 0.00] CPU features: detected: EL2 vector hardening > [ 0.00] Speculative Store Bypass Disable mitigation not required > [ 0.00] Built 1 zonelists, mobility grouping on. Total pages: 130974 > [ 0.00] Kernel command line: FS2:\Image.1 root=/dev/mmcblk0p3 rw rootwait > earlycon=uart8250_log,mmio1 > [ 0.00] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) > [ 0.00] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) > [ 0.00] Memory: 472776K/532212K available (9340K kernel code, 734K > rwdata, 3412K rodata, 832K init, 35) > [ 0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 > [ 0.00] rcu: Hierarchical RCU implementation. > [ 0.00] rcu: RCU event tracing is enabled. > [ 0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 > jiffies. > [ 0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 > [ 0.00] GICv3: GIC: Using split EOI/Deactivate mode > [ 0.00] GICv3: Distributor has no Range Selector support > [ 0.00] GICv3: no VLPI support, no direct LPI support > [ 0.00] GICv3: CPU0: found redistributor 0 region 0:0x63e0 > [ 0.00] ITS [mem 0x63c2-0x63c2] > [ 0.00] ITS@0x63c2: allocated 65536 Devices @fd48 (flat, > esz 8, psz 64K, shr 0) > [ 0.00] ITS: using cache flushing for cmd queue > [ 0.00] Unable to handle kernel paging request at virtual address > 800975c36004 > [ 0.00] Mem abort info: > [ 0.00] ESR = 0x9605 > [ 0.00] Exception class = DABT (current EL), IL = 32 bits > [ 0.00] SET = 0, FnV = 0 > [ 0.00] EA = 0, S1PTW = 0 > [ 0.00] Data abort info: > [ 0.00] ISV = 0, ISS = 0x0005 > [ 0.00] CM = 0, WnR = 0 > [ 0.00] swapper pgtable: 4k pages, 48-bit VAs, pgdp = (ptrval) > [ 0.00] [800975c36004] pgd=ffdf8003, pud= > [ 0.00] Internal error: Oops: 9605 [#1] SMP > [ 0.00] Modules linked in: > [ 0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.0.0 #1 > [ 0.00] Hardware name: Stingray PS1100R (BCM958804A8040) (DT) > [ 0.00] pstate: 6085 (nZCv daIf -PAN -UAO) > [ 0.00] pc : efi_mem_reserve_persistent+0x60/0x1b8 > [ 0.00] lr : efi_mem_reserve_persistent+0x1a0/0x1b8 > [ 0.00] sp : 10dd3c30 > [ 0.00] x29:
Re: gicv3-its driver crashes in crash dump kernel
On Thu, 6 Jun 2019 at 16:32, Marc Zyngier wrote:
>
> Hi Jonathan,
>
> On 05/06/2019 23:14, Jonathan Richardson wrote:
> > Hi,
> >
> > As of the 5.0 kernel we're seeing the crash dump kernel crash when the
> > gicv3-its driver calls gic_reserve_range():
>
> [...]
>
> > On crash dump boot, gic calls the same function,
> > efi_mem_reserve_persistent, finds the entry that was on initial boot
> > (0xc3836000), converts it to a va, and then crashes when it's used on this
> > line:
> > atomic_fetch_add_unless(>count
> >
> > In the previous revision of this file, kmalloc was called and this worked
> > fine.
> >
> > [0.00] GICv3: GIC: Using split EOI/Deactivate mode
> > [0.00] GICv3: Distributor has no Range Selector support
> > [0.00] GICv3: no VLPI support, no direct LPI support
> > [0.00] GICv3: CPU0: found redistributor 1 region
> > 0:0x63e2
> > [0.00] ITS [mem 0x63c2-0x63c2]
> > [0.00] ITS@0x63c2: allocated 32768 Devices @fd48
> > (flat, esz 8, psz 64K, shr 0)
> > [0.00] ITS: using cache flushing for cmd queue
> > [0.00] iter: prsv = 0xc3836000
> > [0.00] rsv = 0x43836000
> > [0.00] Unable to handle kernel paging request at virtual address
> > 80a343836004
> > [0.00] Mem abort info:
> > [0.00] ESR = 0x9604
> > [0.00] Exception class = DABT (current EL), IL = 32 bits
> >
> > int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> > {
> >
> > for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) {
> > printk("iter: prsv = 0x%x\n", prsv);
> > rsv = __va(prsv);
> > printk("rsv = 0x%x\n", rsv);
> > index = atomic_fetch_add_unless(>count, 1, rsv->size);
> > if (index < rsv->size) {
> > rsv->entry[index].base = addr;
> > rsv->entry[index].size = size;
> >
> >
> > It looks like the change has broken crash dump kernel, but I'm not
> > sure what it should be doing instead. Has anyone used gicv3-its with
> > crash dump kernel after this change?
>
> I've definitely used kexec/kdump since, both in VMs and bare-metal.
> Other than __va() going horribly wrong, I have no idea.
>
> Ard, do you have any suggestion?
>
Not sure. It would be helpful to have the entire log, though.
including the normal kernel boot. I can take a look tomorrow.
Re: [PATCH] efi: Fix TPM code build failure on ARM
On Thu, Jun 6, 2019 at 4:39 AM Ard Biesheuvel wrote: > > On Wed, 5 Jun 2019 at 20:11, Matthew Garrett > wrote: > > > > asm/early_ioremap.h needs to be #included before tpm_eventlog.h in order > > to ensure that early_memremap is available. > > > > Doesn't that make it tpm_eventlog.h's job to #include it? tpm_eventlog.h doesn't use early_memremap directly, it's expanded from the macros declared in tpm.c .
Re: [PATCH V2] tpm: Don't duplicate events from the final event log in the TCG2 log
On Wed, Jun 05, 2019 at 11:05:15AM -0700, Matthew Garrett wrote: > After the first call to GetEventLog() on UEFI systems using the TCG2 > crypto agile log format, any further log events (other than those > triggered by ExitBootServices()) will be logged in both the main log and > also in the Final Events Log. While the kernel only calls GetEventLog() > immediately before ExitBootServices(), we can't control whether earlier > parts of the boot process have done so. This will result in log entries > that exist in both logs, and so the current approach of simply appending > the Final Event Log to the main log will result in events being > duplicated. > > We can avoid this problem by looking at the size of the Final Event Log > just before we call ExitBootServices() and exporting this to the main > kernel. The kernel can then skip over all events that occured before > ExitBootServices() and only append events that were not also logged to > the main log. > > Signed-off-by: Matthew Garrett > Reported-by: Joe Richey > Suggested-by: Joe Richey Reviewed-by: Jarkko Sakkinen /Jarkko
Re: [PATCH for-4.9-stable] efi/libstub: Unify command line param parsing
On Thu, Jun 06, 2019 at 12:25:13PM +0200, Ard Biesheuvel wrote: > Commit 60f38de7a8d4e816100ceafd1b382df52527bd50 upstream. > > Merge the parsing of the command line carried out in arm-stub.c with > the handling in efi_parse_options(). Note that this also fixes the > missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin > command line should supersede the one passed by the firmware. > > Signed-off-by: Ard Biesheuvel > Cc: Linus Torvalds > Cc: Matt Fleming > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: b...@redhat.com > Cc: bhsha...@redhat.com > Cc: b...@alien8.de > Cc: eug...@hp.com > Cc: evgeny.kalu...@intel.com > Cc: jh...@codeaurora.org > Cc: leif.lindh...@linaro.org > Cc: linux-efi@vger.kernel.org > Cc: mark.rutl...@arm.com > Cc: roy.fr...@cavium.com > Cc: rruig...@codeaurora.org > Link: > http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org > Signed-off-by: Ingo Molnar > [ardb: fix up merge conflicts with 4.9.180] > Signed-off-by: Ard Biesheuvel > --- > This fixes the GCC build issue reported by Eike. > > Note that testing of arm64 stable kernels should cover CONFIG_RANDOMIZE_BASE, > since it has a profound impact on how the kernel binary gets put together. Good idea. Is that in any arm64 stable kernel configuration? If not, I can ask the Linaro build/test people to add it there. And isn't it part of kernel.ci already? We get the results of that for stable releases. Anyway, thanks for the patch, now queued up. thanks, greg k-h
Re: gicv3-its driver crashes in crash dump kernel
Hi Jonathan,
On 05/06/2019 23:14, Jonathan Richardson wrote:
> Hi,
>
> As of the 5.0 kernel we're seeing the crash dump kernel crash when the
> gicv3-its driver calls gic_reserve_range():
[...]
> On crash dump boot, gic calls the same function, efi_mem_reserve_persistent,
> finds the entry that was on initial boot (0xc3836000), converts it to a va,
> and then crashes when it's used on this line:
> atomic_fetch_add_unless(>count
>
> In the previous revision of this file, kmalloc was called and this worked
> fine.
>
> [0.00] GICv3: GIC: Using split EOI/Deactivate mode
> [0.00] GICv3: Distributor has no Range Selector support
> [0.00] GICv3: no VLPI support, no direct LPI support
> [0.00] GICv3: CPU0: found redistributor 1 region 0:0x63e2
> [0.00] ITS [mem 0x63c2-0x63c2]
> [0.00] ITS@0x63c2: allocated 32768 Devices @fd48
> (flat, esz 8, psz 64K, shr 0)
> [0.00] ITS: using cache flushing for cmd queue
> [0.00] iter: prsv = 0xc3836000
> [0.00] rsv = 0x43836000
> [0.00] Unable to handle kernel paging request at virtual address
> 80a343836004
> [0.00] Mem abort info:
> [0.00] ESR = 0x9604
> [0.00] Exception class = DABT (current EL), IL = 32 bits
>
> int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> {
>
> for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) {
> printk("iter: prsv = 0x%x\n", prsv);
> rsv = __va(prsv);
> printk("rsv = 0x%x\n", rsv);
> index = atomic_fetch_add_unless(>count, 1, rsv->size);
> if (index < rsv->size) {
> rsv->entry[index].base = addr;
> rsv->entry[index].size = size;
>
>
> It looks like the change has broken crash dump kernel, but I'm not
> sure what it should be doing instead. Has anyone used gicv3-its with
> crash dump kernel after this change?
I've definitely used kexec/kdump since, both in VMs and bare-metal.
Other than __va() going horribly wrong, I have no idea.
Ard, do you have any suggestion?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH for-4.9-stable] efi/libstub: Unify command line param parsing
On Thu, 6 Jun 2019 at 15:22, Sasha Levin wrote: > > On Thu, Jun 06, 2019 at 12:25:13PM +0200, Ard Biesheuvel wrote: > >Commit 60f38de7a8d4e816100ceafd1b382df52527bd50 upstream. > > > >Merge the parsing of the command line carried out in arm-stub.c with > >the handling in efi_parse_options(). Note that this also fixes the > >missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin > >command line should supersede the one passed by the firmware. > > > >Signed-off-by: Ard Biesheuvel > >Cc: Linus Torvalds > >Cc: Matt Fleming > >Cc: Peter Zijlstra > >Cc: Thomas Gleixner > >Cc: b...@redhat.com > >Cc: bhsha...@redhat.com > >Cc: b...@alien8.de > >Cc: eug...@hp.com > >Cc: evgeny.kalu...@intel.com > >Cc: jh...@codeaurora.org > >Cc: leif.lindh...@linaro.org > >Cc: linux-efi@vger.kernel.org > >Cc: mark.rutl...@arm.com > >Cc: roy.fr...@cavium.com > >Cc: rruig...@codeaurora.org > >Link: > >http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org > >Signed-off-by: Ingo Molnar > >[ardb: fix up merge conflicts with 4.9.180] > >Signed-off-by: Ard Biesheuvel > >--- > >This fixes the GCC build issue reported by Eike. > > > >Note that testing of arm64 stable kernels should cover CONFIG_RANDOMIZE_BASE, > >since it has a profound impact on how the kernel binary gets put together. > > Should this fix be applied to 4.9 as well? > > I see it in 4.14+ > I don't understand this question. The fix is proposed for v4.9 because it fixes a build error with GCC that was caused by a backport of one of the clang enablement patches.
Re: [PATCH for-4.9-stable] efi/libstub: Unify command line param parsing
On Thu, Jun 06, 2019 at 12:25:13PM +0200, Ard Biesheuvel wrote: Commit 60f38de7a8d4e816100ceafd1b382df52527bd50 upstream. Merge the parsing of the command line carried out in arm-stub.c with the handling in efi_parse_options(). Note that this also fixes the missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin command line should supersede the one passed by the firmware. Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: b...@redhat.com Cc: bhsha...@redhat.com Cc: b...@alien8.de Cc: eug...@hp.com Cc: evgeny.kalu...@intel.com Cc: jh...@codeaurora.org Cc: leif.lindh...@linaro.org Cc: linux-efi@vger.kernel.org Cc: mark.rutl...@arm.com Cc: roy.fr...@cavium.com Cc: rruig...@codeaurora.org Link: http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org Signed-off-by: Ingo Molnar [ardb: fix up merge conflicts with 4.9.180] Signed-off-by: Ard Biesheuvel --- This fixes the GCC build issue reported by Eike. Note that testing of arm64 stable kernels should cover CONFIG_RANDOMIZE_BASE, since it has a profound impact on how the kernel binary gets put together. Should this fix be applied to 4.9 as well? I see it in 4.14+ -- Thanks, Sasha
[RFC PATCH 6/6] efi / ras: CCIX Agent internal error reporting
The CCIX 1.0 Base specification defines an internal agent error,
for which the specific data present afte the header is vendor
defined.
Signed-off-by: Jonathan Cameron
---
drivers/acpi/apei/ghes.c | 4 ++
drivers/firmware/efi/cper-ccix.c | 43 +
include/linux/cper.h | 29 +++
include/ras/ras_event.h | 64
4 files changed, 140 insertions(+)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 2cabac7a344c7..0e21b2a9c3c50 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -520,6 +520,10 @@ static void ghes_handle_ccix_per(struct
acpi_hest_generic_data *gdata, int sev)
trace_ccix_link_error_event(payload, err_seq, sev,
ccix_link_err_ven_len_get(payload));
break;
+ case CCIX_AGENT_INTERNAL_ERROR:
+ trace_ccix_agent_error_event(payload, err_seq, sev,
+
ccix_agent_err_ven_len_get(payload));
+ break;
default:
/* Unknown error type */
pr_info("CCIX error of unknown or vendor defined type\n");
diff --git a/drivers/firmware/efi/cper-ccix.c b/drivers/firmware/efi/cper-ccix.c
index 1a9661a6c49f4..316a7ad3fec69 100644
--- a/drivers/firmware/efi/cper-ccix.c
+++ b/drivers/firmware/efi/cper-ccix.c
@@ -583,6 +583,38 @@ static int cper_ccix_link_err_details(const char *pfx,
return 0;
}
+static int cper_ccix_agent_err_details(const char *pfx,
+ struct acpi_hest_generic_data *gdata)
+{
+ struct cper_ccix_agent_err *full_agent_err;
+ struct cper_sec_ccix_agent_err *agent_err;
+ u16 vendor_data_len;
+ int i;
+
+ if (gdata->error_data_length < sizeof(*full_agent_err))
+ return -ENOSPC;
+
+ full_agent_err = acpi_hest_get_payload(gdata);
+
+ agent_err = _agent_err->agent_record;
+
+ if (agent_err->validation_bits &
CCIX_AGENT_INTERNAL_ERR_VENDOR_DATA_VALID) {
+ if (gdata->error_data_length < sizeof(*full_agent_err) + 4)
+ return -ENOSPC;
+
+ vendor_data_len = agent_err->vendor_data[0] & GENMASK(15, 0);
+ if (gdata->error_data_length <
+ sizeof(*full_agent_err) + vendor_data_len)
+ return -ENOSPC;
+
+ for (i = 0; i < vendor_data_len/4 - 1; i++)
+ printk("%s""Vendor%d: 0x%08x\n", pfx, i,
+ agent_err->vendor_data[i + 1]);
+ }
+
+ return 0;
+}
+
int cper_print_ccix_per(const char *pfx, struct acpi_hest_generic_data *gdata)
{
struct cper_sec_ccix_header *header = acpi_hest_get_payload(gdata);
@@ -652,6 +684,8 @@ int cper_print_ccix_per(const char *pfx, struct
acpi_hest_generic_data *gdata)
return cper_ccix_port_err_details(pfx, gdata);
case CCIX_LINK_ERROR:
return cper_ccix_link_err_details(pfx, gdata);
+ case CCIX_AGENT_INTERNAL_ERROR:
+ return cper_ccix_agent_err_details(pfx, gdata);
default:
/* Vendor defined so no formatting be done */
break;
@@ -871,3 +905,12 @@ const char *cper_ccix_link_err_unpack(struct trace_seq *p,
return ret;
}
+
+void cper_ccix_agent_err_pack(const struct cper_sec_ccix_agent_err
*agent_record,
+ struct cper_ccix_agent_err_compact *cagent_err,
+ const u16 vendor_data_len,
+ u8 *vendor_data)
+{
+ cagent_err->validation_bits = agent_record->validation_bits;
+ memcpy(vendor_data, _record->vendor_data[1], vendor_data_len);
+}
diff --git a/include/linux/cper.h b/include/linux/cper.h
index 05d73604dfd2b..961c4ff7f0791 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -795,6 +795,30 @@ struct cper_ccix_link_err_compact {
__u8credit_type;
};
+struct cper_sec_ccix_agent_err {
+ __u32 validation_bits;
+#define CCIX_AGENT_INTERNAL_ERR_VENDOR_DATA_VALID BIT(0)
+ __u32 vendor_data[];
+};
+
+struct cper_ccix_agent_err {
+ struct cper_sec_ccix_header header;
+ __u32 ccix_header[CCIX_PER_LOG_HEADER_DWS];
+ struct cper_sec_ccix_agent_err agent_record;
+};
+
+static inline u16 ccix_agent_err_ven_len_get(struct cper_ccix_agent_err
*agent_err)
+{
+ if (agent_err->agent_record.validation_bits &
CCIX_AGENT_INTERNAL_ERR_VENDOR_DATA_VALID)
+ return agent_err->agent_record.vendor_data[0] & 0x;
+ else
+ return 0;
+}
+
+struct cper_ccix_agent_err_compact {
+ __u32 validation_bits;
+};
+
/* Reset to default packing */
#pragma pack()
@@ -847,6 +871,11 @@ void cper_ccix_link_err_pack(const struct
cper_sec_ccix_link_error *link_record,
const char *cper_ccix_link_err_unpack(struct
[RFC PATCH 4/6] efi / ras: CCIX Port error reporting
The CCIX 1.0 base specification defines a CCIX protocol layer port.
The specification provides a mechanism for detailed error logging
for these ports. The UEFI 2.8 specification includes a CCIX CPER
record for firmware first handling to report these errors to the
operating system.
This patch is very similar to the support previously added for
for CCIX Memory Errors and provides both logging and RAS tracepoint
for this error class.
Signed-off-by: Jonathan Cameron
---
drivers/acpi/apei/ghes.c | 4 +
drivers/firmware/efi/cper-ccix.c | 123 +++
include/linux/cper.h | 42 +++
include/ras/ras_event.h | 66 +
4 files changed, 235 insertions(+)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index a412cfb7c8657..2b2c0df204523 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -512,6 +512,10 @@ static void ghes_handle_ccix_per(struct
acpi_hest_generic_data *gdata, int sev)
trace_ccix_atc_error_event(payload, err_seq, sev,
ccix_atc_err_ven_len_get(payload));
break;
+ case CCIX_PORT_ERROR:
+ trace_ccix_port_error_event(payload, err_seq, sev,
+ ccix_port_err_ven_len_get(payload));
+ break;
default:
/* Unknown error type */
pr_info("CCIX error of unknown or vendor defined type\n");
diff --git a/drivers/firmware/efi/cper-ccix.c b/drivers/firmware/efi/cper-ccix.c
index 1b88458eae32f..fcf77834b9894 100644
--- a/drivers/firmware/efi/cper-ccix.c
+++ b/drivers/firmware/efi/cper-ccix.c
@@ -428,6 +428,81 @@ static int cper_ccix_atc_err_details(const char *pfx,
return 0;
}
+static const char * const ccix_port_err_type_strs[] = {
+ "Generic Bus / Slave Error",
+ "Bus Parity / ECC Error",
+ "BDF Not Present",
+ "Invalid Address",
+ "Invalid AgentID",
+ "Bus Timeout",
+ "Hang",
+ "Egress Blocked",
+};
+
+static const char *cper_ccix_port_err_type_str(__u8 op)
+{
+ return op < ARRAY_SIZE(ccix_port_err_type_strs) ?
+ ccix_port_err_type_strs[op] : "Reserved";
+}
+
+static const char * const ccix_port_err_op_strs[] = {
+ "Command",
+ "Read",
+ "Write",
+};
+
+static const char *cper_ccix_port_err_op_str(__u8 op)
+{
+ return op < ARRAY_SIZE(ccix_port_err_op_strs) ?
+ ccix_port_err_op_strs[op] : "Reserved";
+}
+
+static int cper_ccix_port_err_details(const char *pfx,
+struct acpi_hest_generic_data *gdata)
+{
+ struct cper_ccix_port_error *full_port_err;
+ struct cper_sec_ccix_port_error *port_err;
+ u16 vendor_data_len;
+ int i;
+
+ if (gdata->error_data_length < sizeof(*full_port_err))
+ return -ENOSPC;
+
+ full_port_err = acpi_hest_get_payload(gdata);
+
+ port_err = _port_err->port_record;
+
+ if (port_err->validation_bits & CCIX_PORT_ERR_TYPE_VALID)
+ printk("%s""Error Type: %s\n", pfx,
+ cper_ccix_port_err_type_str(port_err->err_type));
+
+ if (port_err->validation_bits & CCIX_PORT_ERR_OP_VALID)
+ printk("%s""Operation: %s\n", pfx,
+ cper_ccix_port_err_op_str(port_err->op_type));
+
+ /* CHECK THE AER EQUIVALENT */
+ if (port_err->validation_bits & CCIX_PORT_ERR_MESSAGE_VALID) {
+ for (i = 0; i < ARRAY_SIZE(port_err->message); i++)
+ printk("%s""Message%d: 0x%08x\n", pfx, i,
+ port_err->message[i]);
+ }
+
+ if (port_err->validation_bits & CCIX_PORT_ERR_VENDOR_DATA_VALID) {
+ if (gdata->error_data_length < sizeof(*full_port_err) + 4)
+ return -ENOSPC;
+
+ vendor_data_len = port_err->vendor_data[0] & GENMASK(15, 0);
+ if (gdata->error_data_length < sizeof(*full_port_err) +
vendor_data_len)
+ return -ENOSPC;
+
+ for (i = 0; i < vendor_data_len / 4 - 1; i++)
+ printk("%s""Vendor%d: 0x%08x\n", pfx, i,
+ port_err->vendor_data[i + 1]);
+ }
+
+ return 0;
+}
+
int cper_print_ccix_per(const char *pfx, struct acpi_hest_generic_data *gdata)
{
struct cper_sec_ccix_header *header = acpi_hest_get_payload(gdata);
@@ -493,6 +568,8 @@ int cper_print_ccix_per(const char *pfx, struct
acpi_hest_generic_data *gdata)
return cper_ccix_cache_err_details(pfx, gdata);
case CCIX_ATC_ERROR:
return cper_ccix_atc_err_details(pfx, gdata);
+ case CCIX_PORT_ERROR:
+ return cper_ccix_port_err_details(pfx, gdata);
default:
/* Vendor defined so no formatting be done */
break;
@@ -608,3 +685,49 @@ const char
[RFC PATCH 3/6] efi / ras: CCIX Address Translation Cache error reporting
CCIX devices tend to make heavy use of ATCs. The CCIX base
specification defines a protocol error message (PER) that
describes errors reported by such caches. The UEFI 2.8
specification includes a CCIX CPER record for firmware first
handling to report these errors to the operating system.
This patch is very similar to the support previously added
for CCIX Memory Errors and provides both logging and RAS
tracepoint for this error class.
Signed-off-by: Jonathan Cameron
---
drivers/acpi/apei/ghes.c | 4 ++
drivers/firmware/efi/cper-ccix.c | 84
include/linux/cper.h | 39 +++
include/ras/ras_event.h | 67 +
4 files changed, 194 insertions(+)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1afe47f7bb5b5..a412cfb7c8657 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -508,6 +508,10 @@ static void ghes_handle_ccix_per(struct
acpi_hest_generic_data *gdata, int sev)
trace_ccix_cache_error_event(payload, err_seq, sev,
ccix_cache_err_ven_len_get(payload));
break;
+ case CCIX_ATC_ERROR:
+ trace_ccix_atc_error_event(payload, err_seq, sev,
+ ccix_atc_err_ven_len_get(payload));
+ break;
default:
/* Unknown error type */
pr_info("CCIX error of unknown or vendor defined type\n");
diff --git a/drivers/firmware/efi/cper-ccix.c b/drivers/firmware/efi/cper-ccix.c
index 53a466eb05b7d..1b88458eae32f 100644
--- a/drivers/firmware/efi/cper-ccix.c
+++ b/drivers/firmware/efi/cper-ccix.c
@@ -391,6 +391,43 @@ static int cper_ccix_cache_err_details(const char *pfx,
return 0;
}
+static int cper_ccix_atc_err_details(const char *pfx,
+struct acpi_hest_generic_data *gdata)
+{
+ struct cper_ccix_atc_error *full_atc_err;
+ struct cper_sec_ccix_atc_error *atc_err;
+ u16 vendor_data_len;
+ int i;
+
+ if (gdata->error_data_length < sizeof(*full_atc_err))
+ return -ENOSPC;
+
+ full_atc_err = acpi_hest_get_payload(gdata);
+
+ atc_err = _atc_err->atc_record;
+
+ if (atc_err->validation_bits & CCIX_ATC_ERR_OP_VALID)
+ printk("%s""Operation: %s\n", pfx,
+ cper_ccix_cache_err_op_str(atc_err->op_type));
+
+ if (atc_err->validation_bits & CCIX_ATC_ERR_INSTANCE_ID_VALID)
+ printk("%s""Instance ID: %d\n", pfx, atc_err->instance);
+
+ if (atc_err->validation_bits & CCIX_ATC_ERR_VENDOR_DATA_VALID) {
+ if (gdata->error_data_length < sizeof(*full_atc_err) + 4)
+ return -ENOSPC;
+ vendor_data_len = atc_err->vendor_data[0] & GENMASK(15, 0);
+ if (gdata->error_data_length < sizeof(*full_atc_err) +
vendor_data_len)
+ return -ENOSPC;
+
+ for (i = 0; i < vendor_data_len / 4 - 1; i++)
+ printk("%s""Vendor%d: 0x%08x\n", pfx, i,
+ atc_err->vendor_data[i + 1]);
+ }
+
+ return 0;
+}
+
int cper_print_ccix_per(const char *pfx, struct acpi_hest_generic_data *gdata)
{
struct cper_sec_ccix_header *header = acpi_hest_get_payload(gdata);
@@ -454,6 +491,8 @@ int cper_print_ccix_per(const char *pfx, struct
acpi_hest_generic_data *gdata)
return cper_ccix_mem_err_details(pfx, gdata);
case CCIX_CACHE_ERROR:
return cper_ccix_cache_err_details(pfx, gdata);
+ case CCIX_ATC_ERROR:
+ return cper_ccix_atc_err_details(pfx, gdata);
default:
/* Vendor defined so no formatting be done */
break;
@@ -524,3 +563,48 @@ const char *cper_ccix_cache_err_unpack(struct trace_seq *p,
return ret;
}
+
+void cper_ccix_atc_err_pack(const struct cper_sec_ccix_atc_error *atc_record,
+ struct cper_ccix_atc_err_compact *catc_err,
+ const u16 vendor_data_len,
+ u8 *vendor_data)
+{
+ catc_err->validation_bits = atc_record->validation_bits;
+ catc_err->op_type = atc_record->op_type;
+ catc_err->instance = atc_record->instance;
+ memcpy(vendor_data, _record->vendor_data[1], vendor_data_len);
+}
+
+static int cper_ccix_err_atc_location(struct cper_ccix_atc_err_compact
*catc_err,
+ char *msg)
+{
+ u32 len = CPER_REC_LEN - 1;
+ u32 n = 0;
+
+ if (!msg)
+ return 0;
+
+ if (catc_err->validation_bits & CCIX_ATC_ERR_OP_VALID)
+ n += snprintf(msg + n, len, "Op: %s ",
+cper_ccix_cache_err_op_str(catc_err->op_type));
+
+ if (catc_err->validation_bits & CCIX_ATC_ERR_INSTANCE_ID_VALID)
+ n += snprintf(msg
[RFC PATCH 2/6] efi / ras: CCIX Cache error reporting
As CCIX Request Agents have fully cache coherent caches,
the CCIX 1.0 Base Specification defines detailed error
reporting for these caches.
A CCIX cache error is reported via a CPER record as defined in the
UEFI 2.8 specification. The PER log section is defined in the
CCIX 1.0 Base Specification.
Signed-off-by: Jonathan Cameron
---
drivers/acpi/apei/ghes.c | 4 +
drivers/firmware/efi/cper-ccix.c | 170 +++
include/linux/cper.h | 57 +++
include/ras/ras_event.h | 66
4 files changed, 297 insertions(+)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index cfc7dc31a9380..1afe47f7bb5b5 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -504,6 +504,10 @@ static void ghes_handle_ccix_per(struct
acpi_hest_generic_data *gdata, int sev)
trace_ccix_memory_error_event(payload, err_seq, sev,
ccix_mem_err_ven_len_get(payload));
break;
+ case CCIX_CACHE_ERROR:
+ trace_ccix_cache_error_event(payload, err_seq, sev,
+
ccix_cache_err_ven_len_get(payload));
+ break;
default:
/* Unknown error type */
pr_info("CCIX error of unknown or vendor defined type\n");
diff --git a/drivers/firmware/efi/cper-ccix.c b/drivers/firmware/efi/cper-ccix.c
index 9856804bdca81..53a466eb05b7d 100644
--- a/drivers/firmware/efi/cper-ccix.c
+++ b/drivers/firmware/efi/cper-ccix.c
@@ -287,6 +287,110 @@ static int cper_ccix_mem_err_details(const char *pfx,
return 0;
}
+static const char * const ccix_cache_type_strs[] = {
+ "Instruction Cache",
+ "Data Cache",
+ "Generic / Unified Cache",
+ "Snoop Filter Directory",
+};
+
+static const char *cper_ccix_cache_type_str(__u8 type)
+{
+ return type < ARRAY_SIZE(ccix_cache_type_strs) ?
+ ccix_cache_type_strs[type] : "Reserved";
+}
+
+static const char * const ccix_cache_err_type_strs[] = {
+ "Data",
+ "Tag",
+ "Timeout",
+ "Hang",
+ "Data Lost",
+ "Invalid Address",
+};
+
+const char *cper_ccix_cache_err_type_str(__u8 error_type)
+{
+ return error_type < ARRAY_SIZE(ccix_cache_err_type_strs) ?
+ ccix_cache_err_type_strs[error_type] : "Reserved";
+}
+
+static const char * const ccix_cache_err_op_strs[] = {
+ "Generic",
+ "Generic Read",
+ "Generic Write",
+ "Data Read",
+ "Data Write",
+ "Instruction Fetch",
+ "Prefetch",
+ "Eviction",
+ "Snooping",
+ "Snooped",
+ "Management / Command Error",
+};
+
+static const char *cper_ccix_cache_err_op_str(__u8 op)
+{
+ return op < ARRAY_SIZE(ccix_cache_err_op_strs) ?
+ ccix_cache_err_op_strs[op] : "Reserved";
+}
+
+static int cper_ccix_cache_err_details(const char *pfx,
+struct acpi_hest_generic_data *gdata)
+{
+ struct cper_ccix_cache_error *full_cache_err;
+ struct cper_sec_ccix_cache_error *cache_err;
+ u16 vendor_data_len;
+ int i;
+
+ if (gdata->error_data_length < sizeof(*full_cache_err))
+ return -ENOSPC;
+
+ full_cache_err = acpi_hest_get_payload(gdata);
+
+ cache_err = _cache_err->cache_record;
+
+ if (cache_err->validation_bits & CCIX_CACHE_ERR_TYPE_VALID)
+ printk("%s""Cache Type: %s\n", pfx,
+ cper_ccix_cache_type_str(cache_err->cache_type));
+
+ if (cache_err->validation_bits & CCIX_CACHE_ERR_OP_VALID)
+ printk("%s""Operation: %s\n", pfx,
+ cper_ccix_cache_err_op_str(cache_err->op_type));
+
+ if (cache_err->validation_bits & CCIX_CACHE_ERR_CACHE_ERR_TYPE_VALID)
+ printk("%s""Cache Error Type: %s\n", pfx,
+
cper_ccix_cache_err_type_str(cache_err->cache_error_type));
+
+ if (cache_err->validation_bits & CCIX_CACHE_ERR_LEVEL_VALID)
+ printk("%s""Level: %d\n", pfx, cache_err->cache_level);
+
+ if (cache_err->validation_bits & CCIX_CACHE_ERR_SET_VALID)
+ printk("%s""Set: %d\n", pfx, cache_err->set);
+
+ if (cache_err->validation_bits & CCIX_CACHE_ERR_WAY_VALID)
+ printk("%s""Way: %d\n", pfx, cache_err->way);
+
+ if (cache_err->validation_bits & CCIX_CACHE_ERR_INSTANCE_ID_VALID)
+ printk("%s""Instance ID: %d\n", pfx, cache_err->instance);
+
+ if (cache_err->validation_bits & CCIX_CACHE_ERR_VENDOR_DATA_VALID) {
+ if (gdata->error_data_length < sizeof(*full_cache_err) + 4)
+ return -ENOSPC;
+
+ vendor_data_len = cache_err->vendor_data[0] & GENMASK(15, 0);
+ if (gdata->error_data_length <
+ sizeof(*full_cache_err) + vendor_data_len)
+ return -ENOSPC;
+
+
[RFC PATCH 1/6] efi / ras: CCIX Memory error reporting
CCIX defines a number of different error types
(See CCIX spec 1.0) and UEFI 2.8 defines a CPER record to allow
for them to be reported when firmware first handling is in use.
The last part of that record is a copy of the CCIX protocol
error record which can provide very detailed information.
This patch introduces infrastructure and support for one of those
error types, CCIX Memory Errors. Later patches will supply
equivalent support for the other error types.
The variable length and content of the different messages makes
a single tracepoint impractical. As such the current RAS
tracepoint only covers the memory error. Additional trace points
will be introduced for other error types along with their
cper handling in a follow up series.
RAS daemon support to follow shortly. qemu injection patches
also available but not currently planing to upstream those.
Signed-off-by: Jonathan Cameron
---
drivers/acpi/apei/Kconfig| 8 +
drivers/acpi/apei/ghes.c | 39
drivers/firmware/efi/Kconfig | 5 +
drivers/firmware/efi/Makefile| 1 +
drivers/firmware/efi/cper-ccix.c | 356 +++
drivers/firmware/efi/cper.c | 6 +
include/linux/cper.h | 118 ++
include/ras/ras_event.h | 77 +++
8 files changed, 610 insertions(+)
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index 6b18f8bc7be35..e687b18dee344 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -68,3 +68,11 @@ config ACPI_APEI_ERST_DEBUG
error information to and from a persistent store. Enable this
if you want to debugging and testing the ERST kernel support
and firmware implementation.
+
+config ACPI_APEI_CCIX
+ bool "APEI CCIX error recovery support"
+ depends on ACPI_APEI && MEMORY_FAILURE
+ help
+CCIX has a number of defined error types. This option enables
+the handling of CPER records generated by a firmware performing
+firmware first error handling of these CCIX errors.
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 993940d582f50..cfc7dc31a9380 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -477,6 +477,42 @@ static void ghes_handle_aer(struct acpi_hest_generic_data
*gdata)
#endif
}
+static void ghes_handle_ccix_per(struct acpi_hest_generic_data *gdata, int sev)
+{
+#ifdef CONFIG_ACPI_APEI_CCIX
+ struct cper_sec_ccix_header *header = acpi_hest_get_payload(gdata);
+ __u32 *dw;
+ enum ccix_per_type per_type;
+ static u32 err_seq;
+ void *payload;
+
+ /* Check if space for CCIX CPER header and 8 DW of a PER log header */
+ if (gdata->error_data_length <
+ sizeof(*header) + CCIX_PER_LOG_HEADER_DWS * sizeof(__u32))
+ return;
+
+ if ((header->validation_bits & CPER_CCIX_VALID_PER_LOG) == 0)
+ return;
+
+ dw = (__u32 *)(header + 1);
+
+ per_type = FIELD_GET(CCIX_PER_LOG_DW1_PER_TYPE_M, dw[1]);
+ payload = acpi_hest_get_payload(gdata);
+
+ switch (per_type) {
+ case CCIX_MEMORY_ERROR:
+ trace_ccix_memory_error_event(payload, err_seq, sev,
+
ccix_mem_err_ven_len_get(payload));
+ break;
+ default:
+ /* Unknown error type */
+ pr_info("CCIX error of unknown or vendor defined type\n");
+ break;
+ }
+ err_seq++;
+#endif
+}
+
static void ghes_do_proc(struct ghes *ghes,
const struct acpi_hest_generic_status *estatus)
{
@@ -507,6 +543,9 @@ static void ghes_do_proc(struct ghes *ghes,
else if (guid_equal(sec_type, _SEC_PCIE)) {
ghes_handle_aer(gdata);
}
+ else if (guid_equal(sec_type, _SEC_CCIX)) {
+ ghes_handle_ccix_per(gdata, estatus->error_severity);
+ }
else if (guid_equal(sec_type, _SEC_PROC_ARM)) {
struct cper_sec_proc_arm *err =
acpi_hest_get_payload(gdata);
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index d4ea929e8b344..9ea161f68da8d 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -195,6 +195,11 @@ config UEFI_CPER_X86
depends on UEFI_CPER && X86
default y
+config UEFI_CPER_CCIX
+ bool
+ depends on UEFI_CPER
+ default y
+
config EFI_DEV_PATH_PARSER
bool
depends on ACPI
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index d2d0d20306200..69287da9664b6 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_EFI_CAPSULE_LOADER) += capsule-loader.o
obj-$(CONFIG_EFI_EARLYCON) += earlycon.o
obj-$(CONFIG_UEFI_CPER_ARM)+= cper-arm.o
obj-$(CONFIG_UEFI_CPER_X86)
[RFC PATCH 5/6] efi / ras: CCIX Link error reporting
The CCIX 1.0 Base Specification defines a protocol layer
CCIX link and related error reporting mechanism.
The UEFI 2.8 specification includes a CCIX CPER record for
firmware first handling to report these errors to the
operating system.
This patch is very similar to the support previously added
for CCIX Memory Errors and provides both logging and RAS
tracepoint for this error class.
Signed-off-by: Jonathan Cameron
---
drivers/acpi/apei/ghes.c | 4 +
drivers/firmware/efi/cper-ccix.c | 140 +++
include/linux/cper.h | 48 +++
include/ras/ras_event.h | 65 ++
4 files changed, 257 insertions(+)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 2b2c0df204523..2cabac7a344c7 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -516,6 +516,10 @@ static void ghes_handle_ccix_per(struct
acpi_hest_generic_data *gdata, int sev)
trace_ccix_port_error_event(payload, err_seq, sev,
ccix_port_err_ven_len_get(payload));
break;
+ case CCIX_LINK_ERROR:
+ trace_ccix_link_error_event(payload, err_seq, sev,
+ ccix_link_err_ven_len_get(payload));
+ break;
default:
/* Unknown error type */
pr_info("CCIX error of unknown or vendor defined type\n");
diff --git a/drivers/firmware/efi/cper-ccix.c b/drivers/firmware/efi/cper-ccix.c
index fcf77834b9894..1a9661a6c49f4 100644
--- a/drivers/firmware/efi/cper-ccix.c
+++ b/drivers/firmware/efi/cper-ccix.c
@@ -503,6 +503,86 @@ static int cper_ccix_port_err_details(const char *pfx,
return 0;
}
+static const char * const ccix_link_err_type_strs[] = {
+ "Generic Error",
+ "Credit Underflow",
+ "Credit Overflow",
+ "Unusable Credit Received",
+ "Link Credit Timeout",
+};
+
+static const char *cper_ccix_link_err_type_str(__u8 op)
+{
+ return op < ARRAY_SIZE(ccix_link_err_type_strs) ?
+ ccix_link_err_type_strs[op] : "Reserved";
+}
+
+static const char * const ccix_link_credit_type_strs[] = {
+ "Memory",
+ "Snoop",
+ "Data",
+ "Misc",
+};
+
+static const char *cper_ccix_link_credit_type_str(__u8 op)
+{
+ return op < ARRAY_SIZE(ccix_link_credit_type_strs) ?
+ ccix_link_credit_type_strs[op] : "Reserved";
+}
+
+static int cper_ccix_link_err_details(const char *pfx,
+struct acpi_hest_generic_data *gdata)
+{
+ struct cper_ccix_link_error *full_link_err;
+ struct cper_sec_ccix_link_error *link_err;
+ u16 vendor_data_len;
+ int i;
+
+ if (gdata->error_data_length < sizeof(*full_link_err))
+ return -ENOSPC;
+
+ full_link_err = acpi_hest_get_payload(gdata);
+
+ link_err = _link_err->link_record;
+
+ if (link_err->validation_bits & CCIX_LINK_ERR_TYPE_VALID)
+ printk("%s""Error Type: %s\n", pfx,
+ cper_ccix_link_err_type_str(link_err->err_type));
+
+ if (link_err->validation_bits & CCIX_LINK_ERR_OP_VALID)
+ printk("%s""Operation: %s\n", pfx,
+ cper_ccix_port_err_op_str(link_err->op_type));
+
+ if (link_err->validation_bits & CCIX_LINK_ERR_LINK_ID_VALID)
+ printk("%s""Link ID: %d\n", pfx, link_err->link_id);
+
+ if (link_err->validation_bits & CCIX_LINK_ERR_CREDIT_TYPE_VALID)
+ printk("%s""Credit Type: %s\n", pfx,
+ cper_ccix_link_credit_type_str(link_err->credit_type));
+
+ /* CHECK THE AER EQUIVALENT */
+ if (link_err->validation_bits & CCIX_LINK_ERR_MESSAGE_VALID) {
+ for (i = 0; i < ARRAY_SIZE(link_err->message); i++)
+ printk("%s""Message%d: 0x%08x\n", pfx, i,
link_err->message[i]);
+ }
+
+ if (link_err->validation_bits & CCIX_LINK_ERR_VENDOR_DATA_VALID) {
+ if (gdata->error_data_length < sizeof(*full_link_err) + 4)
+ return -ENOSPC;
+
+ vendor_data_len = link_err->vendor_data[0] & GENMASK(15, 0);
+ if (gdata->error_data_length < sizeof(*full_link_err) +
vendor_data_len)
+ return -ENOSPC;
+
+ for (i = 0; i < vendor_data_len/4 - 1; i++)
+ printk("%s""Vendor%d: 0x%08x\n", pfx, i,
+ link_err->vendor_data[i + 1]);
+
+ }
+
+ return 0;
+}
+
int cper_print_ccix_per(const char *pfx, struct acpi_hest_generic_data *gdata)
{
struct cper_sec_ccix_header *header = acpi_hest_get_payload(gdata);
@@ -570,6 +650,8 @@ int cper_print_ccix_per(const char *pfx, struct
acpi_hest_generic_data *gdata)
return cper_ccix_atc_err_details(pfx, gdata);
case CCIX_PORT_ERROR:
return cper_ccix_port_err_details(pfx,
[RFC PATCH 0/6] CCIX Protocol Error reporting
UEFI 2.8 defines a new CPER record Appendix N for CCIX Protocol Error Records (PER). www.uefi.org These include Protocol Error Record logs which are defined in the CCIX 1.0 Base Specification www.ccixconsortium.com. Handling of coherency protocol errors is complex and how Linux does this will take some time to evolve. For now, fatal errors are handled via the usual means and everything else is reported. There are 6 types of error defined, covering: * Memory errors * Cache errors * Address translation unit errors * CCIX port errors * CCIX link errors * Agent internal errors. The set includes tracepoints to report the errors to RAS Daemon and a patch set for RAS Daemon will follow shortly. There are several open questions for this RFC. 1. Reporting of vendor data. We have little choice but to do this via a dynamic array as these blocks can take arbitrary size. I had hoped no one would actually use these given the odd mismatch between a standard error structure and non standard element, but there are already designs out there that do use it. 2. The trade off between explicit tracepoint fields, on which we might want to filter, and the simplicity of a blob. I have gone for having the whole of the block specific to the PER error type in an opaque blob. Perhaps this is not the right balance? 3. Whether defining 6 new tracepoints is sensible. I think it is: * They are all defined by the CCIX specification as independant error classes. * Many of them can only be generated by particular types of agent. * The handling required will vary widely depending on types. In the kernel some map cleanly onto existing handling. Keeping the whole flow separate will aide this. They vary by a similar amount in scope to the RAS errors found on an existing system which have independent tracepoints. * Separating them out allows for filtering on the tracepoints by elements that are not shared between them. * Muxing the lot into one record type can lead to ugly code both in kernel and in userspace. Rasdaemon patches will follow shortly. This patch is being distributed by the CCIX Consortium, Inc. (CCIX) to you and other parties that are paticipating (the "participants") in the Linux kernel with the understanding that the participants will use CCIX's name and trademark only when this patch is used in association with the Linux kernel and associated user space. CCIX is also distributing this patch to these participants with the understanding that if any portion of the CCIX specification will be used or referenced in the Linux kernel, the participants will not modify the cited portion of the CCIX specification and will give CCIX propery copyright attribution by including the following copyright notice with the cited part of the CCIX specification: "© 2019 CCIX CONSORTIUM, INC. ALL RIGHTS RESERVED." Jonathan Cameron (6): efi / ras: CCIX Memory error reporting efi / ras: CCIX Cache error reporting efi / ras: CCIX Address Translation Cache error reporting efi / ras: CCIX Port error reporting efi / ras: CCIX Link error reporting efi / ras: CCIX Agent internal error reporting drivers/acpi/apei/Kconfig| 8 + drivers/acpi/apei/ghes.c | 59 ++ drivers/firmware/efi/Kconfig | 5 + drivers/firmware/efi/Makefile| 1 + drivers/firmware/efi/cper-ccix.c | 916 +++ drivers/firmware/efi/cper.c | 6 + include/linux/cper.h | 333 +++ include/ras/ras_event.h | 405 ++ 8 files changed, 1733 insertions(+) create mode 100644 drivers/firmware/efi/cper-ccix.c -- 2.20.1
Re: [PATCH for-4.9-stable] efi/libstub: Unify command line param parsing
Ard Biesheuvel wrote: > Commit 60f38de7a8d4e816100ceafd1b382df52527bd50 upstream. > > Merge the parsing of the command line carried out in arm-stub.c with > the handling in efi_parse_options(). Note that this also fixes the > missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin > command line should supersede the one passed by the firmware. > > Signed-off-by: Ard Biesheuvel > Cc: Linus Torvalds > Cc: Matt Fleming > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: b...@redhat.com > Cc: bhsha...@redhat.com > Cc: b...@alien8.de > Cc: eug...@hp.com > Cc: evgeny.kalu...@intel.com > Cc: jh...@codeaurora.org > Cc: leif.lindh...@linaro.org > Cc: linux-efi@vger.kernel.org > Cc: mark.rutl...@arm.com > Cc: roy.fr...@cavium.com > Cc: rruig...@codeaurora.org > Link: > http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org > Signed-off-by: Ingo Molnar > [ardb: fix up merge conflicts with 4.9.180] > Signed-off-by: Ard Biesheuvel > --- > This fixes the GCC build issue reported by Eike. > > Note that testing of arm64 stable kernels should cover > CONFIG_RANDOMIZE_BASE, since it has a profound impact on how the kernel > binary gets put together. Confirmed, this patch works for me on top of 4.9.180. -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH] efi: Fix TPM code build failure on ARM
On Wed, 5 Jun 2019 at 20:11, Matthew Garrett wrote: > > asm/early_ioremap.h needs to be #included before tpm_eventlog.h in order > to ensure that early_memremap is available. > Doesn't that make it tpm_eventlog.h's job to #include it? > Signed-off-by: Matthew Garrett > --- > drivers/firmware/efi/tpm.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c > index 0bdceb5913aa..1d3f5ca3eaaf 100644 > --- a/drivers/firmware/efi/tpm.c > +++ b/drivers/firmware/efi/tpm.c > @@ -7,13 +7,12 @@ > #define TPM_MEMREMAP(start, size) early_memremap(start, size) > #define TPM_MEMUNMAP(start, size) early_memunmap(start, size) > > +#include > #include > #include > #include > #include > > -#include > - > int efi_tpm_final_log_size; > EXPORT_SYMBOL(efi_tpm_final_log_size); > > -- > 2.22.0.rc1.311.g5d7573a151-goog >
[PATCH for-4.9-stable] efi/libstub: Unify command line param parsing
Commit 60f38de7a8d4e816100ceafd1b382df52527bd50 upstream.
Merge the parsing of the command line carried out in arm-stub.c with
the handling in efi_parse_options(). Note that this also fixes the
missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin
command line should supersede the one passed by the firmware.
Signed-off-by: Ard Biesheuvel
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: b...@redhat.com
Cc: bhsha...@redhat.com
Cc: b...@alien8.de
Cc: eug...@hp.com
Cc: evgeny.kalu...@intel.com
Cc: jh...@codeaurora.org
Cc: leif.lindh...@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: mark.rutl...@arm.com
Cc: roy.fr...@cavium.com
Cc: rruig...@codeaurora.org
Link: http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar
[ardb: fix up merge conflicts with 4.9.180]
Signed-off-by: Ard Biesheuvel
---
This fixes the GCC build issue reported by Eike.
Note that testing of arm64 stable kernels should cover CONFIG_RANDOMIZE_BASE,
since it has a profound impact on how the kernel binary gets put together.
drivers/firmware/efi/libstub/arm-stub.c| 23 ++--
drivers/firmware/efi/libstub/arm64-stub.c | 4 +---
drivers/firmware/efi/libstub/efi-stub-helper.c | 19 +---
drivers/firmware/efi/libstub/efistub.h | 2 ++
include/linux/efi.h| 2 +-
5 files changed, 22 insertions(+), 28 deletions(-)
diff --git a/drivers/firmware/efi/libstub/arm-stub.c
b/drivers/firmware/efi/libstub/arm-stub.c
index 993aa56755f6..726d1467b778 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -18,7 +18,6 @@
#include "efistub.h"
-bool __nokaslr;
static int efi_get_secureboot(efi_system_table_t *sys_table_arg)
{
@@ -268,18 +267,6 @@ unsigned long efi_entry(void *handle, efi_system_table_t
*sys_table,
goto fail;
}
- /* check whether 'nokaslr' was passed on the command line */
- if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
- static const u8 default_cmdline[] = CONFIG_CMDLINE;
- const u8 *str, *cmdline = cmdline_ptr;
-
- if (IS_ENABLED(CONFIG_CMDLINE_FORCE))
- cmdline = default_cmdline;
- str = strstr(cmdline, "nokaslr");
- if (str == cmdline || (str > cmdline && *(str - 1) == ' '))
- __nokaslr = true;
- }
-
si = setup_graphics(sys_table);
status = handle_kernel_image(sys_table, image_addr, _size,
@@ -291,9 +278,13 @@ unsigned long efi_entry(void *handle, efi_system_table_t
*sys_table,
goto fail_free_cmdline;
}
- status = efi_parse_options(cmdline_ptr);
- if (status != EFI_SUCCESS)
- pr_efi_err(sys_table, "Failed to parse EFI cmdline options\n");
+ if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
+ IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
+ cmdline_size == 0)
+ efi_parse_options(CONFIG_CMDLINE);
+
+ if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && cmdline_size > 0)
+ efi_parse_options(cmdline_ptr);
secure_boot = efi_get_secureboot(sys_table);
if (secure_boot > 0)
diff --git a/drivers/firmware/efi/libstub/arm64-stub.c
b/drivers/firmware/efi/libstub/arm64-stub.c
index 959d9b8d4845..f7a6970e9abc 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -24,8 +24,6 @@
#include "efistub.h"
-extern bool __nokaslr;
-
efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
{
u64 tg;
@@ -60,7 +58,7 @@ efi_status_t handle_kernel_image(efi_system_table_t
*sys_table_arg,
u64 phys_seed = 0;
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
- if (!__nokaslr) {
+ if (!nokaslr()) {
status = efi_get_random_bytes(sys_table_arg,
sizeof(phys_seed),
(u8 *)_seed);
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 09d10dcf1fc6..1c963c4d1bde 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -32,6 +32,13 @@
static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE;
+static int __section(.data) __nokaslr;
+
+int __pure nokaslr(void)
+{
+ return __nokaslr;
+}
+
/*
* Allow the platform to override the allocation granularity: this allows
* systems that have the capability to run with a larger page size to deal
@@ -351,17 +358,13 @@ void efi_free(efi_system_table_t *sys_table_arg, unsigned
long size,
* environments, first in the early boot environment of the EFI boot
* stub, and subsequently during the kernel boot.
*/
-efi_status_t efi_parse_options(char *cmdline)
+efi_status_t
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Thu, 6 Jun 2019 at 11:40, Rolf Eike Beer wrote: > > Ard Biesheuvel wrote: > > On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer wrote: > > > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > > > > Greg KH wrote: > > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > > I decided to dig out a toy project which uses a DragonBoard 410c. > > > > > > This > > > > > > has > > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > > unrelated > > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it > > > > > > was > > > > > > buildable, which was good enough. > > > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in > > > > > > function > > > > > > `handle_kernel_image': > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > > c:63 > > > > > > > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > > > be > > > > > > used when making a shared object; recompile with -fPIC > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > > c:63 > > > > > > > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target > > > > > > 'vmlinux' > > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca > > > > > > from > > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > > reverting > > > > > > this commit fixes the build. > > > > > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > > > 9.1.0. > > > > > > See > > > > > > the attached .config for reference. > > > > > > > > > > > > If you have questions or patches just ping me. > > > > > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > > > 5.1.7 with the same config as before and "make olddefconfig" builds for > > > > me. > > > > > > Just for the fun of it: both 4.19 and 4.19.48 also work. > > > Could you please check whether patch > > 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether > > it fixes the problem? Thanks. > > The part in drivers/firmware/efi/libstub/arm-stub.c needs to be applied by > hand, but afterwards things build fine. > Thanks. I'll send out a backport.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Ard Biesheuvel wrote: > On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer wrote: > > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > > > Greg KH wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > I decided to dig out a toy project which uses a DragonBoard 410c. > > > > > This > > > > > has > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > unrelated > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it > > > > > was > > > > > buildable, which was good enough. > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in > > > > > function > > > > > `handle_kernel_image': > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > c:63 > > > > > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > > be > > > > > used when making a shared object; recompile with -fPIC > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > c:63 > > > > > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target > > > > > 'vmlinux' > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca > > > > > from > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > reverting > > > > > this commit fixes the build. > > > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > > 9.1.0. > > > > > See > > > > > the attached .config for reference. > > > > > > > > > > If you have questions or patches just ping me. > > > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > 5.1.7 with the same config as before and "make olddefconfig" builds for > > > me. > > > > Just for the fun of it: both 4.19 and 4.19.48 also work. > Could you please check whether patch > 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether > it fixes the problem? Thanks. The part in drivers/firmware/efi/libstub/arm-stub.c needs to be applied by hand, but afterwards things build fine. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Thu, 6 Jun 2019 at 10:58, Ard Biesheuvel wrote: > > On Thu, 6 Jun 2019 at 09:08, Greg KH wrote: > > > > On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > > > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers > > > wrote: > > > > > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > > > wrote: > > > > > For the record, this is an example of why I think backporting those > > > > > clang enablement patches is a bad idea. > > > > > > > > There's always a risk involved with backports of any kind; more CI > > > > coverage can help us mitigate some of these risks in an automated > > > > fashion before we get user reports like this. I meet with the > > > > KernelCI folks weekly, so I'll double check on the coverage of the > > > > stable tree's branches. The 0day folks are also very responsive and > > > > I've spoken with them a few times, so I'll try to get to the bottom of > > > > why this wasn't reported by either of those. > > > > > > > > Also, these patches help keep Android, CrOS, and Google internal > > > > production kernels closer to their upstream sources. > > > > > > > > > We can't actually build those > > > > > kernels with clang, can we? So what is the point? > > > > > > > > Here's last night's build: > > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > > > > > > > > > > If you are saying that plain upstream 4.9-stable defconfig can be > > > built with Clang, then I am pleasantly surprised. > > > > I know some specific configs can, there's no rule that I know of that > > 'defconfig' support is required. But then again, it might also work, > > try it and see :) > > > > Well, it is the rule that the arm64 maintainers use. > > > > > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > > > > built with Clang. I think this number will grow at least one order of > > > > magnitude imminently. > > > > > > > > > > I know that (since you keep reminding me :-)), but obviously, Google > > > does not care about changes that regress GCC support. > > > > What are you talking about? Bugs happen all the time, what specifically > > did "Google" do to break gcc support? If you are referring to this > > patch, and it is a regression, of course I will revert it. But note > > that gcc and 4.9 works just fine for all of the other users right now, > > remember we do do a lot of testing of these releases. > > > > Don't get me wrong: I am not blaming Google for this. But having > strict Documented/ stable-rules, violating them by backporting patches > that are clearly not bug fixes, and *then* saying 'bugs happen all the > time' makes no sense to me at all. BTW I hit the same issue immediately building 4.9.180 defconfig + CONFIG_RANDOMIZE_BASE=y, using my distro GCC (6.3.0), so I'd say the testing coverage is not sufficient.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer wrote: > > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > > Greg KH wrote: > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > I decided to dig out a toy project which uses a DragonBoard 410c. This > > > > has > > > > been "running" with kernel 4.9, which I would keep this way for > > > > unrelated > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > > buildable, which was good enough. > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > > > `handle_kernel_image': > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > > : > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > aarch64-unknown-linux-gnueabi-ld: > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be > > > > used when making a shared object; recompile with -fPIC > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > > : > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > reverting > > > > this commit fixes the build. > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. > > > > See > > > > the attached .config for reference. > > > > > > > > If you have questions or patches just ping me. > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > 5.1.7 with the same config as before and "make olddefconfig" builds for me. > > Just for the fun of it: both 4.19 and 4.19.48 also work. > Thanks Rolf Could you please check whether patch 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether it fixes the problem? Thanks.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Thu, 6 Jun 2019 at 09:08, Greg KH wrote: > > On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers > > wrote: > > > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > > wrote: > > > > For the record, this is an example of why I think backporting those > > > > clang enablement patches is a bad idea. > > > > > > There's always a risk involved with backports of any kind; more CI > > > coverage can help us mitigate some of these risks in an automated > > > fashion before we get user reports like this. I meet with the > > > KernelCI folks weekly, so I'll double check on the coverage of the > > > stable tree's branches. The 0day folks are also very responsive and > > > I've spoken with them a few times, so I'll try to get to the bottom of > > > why this wasn't reported by either of those. > > > > > > Also, these patches help keep Android, CrOS, and Google internal > > > production kernels closer to their upstream sources. > > > > > > > We can't actually build those > > > > kernels with clang, can we? So what is the point? > > > > > > Here's last night's build: > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > > > > > > > If you are saying that plain upstream 4.9-stable defconfig can be > > built with Clang, then I am pleasantly surprised. > > I know some specific configs can, there's no rule that I know of that > 'defconfig' support is required. But then again, it might also work, > try it and see :) > Well, it is the rule that the arm64 maintainers use. > > > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > > > built with Clang. I think this number will grow at least one order of > > > magnitude imminently. > > > > > > > I know that (since you keep reminding me :-)), but obviously, Google > > does not care about changes that regress GCC support. > > What are you talking about? Bugs happen all the time, what specifically > did "Google" do to break gcc support? If you are referring to this > patch, and it is a regression, of course I will revert it. But note > that gcc and 4.9 works just fine for all of the other users right now, > remember we do do a lot of testing of these releases. > Don't get me wrong: I am not blaming Google for this. But having strict Documented/ stable-rules, violating them by backporting patches that are clearly not bug fixes, and *then* saying 'bugs happen all the time' makes no sense to me at all.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > Greg KH wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > I decided to dig out a toy project which uses a DragonBoard 410c. This > > > has > > > been "running" with kernel 4.9, which I would keep this way for > > > unrelated > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > buildable, which was good enough. > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > > `handle_kernel_image': > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > : > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > aarch64-unknown-linux-gnueabi-ld: > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be > > > used when making a shared object; recompile with -fPIC > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > : > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > reverting > > > this commit fixes the build. > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. > > > See > > > the attached .config for reference. > > > > > > If you have questions or patches just ping me. > > > > Does Linus's latest tree also fail for you (or 5.1)? > > 5.1.7 with the same config as before and "make olddefconfig" builds for me. Just for the fun of it: both 4.19 and 4.19.48 also work. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Greg KH wrote: > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > buildable, which was good enough. > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > aarch64-unknown-linux-gnueabi-ld: > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > `handle_kernel_image': > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > aarch64-unknown-linux-gnueabi-ld: > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be > > used when making a shared object; recompile with -fPIC > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > (.init.text+0xc): dangerous relocation: unsupported relocation > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > failed -make[1]: *** [vmlinux] Error 1 > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > this commit fixes the build. > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. > > See > > the attached .config for reference. > > > > If you have questions or patches just ping me. > > Does Linus's latest tree also fail for you (or 5.1)? 5.1.7 with the same config as before and "make olddefconfig" builds for me. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Nick Desaulniers wrote:
> On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers
>
> wrote:
> > On Wed, Jun 5, 2019 at 9:26 AM Greg KH wrote:
> > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote:
> > > > I decided to dig out a toy project which uses a DragonBoard 410c. This
> > > > has
> > > > been "running" with kernel 4.9, which I would keep this way for
> > > > unrelated
> > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was
> > > > buildable, which was good enough.
> > > >
> > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail:
> > > >
> > > > aarch64-unknown-linux-gnueabi-ld:
> > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function
> > > > `handle_kernel_image':
> > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:
> > > > 63:
> > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_'
> > > > aarch64-unknown-linux-gnueabi-ld:
> > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation
> > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol
> > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not
> > > > be used when making a shared object; recompile with -fPIC
> > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:
> > > > 63:
> > > > (.init.text+0xc): dangerous relocation: unsupported relocation
> > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux'
> > > > failed -make[1]: *** [vmlinux] Error 1
> > > >
> > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from
> > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be),
> > > > reverting
> > > > this commit fixes the build.
> > > >
> > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as
> > > > 9.1.0. See
> > > > the attached .config for reference.
> > > >
> > > > If you have questions or patches just ping me.
> > >
> > > Does Linus's latest tree also fail for you (or 5.1)?
> > >
> > > Nick, do we need to add another fix that is in mainline for this to work
> > > properly?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Doesn't immediately ring any bells for me.
>
> Upstream commits:
> dd6846d77469 ("arm64: drop linker script hack to hide __efistub_ symbols")
> 1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_ symbols")
>
> Look related to __efistub__ prefixes on symbols and aren't in stable
> 4.9 (maybe Rolf can try cherry picks of those).
I now have cherry-picked these commits:
dd6846d77469
fdfb69a72522e97f9105a6d39a5be0a465951ed8
1212f7a16af4
56067812d5b0e737ac2063e94a50f76b810d6ca3
The 2 additional ones were needed as dependencies of the others. Nothing of
this has helped.
Eike
--
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055
emlix - smart embedded open source
signature.asc
Description: This is a digitally signed message part.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers wrote: > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > wrote: > > > For the record, this is an example of why I think backporting those > > > clang enablement patches is a bad idea. > > > > There's always a risk involved with backports of any kind; more CI > > coverage can help us mitigate some of these risks in an automated > > fashion before we get user reports like this. I meet with the > > KernelCI folks weekly, so I'll double check on the coverage of the > > stable tree's branches. The 0day folks are also very responsive and > > I've spoken with them a few times, so I'll try to get to the bottom of > > why this wasn't reported by either of those. > > > > Also, these patches help keep Android, CrOS, and Google internal > > production kernels closer to their upstream sources. > > > > > We can't actually build those > > > kernels with clang, can we? So what is the point? > > > > Here's last night's build: > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > > > > If you are saying that plain upstream 4.9-stable defconfig can be > built with Clang, then I am pleasantly surprised. I know some specific configs can, there's no rule that I know of that 'defconfig' support is required. But then again, it might also work, try it and see :) > > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > > built with Clang. I think this number will grow at least one order of > > magnitude imminently. > > > > I know that (since you keep reminding me :-)), but obviously, Google > does not care about changes that regress GCC support. What are you talking about? Bugs happen all the time, what specifically did "Google" do to break gcc support? If you are referring to this patch, and it is a regression, of course I will revert it. But note that gcc and 4.9 works just fine for all of the other users right now, remember we do do a lot of testing of these releases. thanks, greg k-h
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers wrote: > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > wrote: > > For the record, this is an example of why I think backporting those > > clang enablement patches is a bad idea. > > There's always a risk involved with backports of any kind; more CI > coverage can help us mitigate some of these risks in an automated > fashion before we get user reports like this. I meet with the > KernelCI folks weekly, so I'll double check on the coverage of the > stable tree's branches. The 0day folks are also very responsive and > I've spoken with them a few times, so I'll try to get to the bottom of > why this wasn't reported by either of those. > > Also, these patches help keep Android, CrOS, and Google internal > production kernels closer to their upstream sources. > > > We can't actually build those > > kernels with clang, can we? So what is the point? > > Here's last night's build: > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > If you are saying that plain upstream 4.9-stable defconfig can be built with Clang, then I am pleasantly surprised. > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > built with Clang. I think this number will grow at least one order of > magnitude imminently. > I know that (since you keep reminding me :-)), but obviously, Google does not care about changes that regress GCC support. > > Alternatively, we can just revert this patch from 4.9 > > That would break at least the above devices next time Android and CrOS > pulled from stable. > > > It would be helpful to get a relocation dump (objdump -r) of > > arm64-stub.o to figure out which symbol needs a 'hidden' annotation to > > prevent GCC from emitting it as a PIC reference requiring a GOT. > > Sounds like the best way forward, as well as having more info on which > config/toolchain reliably reproduces the issue. Let me know once you can reproduce it, I will have a look as well.
