linux-kernel - Re: [RFC PATCH] irqchip/gic-v3: wait irq done to set affinity

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: <86pmbrop11.wl-maz@kernel.org>
Date:   Fri, 06 Jan 2023 11:55:54 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Yipeng Zou <zouyipeng@...wei.com>
Cc:     <tglx@...utronix.de>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <hewenliang4@...wei.com>,
        <chris.zjh@...wei.com>, <liaochang1@...wei.com>
Subject: Re: [RFC PATCH] irqchip/gic-v3: wait irq done to set affinity

On Fri, 06 Jan 2023 08:21:36 +0000,
Yipeng Zou <zouyipeng@...wei.com> wrote:
> 
> Recently we have some problem about gic set affinity in our test.
> 
> This patch just aim to make some discuss about this problem.
> 
> For now, the implementation of gic set affinity going to take effects
> immediately, and without check if any irq are being processed.
> 
> So, This leads to some problem, think about this scenario:
> 
> 1. First, we have an irq was generated by an device.
> 
> 2. In the processing of this irq(after handle event, before clear
> IRQD_IRQ_INPROGRESS flag), we modify the route and the gic takes effect
> immediately,at the same time the new one was generated again.

How is that possible?

If it is affected by GICD_IROUTERn (as your patch suggests), then it
is a SPI. If it is a SPI, it has an active state. Which means it
cannot fire again without a deactivation (EOI if EOImode=0, EOI+DIR if
EOImode=1) having taken place.

So either something has deactivated the interrupt without masking it
beforehand, or the active state is not honoured. Either way, this is
wrong.

> 
> 3. The new irq will be processing in other cpu which different form the
> old one.
> 
> 4. The new irq going to be discarded because of the flag IRQD_IRQ_INPROGRESS
> has been set.
> 
> I notice that if we set IRQF_ONESHOT when register the irq, this problem
> will gone.
> 
> But I'm also thinking about change the gic_set_affinity function, to wait
> current irq done on all cpus before gic_write_irouter.
> I'm not sure if that's appropriate.

The base architecture should guarantee that this is not a problem,
thanks to the active state. If that was a LPI (which do not have an
active state), that'd be a different problem. But this doesn't seem to
be the case here.

I'm afraid to say that what you describe seem like a bug of some sort,
either HW or SW.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.