linux-kernel - Re: [RFC PATCH v2 08/10] irqchip/gic-v3-its: Use irq_chip_ack

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:   Thu, 27 May 2021 13:17:59 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Vincenzo Frascino <vincenzo.frascino@....com>
Subject: Re: [RFC PATCH v2 08/10] irqchip/gic-v3-its: Use irq_chip_ack_parent()

On Tue, 25 May 2021 18:32:53 +0100,
Valentin Schneider <valentin.schneider@....com> wrote:
> 
> Subsequent patches will make the GIC irqchips use a flow handler that
> issues an ->irq_ack(). irqchips of child domains need to handle this.
> 
> Note: I'm very much not fond of this; this is treacherous and explodes if
> any parent chip doesn't have an ->ack() callback. It turns out okay with
> EOImode=0 because handle_fasteoi_irq() doesn't issue any ->ack(), but that
> is very fragile at best.
> 
> An alternative would be to
> o make irq_chip_ack_parent() check the callback against NULL

That's an overhead I'd like to avoid in the general case, given that
we already have a bunch of users.

> o make irq_chip_ack_parent() the default chip->irq_ack() via
>   MSI_FLAG_USE_DEF_CHIP_OPS.

Seem like a reasonable approach: how about a custom irq_ack() callback
that iterates over the hierarchy until it finds an a non-NULL entry?
Flows that don't use ack won't be impacted, users that need ack will
provide one if they want, and the default will do something slightly
slower, but at least unsurprising.

> XXX: what about pMSI and fMSI ?

Same thing. They are just bus-specific domains on top of the ITS
domain, and must follow the same convention.

However, this patch is perfectly acceptable to me (as long as you take
care of platform and fsl -MSI).

Thanks,

	M.

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