linux-kernel - AW: 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]

Message-ID: <BAF0C2081321BA469F9ADF648F97D9B04C78FA607E@MCC023.weinmann.com>
Date:	Fri, 1 Mar 2013 14:27:20 +0100
From:	"Velykokhatko, Sergey" <Sergey.Velykokhatko@...-med.de>
To:	"'Richard Genoud'" <richard.genoud@...il.com>
CC:	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>,
	"artem.bityutskiy@...ux.intel.com" <artem.bityutskiy@...ux.intel.com>
Subject: AW: Bug in mtd_get_device_size()?

Hi Richard,

>And if you want to tweak the BEB_LIMIT for each of your UBI partition, it's possible, via the ubiattach call ( get the master branchof of git://git.infradead.org/mtd-utils.git ) cf http://git.infradead.org/mtd-utils.git/commit/878e06ea555ba5dbfb974b3904d1a86a9a0e20f5

Aha! I didn't see that before. In my case will be useful. Thanks for idea! 

Let I ask you one more question, probably you have better idea how to resolve it. If you have no other solution as my, should not answer. Also: as I mentioned before, I have one big partition with 4 UBI volumes on it: one of volumes will contain extreme important data (for example device type and serial number) and data on this volume will be written only several times for whole device life; and on other volume will be stored patient data that will be written relative often. Now in my SW that runs as init process I call ubiatach+mount. If ubiattach or mount for any of UBI volumes returns error, I call ubiformat+ubimkvol+mount again. This is normal use case when the device booted first time after production. With 2.6.38 and 3.3 kernel I had no problems but after update on 3.7 I got reported 2 cases when devices lost all their data. Unfortunately I have no additional information why it happened, but anyway is it really necessary to runs ubiformat+ubimkvol for such cases? Or is it possible to recover data? Since my solution for this case is to put the device data in separate MTD with one single UBI volume. But you know how much space I should reserve on NAND MTD for single XML-File with 200Bytes :-). Alternative is to try to mount only device volume, copy data in tmpfs, run ubiformat+ubimkvol+mount and copy the data back to the device volume. Or you have other idea?

Thanks a lot,
Best regards,
Sergey

-----Ursprüngliche Nachricht-----
Von: Richard Genoud [mailto:richard.genoud@...il.com] 
Gesendet: Freitag, 1. März 2013 13:10
An: Velykokhatko, Sergey
Cc: Brian Norris; linux-mtd@...ts.infradead.org; linux-kernel@...r.kernel.org; artem.bityutskiy@...ux.intel.com
Betreff: Re: Bug in mtd_get_device_size()?

2013/3/1 Velykokhatko, Sergey <Sergey.Velykokhatko@...-med.de>:
> Hi Richard,
>
> Thanks a lot for your explanations. Now at least I understand your logic. And it seems to be reasonable. Your start point that all bad blocks for flash chip could be placed in single MTD. This is really worst worst case, but... Theoretically it could happened. And you should take care of it.
> And you are right again in things about my chip. I interpreted that up to 40 blocks could be bad from chip production. But now found on side 104 of 125 one note (sometimes I like datasheets :-) ):
>
> "
> Notes:
>  1. Invalid blocks are blocks that contain one or more bad bits. The 
> device may contain bad blocks upon shipment. Additional bad blocks may 
> develop over time; however, the total number of available blocks will 
> not drop below NVB during the endurance life of the device. Do not erase or program blocks marked invalid by the factory.
> "
>
> Also I should expect up to 40 bad blocks. Nearly 1%.  No more for endurance case.
That less than many NAND device, so in your case, you should set CONFIG_MTD_UBI_BEB_LIMIT to 10 (40 bad blocks on a total of 4096)

>
> Independing from this I wanted to make my kernel partition bigger. Now just no time for this, we are still in developing with our device.
>
>
>>If not, we have to accept to loose some space for bad blocks, or use 
>>NOR :)
> :) NOR is expensive. And UBI takes a lot of space since based on worst 
> case estimation of NAND features. I have to find compromise
yes... may be one day we will have cheap, reliable and fast flash storage.
(and at least your nand is SLC, not MLC !)

And if you want to tweak the BEB_LIMIT for each of your UBI partition, it's possible, via the ubiattach call ( get the master branchof of git://git.infradead.org/mtd-utils.git ) cf http://git.infradead.org/mtd-utils.git/commit/878e06ea555ba5dbfb974b3904d1a86a9a0e20f5
and via the ubi module parameter :
mtd=<name|num|path>[,<vid_hdr_offs>[,max_beb_per1024]]

with that, you won't need your kernel patch anymore !

Regards,
Richard.