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
| ||
|
Date: Mon, 24 Aug 2009 22:12:01 -0700 From: Yinghai Lu <yinghai@...nel.org> To: Ravikiran G Thirumalai <kiran@...lex86.org> CC: Ingo Molnar <mingo@...e.hu>, torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org, shai@...lex86.org, Suresh Siddha <suresh.b.siddha@...el.com> Subject: Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id Ravikiran G Thirumalai wrote: > On Mon, Aug 24, 2009 at 04:53:45PM -0700, Yinghai Lu wrote: >> Ravikiran G Thirumalai wrote: >>> Signed-off-by: Ravikiran Thirumalai <kiran@...lex86.org> >>> Cc: Yinghai Lu <yinghai@...nel.org> >>> >>> Index: linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c >>> =================================================================== >>> --- linux-2.6.31-rc6.orig/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 12:42:16.000000000 -0700 >>> +++ linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 14:12:21.654837472 -0700 >>> @@ -161,7 +161,8 @@ static int flat_apic_id_registered(void) >>> >>> static int flat_phys_pkg_id(int initial_apic_id, int index_msb) >>> { >>> - return initial_apic_id >> index_msb; >>> + return cpu_has_apic ? hard_smp_processor_id() >> index_msb : >>> + initial_apic_id >> index_msb; >>> } >> it seems we should use initial apic id here. >> > > Why? The specs seem to indicate otherwise unless I am mistaken -- > Intel systems programming guide, Vol 3A Part1, chapter 7 section > 7.5.5 - Identifying Logical Processors in a MP system: > <quote> > After the BIOS has completed the MP initialization protocol, each logical > processor can be uniquely identified by its local APIC ID. Software can > access these APIC IDs in either of the following ways > </quote> > phys_pkg_id() indicates that the logical package id is being looked up, > so local apic id should be used here no? > What am I missing? initial apic id : it can not changed, there is fixed mapping from that to physical processor id aka socket id / node id. apic id: could be changed by BIOS to any value. there is no good way to get phys_pkg_id from that. > > >> can you check which calling for vsmp cause the problem? >> arch/x86/kernel/cpu/addon_cpuid_features.c: c->cpu_core_id = apic->phys_pkg_id(c->initial_apicid, ht_mask_width) >> arch/x86/kernel/cpu/addon_cpuid_features.c: c->phys_proc_id = apic->phys_pkg_id(c->initial_apicid, core_plus_mask_width >> ); >> arch/x86/kernel/cpu/addon_cpuid_features.c: c->apicid = apic->phys_pkg_id(c->initial_apicid, 0); > > The above are definitely problematic. Anyplace that uses phys_pkg_id to get > the unique pkg id of a logical processor will have problems. that is from intel new cpuid(0x0b) leaf, that is with initial_apicid according to intel EDS. we need to figure out your initial apic id. and find out good way for phys_pkg_id. and may need to modify apic->phys_pkg_id member according to dmi info. 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/
Powered by blists - more mailing lists