linux-toradex.git/drivers/mtd/ubi/eba.c, branch v4.10

UBI: Fix crash in try_recover_peb()

2016-10-19T22:06:06+00:00

    drivers/mtd/ubi/eba.c: In function ‘try_recover_peb’:
    drivers/mtd/ubi/eba.c:744: warning: ‘vid_hdr’ is used uninitialized in this function

The pointer vid_hdr is indeed not initialized, leading to a crash when
it is dereferenced.

Fix this by obtaining the pointer from the VID buffer, like is done
everywhere else.

Fixes: 3291b52f9ff0acc8 ("UBI: introduce the VID buffer concept")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Boris Brezillon 
Signed-off-by: Richard Weinberger

ubi: Fix races around ubi_refill_pools()

2016-10-02T20:54:01+00:00

When writing a new Fastmap the first thing that happens
is refilling the pools in memory.
At this stage it is possible that new PEBs from the new pools
get already claimed and written with data.
If this happens before the new Fastmap data structure hits the
flash and we face power cut the freshly written PEB will not
scanned and unnoticed.

Solve the issue by locking the pools until Fastmap is written.

Cc: 
Fixes: dbb7d2a88d ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger

UBI: introduce the VID buffer concept

2016-10-02T20:48:14+00:00

Currently, all VID headers are allocated and freed using the
ubi_zalloc_vid_hdr() and ubi_free_vid_hdr() function. These functions
make sure to align allocation on ubi->vid_hdr_alsize and adjust the
vid_hdr pointer to match the ubi->vid_hdr_shift requirements.
This works fine, but is a bit convoluted.
Moreover, the future introduction of LEB consolidation (needed to support
MLC/TLC NANDs) will allows a VID buffer to contain more than one VID
header.

Hence the creation of a ubi_vid_io_buf struct to attach extra information
to the VID header.

We currently only store the actual pointer of the underlying buffer, but
will soon add the number of VID headers contained in the buffer.

Signed-off-by: Boris Brezillon 
Signed-off-by: Richard Weinberger

UBI: hide EBA internals

2016-10-02T20:48:14+00:00

Create a private ubi_eba_table struct to hide EBA internals and provide
helpers to allocate, destroy, copy and assing an EBA table to a volume.

Now that external EBA users are using helpers to query/modify the EBA
state we can safely change the internal representation, which will be
needed to support the LEB consolidation concept.

Signed-off-by: Boris Brezillon 
Signed-off-by: Richard Weinberger

UBI: provide an helper to query LEB information

2016-10-02T20:48:14+00:00

This is part of our attempt to hide EBA internals from other part of the
implementation in order to easily adapt it to the MLC needs.

Here we are creating an ubi_eba_leb_desc struct to hide the way we keep
track of the LEB to PEB mapping.

Signed-off-by: Boris Brezillon 
Signed-off-by: Richard Weinberger

UBI: provide an helper to check whether a LEB is mapped or not

2016-10-02T20:48:14+00:00

This is part of the process of hiding UBI EBA's internal to other part of
the UBI implementation, so that we can add new information to the EBA
table without having to patch different places in the UBI code.

Signed-off-by: Boris Brezillon 
Signed-off-by: Richard Weinberger

UBI: simplify LEB write and atomic LEB change code

2016-10-02T20:48:14+00:00

ubi_eba_write_leb(), ubi_eba_write_leb_st() and
ubi_eba_atomic_leb_change() are using a convoluted retry/exit path.
Add the try_write_vid_and_data() function to simplify the retry logic
and make sure we have a single exit path instead of manually releasing
the resources in each error path.

Signed-off-by: Boris Brezillon 
Signed-off-by: Richard Weinberger

UBI: simplify recover_peb() code

2016-10-02T20:48:14+00:00

recover_peb() is using a convoluted retry/exit path. Add try_recover_peb()
to simplify the retry logic and make sure we have a single exit path
instead of manually releasing the resource in each error path.

Signed-off-by: Boris Brezillon 
Signed-off-by: Richard Weinberger

ubi: Make recover_peb power cut aware

2016-06-22T22:29:32+00:00

recover_peb() was never power cut aware,
if a power cut happened right after writing the VID header
upon next attach UBI would blindly use the new partial written
PEB and all data from the old PEB is lost.

In order to make recover_peb() power cut aware, write the new
VID with a proper crc and copy_flag set such that the UBI attach
process will detect whether the new PEB is completely written
or not.
We cannot directly use ubi_eba_atomic_leb_change() since we'd
have to unlock the LEB which is facing a write error.

Cc: stable@vger.kernel.org
Reported-by: Jörg Pfähler 
Reviewed-by: Jörg Pfähler 
Signed-off-by: Richard Weinberger

UBI: Fix static volume checks when Fastmap is used

2016-05-24T13:24:37+00:00

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:
[] dump_stack+0x63/0x82
[] ubi_eba_read_leb+0x486/0x4a0 [ubi]
[] ubi_check_volume+0x83/0xf0 [ubi]
[] ubi_open_volume+0x177/0x350 [ubi]
[] vol_cdev_open+0x58/0xb0 [ubi]
[] chrdev_open+0xae/0x1d0
[] do_dentry_open+0x1ff/0x300
[] ? cdev_put+0x30/0x30
[] vfs_open+0x56/0x60
[] path_openat+0x4f4/0x1190
[] do_filp_open+0x91/0x100
[] ? __alloc_fd+0xc7/0x190
[] do_sys_open+0x13f/0x210
[] SyS_open+0x1e/0x20
[] 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.

Cc: 
Reported-by: Ezequiel Garcia 
Tested-by: Ezequiel Garcia 
Signed-off-by: Richard Weinberger