linux-stable.git/drivers/mtd/ubi, branch linux-4.1.y

ubi: Reject MLC NAND

2018-05-23T01:36:32+00:00

[ Upstream commit b5094b7f135be34630e3ea8a98fa215715d0f29d ]

While UBI and UBIFS seem to work at first sight with MLC NAND, you will
most likely lose all your data upon a power-cut or due to read/write
disturb.
In order to protect users from bad surprises, refuse to attach to MLC
NAND.

Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger 
Acked-by: Boris Brezillon 
Acked-by: Artem Bityutskiy 
Signed-off-by: Sasha Levin

ubi: Fix error for write access

2018-05-23T01:36:32+00:00

[ Upstream commit 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d ]

When opening a device with write access, ubiblock_open returns an error
code. Currently, this error code is -EPERM, but this is not the right
value.

The open function for other block devices returns -EROFS when opening
read-only devices with FMODE_WRITE set. When used with dm-verity, the
veritysetup userspace tool is expecting EROFS, and refuses to use the
ubiblock device.

Use -EROFS for ubiblock as well. As a result, veritysetup accepts the
ubiblock device as valid.

Cc: stable@vger.kernel.org
Fixes: 9d54c8a33eec (UBI: R/O block driver on top of UBI volumes)
Signed-off-by: Romain Izard 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi: fastmap: Don't flush fastmap work on detach

2018-05-23T01:36:32+00:00

[ Upstream commit 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 ]

At this point UBI volumes have already been free()'ed and fastmap can no
longer access these data structures.

Reported-by: Martin Townsend 
Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi: Fix race condition between ubi volume creation and udev

2018-03-21T03:49:52+00:00

[ Upstream commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 ]

Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volume active before
registering it.

Signed-off-by: Clay McClure 
Cc: 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi/upd: Always flush after prepared for an update

2017-05-17T19:07:44+00:00

[ Upstream commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 ]

In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I
managed to trigger and fix a similar bug. Now here is another version of
which I assumed it wouldn't matter back then but it turns out UBI has a
check for it and will error out like this:

|ubi0 warning: validate_vid_hdr: inconsistent used_ebs
|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592

All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
powercut in the middle of the operation.
ubi_start_update() sets the update-marker and puts all EBs on the erase
list. After that userland can proceed to write new data while the old EB
aren't erased completely. A powercut at this point is usually not that
much of a tragedy. UBI won't give read access to the static volume
because it has the update marker. It will most likely set the corrupted
flag because it misses some EBs.
So we are all good. Unless the size of the image that has been written
differs from the old image in the magnitude of at least one EB. In that
case UBI will find two different values for `used_ebs' and refuse to
attach the image with the error message mentioned above.

So in order not to get in the situation, the patch will ensure that we
wait until everything is removed before it tries to write any data.
The alternative would be to detect such a case and remove all EBs at the
attached time after we processed the volume-table and see the
update-marker set. The patch looks bigger and I doubt it is worth it
since usually the write() will wait from time to time for a new EB since
usually there not that many spare EB that can be used.

Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi: Make volume resize power cut aware

2016-08-20T03:07:58+00:00

[ Upstream commit 4946784bd3924b1374f05eebff2fd68660bae866 ]

When the volume resize operation shrinks a volume,
LEBs will be unmapped. Since unmapping will not erase these
LEBs immediately we have to wait for that operation to finish.
Otherwise in case of a power cut right after writing the new
volume table the UBI attach process can find more LEBs than the
volume table knows. This will render the UBI image unattachable.

Fix this issue by waiting for erase to complete and write the new
volume table afterward.

Cc: 
Reported-by: Boris Brezillon 
Reviewed-by: Boris Brezillon 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi: Fix early logging

2016-08-20T03:07:58+00:00

[ Upstream commit bc743f34dfa011e62edd0ea4ae8455be06c083b5 ]

We cannot use ubi_* logging functions before the UBI
object is initialized.

Cc: 
Fixes: 3260870331 ("UBI: Extend UBI layer debug/messaging capabilities")
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi: Fix race condition between ubi device creation and udev

2016-08-20T03:07:58+00:00

[ Upstream commit 714fb87e8bc05ff78255afc0dca981e8c5242785 ]

Install the UBI device object before we arm sysfs.
Otherwise udev tries to read sysfs attributes before UBI is ready and
udev rules will not match.

Cc: 
Signed-off-by: Iosif Harutyunov 
[rw: massaged commit message]
Signed-off-by: Richard Weinberger 

Signed-off-by: Sasha Levin

ubi: Make recover_peb power cut aware

2016-07-11T00:20:01+00:00

[ Upstream commit 972228d87445dc46c0a01f5f3de673ac017626f7 ]

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 
Signed-off-by: Sasha Levin

UBI: Fix static volume checks when Fastmap is used

2016-06-06T23:12:34+00:00

[ Upstream commit 1900149c835ab5b48bea31a823ea5e5a401fb560 ]

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 
Signed-off-by: Sasha Levin