linux-kernel - Re: [tip:x86/urgent] x86, apic: Map the local apic when parsing the MP table.

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]

Message-ID: <m1d3tvtekq.fsf@fess.ebiederm.org>
Date:	Fri, 06 Aug 2010 18:08:05 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Yinghai Lu <yinghai@...nel.org>, mingo@...hat.com,
	linux-kernel@...r.kernel.org, tvrtko.ursulin@...hos.com,
	hilld@...arystorm.net, tglx@...utronix.de, hpa@...ux.intel.com,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, apic: Map the local apic when parsing the MP table.

"H. Peter Anvin" <hpa@...or.com> writes:

> On 08/06/2010 05:08 PM, Yinghai Lu wrote:
>> this change is not needed, it will break:
>> 1. found mptable, but is using default contruct path.
>> 2. visws path, found found mptable, but get_smp_conf is not called.
>> 
>> YH
>
> I'm not sure the above is decipherable.  Please provide an incremental
> patch with a more detailed description.

YH was saying I overoptimized, and it looks like he is right,
although there are only one or two machines in existence that
are likely to be affected.

Untested patch to remove the cleverness below.  It it boots all
is well.

---

From: Eric W. Biederman <ebiederm@...ssion.com>
Date: Fri, 6 Aug 2010 18:00:12 -0700
Subject: [PATCH] x86/apic:  Always map the local apic in init_apic_mappings.

In all of the common cases we currently map the local apic before
we get to init_apic_mappings.  Unfortunately there are still a few
weird subarch code paths that require us to map the local apic in
init_apic_mappings, and those subarchitectures set smp_found_config.

So just unconditionally run the fixmap code, and stop being clever.

Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com>
---
 arch/x86/kernel/apic/apic.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index c07e513..ad96090 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1603,11 +1603,16 @@ void __init init_apic_mappings(void)
 		apic_phys = mp_lapic_addr;
 
 		/*
-		 * acpi lapic path already maps that address in
-		 * acpi_register_lapic_address()
+		 * acpi and mptable paths already fixmap mp_lapic_addr
+		 * at FIX_APIC_BASE but perform the fixmap anyway
+		 * because our initialization code is spaghetti and
+		 * there are weird subarchitectures that do something
+		 * different.  The double fixmap isn't particularly
+		 * expensive and always running the code should prevent
+		 * bitrot.
+		 *
 		 */
-		if (!acpi_lapic && !smp_found_config)
-			set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
+		set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
 
 		apic_printk(APIC_VERBOSE, "mapped APIC to %08lx (%08lx)\n",
 					APIC_BASE, apic_phys);
-- 
1.6.5.2.143.g8cc62

--
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/