1. 30 7月, 2016 2 次提交
  2. 24 5月, 2016 1 次提交
    • R
      UBI: Fix static volume checks when Fastmap is used · 1900149c
      Richard Weinberger 提交于
      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: <stable@vger.kernel.org>
      Reported-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      1900149c
  3. 21 3月, 2016 1 次提交
  4. 02 6月, 2015 1 次提交
  5. 14 4月, 2015 1 次提交
  6. 27 3月, 2015 6 次提交
  7. 26 3月, 2015 1 次提交
  8. 28 1月, 2015 3 次提交
  9. 07 11月, 2014 1 次提交
  10. 26 9月, 2014 1 次提交
  11. 19 9月, 2014 1 次提交
  12. 11 3月, 2014 1 次提交
  13. 05 3月, 2014 1 次提交
  14. 04 3月, 2014 1 次提交
  15. 28 2月, 2014 1 次提交
    • E
      UBI: R/O block driver on top of UBI volumes · 9d54c8a3
      Ezequiel Garcia 提交于
      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>
      9d54c8a3
  16. 10 12月, 2012 1 次提交
  17. 03 10月, 2012 2 次提交
  18. 04 9月, 2012 4 次提交
  19. 18 7月, 2012 1 次提交
  20. 21 5月, 2012 9 次提交
    • J
      UBI: modify ubi_wl_flush function to clear work queue for a lnum · 62f38455
      Joel Reardon 提交于
      This patch modifies ubi_wl_flush to force the erasure of
      particular volume id / logical eraseblock number pairs. Previous functionality
      is preserved when passing UBI_ALL for both values. The locations where ubi_wl_flush
      were called are appropriately changed: ubi_leb_erase only flushes for the
      erased LEB, and ubi_create_volume forces only flushing for its volume id.
      External code can call this new feature via the new function ubi_flush() added
      to kapi.c, which simply passes through to ubi_wl_flush().
      
      This was tested by disabling the call to do_work in ubi thread, which results
      in the work queue remaining unless explicitly called to remove. UBIFS was
      changed to call ubifs_leb_change 50 times for four different LEBs. Then the
      new function was called to clear the queue: passing wrong volume ids / lnum,
      correct ones, and finally UBI_ALL for both to ensure it was finally all
      cleard. The work queue was dumped each time and the selective removal
      of the particular LEB numbers was observed. Extra checks were enabled and
      ubifs's integck was also run. Finally, the drive was repeatedly filled and
      emptied to ensure that the queue was cleared normally.
      
      Artem: amended the patch.
      Signed-off-by: NJoel Reardon <reardonj@inf.ethz.ch>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      62f38455
    • A
      UBI: introduce UBI_ALL constant · 05a3cb7d
      Artem Bityutskiy 提交于
      Joel will use it in his 'ubi_flush()' extention to specify all eraseblocks.
      Also amend the comment for UBI_UNKNOWN - it is used beyond attaching info
      structure now.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      05a3cb7d
    • J
      UBI: add lnum and vol_id to struct ubi_work · d36e59e6
      Joel Reardon 提交于
      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: NJoel Reardon <reardonj@inf.ethz.ch>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      d36e59e6
    • J
      UBI: add volume id struct ubi_ainf_peb · 6dd3bc7e
      Joel Reardon 提交于
      This patch adds the volume id to struct ubi_ainf_peb when scanning the LEBs at
      startup. PEBs now added to the erase queue will know their original LEB number
      and volume id, if available, and will be -1 otherwise (for instance, if the VID
      header is unreadable).
      
      This was tested by creating an ubi device with 3 volumes and disabiling the
      ubi_thread's do_work functionality. The different ubi volumes were formatted
      to ubifs and had files created and erased.  The ubi modules was reloaded and
      the list of LEB's added to the erased list was outputted, confirming the
      volume ids and LEB numbers were appropriate.
      Signed-off-by: NJoel Reardon <reardonj@inf.ethz.ch>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      6dd3bc7e
    • A
      UBI: remove scan.h · 0479ab48
      Artem Bityutskiy 提交于
      This file is small and it does not make sense to have it separate from where
      everything else lives, so merge it with ubi.h.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      0479ab48
    • A
      UBI: move and rename attach_by_scanning · 47e1ec70
      Artem Bityutskiy 提交于
      Rename the 'attach_by_scanning()' function to 'ubi_attach()' and move it to
      scan.c. Richard will plug his fastmap stuff there.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      47e1ec70
    • A
      UBI: rename _init_scan functions · 41e0cd9d
      Artem Bityutskiy 提交于
      We have a couple of initialization funcntionsn left which have "_scan" suffic -
      rename them:
      
      ubi_eba_init_scan() -> ubi_eba_init()
      ubi_wl_init_scan() -> ubi_wl_init()
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      41e0cd9d
    • A
      UBI: rename si to ai · a4e6042f
      Artem Bityutskiy 提交于
      After re-naming the 'struct ubi_scan_info' we should adjust all variables
      named 'si' to something else, because 'si' stands for "scanning info".
      Let's rename it to 'ai' which stands for "attaching info" which is
      a bit more consistent and has the same length, which makes re-naming easy.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
      a4e6042f
    • A
      UBI: rename struct ubi_scan_info · afc15a81
      Artem Bityutskiy 提交于
      Rename 'struct ubi_scan_info' to 'struct ubi_attach_info'. This is part
      of the code re-structuring I am trying to do in order to add fastmap
      in a more logical way. Fastmap can share a lot with scanning, including
      the attach-time data structures, which all now have "scan" word in the
      name. Let's get rid of this word.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
      afc15a81