1. 09 Dec, 2009 7 commits
  2. 07 Dec, 2009 2 commits
  3. 01 Dec, 2009 1 commit
  4. 24 Nov, 2009 5 commits
  5. 23 Nov, 2009 4 commits
  6. 22 Nov, 2009 1 commit
  7. 23 Nov, 2009 1 commit
  8. 24 Nov, 2009 1 commit
  9. 23 Nov, 2009 1 commit
    • Theodore Ts'o's avatar
      ext4: move ext4_forget() to ext4_jbd2.c · d6797d14
      Theodore Ts'o authored
      The ext4_forget() function better belongs in ext4_jbd2.c.  This will
      allow us to do some cleanup of the ext4_journal_revoke() and
      ext4_journal_forget() functions, as well as giving us better error
      reporting since we can report the caller of ext4_forget() when things
      go wrong.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      d6797d14
  10. 19 Nov, 2009 2 commits
  11. 23 Nov, 2009 2 commits
  12. 15 Nov, 2009 1 commit
  13. 23 Nov, 2009 2 commits
  14. 15 Nov, 2009 2 commits
  15. 23 Nov, 2009 3 commits
    • Theodore Ts'o's avatar
      ext4: make sure directory and symlink blocks are revoked · 50689696
      Theodore Ts'o authored
      When an inode gets unlinked, the functions ext4_clear_blocks() and
      ext4_remove_blocks() call ext4_forget() for all the buffer heads
      corresponding to the deleted inode's data blocks.  If the inode is a
      directory or a symlink, the is_metadata parameter must be non-zero so
      ext4_forget() will revoke them via jbd2_journal_revoke().  Otherwise,
      if these blocks are reused for a data file, and the system crashes
      before a journal checkpoint, the journal replay could end up
      corrupting these data blocks.
      
      Thanks to Curt Wohlgemuth for pointing out potential problems in this
      area.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      50689696
    • Theodore Ts'o's avatar
      ext4: add tracepoint for ext4_forget() · beac2da7
      Theodore Ts'o authored
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      beac2da7
    • Theodore Ts'o's avatar
      ext4: remove failed journal checksum check · cf40db13
      Theodore Ts'o authored
      Now that we are checking for failed journal checksums in the jbd2
      layer, we don't need to check in the ext4 mount path --- since a
      checksum fail will result in ext4_load_journal() returning an error,
      causing the file system to refuse to be mounted until e2fsck can deal
      with the problem.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      cf40db13
  16. 15 Nov, 2009 1 commit
    • Theodore Ts'o's avatar
      jbd2: don't wipe the journal on a failed journal checksum · e6a47428
      Theodore Ts'o authored
      If there is a failed journal checksum, don't reset the journal.  This
      allows for userspace programs to decide how to recover from this
      situation.  It may be that ignoring the journal checksum failure might
      be a better way of recovering the file system.  Once we add per-block
      checksums, we can definitely do better.  Until then, a system
      administrator can try backing up the file system image (or taking a
      snapshot) and and trying to determine experimentally whether ignoring
      the checksum failure or aborting the journal replay results in less
      data loss.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      e6a47428
  17. 14 Nov, 2009 1 commit
  18. 23 Nov, 2009 3 commits
    • Akira Fujita's avatar
      ext4: fix spelling typos in move_extent.c · 92c28159
      Akira Fujita authored
      Fix a few spelling typos in move_extent.c
      Signed-off-by: default avatarAkira Fujita <a-fujita@rs.jp.nec.co.jp>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      92c28159
    • Akira Fujita's avatar
      ext4: fix possible recursive locking warning in EXT4_IOC_MOVE_EXT · 49bd22bc
      Akira Fujita authored
      If CONFIG_PROVE_LOCKING is enabled, the double_down_write_data_sem()
      will trigger a false-positive warning of a recursive lock.  Since we
      take i_data_sem for the two inodes ordered by their inode numbers,
      this isn't a problem.  Use of down_write_nested() will notify the lock
      dependency checker machinery that there is no problem here.
      
      This problem was reported by Brian Rogers:
      
      	http://marc.info/?l=linux-ext4&m=125115356928011&w=1Reported-by: default avatarBrian Rogers <brian@xyzw.org>
      Signed-off-by: default avatarAkira Fujita <a-fujita@rs.jp.nec.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      49bd22bc
    • Akira Fujita's avatar
      ext4: fix lock order problem in ext4_move_extents() · fc04cb49
      Akira Fujita authored
      ext4_move_extents() checks the logical block contiguousness
      of original file with ext4_find_extent() and mext_next_extent().
      Therefore the extent which ext4_ext_path structure indicates
      must not be changed between above functions.
      
      But in current implementation, there is no i_data_sem protection
      between ext4_ext_find_extent() and mext_next_extent().  So the extent
      which ext4_ext_path structure indicates may be overwritten by
      delalloc.  As a result, ext4_move_extents() will exchange wrong blocks
      between original and donor files.  I change the place where
      acquire/release i_data_sem to solve this problem.
      
      Moreover, I changed move_extent_per_page() to start transaction first,
      and then acquire i_data_sem.  Without this change, there is a
      possibility of the deadlock between mmap() and ext4_move_extents():
      
      * NOTE: "A", "B" and "C" mean different processes
      
      A-1: ext4_ext_move_extents() acquires i_data_sem of two inodes.
      
      B:   do_page_fault() starts the transaction (T),
           and then tries to acquire i_data_sem.
           But process "A" is already holding it, so it is kept waiting.
      
      C:   While "A" and "B" running, kjournald2 tries to commit transaction (T)
           but it is under updating, so kjournald2 waits for it.
      
      A-2: Call ext4_journal_start with holding i_data_sem,
           but transaction (T) is locked.
      Signed-off-by: default avatarAkira Fujita <a-fujita@rs.jp.nec.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      fc04cb49