linux-kernel - Re: [PATCH 4/4] irqchip: imgpdc: Pass on peripheral mask/unmasks to the parent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 5 Oct 2017 16:43:48 +0100
From:   Ed Blake <ed.blake@...drel.com>
To:     James Hogan <james.hogan@...tec.com>
Cc:     tglx@...utronix.de, jason@...edaemon.net, marc.zyngier@....com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] irqchip: imgpdc: Pass on peripheral mask/unmasks to
 the parent

On 05/10/17 16:26, James Hogan wrote:
> On Thu, Oct 05, 2017 at 03:48:53PM +0100, Ed Blake wrote:
>>
>> I'm not sure how this is supposed to work, but the issue seems to be
>> that without this patch the parent irq isn't being masked.  This is
>> causing the parent handler (MIPS GIC in this case) to be called
>> continuously.  This leads to the PDC irq being masked each time, but not
>> the parent irq.  This is the callstack:
>>
>>     "irq-imgpdc.c"::perip_irq_mask
>>     mask_ack_irq
>>     handle_level_irq
>>     generic_handle_irq_desc
>>     generic_handle_irq
>>     generic_handle_irq_desc
>>     generic_handle_irq
>>     gic_handle_shared_int
>>     gic_handle_local_int
>>     "irq-mips-gic.c"::gic_irq_dispatch
>>     generic_handle_irq_desc
>>     generic_handle_irq
>>     do_IRQ
>>     plat_irq_dispatch()
> Right, yeh it shouldn't technically be masked by the parent (contrary to
> what I said above) because its a chained handler, i.e. as far as the
> kernel knows there could be other IRQs coming through that GIC pin that
> would also get masked.
>
> (though IIRC the perip IRQs can wake, but then they go straight out to
> separate dedicated IRQ pins into the main IRQ chip, i.e. the GIC in this
> case).

That's right, each of the PDC peripherals (RTC, WD, IR) has a dedicated
IRQ to the parent, and the sys wakes are muxed onto a single IRQ.
> I think its worth understanding the root cause here though. Disabling
> routing of an IRQ fundamentally should deassert it. Is it an actual
> hardware bug that has reached silicon?

So you think the PDC->parent IRQ must not be being de-asserted when
IRQ_ROUTE is cleared?  I hadn't considered this and thought it was some
persistence in the GIC due to not being masked / ack'd there.  Is that
possible?  I'll discuss the possible IRQ_ROUTE issue with the hardware team.

Ed.