Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 2月, 2013 1 次提交
  3. 10 2月, 2013 1 次提交
    • T
      ext4: start handle at the last possible moment when creating inodes · 1139575a
      由 Theodore Ts'o 提交于 
      In ext4_{create,mknod,mkdir,symlink}(), don't start the journal handle
until the inode has been succesfully allocated.  In order to do this,
we need to start the handle in the ext4_new_inode().  So create a new
variant of this function, ext4_new_inode_start_handle(), so the handle
can be created at the last possible minute, before we need to modify
the inode allocation bitmap block.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      1139575a
  5. 09 2月, 2013 1 次提交
    • T
      ext4: pass context information to jbd2__journal_start() · 9924a92a
      由 Theodore Ts'o 提交于 
      So we can better understand what bits of ext4 are responsible for
long-running jbd2 handles, use jbd2__journal_start() so we can pass
context information for logging purposes.

The recommended way for finding the longer-running handles is:

   T=/sys/kernel/debug/tracing
   EVENT=$T/events/jbd2/jbd2_handle_stats
   echo "interval > 5" > $EVENT/filter
   echo 1 > $EVENT/enable

   ./run-my-fs-benchmark

   cat $T/trace > /tmp/problem-handles

This will list handles that were active for longer than 20ms.  Having
longer-running handles is bad, because a commit started at the wrong
time could stall for those 20+ milliseconds, which could delay an
fsync() or an O_SYNC operation.  Here is an example line from the
trace file describing a handle which lived on for 311 jiffies, or over
1.2 seconds:

postmark-2917  [000] ....   196.435786: jbd2_handle_stats: dev 254,32 
   tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
   dirtied_blocks 0
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      9924a92a
  7. 11 12月, 2012 1 次提交
  9. 30 11月, 2012 1 次提交
  11. 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
  13. 22 10月, 2012 1 次提交
  15. 24 9月, 2012 1 次提交
  17. 23 7月, 2012 1 次提交
  19. 01 7月, 2012 1 次提交
  21. 29 5月, 2012 2 次提交
  23. 16 5月, 2012 1 次提交
  25. 30 4月, 2012 4 次提交
  27. 20 3月, 2012 2 次提交
  29. 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
  31. 07 2月, 2012 1 次提交
  33. 04 1月, 2012 1 次提交
  35. 29 12月, 2011 2 次提交
  37. 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
  39. 02 11月, 2011 1 次提交
  41. 01 11月, 2011 1 次提交
  43. 29 10月, 2011 1 次提交
  45. 18 10月, 2011 1 次提交
  47. 09 10月, 2011 1 次提交
  49. 10 9月, 2011 5 次提交
  51. 01 8月, 2011 1 次提交
  53. 22 3月, 2011 1 次提交
  55. 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
  57. 22 2月, 2011 1 次提交
  59. 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