linux-kernel - Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo

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: <4EC020A2.9070003@newsguy.com>
Date:	Sun, 13 Nov 2011 11:55:14 -0800
From:	Mike Dunn <mikedunn@...sguy.com>
To:	Robert Jarzmik <robert.jarzmik@...e.fr>
CC:	dedekind1@...il.com, David Woodhouse <dwmw2@...radead.org>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Ivan Djelic <ivan.djelic@...rot.com>
Subject: Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo

On 11/13/2011 08:38 AM, Robert Jarzmik wrote:
>
> And while we're discussing MTD API, I'd like to add another thing I was thinking
> of, from a conversation Mike and Ivan had.
>
> They discussed how UBIFS is "intolerant" to bitflips, and marks a block as
> "unusable" if one bitflip occured, even if the ECC can fix much more.
>
> What I was thinking is that the MTD oob information which exposes how many ECC
> are available should expose as well how many bitflips can be fixed (for example
> 4 bitflips can be fixed, 5 bitflips can be detected). 

You're referring to struct nand_ecclayout?  I wouldn't think that would be the
appropriate place; it just describes the layout, not operational details.

> Then, the read_oob()
> function could return back 0 if read was successful, -Exxxx on error, or a
> positive number N if N bitflips were fixed.
> With this information, upper level could decide from (read_oob() return and
> ecc.fixable_bitflips) if a block should be marked as unusable (worn out) or not.

Something along these lines was suggested by Artem a few days ago:

http://lists.infradead.org/pipermail/linux-mtd/2011-November/038376.html

I'm looking into implementing this.  Currently the drivers return -EUCLEAN from
read() and read_oob() if *any* bit error corrections were made, and this is the
information used by ubi to determine whether to scrub, and also whether to mark
a block as "bad" after running the PEB torture test.  To summarize Artem's
suggestion in my own words... The drivers expose the ecc strength to the mtd
subsystem (as Robert also suggests).  Mtd assigns a "scrublevel" to the device,
settable by the user through sysfs, with ecc strength as the default.  Read
operations no longer go directly to the driver (as they currently do for
unpartitioned devices) but are handled in mtd.  The driver returns the corrected
error count to mtd, which makes the determination of whether to return -EUCLEAN
or 0, based on the number of corrected errors and the scrublevel.

An objection might be that mtd should not be setting policy.  It's also a fairly
sizeable modification.  The alternative would be to implement a mechanism to
return the corrected error count to the higher layer (e.g., ubi) for each read
operation.  This would be even more work, requiring modifications to mtd and ubi.

I'd like to work to resolve this either way, as ubi and ubifs are the killer
apps for these new drivers.

Thanks,
Mike

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