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: <jhjlfk28069.mognet@arm.com>
Date:   Thu, 02 Jul 2020 15:24:30 +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 02/07/20 14:48, Marc Zyngier wrote:
> On 2020-07-02 14:23, Valentin Schneider wrote:
>> 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.
>
> You just made me realise something amazing: I've started to forget about
> all this crap. Which is wonderful! ;-)
>

:)

> More seriously, you are absolutely right. If we wanted to address this,
> we'd probably have to give IPIs their own irqchip so that they get their
> own eoi callback. Not sure that's worth it.
>

I was initially thinking of something like

        if (static_branch_likely(&supports_deactivate_key))
                gic_write_eoir(irqnr);
        else if (__get_intid_range(irqnr) != SGI_RANGE)
                isb();

which is not particularly pretty, so maybe we should just slap this to the
isb():

                /* Superfluous for SGIs, but who cares */

>          M.