From: Balbir Singh <bsingharora@gmail.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH 2/2] powernv/kdump: Fix cases where the kdump kernel can get HMI's
Date: Fri, 15 Dec 2017 13:55:49 +1100 [thread overview]
Message-ID: <CAKTCnznRRNT3cBP911KGAbAPn=_7W9T6h_SdG9wu5nCfFsegKA@mail.gmail.com> (raw)
In-Reply-To: <20171214233220.19f3b36d@roar.ozlabs.ibm.com>
On Fri, Dec 15, 2017 at 12:32 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
> On Thu, 14 Dec 2017 23:16:26 +1100
> Balbir Singh <bsingharora@gmail.com> wrote:
>
>> On Thu, Dec 14, 2017 at 12:51 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
>
>> >> I can't call smp_send_nmi_ipi due to the nmi_ipi_busy_count and
>> >> I'm worried about calling a stale nmi_ipi_function via the
>> >> system_reset_exception path, if we are OK with it, I can revisit
>> >> the code path
>> >
>> > You shouldn't get a stale one, that would also be a bug -- we
>> > have to cope with NMIs coming in at any time that are triggered
>> > externally (not by smp_send_nmi_ipi), so if you see any bugs
>> > there those need to be fixed separately.
>> >
>>
>> Yes, I think it's a bug, nothing clears nmi_ipi_function (from what
>> I can see), so when the next NMI comes in and goes into
>> pnv_system_reset_exception
>> it'll execute the stale handler.
>
> The CPU won't be in the nmi_ipi_pending_mask though, so it shouldn't
> get that far. You could add a bit of paranoia to clear the function
> pointer I suppose, but AFAIKS it's not needed.
>
Yep your right, but these things are so subtle :) I will as paranoia
cleanup nmi_ipi_function, but I'll add that as a TODO
Balbir Singh.
prev parent reply other threads:[~2017-12-15 2:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 8:08 [PATCH 1/2] powerpc/crash: Remove the test for cpu_online in the IPI callback Balbir Singh
2017-12-13 8:08 ` [PATCH 2/2] powernv/kdump: Fix cases where the kdump kernel can get HMI's Balbir Singh
2017-12-13 10:51 ` Nicholas Piggin
2017-12-14 0:12 ` Balbir Singh
2017-12-14 1:51 ` Nicholas Piggin
2017-12-14 12:16 ` Balbir Singh
2017-12-14 13:32 ` Nicholas Piggin
2017-12-15 2:55 ` Balbir Singh [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='CAKTCnznRRNT3cBP911KGAbAPn=_7W9T6h_SdG9wu5nCfFsegKA@mail.gmail.com' \
--to=bsingharora@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).