1. 11 May, 2015 1 commit
  2. 15 Apr, 2015 1 commit
  3. 13 Apr, 2015 1 commit
  4. 12 Apr, 2015 1 commit
  5. 26 Mar, 2015 1 commit
  6. 25 Mar, 2015 5 commits
  7. 10 Feb, 2015 2 commits
    • Kirill A. Shutemov's avatar
      mm: drop vm_ops->remap_pages and generic_file_remap_pages() stub · d83a08db
      Kirill A. Shutemov authored
      Nobody uses it anymore.
      
      [akpm@linux-foundation.org: fix filemap_xip.c]
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d83a08db
    • hujianyang's avatar
      UBIFS: return -EINVAL if log head is empty · 88cff0f0
      hujianyang authored
      CS node is recognized as a sign in UBIFS log replay mechanism.
      Log relaying during mount should find the CS node in log head
      at beginning and then replay the following uncommitted buds.
      
      Here is a bug in log replay path: If the log head, which is
      indicated by @log_lnum in mst_node, is empty, current UBIFS
      replay nothing and directly mount the partition without any
      warning. This action will put filesystem in an abnormal state,
      e.g. space management in LPT area is incorrect to the real
      space usage in main area.
      
      We reproduced this bug by fault injection: turn log head leb
      into all 0xFF. UBIFS driver mount the polluted partition
      normally. But errors occur while running fs_stress on this
      mount:
      
      [89068.055183] UBI error: ubi_io_read: error -74 (ECC error) while reading 59 bytes from PEB 711:33088, read 59 bytes
      [89068.179877] UBIFS error (pid 10517): ubifs_check_node: bad magic 0x101031, expected 0x6101831
      [89068.179882] UBIFS error (pid 10517): ubifs_check_node: bad node at LEB 591:28992
      [89068.179891] Not a node, first 24 bytes:
      [89068.179892] 00000000: 31 10 10 00 37 84 64 04 10 04 00 00 00 00 00 00 20 00 00 00 02 01 00 00                          1...7.d......... .......
      [89068.180282] UBIFS error (pid 10517): ubifs_read_node: expected node type 2
      
      This patch fix the problem by checking *lnum* to guarantee
      the empty leb is not log head leb and return an error if the
      log head leb is incorrectly empty. After this, we could catch
      *log head empty* error in place.
      Signed-off-by: default avatarhujianyang <hujianyang@huawei.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      88cff0f0
  8. 28 Jan, 2015 4 commits
  9. 20 Jan, 2015 2 commits
  10. 07 Nov, 2014 2 commits
  11. 30 Sep, 2014 1 commit
  12. 26 Sep, 2014 1 commit
  13. 19 Sep, 2014 1 commit
  14. 08 Sep, 2014 2 commits
    • Artem Bityutskiy's avatar
      UBIFS: fix free log space calculation · ba29e721
      Artem Bityutskiy authored
      Hu (hujianyang <hujianyang@huawei.com>) discovered an issue in the
      'empty_log_bytes()' function, which calculates how many bytes are left in the
      log:
      
      "
      If 'c->lhead_lnum + 1 == c->ltail_lnum' and 'c->lhead_offs == c->leb_size', 'h'
      would equalent to 't' and 'empty_log_bytes()' would return 'c->log_bytes'
      instead of 0.
      "
      
      At this point it is not clear what would be the consequences of this, and
      whether this may lead to any problems, but this patch addresses the issue just
      in case.
      
      Cc: stable@vger.kernel.org
      Tested-by: default avatarhujianyang <hujianyang@huawei.com>
      Reported-by: default avatarhujianyang <hujianyang@huawei.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      ba29e721
    • Artem Bityutskiy's avatar
      UBIFS: fix a race condition · 052c2807
      Artem Bityutskiy authored
      Hu (hujianyang@huawei.com) discovered a race condition which may lead to a
      situation when UBIFS is unable to mount the file-system after an unclean
      reboot. The problem is theoretical, though.
      
      In UBIFS, we have the log, which basically a set of LEBs in a certain area. The
      log has the tail and the head.
      
      Every time user writes data to the file-system, the UBIFS journal grows, and
      the log grows as well, because we append new reference nodes to the head of the
      log. So the head moves forward all the time, while the log tail stays at the
      same position.
      
      At any time, the UBIFS master node points to the tail of the log. When we mount
      the file-system, we scan the log, and we always start from its tail, because
      this is where the master node points to. The only occasion when the tail of the
      log changes is the commit operation.
      
      The commit operation has 2 phases - "commit start" and "commit end". The former
      is relatively short, and does not involve much I/O. During this phase we mostly
      just build various in-memory lists of the things which have to be written to
      the flash media during "commit end" phase.
      
      During the commit start phase, what we do is we "clean" the log. Indeed, the
      commit operation will index all the data in the journal, so the entire journal
      "disappears", and therefore the data in the log become unneeded. So we just
      move the head of the log to the next LEB, and write the CS node there. This LEB
      will be the tail of the new log when the commit operation finishes.
      
      When the "commit start" phase finishes, users may write more data to the
      file-system, in parallel with the ongoing "commit end" operation. At this point
      the log tail was not changed yet, it is the same as it had been before we
      started the commit. The log head keeps moving forward, though.
      
      The commit operation now needs to write the new master node, and the new master
      node should point to the new log tail. After this the LEBs between the old log
      tail and the new log tail can be unmapped and re-used again.
      
      And here is the possible problem. We do 2 operations: (a) We first update the
      log tail position in memory (see 'ubifs_log_end_commit()'). (b) And then we
      write the master node (see the big lock of code in 'do_commit()').
      
      But nothing prevents the log head from moving forward between (a) and (b), and
      the log head may "wrap" now to the old log tail. And when the "wrap" happens,
      the contends of the log tail gets erased. Now a power cut happens and we are in
      trouble. We end up with the old master node pointing to the old tail, which was
      erased. And replay fails because it expects the master node to point to the
      correct log tail at all times.
      
      This patch merges the abovementioned (a) and (b) operations by moving the master
      node change code to the 'ubifs_log_end_commit()' function, so that it runs with
      the log mutex locked, which will prevent the log from being changed benween
      operations (a) and (b).
      
      Cc: stable@vger.kernel.org # 07e19dff UBIFS: remove mst_mutex
      Cc: stable@vger.kernel.org
      Reported-by: default avatarhujianyang <hujianyang@huawei.com>
      Tested-by: default avatarhujianyang <hujianyang@huawei.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      052c2807
  15. 31 Jul, 2014 1 commit
  16. 28 Jul, 2014 1 commit
  17. 19 Jul, 2014 13 commits