linux-kernel - Re: [PATCH v3 32/37] mtd: nand: denali: support hardware-assisted erased page detection

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] [day] [month] [year] [list]

Date:   Tue, 6 Jun 2017 11:04:19 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc:     linux-mtd@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Marek Vasut <marek.vasut@...il.com>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
        Graham Moore <grmoore@...nsource.altera.com>,
        Enrico Jorns <ejo@...gutronix.de>,
        Chuanxiao Dong <chuanxiao.dong@...el.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jassi Brar <jaswinder.singh@...aro.org>
Subject: Re: [PATCH v3 32/37] mtd: nand: denali: support hardware-assisted
 erased page detection

Hi Boris,


2017-03-31 1:30 GMT+09:00 Boris Brezillon <boris.brezillon@...e-electrons.com>:
> On Thu, 30 Mar 2017 17:15:03 +0900
> Masahiro Yamada <yamada.masahiro@...ionext.com> wrote:
>
>> Recent versions of this IP support automatic erased page detection.
>> If an erased page is detected on reads, the controller does not set
>> INTR__ECC_UNCOR_ERR, but INTR__ERASED_PAGE.  If this feature is
>> supported, the driver can use this information instead of calling
>> nand_check_erased_ecc_chunk().
>>
>> The detection of erased page is based on the number of zeros in the
>> page; if the number of zeros is less than the value in the field
>> ERASED_THRESHOLD, the page is assumed as erased.
>>
>> Set the ERASED_THRESHOLD to (chip->ecc.strength + 1).  This is the
>> worst case where all the bitflips come from the same ECC sector.
>> This field is Reserved for older IP versions, so this commit has
>> no impact on them.
>
> Do you have a way to know the actual number of bitflips in an erased
> ECC block?

There is no way to the actual number of bitflips
except that the driver parses the whole buffer counting bitflips.


> BTW, is the threshold a per-page information or a per ECC
> block information.

Per-page.

Honestly, this hardware feature is not nice
because per-chunk threshold makes sense .




> If you can't know the real number of bitflips I don't think it's safe
> to set the threshold to chip->ecc.strength + 1.

Right.

> You can still use the feature to detect erased pages without any
> bitflips (set ERASED_THRESHOLD to 1), which should be the case most of
> the time, but for cases where you have bitflips I'd recommend using
> nand_check_erased_ecc_chunk() if you can't know the actual number of
> bitflips in the page.
>

You are right.


Probably, this feature can work safely
only when ERASED_THRESHOLD == 1.


I decided to drop this patch from v4 for now,
but I will consider it.


-- 
Best Regards
Masahiro Yamada