linux-kernel - Re: [PATCH v2 06/17] irqchip/gic-v3: Configure SGIs as standard interrupts

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: <jhjmu4i830n.mognet@arm.com>
Date:   Thu, 02 Jul 2020 14:23:04 +0100
From:   Valentin Schneider <valentin.schneider@....com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Russell King <linux@....linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Sumit Garg <sumit.garg@...aro.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>, kernel-team@...roid.com
Subject: Re: [PATCH v2 06/17] irqchip/gic-v3: Configure SGIs as standard interrupts


On 30/06/20 11:15, Marc Zyngier wrote:
> On 2020-06-25 19:25, Valentin Schneider wrote:
>> Also, while staring at this it dawned on me that IPI's don't need the
>> eoimode=0 isb(): due to how the IPI flow-handler is structured, we'll
>> get a
>> gic_eoi_irq() just before calling into the irqaction. Dunno how much we
>> care about it.
>
> That's interesting. This ISB is a leftover from the loop we had before
> the pseudo-NMI code, where we had to make sure the write to EOIR was
> ordered with the read from IAR.
>
> Given that we have an exception return right after the interrupt
> handling, I *think* we could get rid of it (but that would need
> mode checking on broken systems such as TX1...).  I don't think
> this is specific to IPIs though.
>

If I got this one right:

  39a06b67c2c1 ("irqchip/gic: Ensure we have an ISB between ack and ->handle_irq")

you're describing case 2, which is indeed gone on gic-v3. However IIUC we
also want an ISB between poking IAR and calling into the irqaction (case 1)
- we get just that with IPIs due to the early gic_eoi_irq(), but we don't
for the other flows.

> Thanks,
>
>          M.