linux-kernel - Re: [PATCH] irq: fasteoi handler re-runs on concurrent invoke

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:   Wed, 22 Mar 2023 07:48:31 +0000
From:   "Gowans, James" <jgowans@...zon.com>
To:     "zouyipeng@...wei.com" <zouyipeng@...wei.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>
CC:     "maz@...nel.org" <maz@...nel.org>,
        "Raslan, KarimAllah" <karahmed@...zon.com>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] irq: fasteoi handler re-runs on concurrent invoke

On Wed, 2023-03-22 at 14:26 +0800, Yipeng Zou wrote:
> > 在 2023/3/17 19:49, Gowans, James 写道:
> > What are your thoughts on this approach compared to your proposal?
> 
> Hi,
> 
> I also agree with you, enhance the existing generic handlers is a good
> way to go.
> 
> Too many generic handlers really confuse developers.

Thomas, would you be open to taking the patch to tweak the handle_fasteoi_irq
handler? Or is there a different solution to this problem which you prefer?

> About CONFIG_GENERIC_PENDING_IRQ is actually some attempts we made
> before under the suggestion of Thomas.
> 
> This patch is valid for our problem. However, the current config is only
> supported on x86, and some code modifications are required on arm.

Thanks for the patch! I have been trying out CONFIG_GENERIC_PENDING_IRQ too, but
couldn't get it to work; it seems the IRQ never actually moved. I see from your
patch that we would need to tweak the callbacks and explicitly do the affinity
move in the EOI handler of the chip; the generic code won't do it for us.

> This has led to some changes in the original behavior of modifying
> interrupting affinity, from the next interrupt taking effect to the next
> to the next interrupt taking effect.

So this means that even if it's safe to change the affinity right now, the
change will actually be delayed until the *next* interrupt? Specifically because
interrupt doesn't have the IRQD_MOVE_PCNTXT state flag isn't set hence
irq_set_affinity_locked won't call irq_try_set_affinity?

JG