On Thu, Mar 12, 2020 at 02:32:44PM +0100, Wolfram Sang wrote:
> From: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
>
> i2c_verify_client() can fail, so we need to put the device when that
> happens.
NAK, this will do double put and messing up with reference counters.
Besides the fact, that device may disappear after looking up which leads us to
even more problems.
See how i2c_acpi_find_client_by_adev() is used in callers.
>
> Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications")
> Reported-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> Signed-off-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
> ---
>
> RFC because I don't know if it can be that the returned dev is not an
> i2c_client. Yet, since it can happen theoretically, I think we should
> have the checks.
>
> drivers/i2c/i2c-core-acpi.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
> index 8f3dbc97a057..8b0ff780919b 100644
> --- a/drivers/i2c/i2c-core-acpi.c
> +++ b/drivers/i2c/i2c-core-acpi.c
> @@ -394,9 +394,17 @@ EXPORT_SYMBOL_GPL(i2c_acpi_find_adapter_by_handle);
> static struct i2c_client *i2c_acpi_find_client_by_adev(struct acpi_device *adev)
> {
> struct device *dev;
> + struct i2c_client *client;
>
> dev = bus_find_device_by_acpi_dev(&i2c_bus_type, adev);
> - return dev ? i2c_verify_client(dev) : NULL;
> + if (!dev)
> + return NULL;
> +
> + client = i2c_verify_client(dev);
> + if (!client)
> + put_device(dev);
> +
> + return client;
> }
>
> static int i2c_acpi_notify(struct notifier_block *nb, unsigned long value,
> --
> 2.20.1
>
--
With Best Regards,
Andy Shevchenko
