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

UBI: fix soft lockup in ubi_check_volume()

2015-08-06T23:32:19+00:00

commit 9aa272b492e7551a9ee0e2c83c720ea013698485 upstream.

Running mtd-utils/tests/ubi-tests/io_basic.c could cause
soft lockup or watchdog reset. It is because *updatevol*
will perform ubi_check_volume() after updating finish
and this function will full scan the updated lebs if the
volume is initialized as STATIC_VOLUME.

This patch adds *cond_resched()* in the loop of lebs scan
to avoid soft lockup.

Helped by Richard Weinberger 

[ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2101 jiffies g=1606 c=1605 q=56)
[ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G           O 3.10.53 #21
[ 2158.172898] [] (unwind_backtrace+0x0/0x120) from [] (show_stack+0x10/0x14)
[ 2158.172918] [] (show_stack+0x10/0x14) from [] (rcu_check_callbacks+0x1c0/0x660)
[ 2158.172936] [] (rcu_check_callbacks+0x1c0/0x660) from [] (update_process_times+0x38/0x64)
[ 2158.172953] [] (update_process_times+0x38/0x64) from [] (tick_sched_handle+0x54/0x60)
[ 2158.172966] [] (tick_sched_handle+0x54/0x60) from [] (tick_sched_timer+0x44/0x74)
[ 2158.172978] [] (tick_sched_timer+0x44/0x74) from [] (__run_hrtimer+0xc8/0x1b8)
[ 2158.172992] [] (__run_hrtimer+0xc8/0x1b8) from [] (hrtimer_interrupt+0x128/0x2a4)
[ 2158.173007] [] (hrtimer_interrupt+0x128/0x2a4) from [] (arch_timer_handler_virt+0x28/0x30)
[ 2158.173022] [] (arch_timer_handler_virt+0x28/0x30) from [] (handle_percpu_devid_irq+0x9c/0x124)
[ 2158.173036] [] (handle_percpu_devid_irq+0x9c/0x124) from [] (generic_handle_irq+0x20/0x30)
[ 2158.173049] [] (generic_handle_irq+0x20/0x30) from [] (handle_IRQ+0x64/0x8c)
[ 2158.173060] [] (handle_IRQ+0x64/0x8c) from [] (gic_handle_irq+0x3c/0x60)
[ 2158.173074] [] (gic_handle_irq+0x3c/0x60) from [] (__irq_svc+0x40/0x50)
[ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0)
[ 2158.173092] 3c80:                                                       c4043ce4 00000019
[ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000
[ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff
[ 2158.173130] [] (__irq_svc+0x40/0x50) from [] (read_current_timer+0x4/0x38)
[ 2158.173145] [] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f)
[ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073]
[ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash]

Signed-off-by: Wang Kai 
Signed-off-by: hujianyang 
Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings

UBI: fix check for "too many bytes"

2015-08-06T23:32:01+00:00

commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 upstream.

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

Signed-off-by: Brian Norris 
[rw: Fixed comparison]
Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings

UBI: initialize LEB number variable

2015-08-06T23:32:01+00:00

commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 upstream.

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

Signed-off-by: Brian Norris 
Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

UBI: fix out of bounds write

2015-08-06T23:32:01+00:00

commit d74adbdb9abf0d2506a6c4afa534d894f28b763f upstream.

If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the
PEB->LEB mapping.

Caught by Coverity, CID #711212.

Signed-off-by: Brian Norris 
Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.2: adjust context; s/leb/seb/g]
Signed-off-by: Ben Hutchings

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

2015-08-06T23:32:01+00:00

commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 upstream.

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

Signed-off-by: Brian Norris 
Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

UBI: Fix invalid vfree()

2015-02-20T00:49:24+00:00

commit f38aed975c0c3645bbdfc5ebe35726e64caaf588 upstream.

The logic of vfree()'ing vol->upd_buf is tied to vol->updating.
In ubi_start_update() vol->updating is set long before vmalloc()'ing
vol->upd_buf. If we encounter a write failure in ubi_start_update()
before vmalloc() the UBI device release function will try to vfree()
vol->upd_buf because vol->updating is set.
Fix this by allocating vol->upd_buf directly after setting vol->updating.

Fixes:
[   31.559338] UBI warning: vol_cdev_release: update of volume 2 not finished, volume is damaged
[   31.559340] ------------[ cut here ]------------
[   31.559343] WARNING: CPU: 1 PID: 2747 at mm/vmalloc.c:1446 __vunmap+0xe3/0x110()
[   31.559344] Trying to vfree() nonexistent vm area (ffffc90001f2b000)
[   31.559345] Modules linked in:
[   31.565620]  0000000000000bba ffff88002a0cbdb0 ffffffff818f0497 ffff88003b9ba148
[   31.566347]  ffff88002a0cbde0 ffffffff8156f515 ffff88003b9ba148 0000000000000bba
[   31.567073]  0000000000000000 0000000000000000 ffff88002a0cbe88 ffffffff8156c10a
[   31.567793] Call Trace:
[   31.568034]  [] dump_stack+0x4e/0x7a
[   31.568510]  [] ubi_io_write_vid_hdr+0x155/0x160
[   31.569084]  [] ubi_eba_write_leb+0x23a/0x870
[   31.569628]  [] vol_cdev_write+0x226/0x380
[   31.570155]  [] vfs_write+0xb5/0x1f0
[   31.570627]  [] SyS_pwrite64+0x6a/0xa0
[   31.571123]  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Richard Weinberger 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Ben Hutchings

mtd/ftl: fix the double free of the buffers allocated in build_maps()

2014-09-13T22:41:38+00:00

commit a152056c912db82860a8b4c23d0bd3a5aa89e363 upstream.

I got the following panic on my fsl p5020ds board.

  Unable to handle kernel paging request for data at address 0x7375627379737465
  Faulting instruction address: 0xc000000000100778
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=24 CoreNet Generic
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-next-20140613 #145
  task: c0000000fe080000 ti: c0000000fe088000 task.ti: c0000000fe088000
  NIP: c000000000100778 LR: c00000000010073c CTR: 0000000000000000
  REGS: c0000000fe08aa00 TRAP: 0300   Not tainted  (3.15.0-next-20140613)
  MSR: 0000000080029000   CR: 24ad2e24  XER: 00000000
  DEAR: 7375627379737465 ESR: 0000000000000000 SOFTE: 1
  GPR00: c0000000000c99b0 c0000000fe08ac80 c0000000009598e0 c0000000fe001d80
  GPR04: 00000000000000d0 0000000000000913 c000000007902b20 0000000000000000
  GPR08: c0000000feaae888 0000000000000000 0000000007091000 0000000000200200
  GPR12: 0000000028ad2e28 c00000000fff4000 c0000000007abe08 0000000000000000
  GPR16: c0000000007ab160 c0000000007aaf98 c00000000060ba68 c0000000007abda8
  GPR20: c0000000007abde8 c0000000feaea6f8 c0000000feaea708 c0000000007abd10
  GPR24: c000000000989370 c0000000008c6228 00000000000041ed c0000000fe00a400
  GPR28: c00000000017c1cc 00000000000000d0 7375627379737465 c0000000fe001d80
  NIP [c000000000100778] .__kmalloc_track_caller+0x70/0x168
  LR [c00000000010073c] .__kmalloc_track_caller+0x34/0x168
  Call Trace:
  [c0000000fe08ac80] [c00000000087e6b8] uevent_sock_list+0x0/0x10 (unreliable)
  [c0000000fe08ad20] [c0000000000c99b0] .kstrdup+0x44/0x90
  [c0000000fe08adc0] [c00000000017c1cc] .__kernfs_new_node+0x4c/0x130
  [c0000000fe08ae70] [c00000000017d7e4] .kernfs_new_node+0x2c/0x64
  [c0000000fe08aef0] [c00000000017db00] .kernfs_create_dir_ns+0x34/0xc8
  [c0000000fe08af80] [c00000000018067c] .sysfs_create_dir_ns+0x58/0xcc
  [c0000000fe08b010] [c0000000002c711c] .kobject_add_internal+0xc8/0x384
  [c0000000fe08b0b0] [c0000000002c7644] .kobject_add+0x64/0xc8
  [c0000000fe08b140] [c000000000355ebc] .device_add+0x11c/0x654
  [c0000000fe08b200] [c0000000002b5988] .add_disk+0x20c/0x4b4
  [c0000000fe08b2c0] [c0000000003a21d4] .add_mtd_blktrans_dev+0x340/0x514
  [c0000000fe08b350] [c0000000003a3410] .mtdblock_add_mtd+0x74/0xb4
  [c0000000fe08b3e0] [c0000000003a32cc] .blktrans_notify_add+0x64/0x94
  [c0000000fe08b470] [c00000000039b5b4] .add_mtd_device+0x1d4/0x368
  [c0000000fe08b520] [c00000000039b830] .mtd_device_parse_register+0xe8/0x104
  [c0000000fe08b5c0] [c0000000003b8408] .of_flash_probe+0x72c/0x734
  [c0000000fe08b750] [c00000000035ba40] .platform_drv_probe+0x38/0x84
  [c0000000fe08b7d0] [c0000000003599a4] .really_probe+0xa4/0x29c
  [c0000000fe08b870] [c000000000359d3c] .__driver_attach+0x100/0x104
  [c0000000fe08b900] [c00000000035746c] .bus_for_each_dev+0x84/0xe4
  [c0000000fe08b9a0] [c0000000003593c0] .driver_attach+0x24/0x38
  [c0000000fe08ba10] [c000000000358f24] .bus_add_driver+0x1c8/0x2ac
  [c0000000fe08bab0] [c00000000035a3a4] .driver_register+0x8c/0x158
  [c0000000fe08bb30] [c00000000035b9f4] .__platform_driver_register+0x6c/0x80
  [c0000000fe08bba0] [c00000000084e080] .of_flash_driver_init+0x1c/0x30
  [c0000000fe08bc10] [c000000000001864] .do_one_initcall+0xbc/0x238
  [c0000000fe08bd00] [c00000000082cdc0] .kernel_init_freeable+0x188/0x268
  [c0000000fe08bdb0] [c0000000000020a0] .kernel_init+0x1c/0xf7c
  [c0000000fe08be30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4
  Instruction dump:
  41bd0010 480000c8 4bf04eb5 60000000 e94d0028 e93f0000 7cc95214 e8a60008
  7fc9502a 2fbe0000 419e00c8 e93f0022 <7f7e482a> 39200000 88ed06b2 992d06b2
  ---[ end trace b4c9a94804a42d40 ]---

It seems that the corrupted partition header on my mtd device triggers
a bug in the ftl. In function build_maps() it will allocate the buffers
needed by the mtd partition, but if something goes wrong such as kmalloc
failure, mtd read error or invalid partition header parameter, it will
free all allocated buffers and then return non-zero. In my case, it
seems that partition header parameter 'NumTransferUnits' is invalid.

And the ftl_freepart() is a function which free all the partition
buffers allocated by build_maps(). Given the build_maps() is a self
cleaning function, so there is no need to invoke this function even
if build_maps() return with error. Otherwise it will causes the
buffers to be freed twice and then weird things would happen.

Signed-off-by: Kevin Hao 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

mtd: mxc_nand: remove duplicated ecc_stats counting

2014-04-01T23:58:40+00:00

commit 0566477762f9e174e97af347ee9c865f908a5647 upstream.

The ecc_stats.corrected count variable will already be incremented in
the above framework-layer just after this callback.

Signed-off-by: Michael Grzeschik 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

mtd: gpmi: fix kernel BUG due to racing DMA operations

2014-01-03T04:33:20+00:00

commit 7b3d2fb92067bcb29f0f085a9fa9fa64920a6646 upstream.

[1] The gpmi uses the nand_command_lp to issue the commands to NAND chips.
    The gpmi issues a DMA operation with gpmi_cmd_ctrl when it handles
    a NAND_CMD_NONE control command. So when we read a page(NAND_CMD_READ0)
    from the NAND, we may send two DMA operations back-to-back.

    If we do not serialize the two DMA operations, we will meet a bug when

    1.1) we enable CONFIG_DMA_API_DEBUG, CONFIG_DMADEVICES_DEBUG,
         and CONFIG_DEBUG_SG.

    1.2) Use the following commands in an UART console and a SSH console:
         cmd 1: while true;do dd if=/dev/mtd0 of=/dev/null;done
         cmd 1: while true;do dd if=/dev/mmcblk0 of=/dev/null;done

    The kernel log shows below:
    -----------------------------------------------------------------
    kernel BUG at lib/scatterlist.c:28!
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
      .........................
    [<80044a0c>] (__bug+0x18/0x24) from [<80249b74>] (sg_next+0x48/0x4c)
    [<80249b74>] (sg_next+0x48/0x4c) from [<80255398>] (debug_dma_unmap_sg+0x170/0x1a4)
    [<80255398>] (debug_dma_unmap_sg+0x170/0x1a4) from [<8004af58>] (dma_unmap_sg+0x14/0x6c)
    [<8004af58>] (dma_unmap_sg+0x14/0x6c) from [<8027e594>] (mxs_dma_tasklet+0x18/0x1c)
    [<8027e594>] (mxs_dma_tasklet+0x18/0x1c) from [<8007d444>] (tasklet_action+0x114/0x164)
    -----------------------------------------------------------------

    1.3) Assume the two DMA operations is X (first) and Y (second).

         The root cause of the bug:
	   Assume process P issues DMA X, and sleep on the completion
	 @this->dma_done. X's tasklet callback is dma_irq_callback. It firstly
	 wake up the process sleeping on the completion @this->dma_done,
	 and then trid to unmap the scatterlist S. The waked process P will
	 issue Y in another ARM core. Y initializes S->sg_magic to zero
	 with sg_init_one(), while dma_irq_callback is unmapping S at the same
	 time.

	 See the diagram:

                   ARM core 0              |         ARM core 1
	 -------------------------------------------------------------
         (P issues DMA X, then sleep)  --> |
                                           |
         (X's tasklet wakes P)         --> |
                                           |
                                           | <-- (P begin to issue DMA Y)
                                           |
         (X's tasklet unmap the            |
      scatterlist S with dma_unmap_sg) --> | <-- (Y calls sg_init_one() to init
                                           |      scatterlist S)
                                           |

[2] This patch serialize both the X and Y in the following way:
     Unmap the DMA scatterlist S firstly, and wake up the process at the end
     of the DMA callback, in such a way, Y will be executed after X.

     After this patch:

                   ARM core 0              |         ARM core 1
	 -------------------------------------------------------------
         (P issues DMA X, then sleep)  --> |
                                           |
         (X's tasklet unmap the            |
      scatterlist S with dma_unmap_sg) --> |
                                           |
         (X's tasklet wakes P)         --> |
                                           |
                                           | <-- (P begin to issue DMA Y)
                                           |
                                           | <-- (Y calls sg_init_one() to init
                                           |     scatterlist S)
                                           |

Signed-off-by: Huang Shijie 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

mtd: m25p80: fix allocation size

2014-01-03T04:33:18+00:00

commit 778d226a1462572b51d6777cdb1d611543410cb4 upstream.

This patch fixes two memory errors:

1. During a probe failure (in mtd_device_parse_register?) the command
   buffer would not be freed.

2. The command buffer's size is determined based on the 'fast_read'
   boolean, but the assignment of fast_read is made after this
   allocation. Thus, the buffer may be allocated "too small".

To fix the first, just switch to the devres version of kzalloc.

To fix the second, increase MAX_CMD_SIZE unconditionally. It's not worth
saving a byte to fiddle around with the conditions here.

This problem was reported by Yuhang Wang a while back.

Signed-off-by: Brian Norris 
Reported-by: Yuhang Wang 
Reviewed-by: Sourav Poddar 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings