kernel/linux.git/drivers/mtd/ubi, branch v4.4.235

ubi: Do not drop UBI device reference before using

2019-12-05T14:26:47+00:00

[ Upstream commit e542087701f09418702673631a908429feb3eae0 ] The UBI device reference is dropped but then the device is used as a parameter of ubi_err. The bug is introduced in changing ubi_err's behavior. The old ubi_err does not require a UBI device as its first parameter, but the new one does. Fixes: 32608703310 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by: Pan Bian Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

ubi: Put MTD device after it is not used

2019-12-05T14:26:46+00:00

[ Upstream commit b95f83ab762dd6211351b9140f99f43644076ca8 ] The MTD device reference is dropped via put_mtd_device, however its field ->index is read and passed to ubi_msg. To fix this, the patch moves the reference dropping after calling ubi_msg. Signed-off-by: Pan Bian Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

mtd: ubi: wl: Fix error return code in ubi_wl_init()

2018-09-19T20:49:00+00:00

commit 7233982ade15eeac05c6f351e8d347406e6bcd2f upstream. Fix to return error code -ENOMEM from the kmem_cache_alloc() error handling case instead of 0, as done elsewhere in this function. Fixes: f78e5623f45b ("ubi: fastmap: Erase outdated anchor PEBs during attach") Signed-off-by: Wei Yongjun Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

ubi: fastmap: Erase outdated anchor PEBs during attach

2018-07-25T08:18:33+00:00

commit f78e5623f45bab2b726eec29dc5cefbbab2d0b1c upstream. The fastmap update code might erase the current fastmap anchor PEB in case it doesn't find any new free PEB. When a power cut happens in this situation we must not have any outdated fastmap anchor PEB on the device, because that would be used to attach during next boot. The easiest way to make that sure is to erase all outdated fastmap anchor PEBs synchronously during attach. Signed-off-by: Sascha Hauer Reviewed-by: Richard Weinberger Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Cc: Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

ubi: Fix Fastmap's update_vol()

2018-07-25T08:18:33+00:00

commit f7d11b33d4e8cedf19367c09b891bbc705163976 upstream. Usually Fastmap is free to consider every PEB in one of the pools as newer than the existing PEB. Since PEBs in a pool are by definition newer than everything else. But update_vol() missed the case that a pool can contain more than one candidate. Cc: Fixes: dbb7d2a88d ("UBI: Add fastmap core") Signed-off-by: Richard Weinberger Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

ubi: Fix races around ubi_refill_pools()

2018-07-25T08:18:33+00:00

commit 2e8f08deabbc7eefe4c5838aaa6aa9a23a8acf2e upstream. 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 Signed-off-by: Greg Kroah-Hartman

ubi: Be more paranoid while seaching for the most recent Fastmap

2018-07-25T08:18:32+00:00

commit 74f2c6e9a47cf4e508198c8594626cc82906a13d upstream. Since PEB erasure is asynchornous it can happen that there is more than one Fastmap on the MTD. This is fine because the attach logic will pick the Fastmap data structure with the highest sequence number. On a not so well configured MTD stack spurious ECC errors are common. Causes can be different, bad hardware, wrong operating modes, etc... If the most current Fastmap renders bad due to ECC errors UBI might pick an older Fastmap to attach from. While this can only happen on an anyway broken setup it will show completely different sympthoms and makes finding the root cause much more difficult. So, be debug friendly and fall back to scanning mode of we're facing an ECC error while scanning for Fastmap. Cc: Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

ubi: Rework Fastmap attach base code

2018-07-25T08:18:32+00:00

commit fdf10ed710c0aa177e8dfcd84e65e4e5e8e0956b upstream. Introduce a new list to the UBI attach information object to be able to deal better with old and corrupted Fastmap eraseblocks. Also move more Fastmap specific code into fastmap.c. Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

ubi: Introduce vol_ignored()

2018-07-25T08:18:32+00:00

commit 243a4f8126fcf7facb04b324dbb7c85d10b11ce9 upstream. This makes the logic more easy to follow. Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

ubi: fastmap: Correctly handle interrupted erasures in EBA

2018-07-11T14:03:47+00:00

commit 781932375ffc6411713ee0926ccae8596ed0261c upstream. Fastmap cannot track the LEB unmap operation, therefore it can happen that after an interrupted erasure the mapping still looks good from Fastmap's point of view, while reading from the PEB will cause an ECC error and confuses the upper layer. Instead of teaching users of UBI how to deal with that, we read back the VID header and check for errors. If the PEB is empty or shows ECC errors we fixup the mapping and schedule the PEB for erasure. Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Cc: Reported-by: martin bayern Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman