Re: gicv3-its driver crashes in crash dump kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 6 Jun 2019 at 16:32, Marc Zyngier <marc.zyngier@xxxxxxx> 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(&rsv->count
> >
> > In the previous revision of this file, kmalloc was called and this worked fine.
> >
> > [    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
> > [    0.000000] GICv3: Distributor has no Range Selector support
> > [    0.000000] GICv3: no VLPI support, no direct LPI support
> > [    0.000000] GICv3: CPU0: found redistributor 1 region 0:0x0000000063e20000
> > [    0.000000] ITS [mem 0x63c20000-0x63c2ffff]
> > [    0.000000] ITS@0x0000000063c20000: allocated 32768 Devices @fd480000 (flat, esz 8, psz 64K, shr 0)
> > [    0.000000] ITS: using cache flushing for cmd queue
> > [    0.000000] iter: prsv = 0xc3836000
> > [    0.000000] rsv = 0x43836000
> > [    0.000000] Unable to handle kernel paging request at virtual address ffff80a343836004
> > [    0.000000] Mem abort info:
> > [    0.000000]   ESR = 0x96000004
> > [    0.000000]   Exception class = DABT (current EL), IL = 32 bits
> >
> > int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> > {
> > <clip>
> >     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(&rsv->count, 1, rsv->size);
> >         if (index < rsv->size) {
> >             rsv->entry[index].base = addr;
> >             rsv->entry[index].size = size;
> > <clip>
> >
> > 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.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux