On Fri, Jul 28 2023 at 14:51, Thomas Gleixner wrote: > On Mon, Jul 03 2023 at 00:28, Zhang Rui wrote: >> >> +static bool has_lapic_cpus; > > Yet another random flag. Sigh. > > I really hate this. Why not doing the obvious? > > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -2452,6 +2452,9 @@ int generic_processor_info(int apicid, i > bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid, > phys_cpu_present_map); > > + if (physid_isset(apicid, phys_cpu_present_map)) > + return -EBUSY; > + > /* > * boot_cpu_physical_apicid is designed to have the apicid > * returned by read_apic_id(), i.e, the apicid of the > > As the call sites during MADT parsing ignore the return value anyway, > there is no harm and this is a proper defense against broken tables > which enumerate an APIC twice. In fact that function should not have a return value at all, but because it's not clearly separated between boot time and physical hotplug, it has to have one ...
