1. 07 Jun, 2018 3 commits
  2. 17 Jan, 2018 1 commit
  3. 19 Oct, 2016 1 commit
  4. 02 Oct, 2016 7 commits
  5. 22 Jun, 2016 1 commit
  6. 24 May, 2016 2 commits
    • Richard Weinberger's avatar
      UBI: Fix static volume checks when Fastmap is used · 1900149c
      Richard Weinberger authored
      Ezequiel reported that he's facing UBI going into read-only
      mode after power cut. It turned out that this behavior happens
      only when updating a static volume is interrupted and Fastmap is
      used.
      
      A possible trace can look like:
      ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
      ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
      CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
      Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
      0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
      ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
      ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
      Call Trace:
      [<ffffffff8140d841>] dump_stack+0x63/0x82
      [<ffffffffa003abf6>] ubi_eba_read_leb+0x486/0x4a0 [ubi]
      [<ffffffffa00453b3>] ubi_check_volume+0x83/0xf0 [ubi]
      [<ffffffffa0039d97>] ubi_open_volume+0x177/0x350 [ubi]
      [<ffffffffa00375d8>] vol_cdev_open+0x58/0xb0 [ubi]
      [<ffffffff8124b08e>] chrdev_open+0xae/0x1d0
      [<ffffffff81243bcf>] do_dentry_open+0x1ff/0x300
      [<ffffffff8124afe0>] ? cdev_put+0x30/0x30
      [<ffffffff81244d36>] vfs_open+0x56/0x60
      [<ffffffff812545f4>] path_openat+0x4f4/0x1190
      [<ffffffff81256621>] do_filp_open+0x91/0x100
      [<ffffffff81263547>] ? __alloc_fd+0xc7/0x190
      [<ffffffff812450df>] do_sys_open+0x13f/0x210
      [<ffffffff812451ce>] SyS_open+0x1e/0x20
      [<ffffffff81a99e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      
      UBI checks static volumes for data consistency and reads the
      whole volume upon first open. If the volume is found erroneous
      users of UBI cannot read from it, but another volume update is
      possible to fix it. The check is performed by running
      ubi_eba_read_leb() on every allocated LEB of the volume.
      For static volumes ubi_eba_read_leb() computes the checksum of all
      data stored in a LEB. To verify the computed checksum it has to read
      the LEB's volume header which stores the original checksum.
      If the volume header is not found UBI treats this as fatal internal
      error and switches to RO mode. If the UBI device was attached via a
      full scan the assumption is correct, the volume header has to be
      present as it had to be there while scanning to get known as mapped.
      If the attach operation happened via Fastmap the assumption is no
      longer correct. When attaching via Fastmap UBI learns the mapping
      table from Fastmap's snapshot of the system state and not via a full
      scan. It can happen that a LEB got unmapped after a Fastmap was
      written to the flash. Then UBI can learn the LEB still as mapped and
      accessing it returns only 0xFF bytes. As UBI is not a FTL it is
      allowed to have mappings to empty PEBs, it assumes that the layer
      above takes care of LEB accounting and referencing.
      UBIFS does so using the LEB property tree (LPT).
      For static volumes UBI blindly assumes that all LEBs are present and
      therefore special actions have to be taken.
      
      The described situation can happen when updating a static volume is
      interrupted, either by a user or a power cut.
      The volume update code first unmaps all LEBs of a volume and then
      writes LEB by LEB. If the sequence of operations is interrupted UBI
      detects this either by the absence of LEBs, no volume header present
      at scan time, or corrupted payload, detected via checksum.
      In the Fastmap case the former method won't trigger as no scan
      happened and UBI automatically thinks all LEBs are present.
      Only by reading data from a LEB it detects that the volume header is
      missing and incorrectly treats this as fatal error.
      To deal with the situation ubi_eba_read_leb() from now on checks
      whether we attached via Fastmap and handles the absence of a
      volume header like a data corruption error.
      This way interrupted static volume updates will correctly get detected
      also when Fastmap is used.
      
      Cc: <[email protected]>
      Reported-by: Ezequiel Garcia's avatarEzequiel Garcia <[email protected]>
      Tested-by: Ezequiel Garcia's avatarEzequiel Garcia <[email protected]>
      Signed-off-by: default avatarRichard Weinberger <[email protected]>
      1900149c
    • Richard Weinberger's avatar
      UBI: Don't read back all data in ubi_eba_copy_leb() · 1e0a74f1
      Richard Weinberger authored
      Drop this paranoia check from the old days.
      If our MTD driver or the flash is so bad that we even cannot
      trust it to write data we have bigger problems.
      
      If one really does not trust the flash and wants write-verify
      she can enable UBI io checks using debugfs.
      Signed-off-by: default avatarRichard Weinberger <[email protected]>
      1e0a74f1
  7. 03 Oct, 2015 1 commit
  8. 26 Mar, 2015 4 commits
    • Richard Weinberger's avatar
      UBI: Fastmap: Locking updates · 111ab0b2
      Richard Weinberger authored
      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: default avatarRichard Weinberger <[email protected]>
      111ab0b2
    • Richard Weinberger's avatar
      UBI: Fastmap: Fix race after ubi_wl_get_peb() · 8fb2a514
      Richard Weinberger authored
      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: default avatarRichard Weinberger <[email protected]>
      8fb2a514
    • Richard Weinberger's avatar
      UBI: Fastmap: Fix race in ubi_eba_atomic_leb_change() · 36a87e44
      Richard Weinberger authored
      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: default avatarRichard Weinberger <[email protected]>
      36a87e44
    • Brian Norris's avatar
      UBI: fix out of bounds write · d74adbdb
      Brian Norris authored
      If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the
      PEB->LEB mapping.
      
      Caught by Coverity, CID #711212.
      
      Cc: stable <[email protected]>
      Signed-off-by: Brian Norris's avatarBrian Norris <[email protected]>
      Signed-off-by: default avatarRichard Weinberger <[email protected]>
      d74adbdb
  9. 23 Feb, 2015 1 commit
  10. 28 Jan, 2015 2 commits
    • Artem Bityutskiy's avatar
      UBI: do propagate positive error codes up · 0e707ae7
      Artem Bityutskiy authored
      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: default avatarDan Carpenter <[email protected]>
      Signed-off-by: default avatarArtem Bityutskiy <[email protected]>
      0e707ae7
    • Richard Weinberger's avatar
      UBI: Add initial support for scatter gather · 9ff08979
      Richard Weinberger authored
      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: default avatarRichard Weinberger <[email protected]>
      Tested-by: Ezequiel Garcia's avatarEzequiel Garcia <[email protected]>
      Reviewed-by: Ezequiel Garcia's avatarEzequiel Garcia <[email protected]>
      9ff08979
  11. 07 Nov, 2014 1 commit
  12. 26 Sep, 2014 1 commit
  13. 03 Oct, 2012 3 commits
  14. 04 Sep, 2012 1 commit
  15. 21 May, 2012 1 commit
    • Joel Reardon's avatar
      UBI: add lnum and vol_id to struct ubi_work · d36e59e6
      Joel Reardon authored
      This is part of a multipart patch to allow UBI to force the erasure of
      particular logical eraseblock numbers. In this patch, the volume id and LEB
      number are added to ubi_work data structure, and both are also passed as a
      parameter to schedule erase to set it appropriately. Whenever ubi_wl_put_peb
      is called, the lnum is also passed to be forwarded to schedule erase. Later,
      a new ubi_sync_lnum will be added to execute immediately all work related to
      that lnum.
      
      This was tested by outputting the vol_id and lnum during the schedule of
      erasure. The ubi thread was disabled and two ubifs drives on separate
      partitions repeated changed a small number of LEBs. The ubi module was readded,
      and all the erased LEBs, corresponding to the volumes, were added to the
      schedule erase queue.
      
      Artem: minor tweaks
      Signed-off-by: default avatarJoel Reardon <[email protected]>
      Signed-off-by: default avatarArtem Bityutskiy <[email protected]x.intel.com>
      d36e59e6
  16. 20 May, 2012 10 commits