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

mtd: nand: xway: disable module support

2017-01-26T16:41:03+00:00

commit 73529c872a189c747bdb528ce9b85b67b0e28dec upstream.

The xway_nand driver accesses the ltq_ebu_membase symbol which is not
exported. This also should not get exported and we should handle the
EBU interface in a better way later. This quick fix just deactivated
support for building as module.

Fixes: 99f2b107924c ("mtd: lantiq: Add NAND support on Lantiq XWAY SoC.")
Signed-off-by: Hauke Mehrtens 
Signed-off-by: Boris Brezillon 
Signed-off-by: Jiri Slaby

mtd: blkdevs: fix potential deadlock + lockdep warnings

2016-11-28T21:22:56+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: Jiri Slaby

UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header

2016-11-24T15:23:36+00:00

commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.

scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.

Signed-off-by: Boris Brezillon 
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger 
Signed-off-by: Jiri Slaby

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

2016-10-07T08:03:56+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: Jiri Slaby

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

2016-10-06T06:21:56+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: Jiri Slaby

ubi: Fix race condition between ubi device creation and udev

2016-08-19T07:51:24+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: Jiri Slaby

ubi: Make volume resize power cut aware

2016-08-19T07:51:23+00:00

commit 4946784bd3924b1374f05eebff2fd68660bae866 upstream.

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.

Reported-by: Boris Brezillon 
Reviewed-by: Boris Brezillon 
Signed-off-by: Richard Weinberger 
Signed-off-by: Jiri Slaby

mtd: onenand: fix deadlock in onenand_block_markbad

2016-04-11T14:44:27+00:00

commit 5e64c29e98bfbba1b527b0a164f9493f3db9e8cb upstream.

Commit 5942ddbc500d ("mtd: introduce mtd_block_markbad interface")
incorrectly changed onenand_block_markbad() to call mtd_block_markbad
instead of onenand_chip's block_markbad function. As a result the function
will now recurse and deadlock. Fix by reverting the change.

Fixes: 5942ddbc500d ("mtd: introduce mtd_block_markbad interface")
Signed-off-by: Aaro Koskinen 
Acked-by: Artem Bityutskiy 
Signed-off-by: Brian Norris 
Signed-off-by: Jiri Slaby

ubi: Fix out of bounds write in volume update code

2016-03-14T12:10:03+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: Jiri Slaby

mtd: mtdpart: fix add_mtd_partitions error path

2016-02-15T16:07:49+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: Jiri Slaby