All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Waiman Long <llong@redhat.com>, Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86/nmi: Use trylock in __register_nmi_handler() when in_nmi()
Date: Fri, 29 Nov 2024 17:57:30 +0100	[thread overview]
Message-ID: <87ttbqvuyt.ffs@tglx> (raw)
In-Reply-To: <89cdf387-f75f-472f-9f4b-e3582d1d2c93@redhat.com>

On Thu, Nov 28 2024 at 20:55, Waiman Long wrote:
> On 11/28/24 8:06 PM, Waiman Long wrote:
>>
>> On 11/28/24 4:28 AM, Peter Zijlstra wrote:
>>> On Wed, Nov 27, 2024 at 06:34:55PM -0500, Waiman Long wrote:
>>>> The __register_nmi_handler() function can be called in NMI context from
>>>> nmi_shootdown_cpus() leading to a lockdep splat like the following.
>>> This seems fundamentally insane. Why are we okay with this?
>>
>> According to the functional comment of nmi_shootdown_cpus(),
>>
>>  * nmi_shootdown_cpus() can only be invoked once. After the first
>>  * invocation all other CPUs are stuck in crash_nmi_callback() and
>>  * cannot respond to a second NMI.
>>
>> That is why it has to insert the crash_nmi_callback() call with 
>> register_nmi_handler() here in the NMI context. Changing this will 
>> require a fundamental redesign of the way this shutdown process need 
>> to be handled and I am not knowledgeable enough to do that. I will 
>> certainly appreciate idea to handle it in a more graceful way.
>
> One idea that I current have is to add a emergency callback pointer to 
> the nmi_desc structure which, if set, has priority over the handlers in 
> the linked list and will be called first. In this way, 
> nmi_shootdown_cpus() can set the pointer to point to 
> crash_nmi_callback() without the need to take a lock and insert another 
> handler at the front of the list. Please let me know if this idea is 
> acceptable or not.

That's way more sane.

  reply	other threads:[~2024-11-29 16:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27 23:34 [PATCH] x86/nmi: Use trylock in __register_nmi_handler() when in_nmi() Waiman Long
2024-11-28  9:28 ` Peter Zijlstra
2024-11-29  1:06   ` Waiman Long
2024-11-29  1:55     ` Waiman Long
2024-11-29 16:57       ` Thomas Gleixner [this message]
2024-11-30  3:10         ` Waiman Long

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=87ttbqvuyt.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llong@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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 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.