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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 17 Sep 2014 20:16:44 +0200 From: Boris BREZILLON <boris.brezillon@...e-electrons.com> To: Huang Shijie <shijie8@...il.com> Cc: Brian Norris <computersforpeace@...il.com>, Huang Shijie <shijie.huang@...el.com>, Mike Voytovich <mvoytovich@...pal.com>, linux-kernel@...r.kernel.org, Huang Shijie <b32955@...escale.com>, linux-mtd@...ts.infradead.org, Roy Lee <roylee@...pal.com>, David Woodhouse <dwmw2@...radead.org>, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH] mtd: nand: gpmi: add proper raw access support Hi Huang, On Wed, 17 Sep 2014 23:26:11 +0800 Huang Shijie <shijie8@...il.com> wrote: > On Mon, Sep 15, 2014 at 10:12:10PM +0200, Boris BREZILLON wrote: > > On Mon, 15 Sep 2014 22:43:02 +0800 > > Huang Shijie <shijie8@...il.com> wrote: > > > > > On Sat, Sep 13, 2014 at 10:38:41AM -0700, Brian Norris wrote: > > > > On Sat, Sep 13, 2014 at 11:36:24PM +0800, Huang Shijie wrote: > > > > > On Fri, Sep 12, 2014 at 02:30:50PM +0200, Boris BREZILLON wrote: > > > > > > This test validates what's returned by ecc_strength file in sysfs > > > > > > (which in turn is specified by the NAND controller when initializing > > > > > > the NAND chip). > > > > > > > > > > > > Doing this should not imply knowing the ECC algorithm in use in the > > > > > > NAND controller or the layout used to store data on NAND. > > > > > the difficulty is that the ECC parity area can be not byte aligned. > > > > > > > > Is there a problem with just rounding up to the nearest byte alignment > > > > and ignoring the few bits that are wasted? > > > > > > I feel a little confused with the two hooks. > > > > > > does the ecc->write_page_raw need to write the ECC parity data? > > > > Depending on the oob_required argument, it might be allowed to > > overwrite the ECC bytes even if this implies breaking page reliability > > (which is exactly what's expected). > > > > When using raw write with with oob write option the writer should take > > care of regenerating ECC bytes (which you said was impossible in GPMI > > case) or copying them from a previous raw read. > Thanks for the explanation. > > If we do not write the OOB, should we write the ECC bytes? No we shouldn't, and if you take a look at my new proposal you'll see that I always write ECC bytes even when oob_required is not required, but this is not a problem because in this case the nand_base code has already set the oob area to 0xff and, if I'm correct, writing 0xff is just like leaving the area unwritten. Of course leaving the ECC bytes to 0xff after a page erase will certainly trigger ECC errors when reading the page back in normal mode, but this is the MTD user responsibility to know what he's doing. > The hooks should comment clearly about how to implement them :( Absolutely, and if we all agree on the expected behavior, I'll be happy to document it ;-). > > > > > Here is a real example of what one could test with raw write + oob: > > 1) read a page in raw mode > > 2) flip some bits in the generated ECC bytes (or what you references as > > parity data) (this case can actually happen in real life) > > 3) write the modified page in raw mode > > 4) read back the same page in normal and check that ECC correction still > > works as expected > the nandbiterr test mode does the test as above. > But i think the multi-writes to the same page should occur only for the > SLC nand. I already have a patch for that :-): http://code.bulix.org/f69wuu-87021 This patch is erasing the NAND block between each bitflip insertion so that it can work on MLC nandflashes too. Anyway, IMHO this nandbiterrs testsuite should be implemented in a user-space tool (which could be part of mtd-utils) because we already have all the primitives we need to do it from there (ioctls to access NAND chips in raw mode). > > I will read your new patch set carefully in this weekend. Thanks. Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists