From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] generic: Add the exception case checking routine for ppi interrupt
Date: Tue, 30 Aug 2016 12:07:36 +0100 [thread overview]
Message-ID: <57C568F8.20802@arm.com> (raw)
In-Reply-To: <57C5617B.6080801@huawei.com>
+Mark
On 30/08/16 11:35, majun (F) wrote:
>
>
> ? 2016/8/30 16:50, Marc Zyngier ??:
>> On 30/08/16 05:17, MaJun wrote:
>>> From: Ma Jun <majun258@huawei.com>
>>>
>>> During system booting, if the interrupt which has no action registered
>>> is triggered, it would cause system panic when try to access the
>>> action member.
>>
>> And why would that interrupt be enabled? If you enable a PPI before
>> registering a handler, you're doing something wrong.
>>
>
> Actually,the problem described above happened during the capture
> kernel booting.
>
> In my system, sometimes there is a pending physical timer
> interrupt(30) when the first kernel panic and the status is kept
> until the capture kernel booting.
And that's perfectly fine. The interrupt can be pending forever, as it
shouldn't get enabled.
> So, this interrupt will be handled during capture kernel booting.
Why? Who enables it?
>
> Becasue we use virt timer interrupt but not physical timer interrupt
> in capture kernel, the interrupt 30 has no action handler.
Again: who enables this interrupt? Whichever driver enables it should be
fixed.
> Besides, I think we need to do exception check in this function just
> like "handle_fasteoi_irq" does.
I respectfully disagree. This will only hide a whole class of silly
bugs, and I'd rather squash them instead of papering over them.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: "majun (F)" <majun258@huawei.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, tglx@linutronix.de,
dingtianhong@huawei.com, guohanjun@huawei.com
Cc: Mark Rutland <Mark.Rutland@arm.com>
Subject: Re: [PATCH] generic: Add the exception case checking routine for ppi interrupt
Date: Tue, 30 Aug 2016 12:07:36 +0100 [thread overview]
Message-ID: <57C568F8.20802@arm.com> (raw)
In-Reply-To: <57C5617B.6080801@huawei.com>
+Mark
On 30/08/16 11:35, majun (F) wrote:
>
>
> 在 2016/8/30 16:50, Marc Zyngier 写道:
>> On 30/08/16 05:17, MaJun wrote:
>>> From: Ma Jun <majun258@huawei.com>
>>>
>>> During system booting, if the interrupt which has no action registered
>>> is triggered, it would cause system panic when try to access the
>>> action member.
>>
>> And why would that interrupt be enabled? If you enable a PPI before
>> registering a handler, you're doing something wrong.
>>
>
> Actually,the problem described above happened during the capture
> kernel booting.
>
> In my system, sometimes there is a pending physical timer
> interrupt(30) when the first kernel panic and the status is kept
> until the capture kernel booting.
And that's perfectly fine. The interrupt can be pending forever, as it
shouldn't get enabled.
> So, this interrupt will be handled during capture kernel booting.
Why? Who enables it?
>
> Becasue we use virt timer interrupt but not physical timer interrupt
> in capture kernel, the interrupt 30 has no action handler.
Again: who enables this interrupt? Whichever driver enables it should be
fixed.
> Besides, I think we need to do exception check in this function just
> like "handle_fasteoi_irq" does.
I respectfully disagree. This will only hide a whole class of silly
bugs, and I'd rather squash them instead of papering over them.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2016-08-30 11:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-30 4:17 [PATCH] generic: Add the exception case checking routine for ppi interrupt MaJun
2016-08-30 4:17 ` MaJun
2016-08-30 8:50 ` Marc Zyngier
2016-08-30 8:50 ` Marc Zyngier
2016-08-30 10:35 ` majun (F)
2016-08-30 10:35 ` majun (F)
2016-08-30 11:07 ` Marc Zyngier [this message]
2016-08-30 11:07 ` Marc Zyngier
2016-08-30 11:21 ` Mark Rutland
2016-08-30 11:21 ` Mark Rutland
2016-08-31 6:35 ` majun (F)
2016-08-31 6:35 ` majun (F)
2016-08-31 8:35 ` Marc Zyngier
2016-08-31 8:35 ` Marc Zyngier
2016-09-01 8:15 ` majun (F)
2016-09-01 8:15 ` majun (F)
2016-09-01 9:03 ` Marc Zyngier
2016-09-01 9:03 ` Marc Zyngier
2016-09-02 13:08 ` Thomas Gleixner
2016-09-02 13:08 ` Thomas Gleixner
2016-09-02 15:49 ` Marc Zyngier
2016-09-02 15:49 ` Marc Zyngier
2016-09-02 16:13 ` [tip:irq/core] genirq: Robustify handle_percpu_devid_irq() tip-bot 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=57C568F8.20802@arm.com \
--to=marc.zyngier@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.