linux-kernel - Re: Regression caused by "eeprom: at24: Probe for DDR3 thermal sensor in the SPD case" - "sysfs: cannot create duplicate filename"

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: <5a4e1cd6-5770-423b-9a25-a0fbfd93014a@roeck-us.net>
Date: Mon, 24 Jun 2024 20:45:27 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Heiner Kallweit <hkallweit1@...il.com>, Krzysztof Olędzki
 <ole@....pl>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Bartosz Golaszewski <brgl@...ev.pl>,
 Geert Uytterhoeven <geert+renesas@...der.be>,
 Wolfram Sang <wsa@...-dreams.de>
Cc: stable@...r.kernel.org, linux-i2c@...r.kernel.org,
 linux-hwmon@...r.kernel.org,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Regression caused by "eeprom: at24: Probe for DDR3 thermal sensor
 in the SPD case" - "sysfs: cannot create duplicate filename"

On 6/24/24 13:58, Heiner Kallweit wrote:
[ ... ]
> 
> Too me the issue also looks like a race. According to the OP's logs:
> - jc42 at 0x18 is instantiated successfully
> - jc42 at 0x19 returns -EBUSY. This is what is expected if the device
>    has been instantiated otherwise already.
> - jc42 at 0x1a returns -EEXIST. Here two instantiations of the the same
>    device seem to collide.
> - jc42 at 0x1b returns -EBUSY, like at 0x19.
> 
> So it looks like referenced change isn't wrong, but reveals an
> underlying issue with device instantiation races.

It isn't just a race, though. Try to unload the at24 (or ee1004 driver
for DDR4) and load it again, and you'll see the -EBUSY errors. Problem
is that instantiating those drivers _always_ triggers the call to
i2c_new_client_device() even if the jc42 device is already instantiated.
Unloading the spd/eeprom driver doesn't unload the jc42 driver,
so -EBUSY will be seen if the spd/eeprom driver is loaded again.

I have not been able to reproduce the backtrace with my systems, but those
are all with AMD CPUs using the piix4 driver, so timing is likely different.
Another difference is that my systems (with DDR4) use the ee1004 driver.
That driver instantiates the jc42 devices under a driver lock, so it is
guaranteed that a single instantiation doesn't interfere with other
instantiations running in parallel.

Guenter