Using this debugfs knob fastmap self checks can be controlled.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org>

If UBI is unable to write the fastmap to the device
we have make sure that upon next attach UBI will fall
back to scanning mode.
In case we cannot ensure that they only thing we can do
is falling back to read-only mode.

The current error handling code is not powercut proof.
It could happen that a powercut while invalidating would
lead to a state where an too old fastmap could be used upon
attach.
This patch addresses the issue by writing a fake fastmap
super block to a fresh PEB instead of reerasing the existing one.
The fake fastmap super block will UBI case to do a full scan.
Signed-off-by: NRichard Weinberger <richard@nod.at>

The current code assumes that each fastmap has the same amount of PEBs.
So far this is true but will change soon.
Signed-off-by: NRichard Weinberger <richard@nod.at>

a) Rename ubi->fm_sem to ubi->fm_eba_sem as this semaphore
protects EBA changes.
b) Turn ubi->fm_mutex into a rw semaphore. It will still serialize
fastmap writes but also ensures that ubi_wl_put_peb() is not
interrupted by a fastmap write. We use a rw semaphore to allow
ubi_wl_put_peb() still to be executed in parallel if no fastmap
write is happening.
Signed-off-by: NRichard Weinberger <richard@nod.at>

If we set it for dynamic ones we might confuse various self checks.
Signed-off-by: NRichard Weinberger <richard@nod.at>

ubi_wl_get_peb() returns a fresh PEB which can be used by
user of UBI. Due to the pool logic fastmap will correctly
map this PEB upon attach time because it will be scanned.

If a new fastmap is written (due to heavy parallel io)
while the before the fresh PEB is assigned to the EBA table
it will not be scanned as it is no longer in the pool.
So, the race window exists between ubi_wl_get_peb()
and the EBA table assignment.
We have to make sure that no new fastmap can be written
while that.

To ensure that ubi_wl_get_peb() will grab ubi->fm_sem in read mode
and the user of ubi_wl_get_peb() has to release it after the PEB
got assigned.
Signed-off-by: NRichard Weinberger <richard@nod.at>

If a LEB is unmapped we have to decrement leb_count as well.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Don't use a fixed size for the WL pool.
Make it instead 50% of the user pool.
We don't make it 100% as it is not as heavily used as the user pool.
Signed-off-by: NRichard Weinberger <richard@nod.at>

We have to switch to ro mode to guarantee that upon next UBI attach
all data is consistent.
Signed-off-by: NRichard Weinberger <richard@nod.at>

This logic is in vain as we treat protected PEBs also as used, so this
case must not happen.
If a PEB is found which is in the EBA table but not known as used
has to be issued as fatal error.
Signed-off-by: NRichard Weinberger <richard@nod.at>

It is legal to have PEBs left in the used list.
This can happen if UBI copies a PEB and a powercut happens
between writing a new fastmap and adding this PEB into the EBA table.
In this case the old PEB will be used.
Signed-off-by: NRichard Weinberger <richard@nod.at>

This function a) requests a new PEB, b) writes data to it,
c) returns the old PEB and d) registers the new PEB in the EBA table.

For the non-fastmap case this works perfectly fine and is powercut safe.
Is fastmap enabled this can lead to issues.
If a new fastmap is written between a) and c) the freshly requested PEB
is no longer in a pool and will not be scanned upon attaching.
If now a powercut happens between c) and d) the freshly requested PEB
will not be scanned and the old one got already scheduled for erase.
After attaching the EBA table will point to a erased PEB.

Fix this issue by swapping steps c) and d).
Signed-off-by: NRichard Weinberger <richard@nod.at>

There is always exactly one ubi_attach_info object allocated,
therefore we don't have to care about the name.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Currently we leak a few ubi_ainf_pebs while attaching.
Signed-off-by: NRichard Weinberger <richard@nod.at>

There is no need to switch to ro mode if ubi_update_fastmap() fails.
Also get rid of the ifdef.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org>

...such that we can implement NOP variants of some functions.
This will help to reduce fastmap specific ifdefs in other c files.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org>

If ubi_update_fastmap() fails notify the user.
This is not a hard error as ubi_update_fastmap() makes sure that upon failure
the current on-flash fastmap will no be used upon next UBI attach.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Add a ubi_fastmap_close() to free all resources used by fastmap
at WL shutdown.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Tested-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

There is no need to allocate new ones every time, we can reuse
the existing ones.
This makes the code cleaner and more easy to follow.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

Currently ubi_refill_pools() first fills the first and then
the second one.
If only very few free PEBs are available the second pool can get
zero PEBs.
Change ubi_refill_pools() to distribute free PEBs fair between
all pools.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

Make it two functions, wl_get_wle() and wl_get_peb().
wl_get_peb() works exactly like __wl_get_peb() but wl_get_wle()
does not call produce_free_peb().
While refilling the fastmap user pool we cannot release ubi->wl_lock
as produce_free_peb() does.
Hence the fastmap logic uses now wl_get_wle().
Signed-off-by: NRichard Weinberger <richard@nod.at>

ubi_wl_get_peb() has two problems, it reads the pool
size and usage counters without any protection.
While reading one value would be perfectly fine it reads multiple
values and compares them. This is racy and can lead to incorrect
pool handling.
Furthermore ubi_update_fastmap() is called without wl_lock held,
before incrementing the used counter it needs to be checked again.
It could happen that another thread consumed all PEBs from the
pool and the counter goes beyond ->size.
Signed-off-by: NRichard Weinberger <richard@nod.at>

...otherwise the deferred work might run after datastructures
got freed and corrupt memory.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

If the WL pool runs out of PEBs we schedule a fastmap write
to refill it as soon as possible.
Ensure that only one at a time is scheduled otherwise we might end in
a fastmap write storm because writing the fastmap can schedule another
write if bitflips are detected.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

The kerneldoc for @vid_hdr_aloffset continues onto a second line, but
this is not obvious, because the second line isn't indented, and it
begins with '@'.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

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

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
[rw: Fixed comparison]
Signed-off-by: NRichard Weinberger <richard@nod.at>

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

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

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

Caught by Coverity, CID #711212.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

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

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

commit 0e707ae7 ("UBI: do propagate positive error codes up") seems
to have produced an unintended change in the control flow here.

Completely untested, but it looks obvious.

Caught by Coverity, which didn't like the indentation. CID 1271184.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

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: ff1f48ee ('UBI: Block: Add blk-mq support')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

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: NDan Ehrenberg <dehrenberg@chromium.org>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>

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 <richard@nod.at>

[ 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] [<c000f624>] (unwind_backtrace+0x0/0x120) from [<c000c294>] (show_stack+0x10/0x14)
[ 2158.172918] [<c000c294>] (show_stack+0x10/0x14) from [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660)
[ 2158.172936] [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660) from [<c002b480>] (update_process_times+0x38/0x64)
[ 2158.172953] [<c002b480>] (update_process_times+0x38/0x64) from [<c005ff38>] (tick_sched_handle+0x54/0x60)
[ 2158.172966] [<c005ff38>] (tick_sched_handle+0x54/0x60) from [<c00601ac>] (tick_sched_timer+0x44/0x74)
[ 2158.172978] [<c00601ac>] (tick_sched_timer+0x44/0x74) from [<c003f348>] (__run_hrtimer+0xc8/0x1b8)
[ 2158.172992] [<c003f348>] (__run_hrtimer+0xc8/0x1b8) from [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4)
[ 2158.173007] [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4) from [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30)
[ 2158.173022] [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30) from [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124)
[ 2158.173036] [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124) from [<c0082bd8>] (generic_handle_irq+0x20/0x30)
[ 2158.173049] [<c0082bd8>] (generic_handle_irq+0x20/0x30) from [<c000969c>] (handle_IRQ+0x64/0x8c)
[ 2158.173060] [<c000969c>] (handle_IRQ+0x64/0x8c) from [<c0008544>] (gic_handle_irq+0x3c/0x60)
[ 2158.173074] [<c0008544>] (gic_handle_irq+0x3c/0x60) from [<c02f0f80>] (__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] [<c02f0f80>] (__irq_svc+0x40/0x50) from [<c0186cb8>] (read_current_timer+0x4/0x38)
[ 2158.173145] [<c0186cb8>] (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: NWang Kai <morgan.wang@huawei.com>
Signed-off-by: Nhujianyang <hujianyang@huawei.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

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: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

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: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

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: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Some cosmetic fixes to the patch "UBI: Extend UBI layer debug/messaging
capabilities".
Signed-off-by: NTanya Brokhman <tlinder@codeaurora.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

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: NRichard Weinberger <richard@nod.at>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: NJens Axboe <axboe@fb.com>
Acked-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

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: NRichard Weinberger <richard@nod.at>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>