user/sven/linux.git/drivers/mtd, branch v3.18.27

UBI: return ENOSPC if no enough space available

2015-10-28T02:14:16Z

[ Upstream commit 7c7feb2ebfc9c0552c51f0c050db1d1a004faac5 ] UBI: attaching mtd1 to ubi0 UBI: scanning is finished UBI error: init_volumes: not enough PEBs, required 706, available 686 UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1) UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM UBI error: ubi_init: cannot attach mtd1 If available PEBs are not enough when initializing volumes, return -ENOSPC directly. If available PEBs are not enough when initializing WL, return -ENOSPC instead of -ENOMEM. Cc: stable@vger.kernel.org Signed-off-by: Sheng Yong Signed-off-by: Richard Weinberger Reviewed-by: David Gstir Signed-off-by: Sasha Levin

UBI: Validate data_size

2015-10-28T02:14:15Z

[ Upstream commit 281fda27673f833a01d516658a64d22a32c8e072 ] Make sure that data_size is less than LEB size. Otherwise a handcrafted UBI image is able to trigger an out of bounds memory access in ubi_compare_lebs(). Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Reviewed-by: David Gstir Signed-off-by: Sasha Levin

mtd: pxa3xx_nand: add a default chunk size

2015-10-28T02:14:01Z

[ Upstream commit bc3e00f04cc1fe033a289c2fc2e5c73c0168d360 ] When keeping the configuration set by the bootloader (by using the marvell,nand-keep-config property), the pxa3xx_nand_detect_config() function is called and set the chunk size to 512 as a default value if NDCR_PAGE_SZ is not set. In the other case, when not keeping the bootloader configuration, no chunk size is set. Fix this by adding a default chunk size of 512. Fixes: 70ed85232a93 ("mtd: nand: pxa3xx: Introduce multiple page I/O support") Signed-off-by: Antoine Tenart Acked-by: Robert Jarzmik Signed-off-by: Brian Norris Signed-off-by: Sasha Levin

mtd: fix: avoid race condition when accessing mtd->usecount

2015-07-04T03:02:14Z

[ Upstream commit 073db4a51ee43ccb827f54a4261c0583b028d5ab ] On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to mtd->usecount were done without taking mtd_table_mutex. kernel: Call Trace: kernel: [] __put_mtd_device+0x20/0x50 kernel: [] blktrans_release+0x8c/0xd8 kernel: [] __blkdev_put+0x1a8/0x200 kernel: [] blkdev_close+0x1c/0x30 kernel: [] __fput+0xac/0x250 kernel: [] task_work_run+0xd8/0x120 kernel: [] work_notifysig+0x10/0x18 kernel: kernel: Code: 2442ffff ac8202d8 000217fe <00020336> dc820128 10400003 00000000 0040f809 00000000 kernel: ---[ end trace 080fbb4579b47a73 ]--- Fixed by taking the mutex in blktrans_open and blktrans_release. Note that this locking is already suggested in include/linux/mtd/blktrans.h: struct mtd_blktrans_ops { ... /* Called with mtd_table_mutex held; no race with add/remove */ int (*open)(struct mtd_blktrans_dev *dev); void (*release)(struct mtd_blktrans_dev *dev); ... }; But we weren't following it. Originally reported by (and patched by) Zhang and Giuseppe, independently. Improved and rewritten. Cc: stable@vger.kernel.org Reported-by: Zhang Xingcai Reported-by: Giuseppe Cantavenera Tested-by: Giuseppe Cantavenera Acked-by: Alexander Sverdlin Signed-off-by: Brian Norris Signed-off-by: Sasha Levin

UBI: fix check for "too many bytes"

2015-05-17T23:12:11Z

[ Upstream commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 ] The comparison from the previous line seems to have been erroneously (partially) copied-and-pasted onto the next. The second line should be checking req.bytes, not req.lnum. Coverity CID #139400 Cc: stable Signed-off-by: Brian Norris [rw: Fixed comparison] Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

UBI: initialize LEB number variable

2015-05-17T23:12:10Z

[ Upstream commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 ] In some of the 'out_not_moved' error paths, lnum may be used uninitialized. Don't ignore the warning; let's fix it. This uninitialized variable doesn't have much visible effect in the end, since we just schedule the PEB for erasure, and its LEB number doesn't really matter (it just gets printed in debug messages). But let's get it straight anyway. Coverity CID #113449 Cc: stable Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

UBI: fix out of bounds write

2015-05-17T23:12:10Z

[ Upstream commit d74adbdb9abf0d2506a6c4afa534d894f28b763f ] If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the PEB->LEB mapping. Caught by Coverity, CID #711212. Cc: stable Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

UBI: account for bitflips in both the VID header and data

2015-05-17T23:12:10Z

[ Upstream commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 ] We are completely discarding the earlier value of 'bitflips', which could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the bitwise OR of header and data 'bitflip' statuses instead. Coverity CID #1226856 Cc: stable Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

mtd: nand: pxa3xx: Fix PIO FIFO draining

2015-03-28T13:50:41Z

[ Upstream commit 8dad0386b97c4bd6edd56752ca7f2e735fe5beb4 ] The NDDB register holds the data that are needed by the read and write commands. However, during a read PIO access, the datasheet specifies that after each 32 bytes read in that register, when BCH is enabled, we have to make sure that the RDDREQ bit is set in the NDSR register. This fixes an issue that was seen on the Armada 385, and presumably other mvebu SoCs, when a read on a newly erased page would end up in the driver reporting a timeout from the NAND. Cc: # v3.14 Signed-off-by: Maxime Ripard Reviewed-by: Boris Brezillon Acked-by: Ezequiel Garcia Signed-off-by: Brian Norris Signed-off-by: Sasha Levin

mtd: nand: omap: Fix NAND enumeration on 3430 LDP

2015-01-16T14:59:54Z

commit 775a9134f4398ca98a10af8cc3cf9b664017267f upstream. 3430LDP has NAND flash with 32 bytes OOB size which is sufficient to hold BCH8 codes but the small page check introduced in commit b491da7233d5 ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes") considers anything below 64 bytes unsuitable for BCH4/8/16. There is another bug in that code where it doesn't skip the check for OMAP_ECC_HAM1_CODE_SW. Get rid of that small page check code as it is insufficient and redundant because we are checking for OOB available bytes vs ecc layout before calling nand_scan_tail(). Fixes: b491da7233d5 ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes") Reported-by: Tony Lindgren Signed-off-by: Roger Quadros Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman