linux-kernel - Re: x86_32_early_logical_apicid() -> one warning per CPU on late-determined BIGSMP systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Aug 2011 12:15:56 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Jan Beulich <JBeulich@...ell.com>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: x86_32_early_logical_apicid() -> one warning per CPU on
 late-determined BIGSMP systems

Hello,

On Thu, Aug 11, 2011 at 01:49:03PM +0100, Jan Beulich wrote:
> with generic_processor_info() getting run before generic_bigsmp_probe(),
> the values obtained by the former though apic->x86_32_early_logical_apicid()
> (still pointing to default_x86_32_early_logical_apicid() at that time) and
> stored into early_per_cpu(x86_cpu_to_logical_apicid, cpu) can't possibly
> match the ones obtained by setup_local_APIC() (since only at this point
> apic->x86_32_early_logical_apicid() points to bigsmp_early_logical_apicid()),
> thus causing the warning there to generally trigger on each CPU.

Ooh, okay, bigsmp switches apic pretty late in the init.  Wouldn't it
be better to move that to right after dmi init regardless of this
problem?

> Except for removing the warning, all other possible solutions to this that
> I can think of seem ugly to me (i.e. somehow re-initializing
> x86_cpu_to_logical_apicid for all CPUs), but I wonder why setting up
> x86_cpu_to_logical_apicid needs to be done this early if prior to
> setup_local_APIC() doing it a second time the value can't be used for
> anything anyway (because it could validly be BAD_APICID). If there
> aren't any future plans (honestly, I can't really make much sense of
> commit acb8bc09c6185e4d3d582d0076aaa6a89f19d8c5's comment),
> perhaps x86_32_early_logical_apicid() could get removed again?

Yeah, the future already came and went.  On x86_32, cpu -> numa node
mapping API used to require logical apicid and that's the reason why
logical apicid mapping was needed before processor init so that percpu
area affinity can be set up correctly.  This is also why the
requirement was soft - it only affected percpu memory layout.  The API
is now unified with 64bit and based on cpu number (and physical
apicid).  Please take a look at commit 89e5dc218e "x86: Replace
apic->apicid_to_node() with ->x86_32_numa_cpu_node()".

It's interesting that numaq was the only apic which required logical
apicid to calculate numa node and it can't even do that before SMP
bring up making acquiring logical apic ID early rather pointless -
but, well, it was a necessary transition step as logical apicid was
entangled with the rest of 32bit numa init.  Anyways, it's untangled
now and we no longer need early cpu -> logical apicid mapping.

So, yeah, please go ahead and remove it.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/