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] [day] [month] [year] [list]
Message-ID:
 <NTZPR01MB10182E9F6E50D679A6EAC3B4F8B92@NTZPR01MB1018.CHNPR01.prod.partner.outlook.cn>
Date: Sun, 20 Apr 2025 03:31:09 +0000
From: EnDe Tan <ende.tan@...rfivetech.com>
To: Jarkko Nikula <jarkko.nikula@...ux.intel.com>, "linux-i2c@...r.kernel.org"
	<linux-i2c@...r.kernel.org>
CC: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>,
	"mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>,
	"jsd@...ihalf.com" <jsd@...ihalf.com>, "andi.shyti@...nel.org"
	<andi.shyti@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Leyfoon Tan <leyfoon.tan@...rfivetech.com>,
	"endeneer@...il.com" <endeneer@...il.com>
Subject: RE: [1/1] i2c: designware: Ensure runtime suspend is invoked during
 rapid slave unregistration and registration

It appears that when performing a rapid sequence of `delete_device -> new_device -> delete_device -> new_device`, the `dw_i2c_plat_runtime_suspend` is not invoked for the second `delete_device`.

This seems to happen because when `i2c_dw_unreg_slave` is about to trigger suspend during the second `delete_device`, the second `new_device` operation cancels the suspend. As a result, `dw_i2c_plat_runtime_resume` is not called (since there was no suspend), which means `i_dev->init` (i.e., `i2c_dw_init_slave`) is skipped.

Because `i2c_dw_init_slave` is skipped, `i2c_dw_configure_fifo_slave` is not invoked, which leaves `DW_IC_INTR_MASK` unconfigured.
If we inspect the interrupt mask register using devmem, it will show as zero.

Here's an example shell script to reproduce the issue:
```
#!/bin/sh

SLAVE_LADDR=0x1010
SLAVE_BUS=13
NEW_DEVICE=/sys/bus/i2c/devices/i2c-$SLAVE_BUS/new_device
DELETE_DEVICE=/sys/bus/i2c/devices/i2c-$SLAVE_BUS/delete_device

# Create initial device
echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE
sleep 2

# Rapid sequence of delete_device -> new_device -> delete_device -> new_device
echo $SLAVE_LADDR > $DELETE_DEVICE
echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE
echo $SLAVE_LADDR > $DELETE_DEVICE
echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE

# If we use devmem to inspect IC_INTR_MASK, it will show as zero
```


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ