linux-kernel - Re: [PATCH 0/2] i2c: smbus: Handle stuck alerts

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: <f5886c83-27c2-475d-b75a-4ad107d039ed@roeck-us.net>
Date: Sun, 28 Jul 2024 17:31:09 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>,
 Wolfram Sang <wsa@...nel.org>, Jean Delvare <khali@...ux-fr.org>,
 linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] i2c: smbus: Handle stuck alerts

On 7/28/24 12:59, Wolfram Sang wrote:
> Hi Guenter,
> 
> as I mentioned before I now have to deal with SMBusAlert as well and had
> a chance to review and test this series. When developing the SMBAlert
> trigger mechanism for the i2c testunit, I also experienced the interrupt
> storm and your patches helped. See later mails for details.
> 
>> Note that there is one situation which is not addressed by this set of
>> patches: If the corrupted address points to yet another device with alert
>> handler on the same bus, the alert handler of that device will be called.
>> If it is not a source of the alert, we are back to the original problem.
>> I do not know how to address this case.
> 
> I think this can only work if we require .alert-handlers to start with a
> sanity check to make sure their device really raised an interrupt
> condition. And then return either -EBUSY or 0, similar to IRQ_HANDLED or
> IRQ_NONE. Or?
> 

I think so, but I am not sure if it is worth the effort. It would require
changing the API, and each driver supporting alert callbacks would have
to implement code to detect if it actually got an interrupt.

Thanks,
Guenter