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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <18c810b6-2961-44e6-b890-5c6830fde995@roeck-us.net>
Date: Wed, 12 Jun 2024 10:49:39 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Wolfram Sang <wsa@...nel.org>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: 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

Hi,

On Mon, Jan 10, 2022 at 09:28:55AM -0800, Guenter Roeck wrote:
> While playing with SMBus alert functionality, I noticed the following
> messages if alert was active on more than once device.
> 
> smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0
> smbus_alert 3-000c: no driver alert()!
> 
> or:
> 
> smbus_alert 3-000c: SMBALERT# from dev 0x28, flag 0
> 
> This is seen if multiple devices assert alert at the same time and at least
> one of them does not or not correctly implement SMBus arbitration.
> 
> Once it starts, this message repeats forever at high rate.
> Worst case, the problem turn resulted in system crashes after a while.
> 
> The following two patches fix the problem for me. The first patch
> aborts the endless loop in smbus_alert() if no handler is found
> for an alert address. The second patch sends alerts to all devices
> with alert handler if that situation is observed.
> 
> I split the changes into two patches since I figured that the first patch
> might be easier to accept. However, both patches are really needed to
> fix the problem for good.
> 
> 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.
> 
> ----------------------------------------------------------------
> Guenter Roeck (2):
>       i2c: smbus: Improve handling of stuck alerts
>       i2c: smbus: Send alert notifications to all devices if source not found
> 
>  drivers/i2c/i2c-smbus.c | 64 ++++++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 58 insertions(+), 6 deletions(-)

Looking through the patches I carry locally, I just noticed that
I never got a reply to this series. Is there a problem with it,
or did it just get lost ?

Thanks,
Guenter