On Mon, 29 Apr 2024 10:21:31 +0100 Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > On Sun, 28 Apr 2024 12:28:03 +0100 > Marc Zyngier <maz@xxxxxxxxxx> wrote: > > > On Fri, 26 Apr 2024 19:28:58 +0100, > > Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > > > > > > > > I'll not send a formal v9 until early next week, so here is the current state > > > if you have time to take another look before then. > > > > Don't bother resending this on my account -- you only sent it on > > Friday and there hasn't been much response to it yet. There is still a > > problem (see below), but looks otherwise OK. > > > > [...] > > > > > @@ -2363,11 +2381,25 @@ gic_acpi_parse_madt_gicc(union acpi_subtable_headers *header, > > > (struct acpi_madt_generic_interrupt *)header; > > > u32 reg = readl_relaxed(acpi_data.dist_base + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK; > > > u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2; > > > + int cpu = get_cpu_for_acpi_id(gicc->uid); > > > > I already commented that get_cpu_for_acpi_id() can... > > Indeed sorry - I blame Friday syndrome for me failing to address that. > > > > > > void __iomem *redist_base; > > > > > > - if (!acpi_gicc_is_usable(gicc)) > > > + /* Neither enabled or online capable means it doesn't exist, skip it */ > > > + if (!(gicc->flags & (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE))) > > > return 0; > > > > > > + /* > > > + * Capable but disabled CPUs can be brought online later. What about > > > + * the redistributor? ACPI doesn't want to say! > > > + * Virtual hotplug systems can use the MADT's "always-on" GICR entries. > > > + * Otherwise, prevent such CPUs from being brought online. > > > + */ > > > + if (!(gicc->flags & ACPI_MADT_ENABLED)) { > > > + pr_warn("CPU %u's redistributor is inaccessible: this CPU can't be brought online\n", cpu); > > > + cpumask_set_cpu(cpu, &broken_rdists); > > > > ... return -EINVAL, and then be passed to cpumask_set_cpu(), with > > interesting effects. It shouldn't happen, but I trust anything that > > comes from firmware tables as much as I trust a campaigning > > politician's promises. This should really result in the RD being > > considered unusable, but without affecting any CPU (there is no valid > > CPU the first place). > > > > Another question is what get_cpu_for acpi_id() returns for a disabled > > CPU. A valid CPU number? Or -EINVAL? > It's a match function that works by iterating over 0 to nr_cpu_ids and > > if (uid == get_acpi_id_for_cpu(cpu)) > > So the question become does get_acpi_id_for_cpu() return a valid CPU > number for a disabled CPU. > > That uses acpi_cpu_get_madt_gicc(cpu)->uid so this all gets a bit circular. > That looks it up via cpu_madt_gicc[cpu] which after the proposed updated > patch is set if enabled or online capable. There are however a few other > error checks in acpi_map_gic_cpu_interface() that could lead to it > not being set (MPIDR validity checks). I suspect all of these end up being > fatal elsewhere which is why this hasn't blown up before. > > If any of those cases are possible we could get a null pointer > dereference. > > Easy to harden this case via the following (which will leave us with > -EINVAL. There are other call sites that might trip over this. > I'm inclined to harden them as a separate issue though so as not > to get in the way of this patch set. > > > diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h > index bc9a6656fc0c..a407f9cd549e 100644 > --- a/arch/arm64/include/asm/acpi.h > +++ b/arch/arm64/include/asm/acpi.h > @@ -124,7 +124,8 @@ static inline int get_cpu_for_acpi_id(u32 uid) > int cpu; > > for (cpu = 0; cpu < nr_cpu_ids; cpu++) > - if (uid == get_acpi_id_for_cpu(cpu)) > + if (acpi_cpu_get_madt_gicc(cpu) && > + uid == get_acpi_id_for_cpu(cpu)) > return cpu; > > return -EINVAL; > > I'll spin an additional patch to make that change after testing I haven't > messed it up. > > At the call site in gic_acpi_parse_madt_gicc() I'm not sure we can do better > than just skipping setting broken_rdists. I'll also pull the declaration of > that cpu variable down into this condition so it's more obvious we only > care about it in this error path. Just for the record, for my deliberately broken test case it seems that it returns a valid CPU ID anyway. That's what I'd expect given acpi_parse_and_init_cpus() doesn't check if the gicc entrees are enabled or not. Jonathan > > Jonathan > > > > > > > > > Thanks, > > > > M. > > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel