1. 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
  2. 22 10月, 2012 1 次提交
  3. 24 9月, 2012 1 次提交
  4. 23 7月, 2012 1 次提交
  5. 01 7月, 2012 1 次提交
  6. 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
  7. 16 5月, 2012 1 次提交
  8. 30 4月, 2012 4 次提交
  9. 20 3月, 2012 2 次提交
  10. 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
  11. 07 2月, 2012 1 次提交
  12. 04 1月, 2012 1 次提交
  13. 29 12月, 2011 2 次提交
  14. 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
  15. 02 11月, 2011 1 次提交
  16. 01 11月, 2011 1 次提交
  17. 29 10月, 2011 1 次提交
  18. 18 10月, 2011 1 次提交
  19. 09 10月, 2011 1 次提交
  20. 10 9月, 2011 5 次提交
  21. 01 8月, 2011 1 次提交
  22. 22 3月, 2011 1 次提交
  23. 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
  24. 22 2月, 2011 1 次提交
  25. 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
  26. 11 1月, 2011 1 次提交
  27. 28 10月, 2010 4 次提交
    • T
      ext4: rename mark_bitmap_end() to ext4_mark_bitmap_end() · 61d08673
      Theodore Ts'o 提交于
      Fix a namespace leak from fs/ext4
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      
      61d08673
    • T
      ext4: make various ext4 functions be static · 1f109d5a
      Theodore Ts'o 提交于
      These functions have no need to be exported beyond file context.
      
      No functions needed to be moved for this commit; just some function
      declarations changed to be static and removed from header files.
      
      (A similar patch was submitted by Eric Sandeen, but I wanted to handle
      code movement in separate patches to make sure code changes didn't
      accidentally get dropped.)
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      1f109d5a
    • L
      ext4: add interface to advertise ext4 features in sysfs · 857ac889
      Lukas Czerner 提交于
      User-space should have the opportunity to check what features doest ext4
      support in each particular copy. This adds easy interface by creating new
      "features" directory in sys/fs/ext4/. In that directory files
      advertising feature names can be created.
      
      Add lazy_itable_init to the feature list.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      857ac889
    • L
      ext4: add support for lazy inode table initialization · bfff6873
      Lukas Czerner 提交于
      When the lazy_itable_init extended option is passed to mke2fs, it
      considerably speeds up filesystem creation because inode tables are
      not zeroed out.  The fact that parts of the inode table are
      uninitialized is not a problem so long as the block group descriptors,
      which contain information regarding how much of the inode table has
      been initialized, has not been corrupted However, if the block group
      checksums are not valid, e2fsck must scan the entire inode table, and
      the the old, uninitialized data could potentially cause e2fsck to
      report false problems.
      
      Hence, it is important for the inode tables to be initialized as soon
      as possble.  This commit adds this feature so that mke2fs can safely
      use the lazy inode table initialization feature to speed up formatting
      file systems.
      
      This is done via a new new kernel thread called ext4lazyinit, which is
      created on demand and destroyed, when it is no longer needed.  There
      is only one thread for all ext4 filesystems in the system. When the
      first filesystem with inititable mount option is mounted, ext4lazyinit
      thread is created, then the filesystem can register its request in the
      request list.
      
      This thread then walks through the list of requests picking up
      scheduled requests and invoking ext4_init_inode_table(). Next schedule
      time for the request is computed by multiplying the time it took to
      zero out last inode table with wait multiplier, which can be set with
      the (init_itable=n) mount option (default is 10).  We are doing
      this so we do not take the whole I/O bandwidth. When the thread is no
      longer necessary (request list is empty) it frees the appropriate
      structures and exits (and can be created later later by another
      filesystem).
      
      We do not disturb regular inode allocations in any way, it just do not
      care whether the inode table is, or is not zeroed. But when zeroing, we
      have to skip used inodes, obviously. Also we should prevent new inode
      allocations from the group, while zeroing is on the way. For that we
      take write alloc_sem lock in ext4_init_inode_table() and read alloc_sem
      in the ext4_claim_inode, so when we are unlucky and allocator hits the
      group which is currently being zeroed, it just has to wait.
      
      This can be suppresed using the mount option no_init_itable.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      bfff6873