From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1758214AbcH3LHl (ORCPT <rfc822;w@1wt.eu>);
        Tue, 30 Aug 2016 07:07:41 -0400
Received: from foss.arm.com ([217.140.101.70]:37318 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1757864AbcH3LHk (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 30 Aug 2016 07:07:40 -0400
Subject: Re: [PATCH] generic: Add the exception case checking routine for ppi
 interrupt
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
References: <1472530639-21616-1-git-send-email-majun258@huawei.com>
 <57C548D0.3090700@arm.com> <57C5617B.6080801@huawei.com>
Cc: Mark Rutland <Mark.Rutland@arm.com>
From: Marc Zyngier <marc.zyngier@arm.com>
X-Enigmail-Draft-Status: N1110
Organization: ARM Ltd
Message-ID: <57C568F8.20802@arm.com>
Date: Tue, 30 Aug 2016 12:07:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Icedove/38.7.0
MIME-Version: 1.0
In-Reply-To: <57C5617B.6080801@huawei.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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