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>

By using UBI_METAONLY in rename_volumes() it is now possible to rename
an UBI volume atomically while it is open for writing.
This is useful for firmware upgrades.

Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: Andrew Murray <amurray@embedded-bits.co.uk>
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>
Tested-by: NChristoph Fritz <chf.fritz@googlemail.com>
Tested-by: NAndrew Murray <amurray@embedded-bits.co.uk>

UBI_METAONLY is a new open mode for UBI volumes, it indicates
that only meta data is being changed.
Meta data in terms of UBI volumes means data which is stored in the
UBI volume table but not on the volume itself.
While it does not interfere with UBI_READONLY and UBI_READWRITE
it is not allowed to use UBI_METAONLY together with UBI_EXCLUSIVE.

Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: Andrew Murray <amurray@embedded-bits.co.uk>
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>
Tested-by: NChristoph Fritz <chf.fritz@googlemail.com>
Tested-by: NAndrew Murray <amurray@embedded-bits.co.uk>

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]  [<ffffffff818f0497>] dump_stack+0x4e/0x7a
[   31.568510]  [<ffffffff8156f515>] ubi_io_write_vid_hdr+0x155/0x160
[   31.569084]  [<ffffffff8156c10a>] ubi_eba_write_leb+0x23a/0x870
[   31.569628]  [<ffffffff81569b36>] vol_cdev_write+0x226/0x380
[   31.570155]  [<ffffffff81179265>] vfs_write+0xb5/0x1f0
[   31.570627]  [<ffffffff81179f8a>] SyS_pwrite64+0x6a/0xa0
[   31.571123]  [<ffffffff818fde12>] system_call_fastpath+0x16/0x1b

Cc: <stable@vger.kernel.org>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

If the erase worker is unable to erase a PEB it will
free the ubi_wl_entry itself.
The failing ubi_wl_entry must not free()'d again after
do_sync_erase() returns.

Cc: <stable@vger.kernel.org>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This is more a cosmetic change than a fix.
By using ubi_eba_atomic_leb_change()
we can guarantee that the first VTBL record is always
correct and we don't really need the second one anymore.
But we have to keep the second one to not break anything.

Artem: add a comment
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer message types.

The R/O block driver messages were replaced by pr_* since
ubi_device structure is not used by it.

Amended a bit by Artem.
Signed-off-by: NTanya Brokhman <tlinder@codeaurora.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

We need to add fm_sb too.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

s/of/if/
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

It confused me more than once that the cancel flag of the
work function does not indicate the cancellation of a single work.
In fact it indicates the WL sub-system shutdown and therefore
worker functions have to free their wl_entries too.
That's why you cannot cancel a single work, you can only shutdown
all works.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

There is no need to set err, it will be overwritten in any case
later at:
        if (scrub)
                err = ubi_wl_scrub_peb(ubi, pnum);
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

The while loop in produce_free_peb() assumes that each work will produce a
free PEB. This is not true.
If ubi->works_count is 1 and the only scheduled work is the
wear_leveling_worker() produce_free_peb() can loop forever in case
nobody schedules an erase work.
Fix this issue by checking in the while loop whether work is scheduled.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

I noticed this during a code review.  We are checking that the strlen()
of ->name is not less than the ->name_len which the user gave us.  I
believe this bug is harmless but clearly we meant to return here instead
of setting an error code and then not using it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Make clear what work_sem really does.
Suggested-by: NArtem Bityutskiy <dedekind1@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

The UBI_IOCVOLUP ioctl is used to start an update and also to
truncate a volume. In the first case, a "volume updated" notification
is dispatched when the update is done.

This commit adds the "volume updated" notification to be also sent when
the volume is truncated. This is required for UBI block and gluebi to get
notified about the new volume size.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: stable@vger.kernel.org # v3.15+

Static volumes can change its 'used_bytes' when they get updated,
and so the block interface must listen to the UBI_VOLUME_UPDATED
notification to resize the block device accordingly.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: stable@vger.kernel.org # v3.15+

We are currently taking the block device size from the ubi_volume_info.size
field. However, this is not the amount of data in the volume, but the
number of reserved physical eraseblocks, and hence leads to an incorrect
representation of the volume.

In particular, this produces I/O errors on static volumes as the block
interface may attempt to read unmapped PEBs:

$ cat /dev/ubiblock0_0 > /dev/null
UBI error: ubiblock_read_to_buf: ubiblock0_0 ubi_read error -22
end_request: I/O error, dev ubiblock0_0, sector 9536
Buffer I/O error on device ubiblock0_0, logical block 2384
[snip]

Fix this by using the ubi_volume_info.used_bytes field which is set to the
actual number of data bytes for both static and dynamic volumes.

While here, improve the error message to be less stupid and more useful:
UBI error: ubiblock_read_to_buf: ubiblock0_1 ubi_read error -9 on LEB=0, off=15872, len=512

It's worth noticing that the 512-byte sector representation of the volume
is only correct if the volume size is multiple of 512-bytes. This is true for
virtually any NAND device, given eraseblocks and pages are 512-byte multiple
and hence so is the LEB size.

Artem: tweak the error message and make it look more like other UBI error
messages.

Fixes: 9d54c8a3 ("UBI: R/O block driver on top of UBI volumes")
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: stable@vger.kernel.org # v3.15+