public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dave Hansen <dave.hansen@intel.com>,
	Tony Battersby <tonyb@cybernetics.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] x86/cpu: fix intermittent lockup on poweroff
Date: Tue, 25 Apr 2023 23:05:19 +0200	[thread overview]
Message-ID: <87o7nbzn8w.ffs@tglx> (raw)
In-Reply-To: <f5c7a104-d422-bd02-d361-e9e9f433d41d@intel.com>

On Tue, Apr 25 2023 at 13:03, Dave Hansen wrote:

> On 4/25/23 12:26, Tony Battersby wrote:
>> -	if (cpuid_eax(0x8000001f) & BIT(0))
>> +	if (c->extended_cpuid_level >= 0x8000001f &&
>> +	    (cpuid_eax(0x8000001f) & BIT(0)))
>>  		native_wbinvd();
>
> Oh, so the existing code is running into the
>
>> If a value entered for CPUID.EAX is higher than the maximum input
>> value for basic or extended function for that processor then the data
>> for the highest basic information leaf is returned
> behavior.  It's basically looking at BIT(0) of some random extended
> leaf.  Probably 0x80000008 based on your 'cpuid -r' output.

Right, accessing that leaf without checking whether it exists is wrong,
but that does not explain the hang itself.

The only consequence of looking at bit 0 of some random other leaf is
that all CPUs which run stop_this_cpu() issue WBINVD in parallel, which
is slow but should not be a fatal issue.

Tony observed this is a 50% chance to hang, which means this is a timing
issue.

Now there are two things to investigate:

  1) Does the system go south if enough CPUs issue WBINVD concurrently?

     That should be trivial to analyze by enforcing concurreny on a
     WBINVD in an IPI via a global synchronization bit or such

  2) The first thing stop_this_cpu() does is to clear its own bit in the
     CPU online mask.

     The CPU which controls shutdown/reboot waits for num_online_cpus()
     to drop down to one, which means it can proceed _before_ the other
     CPUs have actually reached HALT.

     That's not a new thing. It has been that way forever. Just the
     WBINVD might cause enough delay to create problems.

     That should be trivial to analyze too by just waiting on the
     control side for e.g 100ms after num_online_cpus() dropped down to
     one.

The patch itself is correct as is, but as it does not explain the
underlying problem. There is a real serious issue underneath.

Thanks,

        tglx


  parent reply	other threads:[~2023-04-25 21:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25 19:26 [PATCH RFC] x86/cpu: fix intermittent lockup on poweroff Tony Battersby
2023-04-25 19:39 ` Borislav Petkov
2023-04-25 19:58   ` Tony Battersby
2023-04-25 20:03 ` Dave Hansen
2023-04-25 20:34   ` Dave Hansen
2023-04-25 21:06     ` Borislav Petkov
2023-04-25 21:05   ` Thomas Gleixner [this message]
2023-04-25 22:29     ` Dave Hansen
2023-04-25 23:00       ` Thomas Gleixner
2023-04-26  0:10       ` H. Peter Anvin
2023-04-26 14:45     ` Tony Battersby
2023-04-26 16:37       ` Thomas Gleixner
2023-04-26 17:37         ` Tony Battersby
2023-04-26 17:41           ` [PATCH v2] x86/cpu: fix SME test in stop_this_cpu() Tony Battersby
2023-05-22 14:07             ` [PATCH v2 RESEND] " Tony Battersby
2023-04-26 17:51           ` [PATCH RFC] x86/cpu: fix intermittent lockup on poweroff Tom Lendacky
2023-04-26 18:15             ` Dave Hansen
2023-04-26 19:18               ` Tom Lendacky
2023-04-26 22:02                 ` Andi Kleen
2023-04-26 23:20                   ` Thomas Gleixner
2023-04-26 20:00             ` Thomas Gleixner
2023-06-20 13:00 ` [tip: x86/core] x86/smp: Dont access non-existing CPUID leaf tip-bot2 for Tony Battersby
2023-06-20 13:00 ` [tip: x86/core] x86/smp: Make stop_other_cpus() more robust tip-bot2 for Thomas Gleixner

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=87o7nbzn8w.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=mingo@redhat.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tonyb@cybernetics.com \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox