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

[Guenter Roeck <linux@roeck-us.net>]

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