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]

Date: Thu, 27 Jun 2024 04:29:16 -0700
From: Krzysztof Olędzki <ole@....pl>
To: Guenter Roeck <linux@...ck-us.net>,
        Heiner Kallweit
 <hkallweit1@...il.com>,
        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 24.06.2024 at 20:45, Guenter Roeck wrote:
> 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.

Right, sorry for not mentioning this in the original report:

[    0.269013] pci 0000:00:1f.3: [8086:1c22] type 00 class 0x0c0500
[    0.269098] pci 0000:00:1f.3: reg 0x10: [mem 0xc3a02000-0xc3a020ff 64bit]
[    0.269186] pci 0000:00:1f.3: reg 0x20: [io  0x3000-0x301f]
[    0.334962] pci 0000:00:1f.3: Adding to iommu group 7
[    7.874736] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt

$ lspci -s 0000:00:1f.3 -vvnn
00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04)
        Subsystem: Dell Device [1028:04de]
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin C routed to IRQ 19
        IOMMU group: 7
        Region 0: Memory at c3a02000 (64-bit, non-prefetchable) [size=256]
        Region 4: I/O ports at 3000 [size=32]
        Kernel driver in use: i801_smbus

Krzysztof