[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2ed01b76-0a8d-48ec-a366-40bca78de93e@redhat.com>
Date: Thu, 6 Feb 2025 12:00:31 -0500
From: Waiman Long <llong@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>, Waiman Long <llong@...hat.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
"H. Peter Anvin" <hpa@...or.com>, Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH v4] x86/nmi: Add an emergency handler in nmi_desc & use it
in nmi_shootdown_cpus()
On 2/6/25 11:14 AM, Thomas Gleixner wrote:
> On Wed, Feb 05 2025 at 21:46, Waiman Long wrote:
>> On 2/5/25 4:20 AM, Thomas Gleixner wrote:
>>>> +int set_emergency_nmi_handler(unsigned int type, nmi_handler_t handler)
>>>> +{
>>>> + struct nmi_desc *desc = nmi_to_desc(type);
>>>> + nmi_handler_t orig = NULL;
>>>> +
>>>> + if (!handler) {
>>>> + orig = READ_ONCE(desc->emerg_handler);
>>>> + WARN_ON_ONCE(!orig);
>>>> + }
>>>> +
>>>> + if (try_cmpxchg(&desc->emerg_handler, &orig, handler))
>>>> + return 0;
>>> What's the point of this cmpxchg()? What's the concurrency problem this
>>> tries to address?
>> It is because I am not sure if there can only be one instance of
>> nmi_shootdown_cpus() at any time. If there can't be more than one
>> instance, I can remove the atomic instruction.
> There are two ways to get there:
>
> 1) crash(), which installs a handler
>
> 2) emergency_reboot(), which sets the handler to NULL
>
> If they interfere, then the callback is the least of your
> worries. That's already broken today in so many other ways.
OK, I will remove the atomic instruction in the next version. Thanks for
the explanation.
Cheers,
Longman
Powered by blists - more mailing lists