linux-kernel - Re: [PATCH] eeprom: at25: convert to spi-mem API

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: <764858d5-5633-4aeb-aabe-52f9eb1eb530@csgroup.eu>
Date: Mon, 3 Nov 2025 23:36:20 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: "hui.wang@...onical.com" <hui.wang@...onical.com>,
 "mwalle@...nel.org" <mwalle@...nel.org>,
 "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
 "florent.trinh-thai@...soprasteria.com"
 <florent.trinh-thai@...soprasteria.com>, "arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH] eeprom: at25: convert to spi-mem API



Le 03/11/2025 à 23:29, Sverdlin, Alexander a écrit :
> [Vous ne recevez pas souvent de courriers de alexander.sverdlin@...mens.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Christophe,
> 
> On Mon, 2025-11-03 at 22:46 +0100, Christophe Leroy wrote:
>>>>> Replace the RAW SPI accesses with spi-mem API. The latter will fall back to
>>>>> RAW SPI accesses if spi-mem callbacks are not implemented by a controller
>>>>> driver.
>>>>
>>>> With this patch (kernel v6.17.1) our powerpc boards are totally
>>>> unstable, we get multiple random Oops due to bad memory accesses.
>>>>
>>>> With this commit reverted the board is stable again.
>>>>
>>>> The SPI driver is:
>>>>
>>>> CONFIG_SPI=y
>>>> CONFIG_SPI_MASTER=y
>>>> CONFIG_SPI_MEM=y
>>>> CONFIG_SPI_FSL_LIB=y
>>>> CONFIG_SPI_FSL_CPM=y
>>>> CONFIG_SPI_FSL_SPI=y
>>>>
>>>> How can we further investigate the issue ?
>>>
>>> could you share these "random Oops"?
>>
>> Sure. At the first place they look unrelated. Something is likely
> 
> indeed, no obvious connection... Do you have a chance to run KASAN?

I ran KASAN, it found an overrun in the loop in 
fsl_spi_cpm_bufs_complete() when t->len is odd, but once fixed the 
random problem is still there.

Christophe