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]

Message-ID: <55BB7ABD.7040008@dave-tech.it>
Date:	Fri, 31 Jul 2015 15:40:13 +0200
From:	Andrea Scian <rnd4@...e-tech.it>
To:	Boris Brezillon <boris.brezillon@...e-electrons.com>
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


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?


>> Maybe we can have this discussion in a separate thread, if you want ;-)
>
> No, I think we should keep discussing it in this thread.

OK

KR,

-- 

Andrea SCIAN

DAVE Embedded Systems
--
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/