linux-kernel - Re: [RESEND PATCH v2 0/3] mtd: use ONFI bad blocks per LUN to calculate UBI bad PEB limit

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:   Thu, 27 Oct 2016 21:56:53 +0200
From:   Boris Brezillon <boris.brezillon@...e-electrons.com>
To:     Zach Brown <zach.brown@...com>
Cc:     <dwmw2@...radead.org>, <computersforpeace@...il.com>,
        <richard@....at>, <dedekind1@...il.com>,
        <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH v2 0/3] mtd: use ONFI bad blocks per LUN to
 calculate UBI bad PEB limit

Hi Zach,

Please do not resend after only one week. Reviewing this series was on
my TODO list ;).

On Thu, 27 Oct 2016 14:13:59 -0500
Zach Brown <zach.brown@...com> wrote:

> For ONFI-compliant NAND devices, the ONFI parameters report the maximum number
> of bad blocks per LUN that will be encountered over the lifetime of the device,
> so we can use that information to get a more accurate (and smaller) value for
> the UBI bad PEB limit.
> 
> The ONFI parameter "maxiumum number of bad blocks per LUN" is the max number of
> bad blocks that each individual LUN will ever ecounter. It is not the number of
> bad blocks to reserve for the nand device per LUN in the device.
> 
> This means that in the worst case a UBI device spanning X LUNs will encounter
> "maximum number of bad blocks per LUN" * X bad blocks. The implementation in
> this patch assumes this worst case and allocates bad block accordingly.

That's a discussion I had with Richard a few months ago, and I didn't
know someone had already proposed a patch for that. So that's all good
news.
Indeed, I really think we should use information retrieved at flash
detection time rather than asking the user to explicitly tweak the
bad_peb_limit value for its chip.

> 
> These patches are ordered in terms of their dependencies, but ideally, all 3
> would need to be applied for this to work as intended.
> 
> v1:
>  * Changed commit message to address concerns from v1[1] about this patch set
>    making best case assumptions.
> 
> [1]
> http://lkml.iu.edu/hypermail/linux/kernel/1505.1/04822.html
> 
> Jeff Westfahl (3):
>   mtd: introduce function max_bad_blocks
>   mtd: nand: implement 'max_bad_blocks' mtd function
>   mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available
> 
>  drivers/mtd/mtdpart.c        | 12 ++++++++++++
>  drivers/mtd/nand/nand_base.c | 34 ++++++++++++++++++++++++++++++++++
>  drivers/mtd/ubi/build.c      |  9 +++++++++
>  include/linux/mtd/mtd.h      |  1 +
>  4 files changed, 56 insertions(+)
>