linux-kernel - Re: [PATCH v4 2/8] irqchip: Add Realtek RTD1295 mux driver

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]

Message-ID: <20191119222956.23665e5d@why>
Date:   Tue, 19 Nov 2019 22:29:56 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Andreas Färber <afaerber@...e.de>
Cc:     linux-realtek-soc@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Aleix Roca Nonell <kernelrocks@...il.com>,
        James Tai <james.tai@...ltek.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>
Subject: Re: [PATCH v4 2/8] irqchip: Add Realtek RTD1295 mux driver

On Tue, 19 Nov 2019 21:56:48 +0100
Andreas Färber <afaerber@...e.de> wrote:

> Am 19.11.19 um 13:01 schrieb Marc Zyngier:
> > On 2019-11-19 02:19, Andreas Färber wrote:  
> >> +static void rtd1195_mux_enable_irq(struct irq_data *data)
> >> +{
> >> +    struct rtd1195_irq_mux_data *mux_data =
> >> irq_data_get_irq_chip_data(data);
> >> +    unsigned long flags;
> >> +    u32 mask;
> >> +
> >> +    mask = mux_data->info->isr_to_int_en_mask[data->hwirq];
> >> +    if (!mask)
> >> +        return;  
> > 
> > How can this happen? You've mapped the interrupt, so it exists.
> > I can't see how you can decide to fail such enable.  
> 
> The [UMSK_]ISR bits and the SCPU_INT_EN bits are not (all) the same.
> 
> My ..._isr_to_scpu_int_en[] arrays have 32 entries for O(1) lookup, but
> are sparsely populated. So there are circumstances such as WDOG_NMI as
> well as reserved bits that we cannot enable.

But the you should have failed the map. The moment you allow the
mapping to occur, you have accepted the contract that this interrupt is
usable.

> This check should be
> identical to v3; the equivalent mask check inside the interrupt handler
> was extended with "mask &&" to do the same in this v4.

Spurious interrupts are a different matter. What I'm objecting to here
is a simple question of logic, whether or not you are allowed to fail
enabling an interrupt that you've otherwise allowed to be populated.
 
	M.
-- 
Jazz is not dead. It just smells funny...