linux-stable.git/drivers/mtd/ubi, branch linux-4.17.y

ubi: fastmap: Correctly handle interrupted erasures in EBA

2018-07-03T09:27:03+00:00

commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.

Fastmap cannot track the LEB unmap operation, therefore it can
happen that after an interrupted erasure the mapping still looks
good from Fastmap's point of view, while reading from the PEB will
cause an ECC error and confuses the upper layer.

Instead of teaching users of UBI how to deal with that, we read back
the VID header and check for errors. If the PEB is empty or shows ECC
errors we fixup the mapping and schedule the PEB for erasure.

Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Cc: 
Reported-by: martin bayern 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

ubi: fastmap: Cancel work upon detach

2018-07-03T09:27:03+00:00

commit 6e7d80161066c99d12580d1b985cb1408bb58cf1 upstream.

Ben Hutchings pointed out that 29b7a6fa1ec0 ("ubi: fastmap: Don't flush
fastmap work on detach") does not really fix the problem, it just
reduces the risk to hit the race window where fastmap work races against
free()'ing ubi->volumes[].

The correct approach is making sure that no more fastmap work is in
progress before we free ubi data structures.
So we cancel fastmap work right after the ubi background thread is
stopped.
By setting ubi->thread_enabled to zero we make sure that no further work
tries to wake the thread.

Fixes: 29b7a6fa1ec0 ("ubi: fastmap: Don't flush fastmap work on detach")
Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
Cc: stable@vger.kernel.org
Cc: Ben Hutchings 
Cc: Martin Townsend 

Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'tags/upstream-4.17-rc1' of git://git.infradead.org/linux-ubifs

2018-04-11T23:39:34+00:00

Pull UBI and UBIFS updates from Richard Weinberger:
 "Minor bug fixes and improvements"

* tag 'tags/upstream-4.17-rc1' of git://git.infradead.org/linux-ubifs:
  ubi: Reject MLC NAND
  ubifs: Remove useless parameter of lpt_heap_replace
  ubifs: Constify struct ubifs_lprops in scan_for_leb_for_idx
  ubifs: remove unnecessary assignment
  ubi: Fix error for write access
  ubi: fastmap: Don't flush fastmap work on detach
  ubifs: Check ubifs_wbuf_sync() return code

ubi: Reject MLC NAND

2018-04-04T21:48:11+00:00

While UBI and UBIFS seem to work at first sight with MLC NAND, you will
most likely lose all your data upon a power-cut or due to read/write
disturb.
In order to protect users from bad surprises, refuse to attach to MLC
NAND.

Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger 
Acked-by: Boris Brezillon 
Acked-by: Artem Bityutskiy

ubi: Fix error for write access

2018-04-04T21:48:05+00:00

When opening a device with write access, ubiblock_open returns an error
code. Currently, this error code is -EPERM, but this is not the right
value.

The open function for other block devices returns -EROFS when opening
read-only devices with FMODE_WRITE set. When used with dm-verity, the
veritysetup userspace tool is expecting EROFS, and refuses to use the
ubiblock device.

Use -EROFS for ubiblock as well. As a result, veritysetup accepts the
ubiblock device as valid.

Cc: stable@vger.kernel.org
Fixes: 9d54c8a33eec (UBI: R/O block driver on top of UBI volumes)
Signed-off-by: Romain Izard 
Signed-off-by: Richard Weinberger

ubi: fastmap: Don't flush fastmap work on detach

2018-04-04T21:41:44+00:00

At this point UBI volumes have already been free()'ed and fastmap can no
longer access these data structures.

Reported-by: Martin Townsend 
Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger

mtd: Stop updating erase_info->state and calling mtd_erase_callback()

2018-03-21T08:50:56+00:00

MTD users are no longer checking erase_info->state to determine if the
erase operation failed or succeeded. Moreover, mtd_erase_callback() is
now a NOP.

We can safely get rid of all mtd_erase_callback() calls and all
erase_info->state assignments. While at it, get rid of the
erase_info->state field, all MTD_ERASE_XXX definitions and the
mtd_erase_callback() function.

Signed-off-by: Boris Brezillon 
Reviewed-by: Richard Weinberger 
Reviewed-by: Miquel Raynal 
Acked-by: Bert Kenward 
---
Changes in v2:
- Address a few coding style issues (reported by Miquel)
- Remove comments that are no longer valid (reported by Miquel)

mtd: Unconditionally update ->fail_addr and ->addr in part_erase()

2018-03-15T17:22:26+00:00

->fail_addr and ->addr can be updated no matter the result of
parent->_erase(), we just need to remove the code doing the same thing
in mtd_erase_callback() to avoid adjusting those fields twice.

Note that this can be done because all MTD users have been converted to
not pass an erase_info->callback() and are thus only taking the
->addr_fail and ->addr fields into account after part_erase() has
returned.

While we're at it, get rid of the erase_info->mtd field which was only
needed to let mtd_erase_callback() get the partition device back.

Signed-off-by: Boris Brezillon 
Reviewed-by: Richard Weinberger

mtd: Stop assuming mtd_erase() is asynchronous

2018-03-15T17:21:07+00:00

None of the mtd->_erase() implementations work in an asynchronous manner,
so let's simplify MTD users that call mtd_erase(). All they need to do
is check the value returned by mtd_erase() and assume that != 0 means
failure.

Signed-off-by: Boris Brezillon 
Reviewed-by: Richard Weinberger

ubi: block: Fix locking for idr_alloc/idr_remove

2018-01-18T15:48:31+00:00

This fixes a race with idr_alloc where gd->first_minor can be set to the
same value for two simultaneous calls to ubiblock_create.  Each instance
calls device_add_disk with the same first_minor.  device_add_disk calls
bdi_register_owner which generates several warnings.

WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/devices/virtual/bdi/252:2'

WARNING: CPU: 1 PID: 179 at kernel-source/lib/kobject.c:240
kobject_add_internal+0x1ec/0x2f8
kobject_add_internal failed for 252:2 with -EEXIST, don't try to
register things with the same name in the same directory

WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/dev/block/252:2'

However, device_add_disk does not error out when bdi_register_owner
returns an error.  Control continues until reaching blk_register_queue.
It then BUGs.

kernel BUG at kernel-source/fs/sysfs/group.c:113!
[] (internal_create_group) from []
(sysfs_create_group+0x20/0x24)
[] (sysfs_create_group) from []
(blk_trace_init_sysfs+0x18/0x20)
[] (blk_trace_init_sysfs) from []
(blk_register_queue+0xd8/0x154)
[] (blk_register_queue) from []
(device_add_disk+0x194/0x44c)
[] (device_add_disk) from []
(ubiblock_create+0x284/0x2e0)
[] (ubiblock_create) from []
(vol_cdev_ioctl+0x450/0x554)
[] (vol_cdev_ioctl) from [] (vfs_ioctl+0x30/0x44)
[] (vfs_ioctl) from [] (do_vfs_ioctl+0xa0/0x790)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x44/0x68)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x34)

Locking idr_alloc/idr_remove removes the race and keeps gd->first_minor
unique.

Fixes: 2bf50d42f3a4 ("UBI: block: Dynamically allocate minor numbers")
Cc: stable@vger.kernel.org
Signed-off-by: Bradley Bolen 
Reviewed-by: Boris Brezillon 
Signed-off-by: Richard Weinberger