linux-stable.git/drivers/mtd, branch linux-3.10.y

ubi/upd: Always flush after prepared for an update

2017-06-20T12:04:48+00:00

commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream.

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.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Richard Weinberger 
Signed-off-by: Willy Tarreau

mtd: bcm47xxpart: fix parsing first block after aligned TRX

2017-06-20T12:04:44+00:00

commit bd5d21310133921021d78995ad6346f908483124 upstream.

After parsing TRX we should skip to the first block placed behind it.
Our code was working only with TRX with length not aligned to the
blocksize. In other cases (length aligned) it was missing the block
places right after TRX.

This fixes calculation and simplifies the comment.

Signed-off-by: Rafał Miłecki 
Signed-off-by: Brian Norris 
Signed-off-by: Amit Pundir 
Signed-off-by: Willy Tarreau

mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy

2017-06-20T12:04:28+00:00

commit 906b268477bc03daaa04f739844c120fe4dbc991 upstream.

kernelci.org reports a warning for this driver, as it copies a local
variable into a 'const char *' string:

    drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of 'strncpy' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]

Using kstrndup() simplifies the code and avoids the warning.

Signed-off-by: Arnd Bergmann 
Acked-by: Marek Vasut 
Signed-off-by: Brian Norris 
Signed-off-by: Willy Tarreau

mtd: nand: xway: disable module support

2017-06-07T22:46:56+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: Willy Tarreau

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

2017-02-10T10:03:39+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: Willy Tarreau

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

2017-02-10T10:03:39+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: Willy Tarreau

mtd: blkdevs: fix potential deadlock + lockdep warnings

2017-02-10T10:03:38+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: Willy Tarreau

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

2017-02-10T10:03:27+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: Willy Tarreau

ubi: Fix race condition between ubi device creation and udev

2016-08-27T09:40:38+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.

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

ubi: Make volume resize power cut aware

2016-08-27T09:40:38+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.

Cc: 
Reported-by: Boris Brezillon 
Reviewed-by: Boris Brezillon 
Signed-off-by: Richard Weinberger 
Signed-off-by: Willy Tarreau