linux-kernel - Re: [PATCH 2/2] irqchip/mips-gic: Fix Local compare interrupt

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:   Mon, 10 Apr 2017 15:06:00 -0700
From:   Paul Burton <paul.burton@...tec.com>
To:     Matt Redfearn <matt.redfearn@...tec.com>
CC:     <linux-mips@...ux-mips.org>, Ralf Baechle <ralf@...ux-mips.org>,
        "James Hogan" <james.hogan@...tec.com>,
        Marc Zyngier <marc.zyngier@....com>,
        "Jason Cooper" <jason@...edaemon.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] irqchip/mips-gic: Fix Local compare interrupt

Hi Matt,

On Friday, 31 March 2017 04:05:32 PDT Matt Redfearn wrote:
> Commit 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts") added
> mapping of several local interrupts during initialisation of the gic
> driver. This associates virq numbers with these interrupts.
> Unfortunately, as not all of the interrupts are mapped in hardware
> order, when drivers subsequently request these interrupts they conflict
> with the mappings that have already been set up. For example, this
> manifests itself in the gic clocksource driver, which fails to probe
> with the message:
> 
> clocksource: GIC: mask: 0xffffffffffffffff max_cycles: 0x7350c9738,
> max_idle_ns: 440795203769 ns
> GIC timer IRQ 25 setup failed: -22
> 
> This is because virq 25 (the correct IRQ number specified via device
> tree) was allocated to the PERFCTR interrupt (and 24 to the timer, 26 to
> the FDC).

I'm confused by this - the DT doesn't specify VIRQs, it specifies hardware IRQ 
numbers. Which VIRQ is used should be irrelevant. Is this on a system using 
gic_clocksource_init() from platform code? (Malta?) and therefore relying on  
MIPS_GIC_IRQ_BASE?

If so I think this would be much more cleanly fixed by moving to probe the 
clocksource using DT than by adding more fragile order-dependent mappings in 
the GIC driver. Perhaps we have to live with it for this cycle though...

Thanks,
    Paul

> To fix this, map all of these local interrupts in the hardware
> order so as to associate their virq numbers with the correct hw
> interrupts.
> 
> Fixes: 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts")
> Signed-off-by: Matt Redfearn <matt.redfearn@...tec.com>
> ---
> 
>  drivers/irqchip/irq-mips-gic.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
> index 11d12bccc4e7..cd20df12d63d 100644
> --- a/drivers/irqchip/irq-mips-gic.c
> +++ b/drivers/irqchip/irq-mips-gic.c
> @@ -991,8 +991,12 @@ static void __init gic_map_single_int(struct
> device_node *node,
> 
>  static void __init gic_map_interrupts(struct device_node *node)
>  {
> +	gic_map_single_int(node, GIC_LOCAL_INT_WD);
> +	gic_map_single_int(node, GIC_LOCAL_INT_COMPARE);
>  	gic_map_single_int(node, GIC_LOCAL_INT_TIMER);
>  	gic_map_single_int(node, GIC_LOCAL_INT_PERFCTR);
> +	gic_map_single_int(node, GIC_LOCAL_INT_SWINT0);
> +	gic_map_single_int(node, GIC_LOCAL_INT_SWINT1);
>  	gic_map_single_int(node, GIC_LOCAL_INT_FDC);
>  }


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)