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: <CAFr9PXm4FTw5U9pFNoqptZ28M21czDHrbipCOVRcn7uABkEKSQ@mail.gmail.com>
Date:   Wed, 11 Aug 2021 16:37:55 +0900
From:   Daniel Palmer <daniel@...f.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     richard@....at, linux-mtd@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] mtd: spinand: core: Properly fill the OOB area.

Hi Miquel,

On Sat, 7 Aug 2021 at 05:02, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> This change looks fine, I'll use spinand->oobbuf instead of databuf +
> offset (will update when applying).

Thanks for looking at this for me. One thing I was worried about is
why the SPI NAND subsystem worked before this change with winbond etc
parts.

You probably don't remember now but I sent a patch to include support
for the longsys foresee parts that have the weird quirk of having no
ECC
data in the OOB so it's all usable by the user except for the bad
block marker and the ECC status bits being next to useless.
I found this issue while trying to validate ubi + my ECC status
decoding worked. [0]

The SPI NAND subsystem in u-boot worked fine as it could create the
ubi formatting on the flash and that would survive reboots but any
blocks written by Linux would be bad on reboot.
When Linux created the ubi format it would work until a reboot as the
correct data was cached in memory then u-boot would complain because
all of the blocks were marked bad.

But winbond parts mounted on the same board, same code etc worked just fine.
I guess the OOB is getting fixed somewhere else for other parts. Maybe
it only happens on the longsys parts because there is no ECC in OOB?

Anyhow I was worried my fix hid some other issue/broke other parts.

Cheers,

Daniel

0 - https://lore.kernel.org/lkml/20210408174922.55c1149f@xps13/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ