All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Torsten Kaiser <just.for.lkml@googlemail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH]Fix boot hang in 3.11-rc1/2 because of bug in AMD errata check
Date: Tue, 23 Jul 2013 15:32:43 +0200	[thread overview]
Message-ID: <20130723133243.GE8497@pd.tnic> (raw)
In-Reply-To: <20130723134829.25251b01@googlemail.com>

Basically this patch looks ok, just a couple of nitpicks/comments.

Please change the subject to something more meaningful like

"x86, AMD: Make cpu_has_amd_erratum use currect cpuinfo descriptor" or
so.

On Tue, Jul 23, 2013 at 01:48:29PM +0200, Torsten Kaiser wrote:
> cpu_has_amd_erratum() is buggy, because it uses the per-cpu cpu_info
> before it is filled by smp_store_boot_cpu_info() / smp_store_cpu_info().
> 
> If early microcode loading is enabled its collect_cpu_info_amd_early() will
> fill ->x86 and so the fallback to boot_cpu_data is not used.
> But ->x86_vendor was not filled and is still 0 == X86_VENDOR_INTEL resulting in 
> no errata fixes getting applied and my system hangs on boot.
> 
> Using cpu_info in cpu_has_amd_erratum() is wrong anyway: Its only caller
> init_amd() will have a struct cpuinfo_x86 as parameter and the set_cpu_bug()
> that is controlled by cpu_has_amd_erratum() also only uses that struct.
> 
> So pass the struct cpuinfo_x86 from init_amd() to cpu_has_amd_erratum() and
> the broken fallback can be dropped.
> 
> I also turned the vendor check into an BUG_ON() because init_amd() can only
> be used by AMD CPUs and if the current failure hadn't been silent this bug
> would have been much more obvious.

BUG_ON is kinda heavy-handed here, a WARN_ON should be fine.

Other than that, I like the commit message: it explains the whole deal
in a very detailed manner and I'd wish more commit messages on lkml
would be like that. Good job!

> Signed-off-by: Torsten Kaiser <just.for.lkml@googlemail.com>
> 
> --- a/arch/x86/kernel/cpu/amd.c	2013-07-22 06:33:10.027931005 +0200
> +++ b/arch/x86/kernel/cpu/amd.c	2013-07-22 06:35:15.757931265 +0200
> @@ -512,7 +512,7 @@ static void early_init_amd(struct cpuinf
>  
>  static const int amd_erratum_383[];
>  static const int amd_erratum_400[];
> -static bool cpu_has_amd_erratum(const int *erratum);
> +static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);
>  
>  static void init_amd(struct cpuinfo_x86 *c)
>  {
> @@ -729,11 +729,11 @@ static void init_amd(struct cpuinfo_x86
>  		value &= ~(1ULL << 24);
>  		wrmsrl_safe(MSR_AMD64_BU_CFG2, value);
>  
> -		if (cpu_has_amd_erratum(amd_erratum_383))
> +		if (cpu_has_amd_erratum(c, amd_erratum_383))
>  			set_cpu_bug(c, X86_BUG_AMD_TLB_MMATCH);
>  	}
>  
> -	if (cpu_has_amd_erratum(amd_erratum_400))
> +	if (cpu_has_amd_erratum(c, amd_erratum_400))
>  		set_cpu_bug(c, X86_BUG_AMD_APIC_C1E);
>  
>  	rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
> @@ -878,22 +878,15 @@ static const int amd_erratum_400[] =
>  static const int amd_erratum_383[] =
>  	AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0, 0, 0xff, 0xf));
>  
> -static bool cpu_has_amd_erratum(const int *erratum)
> +
> +static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum)
>  {
> -	struct cpuinfo_x86 *cpu = __this_cpu_ptr(&cpu_info);
>  	int osvw_id = *erratum++;
>  	u32 range;
>  	u32 ms;
>  
> -	/*
> -	 * If called early enough that current_cpu_data hasn't been initialized
> -	 * yet, fall back to boot_cpu_data.
> -	 */
> -	if (cpu->x86 == 0)
> -		cpu = &boot_cpu_data;
> -
> -	if (cpu->x86_vendor != X86_VENDOR_AMD)
> -		return false;
> +	/* Should never be called on non-AMD-CPUs */
> +	BUG_ON(cpu->x86_vendor != X86_VENDOR_AMD);
>  
>  	if (osvw_id >= 0 && osvw_id < 65536 &&
>  	    cpu_has(cpu, X86_FEATURE_OSVW)) {
> 

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

      reply	other threads:[~2013-07-23 13:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-23 11:48 [PATCH]Fix boot hang in 3.11-rc1/2 because of bug in AMD errata check Torsten Kaiser
2013-07-23 13:32 ` Borislav Petkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130723133243.GE8497@pd.tnic \
    --to=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jacob.shin@amd.com \
    --cc=johannes.hirte@fem.tu-ilmenau.de \
    --cc=just.for.lkml@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.