linux-kernel - Re: [PATCH RFC] spi: spi-qpic-snand: overestimate corrected bitflips

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: <875xhr5r2y.fsf@bootlin.com>
Date: Fri, 23 May 2025 16:39:33 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Gabor Juhos <j4g8y7@...il.com>
Cc: Mark Brown <broonie@...nel.org>,  Md Sadre Alam
 <quic_mdalam@...cinc.com>,  Varadarajan Narayanan
 <quic_varada@...cinc.com>,  Sricharan Ramabadhran
 <quic_srichara@...cinc.com>,  linux-spi@...r.kernel.org,
  linux-mtd@...ts.infradead.org,  linux-arm-msm@...r.kernel.org,
  linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] spi: spi-qpic-snand: overestimate corrected bitflips

On 22/05/2025 at 19:33:26 +02, Gabor Juhos <j4g8y7@...il.com> wrote:

> The QPIC hardware is not capable of reporting the exact number of the
> corrected bitflips, it only reports the number of the corrected bytes.
> However the current code treats that as corrected bitflips which is
> quite inaccurate in most cases. For example, even if the hardware reports
> only one byte as corrected, that byte may have contained multiple bit
> errors from one up to the maximum number of correctable bits.
>
> Change the code to report the maximum of the possibly corrected bits,
> thus allowing upper layers to do certain actions before the data gets
> lost due to uncorrectable errors.
>
> Signed-off-by: Gabor Juhos <j4g8y7@...il.com>
> ---
> The patch tries to address Miquel's concerns [1] about the corrected bit
> error reporting capabilities of the QPIC hardware.
>
> [1] https://lore.kernel.org/all/87h61e8kow.fsf@bootlin.com

Thank you very much for attempting to improve the situation. Giving this
a second look, it will not work either and will be even worse, forcing
wear levelling after each read. So let's not change the returned value,
hopefully the real life is different as the test case and most bitflips
will be spread and not concentrated in a single byte. However I'd
welcome either a pr_warn_once() or at least a comment somewhere about
this.

Thanks,
Miquèl