linux-kernel - Re: [RFC PATCH v2 0/5] Rework realtek-rtl IRQ driver

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:   Tue, 28 Dec 2021 09:09:24 +0100
From:   Birger Koblitz <mail@...ger-koblitz.de>
To:     Sander Vanheule <sander@...nheule.net>, tglx@...utronix.de,
        maz@...nel.org, robh+dt@...nel.org, devicetree@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, bert@...t.com, john@...ozen.org
Subject: Re: [RFC PATCH v2 0/5] Rework realtek-rtl IRQ driver

Hi Sander,
> I haven't tested this with VSMP, because it is out of scope for this series. For the binding, I expect that would only require N register ranges instead of one; one per CPU. I think the driver should then be able to perform the IRQ balancing based on that information alone, given that the parent IRQs are available at each CPU.

whether this is out of the scope of this series is not the point. In my experience you only see issues with locking and race conditions with the IRQ driver if you test with VSMP enabled,
because only with VSMP you can be in the IRQ code multiple times at the same time. Since you want to change routing logic and hierarchies I would believe it to be a very good idea
to test that. The present code passes that test.

Cheers,
   Birger