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+

commit 4df38926 ("UBI: block: Avoid disk size integer overflow")
introduced a dereference on dev (which is not initialized at that
point) when printing a warning message.  Re-order disk_capacity check
after the dev is found.

Found by cppcheck:
 [drivers/mtd/ubi/block.c:509]: (error) Uninitialized variable: dev

Artem: tweak the error message a bit
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch fixes the issue that on very large UBI volumes
UBI block does not work correctly.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

There's no need to set the disk capacity with the mutex held, so this
commit takes the variable setting out of the mutex. This simplifies
the disk capacity fix for very large volumes in a follow up commit.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Currently, ubiblock_resize() can fail if the device is not found
in the list. This commit changes the return type, so the function can
return something meaningful on error paths.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Otherwise we'd return a random value if allocation of the workqueue fails.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

When building the name for the workqueue thread, make sure a format
string cannot leak in from the disk name.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This was used in the olden days, back when onions were proper
yellow. Basically it mapped to the current buffer to be
transferred. With highmem being added more than a decade ago,
most drivers map pages out of a bio, and rq->buffer isn't
pointing at anything valid.

Convert old style drivers to just use bio_data().

For the discard payload use case, just reference the page
in the bio.
Signed-off-by: NJens Axboe <axboe@fb.com>

You cannot mark these parameters as __initdata.
Otherwise the data is gone upon module exit.

Fixes:
[  172.045465] BUG: unable to handle kernel paging request at ffffffffa001db38
[  172.046020] IP: [<ffffffff81067aa4>] destroy_params+0x24/0x50
Signed-off-by: NRichard Weinberger <richard@nod.at>
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Rename the UBI_IOCVOLATTBLK and UBI_IOCVOLDETBLK to UBI_IOCVOLCRBLK and
UBI_IOCVOLRMBLK, because we do not use terms "attach" and "detach" for the R/O
block devices on top of UBI volumes. Instead, we use terms "create" and
"remove". This patch also amends the related commentaries.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

Fixes the following warning on ARCH=avr32:

  drivers/mtd/ubi/block.c: In function 'ubiblock_read':
  drivers/mtd/ubi/block.c:207: warning: comparison of distinct pointer types lacks a cast
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

ubiblock_param_ops should be marked as __init as it's only used to set
a driver parameter on insertion time. This commit fixes the following:

  WARNING: drivers/mtd/built-in.o(.text+0x653ac): Section mismatch in
  reference from the variable ubiblock_param_ops to the function
  .init.text:ubiblock_set_param()

  The function ubiblock_param_ops() references the function __init
  ubiblock_set_param(). This is often because ubiblock_param_ops lacks a
  __init annotation or the annotation of ubiblock_set_param is wrong.

Given gcc errors if the struct is marked const __initdata, this commit
drops the const mark from it.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

We already use term attach/detach for UBI->MTD relations, let's not use this
for UBI->ubiblock relations to avoid confusion. Just use 'create' and 'remove'
instead. E.g., "create a R/O block device on top of a UBI volume".
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This commit introduces read-only block device emulation on top of UBI volumes.

Given UBI takes care of wear leveling and bad block management it's possible
to add a thin layer to enable block device access to UBI volumes.
This allows to use a block-oriented filesystem on a flash device.

The UBI block devices are meant to be used in conjunction with any
regular, block-oriented file system (e.g. ext4), although it's primarily
targeted at read-only file systems, such as squashfs.

Block devices are created upon user request through new ioctls:
UBI_IOCVOLATTBLK to attach and UBI_IOCVOLDETBLK to detach.
Also, a new UBI module parameter is added 'ubi.block'. This parameter is
needed in order to attach a block device on boot-up time, allowing to
mount the rootfs on a ubiblock device.
For instance, you could have these kernel parameters:

  ubi.mtd=5 ubi.block=0,0 root=/dev/ubiblock0_0

Or, if you compile ubi as a module:

  $ modprobe ubi mtd=/dev/mtd5 block=/dev/ubi0_0

Artem: amend commentaries and massage the patch a little bit.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>