<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/mtd/ubi/ubi.h, branch linux-4.6.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.6.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.6.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2016-06-01T19:18:05Z</updated>
<entry>
<title>UBI: Fix static volume checks when Fastmap is used</title>
<updated>2016-06-01T19:18:05Z</updated>
<author>
<name>Richard Weinberger</name>
</author>
<published>2016-04-26T14:39:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9ebe3bf54f844d081cbf0146294d04cc69bd1cb9'/>
<id>urn:sha1:9ebe3bf54f844d081cbf0146294d04cc69bd1cb9</id>
<content type='text'>
commit 1900149c835ab5b48bea31a823ea5e5a401fb560 upstream.

Ezequiel reported that he's facing UBI going into read-only
mode after power cut. It turned out that this behavior happens
only when updating a static volume is interrupted and Fastmap is
used.

A possible trace can look like:
ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
Call Trace:
[&lt;ffffffff8140d841&gt;] dump_stack+0x63/0x82
[&lt;ffffffffa003abf6&gt;] ubi_eba_read_leb+0x486/0x4a0 [ubi]
[&lt;ffffffffa00453b3&gt;] ubi_check_volume+0x83/0xf0 [ubi]
[&lt;ffffffffa0039d97&gt;] ubi_open_volume+0x177/0x350 [ubi]
[&lt;ffffffffa00375d8&gt;] vol_cdev_open+0x58/0xb0 [ubi]
[&lt;ffffffff8124b08e&gt;] chrdev_open+0xae/0x1d0
[&lt;ffffffff81243bcf&gt;] do_dentry_open+0x1ff/0x300
[&lt;ffffffff8124afe0&gt;] ? cdev_put+0x30/0x30
[&lt;ffffffff81244d36&gt;] vfs_open+0x56/0x60
[&lt;ffffffff812545f4&gt;] path_openat+0x4f4/0x1190
[&lt;ffffffff81256621&gt;] do_filp_open+0x91/0x100
[&lt;ffffffff81263547&gt;] ? __alloc_fd+0xc7/0x190
[&lt;ffffffff812450df&gt;] do_sys_open+0x13f/0x210
[&lt;ffffffff812451ce&gt;] SyS_open+0x1e/0x20
[&lt;ffffffff81a99e32&gt;] entry_SYSCALL_64_fastpath+0x1a/0xa4

UBI checks static volumes for data consistency and reads the
whole volume upon first open. If the volume is found erroneous
users of UBI cannot read from it, but another volume update is
possible to fix it. The check is performed by running
ubi_eba_read_leb() on every allocated LEB of the volume.
For static volumes ubi_eba_read_leb() computes the checksum of all
data stored in a LEB. To verify the computed checksum it has to read
the LEB's volume header which stores the original checksum.
If the volume header is not found UBI treats this as fatal internal
error and switches to RO mode. If the UBI device was attached via a
full scan the assumption is correct, the volume header has to be
present as it had to be there while scanning to get known as mapped.
If the attach operation happened via Fastmap the assumption is no
longer correct. When attaching via Fastmap UBI learns the mapping
table from Fastmap's snapshot of the system state and not via a full
scan. It can happen that a LEB got unmapped after a Fastmap was
written to the flash. Then UBI can learn the LEB still as mapped and
accessing it returns only 0xFF bytes. As UBI is not a FTL it is
allowed to have mappings to empty PEBs, it assumes that the layer
above takes care of LEB accounting and referencing.
UBIFS does so using the LEB property tree (LPT).
For static volumes UBI blindly assumes that all LEBs are present and
therefore special actions have to be taken.

The described situation can happen when updating a static volume is
interrupted, either by a user or a power cut.
The volume update code first unmaps all LEBs of a volume and then
writes LEB by LEB. If the sequence of operations is interrupted UBI
detects this either by the absence of LEBs, no volume header present
at scan time, or corrupted payload, detected via checksum.
In the Fastmap case the former method won't trigger as no scan
happened and UBI automatically thinks all LEBs are present.
Only by reading data from a LEB it detects that the volume header is
missing and incorrectly treats this as fatal error.
To deal with the situation ubi_eba_read_leb() from now on checks
whether we attached via Fastmap and handles the absence of a
volume header like a data corruption error.
This way interrupted static volume updates will correctly get detected
also when Fastmap is used.

Reported-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Tested-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtd: ubi: Add logging functions ubi_msg, ubi_warn and ubi_err</title>
<updated>2016-03-20T20:36:05Z</updated>
<author>
<name>Joe Perches</name>
</author>
<published>2016-02-25T17:25:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=58d303def2a1fbfb5c794bafe7da54b900d9694e'/>
<id>urn:sha1:58d303def2a1fbfb5c794bafe7da54b900d9694e</id>
<content type='text'>
Using logging functions instead of macros can reduce overall object size.

$ size drivers/mtd/ubi/built-in.o*
   text	   data	    bss	    dec	    hex	filename
 271620	 163364	  73696	 508680	  7c308	drivers/mtd/ubi/built-in.o.allyesconfig.new
 287638	 165380	  73504	 526522	  808ba	drivers/mtd/ubi/built-in.o.allyesconfig.old
  87728	   3780	    504	  92012	  1676c	drivers/mtd/ubi/built-in.o.defconfig.new
  97084	   3780	    504	 101368	  18bf8	drivers/mtd/ubi/built-in.o.defconfig.old

Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>UBI: Use static class and attribute groups</title>
<updated>2015-06-02T11:16:25Z</updated>
<author>
<name>Takashi Iwai</name>
</author>
<published>2015-05-15T08:20:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=53cd255ce7539eff28d86eafb3416a6d964be4df'/>
<id>urn:sha1:53cd255ce7539eff28d86eafb3416a6d964be4df</id>
<content type='text'>
This patch cleans up the manual device_create_file() or
class_create_file() calls by replacing with static attribute groups.
It simplifies the code and also avoids the possible races between the
device/class registration and sysfs creations.

For the simplification, also make ubi_class a static instance with
initializers, too.

Amend a bit by Hujianyang.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Tested-by: Sheng Yong &lt;shengyong1@huawei.com&gt;
Signed-off-by: hujianyang &lt;hujianyang@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>UBI: power cut emulation for testing</title>
<updated>2015-04-13T19:05:17Z</updated>
<author>
<name>david.oberhollenzer@sigma-star.at</name>
</author>
<published>2015-03-26T22:59:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=502690674281a047abd45f81e64c498bc23a8bb3'/>
<id>urn:sha1:502690674281a047abd45f81e64c498bc23a8bb3</id>
<content type='text'>
Emulate random power cuts by switching device to ro after a number of
writes to allow simple power cut testing with nand-sim.

Maximum and minimum number of successful writes before power cut and
what kind of writes (EC header, VID header or none) to interrupt
configurable via debugfs.

Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>UBI: Add accessor functions for WL data structures</title>
<updated>2015-03-26T21:47:35Z</updated>
<author>
<name>Richard Weinberger</name>
</author>
<published>2014-10-28T15:18:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=23c482ef7b7611225f70efe46a3627b889cab1a4'/>
<id>urn:sha1:23c482ef7b7611225f70efe46a3627b889cab1a4</id>
<content type='text'>
Fastmap need access to various WL data structures as
fastmap tightly depends on WL.
To make the access less invasive add accessor functions.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>UBI: Add initial support for fastmap self checks</title>
<updated>2015-03-26T21:46:03Z</updated>
<author>
<name>Richard Weinberger</name>
</author>
<published>2014-09-22T09:44:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5fa7fa5dad0cf8f2b47bb8dca91c605c48d282f6'/>
<id>urn:sha1:5fa7fa5dad0cf8f2b47bb8dca91c605c48d282f6</id>
<content type='text'>
Using this debugfs knob fastmap self checks can be controlled.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Reviewed-by: Tanya Brokhman &lt;tlinder@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>UBI: Fastmap: Locking updates</title>
<updated>2015-03-26T21:46:02Z</updated>
<author>
<name>Richard Weinberger</name>
</author>
<published>2014-11-10T15:28:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=111ab0b26fc1bfad575d1e376e146d194d261e22'/>
<id>urn:sha1:111ab0b26fc1bfad575d1e376e146d194d261e22</id>
<content type='text'>
a) Rename ubi-&gt;fm_sem to ubi-&gt;fm_eba_sem as this semaphore
protects EBA changes.
b) Turn ubi-&gt;fm_mutex into a rw semaphore. It will still serialize
fastmap writes but also ensures that ubi_wl_put_peb() is not
interrupted by a fastmap write. We use a rw semaphore to allow
ubi_wl_put_peb() still to be executed in parallel if no fastmap
write is happening.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>UBI: Fastmap: Wrap fastmap specific function in a ifdef</title>
<updated>2015-03-26T21:45:56Z</updated>
<author>
<name>Richard Weinberger</name>
</author>
<published>2014-10-06T13:12:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5e0246e332349751d39d186ea0b7ec1e371ab2f8'/>
<id>urn:sha1:5e0246e332349751d39d186ea0b7ec1e371ab2f8</id>
<content type='text'>
...such that we can implement NOP variants of some functions.
This will help to reduce fastmap specific ifdefs in other c files.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Reviewed-by: Tanya Brokhman &lt;tlinder@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>UBI: Fastmap: Fix races in ubi_wl_get_peb()</title>
<updated>2015-03-26T20:24:24Z</updated>
<author>
<name>Richard Weinberger</name>
</author>
<published>2014-10-02T13:00:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d59f21bebe9d0fda34027ff1afda4f2b0d5f1869'/>
<id>urn:sha1:d59f21bebe9d0fda34027ff1afda4f2b0d5f1869</id>
<content type='text'>
ubi_wl_get_peb() has two problems, it reads the pool
size and usage counters without any protection.
While reading one value would be perfectly fine it reads multiple
values and compares them. This is racy and can lead to incorrect
pool handling.
Furthermore ubi_update_fastmap() is called without wl_lock held,
before incrementing the used counter it needs to be checked again.
It could happen that another thread consumed all PEBs from the
pool and the counter goes beyond -&gt;size.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
</entry>
<entry>
<title>UBI: Fastmap: Ensure that only one fastmap work is scheduled</title>
<updated>2015-03-26T18:30:54Z</updated>
<author>
<name>Richard Weinberger</name>
</author>
<published>2014-09-23T17:29:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=19371d73c9bd31a8e634ec5a80fc19fcd7714481'/>
<id>urn:sha1:19371d73c9bd31a8e634ec5a80fc19fcd7714481</id>
<content type='text'>
If the WL pool runs out of PEBs we schedule a fastmap write
to refill it as soon as possible.
Ensure that only one at a time is scheduled otherwise we might end in
a fastmap write storm because writing the fastmap can schedule another
write if bitflips are detected.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Reviewed-by: Tanya Brokhman &lt;tlinder@codeaurora.org&gt;
Reviewed-by: Guido Martínez &lt;guido@vanguardiasur.com.ar&gt;
</content>
</entry>
</feed>
