1. 02 6月, 2009 3 次提交
    • A
      UBI: do not switch to R/O mode on read errors · b86a2c56
      Artem Bityutskiy 提交于
      This patch improves UBI errors handling. ATM UBI switches to
      R/O mode when the WL worker fails to read the source PEB.
      This means that the upper layers (e.g., UBIFS) has no
      chances to unmap the erroneous PEB and fix the error.
      This patch changes this behaviour and makes UBI put PEBs
      like this into a separate RB-tree, thus preventing the
      WL worker from hitting the same read errors again and
      again.
      
      But there is a 10% limit on a maximum amount of PEBs like this.
      If there are too much of them, UBI switches to R/O mode.
      
      Additionally, this patch teaches UBI not to panic and
      switch to R/O mode if after a PEB has been copied, the
      target LEB cannot be read back. Instead, now UBI cancels
      the operation and schedules the target PEB for torturing.
      
      The error paths has been tested by ingecting errors
      into 'ubi_eba_copy_leb()'.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      b86a2c56
    • A
      UBI: fix and clean-up error paths in WL worker · 87960c0b
      Artem Bityutskiy 提交于
      This patch fixes the error path in the WL worker - in same cases
      UBI oopses when 'goto out_error' happens and e1 or e2 are NULL.
      This patch also cleans up the error paths a little. And I have
      tested nearly all error paths in the WL worker.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      87960c0b
    • A
      UBI: introduce new constants · 90bf0265
      Artem Bityutskiy 提交于
      This patch is a clean-up and a preparation for the following
      patches. It introduece constants for the return values of the
      'ubi_eba_copy_leb()' function.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      90bf0265
  2. 26 5月, 2009 1 次提交
    • A
      UBI: fix race condition · ddbd3b61
      Artem Bityutskiy 提交于
      This patch fixes a minor problem where we may fail to wake
      upe the UBI background thread. This is not fatal at all,
      it may just result at sligtly worse performace for a short
      period of time, just because the thread will be woken up
      when real I/O on the UBI starts.
      
      Anywey, the issue is the race condition between
      'ubi_attach_mtd_dev()' and 'ubi_thread()'. If we do not
      serialize them, the 'wake_up_process()' call may be done
      before 'ubi_thread()' went seep, but after it checked
      'ubi->thread_enabled'.
      
      This issue was spotted by Shin Hong <hongshin@gmail.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      ddbd3b61
  3. 18 5月, 2009 8 次提交
  4. 16 5月, 2009 12 次提交
  5. 15 5月, 2009 16 次提交