On Fri, 15 Mar 2024 at 15:55, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > Not really. The problem is that a SMP build can run on a UP machine w/o > APIC or command line disables the APIC and will run into the exactly > same problem. The only case where we know that it is impossible is when > APIC support is disabled, which is silly but topic for a different > discussion. Oh, I agree - that was why I said that it shouldn't depend on a local APIC on machines that may not even have one. That "may not even have one" can still be a static option - we technically allow 32-bit UP kernel to not enable X86_UP_APIC, although it might be time to drop that option. > So the proper thing to do is to check for num_possible_cpus() == 1 in > that function. I think that's _one_ proper thing. I still think that the deeper problem is that it still looks at local apic rules even when those rules are completely nonsensical. For example, that MAX_LOCAL_APIC range test may not matter simply because it's testing a constant value, but it still smells entirely wrong to even check for that, when the system doesn't necessarily have one. So I think your patch may fix the immediate bug, but I think it's still just a band-aid. Either we should just make all machines look like they have the proper local apic mappings, or we shouldn't look at any local apic rules AT ALL. So I'd rather see those apic_maps[] just be properly filled in. > Sure you can argue that we could avoid it for SMP=n builds completely, > but I think the right thing to do is to aim for removing CONFIG_SMP and > make the UP build a subset of a generic SMP capable build which has > CONFIG_NR_CPUS=1, i.e. num_possible_cpus() = 1. Why? I wouldn't be entirely opposed to just doing that. UP has become fairly irrelevant. That said, UP is *not* entirely irrelevant on other architectures, and if we drop UP support on x86, we'll be effectively dropping a lot of coverage testing. The number of people who do cross-compilers is pretty small. End result: I'd *much* rather get rid of X86_UP_APIC and the "nolapic" kernel command line, and say "even UP has to have a local APIC". We already require a Pentium-class CPU, so in practice we already require that local APIC setup. And yes, machines existed where it could be turned off, but I don't think that is relevant any more. Put another way: I think "UP config for wider build testing" is a _lot_ more relevant than "no LAPIC support". Linus