linux-stable.git/drivers/mtd, branch v3.2.85

mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl

2016-11-20T01:01:37+00:00

commit f6d7c1b5598b6407c3f1da795dd54acf99c1990c upstream.

This fixes subpage writes when using 4-bit HW ECC.

There has been numerous reports about ECC errors with devices using this
driver for a while.  Also the 4-bit ECC has been reported as broken with
subpages in [1] and with 16 bits NANDs in the driver and in mach* board
files both in mainline and in the vendor BSPs.

What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to
try reinitializing the ECC engine:
- R/W on whole pages properly generates/checks RS code
- try writing the 1st subpage only of a blank page, the subpage is well
  written and the RS code properly generated, re-reading the same page
  the HW detects some ECC error, reading the same page again no ECC
  error is detected

Note that the ECC engine is already reinitialized in the 1-bit case.

Tested on my LCDK with UBI+UBIFS using subpages.
This could potentially get rid of the issue workarounded in [1].

[1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand")

Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage")
Signed-off-by: Karl Beldan 
Acked-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

ubi: Fix race condition between ubi device creation and udev

2016-11-20T01:01:29+00:00

commit 714fb87e8bc05ff78255afc0dca981e8c5242785 upstream.

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.

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

mtd: nand: fix bug writing 1 byte less than page size

2016-11-20T01:01:27+00:00

commit 144f4c98399e2c0ca60eb414c15a2c68125c18b8 upstream.

nand_do_write_ops() determines if it is writing a partial page with the
formula:
	part_pagewr = (column || writelen < (mtd->writesize - 1))

When 'writelen' is exactly 1 byte less than the NAND page size the formula
equates to zero, so the code doesn't process it as a partial write,
although it should.
As a consequence the function remains in the while(1) loop with 'writelen'
becoming 0xffffffff and iterating endlessly.

The bug may not be easy to reproduce in Linux since user space tools
usually force the padding or round-up the write size to a page-size
multiple.
This was discovered in U-Boot where the issue can be reproduced by
writing any size that is 1 byte less than a page-size multiple.
For example, on a NAND with 2K page (0x800):
	=> nand erase.part 
	=> nand write $loadaddr  7ff

[Editor's note: the bug was added in commit 29072b96078f, but moved
around in commit 66507c7bc8895 ("mtd: nand: Add support to use nand_base
poi databuf as bounce buffer")]

Fixes: 29072b96078f ("[MTD] NAND: add subpage write support")
Signed-off-by: Hector Palacios 
Acked-by: Boris Brezillon 
Signed-off-by: Brian Norris 
[bwh: Backported to 3.2: adjusted context as noted above]
Signed-off-by: Ben Hutchings

mtd: pmcmsp-flash: Allocating too much in init_msp_flash()

2016-11-20T01:01:26+00:00

commit 79ad07d45743721010e766e65dc004ad249bd429 upstream.

There is a cut and paste issue here.  The bug is that we are allocating
more memory than necessary for msp_maps.  We should be allocating enough
space for a map_info struct (144 bytes) but we instead allocate enough
for an mtd_info struct (1840 bytes).  It's a small waste.

The other part of this is not harmful but when we allocated msp_flash
then we allocated enough space fro a map_info pointer instead of an
mtd_info pointer.  But since pointers are the same size it works out
fine.

Anyway, I decided to clean up all three allocations a bit to make them
a bit more consistent and clear.

Fixes: 68aa0fa87f6d ('[MTD] PMC MSP71xx flash/rootfs mappings')
Signed-off-by: Dan Carpenter 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

ubi: Make recover_peb power cut aware

2016-08-22T21:37:15+00:00

commit 972228d87445dc46c0a01f5f3de673ac017626f7 upstream.

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.

Reported-by: Jörg Pfähler 
Reviewed-by: Jörg Pfähler 
Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.2:
 - Adjust context
 - Use next_sqnum() instead of ubi_next_sqnum()
 - Use ubi_device::peb_buf1 instead of ubi_device::peb_buf
 - No need to unlock ubi->fm_eba_sem on error]
Signed-off-by: Ben Hutchings

ubi: Fix out of bounds write in volume update code

2016-04-01T00:54:37+00:00

commit e4f6daac20332448529b11f09388f1d55ef2084c upstream.

ubi_start_leb_change() allocates too few bytes.
ubi_more_leb_change_data() will write up to req->upd_bytes +
ubi->min_io_size bytes.

Signed-off-by: Richard Weinberger 
Reviewed-by: Boris Brezillon 
Signed-off-by: Ben Hutchings

mtd: blkdevs: fix potential deadlock + lockdep warnings

2015-11-27T12:48:22+00:00

commit f3c63795e90f0c6238306883b6c72f14d5355721 upstream.

Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.

The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.

 -> blktrans_open()
    ->  mutex_lock(&dev->lock);
    ->  mutex_lock(&mtd_table_mutex);

 -> del_mtd_device()
    ->  mutex_lock(&mtd_table_mutex);
    ->  blktrans_notify_remove() -> del_mtd_blktrans_dev()
       ->  mutex_lock(&dev->lock);

This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired &dev->lock:

        if (mutex_trylock(&mtd_table_mutex)) {
                mutex_unlock(&mtd_table_mutex);
                BUG();
        }

So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so
we always acquire mtd_table_mutex first.

Snippets of the lockdep output follow:

  # modprobe -r m25p80
  [   53.419251]
  [   53.420838] ======================================================
  [   53.427300] [ INFO: possible circular locking dependency detected ]
  [   53.433865] 4.3.0-rc6 #96 Not tainted
  [   53.437686] -------------------------------------------------------
  [   53.444220] modprobe/372 is trying to acquire lock:
  [   53.449320]  (&new->lock){+.+...}, at: [] del_mtd_blktrans_dev+0x80/0xdc
  [   53.457271]
  [   53.457271] but task is already holding lock:
  [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] del_mtd_device+0x18/0x100
  [   53.471321]
  [   53.471321] which lock already depends on the new lock.
  [   53.471321]
  [   53.479856]
  [   53.479856] the existing dependency chain (in reverse order) is:
  [   53.487660]
  -> #1 (mtd_table_mutex){+.+.+.}:
  [   53.492331]        [] blktrans_open+0x34/0x1a4
  [   53.497879]        [] __blkdev_get+0xc4/0x3b0
  [   53.503364]        [] blkdev_get+0x108/0x320
  [   53.508743]        [] do_dentry_open+0x218/0x314
  [   53.514496]        [] path_openat+0x4c0/0xf9c
  [   53.519959]        [] do_filp_open+0x5c/0xc0
  [   53.525336]        [] do_sys_open+0xfc/0x1cc
  [   53.530716]        [] ret_fast_syscall+0x0/0x1c
  [   53.536375]
  -> #0 (&new->lock){+.+...}:
  [   53.540587]        [] mutex_lock_nested+0x38/0x3cc
  [   53.546504]        [] del_mtd_blktrans_dev+0x80/0xdc
  [   53.552606]        [] blktrans_notify_remove+0x7c/0x84
  [   53.558891]        [] del_mtd_device+0x74/0x100
  [   53.564544]        [] del_mtd_partitions+0x80/0xc8
  [   53.570451]        [] mtd_device_unregister+0x24/0x48
  [   53.576637]        [] spi_drv_remove+0x1c/0x34
  [   53.582207]        [] __device_release_driver+0x88/0x114
  [   53.588663]        [] device_release_driver+0x20/0x2c
  [   53.594843]        [] bus_remove_device+0xd8/0x108
  [   53.600748]        [] device_del+0x10c/0x210
  [   53.606127]        [] device_unregister+0xc/0x20
  [   53.611849]        [] __unregister+0x10/0x20
  [   53.617211]        [] device_for_each_child+0x50/0x7c
  [   53.623387]        [] spi_unregister_master+0x58/0x8c
  [   53.629578]        [] release_nodes+0x15c/0x1c8
  [   53.635223]        [] __device_release_driver+0x90/0x114
  [   53.641689]        [] driver_detach+0xb4/0xb8
  [   53.647147]        [] bus_remove_driver+0x4c/0xa0
  [   53.652970]        [] SyS_delete_module+0x11c/0x1e4
  [   53.658976]        [] ret_fast_syscall+0x0/0x1c
  [   53.664621]
  [   53.664621] other info that might help us debug this:
  [   53.664621]
  [   53.672979]  Possible unsafe locking scenario:
  [   53.672979]
  [   53.679169]        CPU0                    CPU1
  [   53.683900]        ----                    ----
  [   53.688633]   lock(mtd_table_mutex);
  [   53.692383]                                lock(&new->lock);
  [   53.698306]                                lock(mtd_table_mutex);
  [   53.704658]   lock(&new->lock);
  [   53.707946]
  [   53.707946]  *** DEADLOCK ***

Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount")
Reported-by: Felipe Balbi 
Tested-by: Felipe Balbi 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

mtd: mtdpart: fix add_mtd_partitions error path

2015-11-27T12:48:19+00:00

commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream.

If we fail to allocate a partition structure in the middle of the partition
creation process, the already allocated partitions are never removed, which
means they are still present in the partition list and their resources are
never freed.

Signed-off-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

UBI: return ENOSPC if no enough space available

2015-11-17T15:54:41+00:00

commit 7c7feb2ebfc9c0552c51f0c050db1d1a004faac5 upstream.

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.

Signed-off-by: Sheng Yong 
Signed-off-by: Richard Weinberger 
Reviewed-by: David Gstir 
Signed-off-by: Ben Hutchings

UBI: Validate data_size

2015-11-17T15:54:41+00:00

commit 281fda27673f833a01d516658a64d22a32c8e072 upstream.

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().

Signed-off-by: Richard Weinberger 
Reviewed-by: David Gstir 
[bwh: Backported to 3.2: drop first argument to ubi_err()]
Signed-off-by: Ben Hutchings