linux-kernel - Re: Bug in mtd_get_device

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, 1 Mar 2013 13:02:18 +0100
From:	Ricard Wanderlof <ricard.wanderlof@...s.com>
To:	Richard Genoud <richard.genoud@...il.com>
CC:	"Velykokhatko, Sergey" <Sergey.Velykokhatko@...-med.de>,
	"artem.bityutskiy@...ux.intel.com" <artem.bityutskiy@...ux.intel.com>,
	Brian Norris <computersforpeace@...il.com>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Bug in mtd_get_device_size()?


On Fri, 1 Mar 2013, Richard Genoud wrote:

> From a Micron Nand datasheet :
> Micron NAND devices are specified to have a minimum of 2,008 (NVB)
> valid blocks out
> of every 2,048 total available blocks. This means the devices may have
> blocks that are
> invalid when they are shipped. An invalid block is one that contains
> one or more bad
> bits. Additional bad blocks may develop with use. However, the total
> number of avail-
> able blocks will not fall below NVB during the endurance life of the product.
>
> As there's very little information on how bad blocks appear, we can
> suppose that even on the 1st erase cycle of a block, it can turn bad.
> That's why we have to use the worst case scenario.

I would think that the primary reason for blocks to go bad is that they 
wear out so that they don't meet the endurance specifications. I.e., when 
worn out, one or more bits will start to flip significantly sooner than on 
a non-worn-out block. Wearing out is a continual process; blocks don't 
just suddenly 'go bad'.

I suppose one can imagine catastrophic failures at any time as well. I 
have never seen this case being specifically reference in an application 
note or white paper from a flash manufacturer though. As you say the 
datasheets are not very forthcoming on that issue.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30
--
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/