linux-kernel - Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc

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:	Fri, 31 Jul 2015 16:10:32 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Andrea Scian <rnd4@...e-tech.it>
Cc:	linux-mtd@...ts.infradead.org,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	linux-kernel@...r.kernel.org, Han Xu <b45815@...escale.com>
Subject: Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in
 default ECC read functions

On Fri, 31 Jul 2015 15:40:13 +0200
Andrea Scian <rnd4@...e-tech.it> wrote:

> 
> Boris,
> 
> Il 31/07/2015 12:32, Boris Brezillon ha scritto:
> > Hi Andrea,
> >
> > Adding Han in Cc.
> >
> > On Fri, 31 Jul 2015 12:07:21 +0200
> > Andrea Scian <rnd4@...e-tech.it> wrote:
> >
> >>
> >> Dear Boris,
> >>
> >>
> >> Il 30/07/2015 19:34, Boris Brezillon ha scritto:
> >>> The default NAND read functions are relying on an underlying controller
> >>> to correct bitflips, but some of those controller cannot properly fix
> >>> bitflips in erased pages.
> >>> In case of ECC failures, check if the page of subpage is empty before
> >>> reporting an ECC failure.
> >>
> >> I'm still wondering if chip->ecc.strength is the right threshold.
> >>
> >> Did you see my comments here [1]? WDYT?
> >
> > Yes I've read it, and decided to go for ecc->strength as a first
> > step (I'm more interested in discussing the approach than the threshold
> > value right now ;-)).
> 
> I perfectly understand, that's the reason why I ask if you want to move 
> to another thread ;-)
> 
> > Anyway, as you pointed out in the thread, writing data on an erased
> > page already containing some bitflips might generate even more
> > bitflips, so using a different threshold for the erased page check
> > makes sense. This threshold should definitely be correlated to the ECC
> > strength, but how, that's the question.
> >
> > How about taking a rather conservative value like 10% of the specified
> > ECC strength, and see how it goes.
> 
> Yes, I think that there's no real way to get the right value, other than 
> feedbacks from on-field testing with various devices.
> 
> I'm also thinking about changing how a NAND page is written on the 
> device, now that we know that even erased page may have (too many!) 
> bitflips if they has not been so-freshly erased.
> 
> Read on NAND device is lot's faster that write, so maybe we can:
> 
> a) read the page before write it, check for bitflips on erased area and 
> write it only if it fit our threshold
> 
> b) read the page after write it and check if the bitflips are lower that 
> a give value
> 
> In this way:
> - we can use ecc_strength as read threshold, because it fits all the 
> other NAND read
> 
> - we can use "something a bit lower than" mtd->bitflip_threshold on 
> read-before-write or read-after-write. If we don't do so the block will 
> be scrubbed next time we read it again (if we are lucky.. if we are 
> unlucky the block will have bitflip > ecc_strength!): IOW we did a write 
> that will trigger another erase/write cycle.
> 
> Am I misunderstanding something?

Nope, but this implies doing an extra read after each write :-/

-- 
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/