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 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.