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, 23 Nov 2015 09:01:20 +0100 From: Ingo Molnar <mingo@...nel.org> To: Juergen Gross <jgross@...e.com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, the arch/x86 maintainers <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...e.de> Subject: Re: lapic_suspend/lapic_resume wrong? * Juergen Gross <jgross@...e.com> wrote: > Hi, > > while trying to find the reason for a hanging kernel during resume > handling I found a strange inconsistency in arch/x86/kernel/apic/apic.c > regarding usage of config options. > > Attached patch addresses this, no test done as I'm not sure whether > this is a correct approach. Can you have a look at it, please? > > > Juergen > > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index 2f69e3b..bc06c9d 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -2270,6 +2270,7 @@ static struct { > unsigned int apic_tmict; > unsigned int apic_tdcr; > unsigned int apic_thmr; > + unsigned int apic_cmci; > } apic_pm_state; > > static int lapic_suspend(void) > @@ -2299,6 +2300,10 @@ static int lapic_suspend(void) > if (maxlvt >= 5) > apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR); > #endif > +#ifdef CONFIG_X86_MCE_INTEL > + if (maxlvt >= 6) > + apic_pm_state.apic_cmci = apic_read(APIC_LVTCMCI); > +#endif > > local_irq_save(flags); > disable_local_APIC(); > @@ -2355,10 +2360,14 @@ static void lapic_resume(void) > apic_write(APIC_SPIV, apic_pm_state.apic_spiv); > apic_write(APIC_LVT0, apic_pm_state.apic_lvt0); > apic_write(APIC_LVT1, apic_pm_state.apic_lvt1); > -#if defined(CONFIG_X86_MCE_INTEL) > +#if defined(CONFIG_X86_THERMAL_VECTOR) > if (maxlvt >= 5) > apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr); > #endif > +#if defined(CONFIG_X86_MCE_INTEL) > + if (maxlvt >= 6) > + apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci); > +#endif > if (maxlvt >= 4) > apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc); > apic_write(APIC_LVTT, apic_pm_state.apic_lvtt); the x86 bit looks absolutely sensible to me. Have you checked whether we indeed lose this value over S/R, or is this mostly working fine by accident, due to us executing the CMCI vector initialization via: mce_syscore_resume()->__mcheck_cpu_init_vendor()->mce_intel_feature_init()->intel_init_cmci() on every resume event? The Xen fix is unrelated, just put into the same patch, right? Thanks, Ingo -- 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