linux.git/drivers/mtd/ubi, branch v4.0-rc2

UBI: block: Fix checking for NULL instead of IS_ERR()

2015-02-12T22:33:32+00:00

We recently switched from allocating ->rq using blk_init_queue() to
use blk_mq_init_queue() so we need to update the error handling to
check for IS_ERR() instead of NULL.

Fixes: ff1f48ee3bb3 ('UBI: Block: Add blk-mq support')
Signed-off-by: Dan Carpenter 
Signed-off-by: Richard Weinberger

UBI: block: Continue creating ubiblocks after an initialization error

2015-02-12T22:29:25+00:00

If one ubi volume is corrupted but another is not, it should be
possible to initialize that ubiblock from a kernel commandline which
includes both of them. This patch changes the error handling behavior
in initializing ubiblock to ensure that all parameters are attempted
even if one fails. If there is a failure, it is logged on dmesg.
It also makes error messages more descriptive by including the
name of the UBI volume that failed.

Tested: Formatted ubi volume /dev/ubi5_0 in a corrupt way and
dev/ubi3_0 properly and included "ubi.block=5,0 ubi.block=3,0" on
the kernel command line. At boot, I see the following in the console:
[   21.082420] UBI error: ubiblock_create_from_param: block: can't open volume on ubi5_0, err=-19
[   21.084268] UBI: ubiblock3_0 created from ubi3:0(rootfs)

Signed-off-by: Dan Ehrenberg 
Reviewed-by: Ezequiel Garcia 
Signed-off-by: Richard Weinberger

UBI: Block: Explain usage of blk_rq_map_sg()

2015-01-28T15:37:40+00:00

Signed-off-by: Richard Weinberger

UBI: fix soft lockup in ubi_check_volume()

2015-01-28T15:18:09+00:00

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

UBI: Fastmap: Care about the protection queue

2015-01-28T15:09:45+00:00

Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.

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

UBI: do propagate positive error codes up

2015-01-28T15:09:25+00:00

UBI uses positive function return codes internally, and should not propagate
them up, except in the place this path fixes. Here is the original bug report
from Dan Carpenter:

The problem is really in ubi_eba_read_leb().

drivers/mtd/ubi/eba.c
   412                  err = ubi_io_read_vid_hdr(ubi, pnum, vid_hdr, 1);
   413                  if (err && err != UBI_IO_BITFLIPS) {
   414                          if (err > 0) {
   415                                  /*
   416                                   * The header is either absent or corrupted.
   417                                   * The former case means there is a bug -
   418                                   * switch to read-only mode just in case.
   419                                   * The latter case means a real corruption - we
   420                                   * may try to recover data. FIXME: but this is
   421                                   * not implemented.
   422                                   */
   423                                  if (err == UBI_IO_BAD_HDR_EBADMSG ||
   424                                      err == UBI_IO_BAD_HDR) {
   425                                          ubi_warn("corrupted VID header at PEB %d, LEB %d:%d",
   426                                                   pnum, vol_id, lnum);
   427                                          err = -EBADMSG;
   428                                  } else
   429                                          ubi_ro_mode(ubi);

On this path we return UBI_IO_FF and UBI_IO_FF_BITFLIPS and it
eventually gets passed to ERR_PTR().  We probably dereference the bad
pointer and oops.  At that point we've gone read only so it was already
a bad situation...

   430                          }
   431                          goto out_free;
   432                  } else if (err == UBI_IO_BITFLIPS)
   433                          scrub = 1;
   434

Reported-by: Dan Carpenter 
Signed-off-by: Artem Bityutskiy

UBI: clean-up printing helpers

2015-01-28T15:09:17+00:00

Let's prefix UBI messages with 'ubiX' instead of 'UBI-X' - this is more
consistent with the way we name UBI devices.

Also, commit "32608703 UBI: Extend UBI layer debug/messaging capabilities"
added the function name print to 'ubi_msg()' - lets revert this change, since
these messages are supposed to be just informative messages, and not debugging
messages.

Signed-off-by: Artem Bityutskiy

UBI: extend UBI layer debug/messaging capabilities - cosmetics

2015-01-28T15:09:09+00:00

Some cosmetic fixes to the patch "UBI: Extend UBI layer debug/messaging
capabilities".

Signed-off-by: Tanya Brokhman 
Signed-off-by: Artem Bityutskiy

UBI: Block: Add blk-mq support

2015-01-28T15:05:20+00:00

Convert the driver to blk-mq.
Beside of moving to the modern block interface this change boosts
also the performance of the driver.

nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron NAND 256MiB 3,3V 8-bit
nand: 256MiB, SLC, page size: 2048, OOB size: 64

root@debian-armhf:~# dd if=/dev/ubiblock0_0 of=/dev/zero bs=1M
243+1 records in
243+1 records out
255080448 bytes (255 MB) copied, 4.39295 s, 58.1 MB/s

vs.

root@debian-armhf:~# dd if=/dev/ubiblock0_0 of=/dev/zero bs=1M
243+1 records in
243+1 records out
255080448 bytes (255 MB) copied, 2.87676 s, 88.7 MB/s

Cc: hch@infradead.org
Cc: axboe@fb.com
Cc: tom.leiming@gmail.com
Signed-off-by: Richard Weinberger 
Tested-by: Ezequiel Garcia 
Reviewed-by: Jens Axboe 
Acked-by: Ezequiel Garcia

UBI: Add initial support for scatter gather

2015-01-28T15:04:26+00:00

Adds a new set of functions to deal with scatter gather.
ubi_eba_read_leb_sg() will read from a LEB into a scatter gather list.
The new data structure struct ubi_sgl will be used within UBI to
hold the scatter gather list itself and metadata to have a cursor
within the list.

Signed-off-by: Richard Weinberger 
Tested-by: Ezequiel Garcia 
Reviewed-by: Ezequiel Garcia