1. 30 11月, 2012 1 次提交
  2. 29 10月, 2012 1 次提交
    • E
      ext4: fix unjournaled inode bitmap modification · ffb5387e
      Eric Sandeen 提交于
      commit 119c0d44 changed
      ext4_new_inode() such that the inode bitmap was being modified
      outside a transaction, which could lead to corruption, and was
      discovered when journal_checksum found a bad checksum in the
      journal during log replay.
      
      Nix ran into this when using the journal_async_commit mount
      option, which enables journal checksumming.  The ensuing
      journal replay failures due to the bad checksums led to
      filesystem corruption reported as the now infamous
      "Apparent serious progressive ext4 data corruption bug"
      
      [ Changed by tytso to only call ext4_journal_get_write_access() only
        when we're fairly certain that we're going to allocate the inode. ]
      
      I've tested this by mounting with journal_checksum and
      running fsstress then dropping power; I've also tested by
      hacking DM to create snapshots w/o first quiescing, which
      allows me to test journal replay repeatedly w/o actually
      power-cycling the box.  Without the patch I hit a journal
      checksum error every time.  With this fix it survives
      many iterations.
      Reported-by: NNix <nix@esperi.org.uk>
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      ffb5387e
  3. 22 10月, 2012 1 次提交
  4. 24 9月, 2012 1 次提交
  5. 23 7月, 2012 1 次提交
  6. 01 7月, 2012 1 次提交
  7. 29 5月, 2012 2 次提交
    • T
      ext4: protect group inode free counting with group lock · 6f2e9f0e
      Tao Ma 提交于
      Now when we set the group inode free count, we don't have a proper
      group lock so that multiple threads may decrease the inode free
      count at the same time. And e2fsck will complain something like:
      
      Free inodes count wrong for group #1 (1, counted=0).
      Fix? no
      
      Free inodes count wrong for group #2 (3, counted=0).
      Fix? no
      
      Directories count wrong for group #2 (780, counted=779).
      Fix? no
      
      Free inodes count wrong for group #3 (2272, counted=2273).
      Fix? no
      
      So this patch try to protect it with the ext4_lock_group.
      
      btw, it is found by xfstests test case 269 and the volume is
      mkfsed with the parameter
      "-O ^resize_inode,^uninit_bg,extent,meta_bg,flex_bg,ext_attr"
      and I have run it 100 times and the error in e2fsck doesn't
      show up again.
      Signed-off-by: NTao Ma <boyu.mt@taobao.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      6f2e9f0e
    • D
      ext4: fix potential NULL dereference in ext4_free_inodes_counts() · bb3d132a
      Dan Carpenter 提交于
      The ext4_get_group_desc() function returns NULL on error, and
      ext4_free_inodes_count() function dereferences it without checking.
      There is a check on the next line, but it's too late.
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      bb3d132a
  8. 16 5月, 2012 1 次提交
  9. 30 4月, 2012 4 次提交
  10. 20 3月, 2012 2 次提交
  11. 21 2月, 2012 1 次提交
    • T
      ext4: fix race when setting bitmap_uptodate flag · 813e5727
      Theodore Ts'o 提交于
      In ext4_read_{inode,block}_bitmap() we were setting bitmap_uptodate()
      before submitting the buffer for read.  The is bad, since we check
      bitmap_uptodate() without locking the buffer, and so if another
      process is racing with us, it's possible that they will think the
      bitmap is uptodate even though the read has not completed yet,
      resulting in inodes and blocks potentially getting allocated more than
      once if we get really unlucky.
      
      Addresses-Google-Bug: 2828254
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      813e5727
  12. 07 2月, 2012 1 次提交
  13. 04 1月, 2012 1 次提交
  14. 29 12月, 2011 2 次提交
  15. 19 12月, 2011 1 次提交
    • J
      ext4: fix error handling on inode bitmap corruption · acd6ad83
      Jan Kara 提交于
      When insert_inode_locked() fails in ext4_new_inode() it most likely means inode
      bitmap got corrupted and we allocated again inode which is already in use. Also
      doing unlock_new_inode() during error recovery is wrong since the inode does
      not have I_NEW set. Fix the problem by jumping to fail: (instead of fail_drop:)
      which declares filesystem error and does not call unlock_new_inode().
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      acd6ad83
  16. 02 11月, 2011 1 次提交
  17. 01 11月, 2011 1 次提交
  18. 29 10月, 2011 1 次提交
  19. 18 10月, 2011 1 次提交
  20. 09 10月, 2011 1 次提交
  21. 10 9月, 2011 5 次提交
  22. 01 8月, 2011 1 次提交
  23. 22 3月, 2011 1 次提交
  24. 17 3月, 2011 1 次提交
    • T
      ext4: Initialize fsync transaction ids in ext4_new_inode() · 688f869c
      Theodore Ts'o 提交于
      When allocating a new inode, we need to make sure i_sync_tid and
      i_datasync_tid are initialized.  Otherwise, one or both of these two
      values could be left initialized to zero, which could potentially
      result in BUG_ON in jbd2_journal_commit_transaction.
      
      (This could happen by having journal->commit_request getting set to
      zero, which could wake up the kjournald process even though there is
      no running transaction, which then causes a BUG_ON via the 
      J_ASSERT(j_ruinning_transaction != NULL) statement.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      688f869c
  25. 22 2月, 2011 1 次提交
  26. 02 2月, 2011 1 次提交
    • E
      fs/vfs/security: pass last path component to LSM on inode creation · 2a7dba39
      Eric Paris 提交于
      SELinux would like to implement a new labeling behavior of newly created
      inodes.  We currently label new inodes based on the parent and the creating
      process.  This new behavior would also take into account the name of the
      new object when deciding the new label.  This is not the (supposed) full path,
      just the last component of the path.
      
      This is very useful because creating /etc/shadow is different than creating
      /etc/passwd but the kernel hooks are unable to differentiate these
      operations.  We currently require that userspace realize it is doing some
      difficult operation like that and than userspace jumps through SELinux hoops
      to get things set up correctly.  This patch does not implement new
      behavior, that is obviously contained in a seperate SELinux patch, but it
      does pass the needed name down to the correct LSM hook.  If no such name
      exists it is fine to pass NULL.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      2a7dba39
  27. 11 1月, 2011 1 次提交
  28. 28 10月, 2010 3 次提交