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]

Date:	Fri, 06 Aug 2010 17:08:04 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	ebiederm@...ssion.com, tvrtko.ursulin@...hos.com,
	hilld@...arystorm.net, tglx@...utronix.de, hpa@...ux.intel.com
CC:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, apic: Map the local apic when parsing the
 MP table.

On 08/05/2010 05:15 PM, tip-bot for Eric W. Biederman wrote:
> Commit-ID:  5989cd6a1cbf86587edcc856791f960978087311
> Gitweb:     http://git.kernel.org/tip/5989cd6a1cbf86587edcc856791f960978087311
> Author:     Eric W. Biederman <ebiederm@...ssion.com>
> AuthorDate: Wed, 4 Aug 2010 13:30:27 -0700
> Committer:  H. Peter Anvin <hpa@...ux.intel.com>
> CommitDate: Thu, 5 Aug 2010 16:26:42 -0700
> 
> x86, apic: Map the local apic when parsing the MP table.
> 
> This fixes a regression in 2.6.35 from 2.6.34, that is
> present for select models of Intel cpus when people are
> using an MP table.
> 
> The commit cf7500c0ea133d66f8449d86392d83f840102632
> "x86, ioapic: In mpparse use mp_register_ioapic" started
> calling mp_register_ioapic from MP_ioapic_info.  An extremely
> simple change that was obviously correct.  Unfortunately
> mp_register_ioapic did just a little more than the previous
> hand crafted code and so we gained this call path.
> 
> The problem call path is:
> MP_ioapic_info()
>   mp_register_ioapic()
>    io_apic_unique_id()
>      io_apic_get_unique_id()
>        get_physical_broadcast()
>          modern_apic()
>            lapic_get_version()
>              apic_read(APIC_LVR)
> 
> Which turned out to be a problem because the local apic
> was not mapped, at that point, unlike the similar point
> in the ACPI parsing code.
> 
> This problem is fixed by mapping the local apic when
> parsing the mptable as soon as we reasonably can.
> 
> Looking at the number of places we setup the fixmap for
> the local apic, I see some serious simplification opportunities.
> For the moment except for not duplicating the setting up of the
> fixmap in init_apic_mappings, I have not acted on them.
> 
> The regression from 2.6.34 is tracked in bug
> https://bugzilla.kernel.org/show_bug.cgi?id=16173
> 
> Cc: <stable@...nel.org> 2.6.35
> Reported-by: David Hill <hilld@...arystorm.net>
> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
> Tested-by: Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
> Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com>
> LKML-Reference: <m1eiee86jg.fsf_-_@...s.ebiederm.org>
> Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com>
> ---
>  arch/x86/kernel/apic/apic.c |    2 +-
>  arch/x86/kernel/mpparse.c   |   16 ++++++++++++++++
>  2 files changed, 17 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index a96489e..c07e513 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1606,7 +1606,7 @@ void __init init_apic_mappings(void)
>  		 * acpi lapic path already maps that address in
>  		 * acpi_register_lapic_address()
>  		 */
> -		if (!acpi_lapic)
> +		if (!acpi_lapic && !smp_found_config)
>  			set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
>  
>  		apic_printk(APIC_VERBOSE, "mapped APIC to %08lx (%08lx)\n",
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
--
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/