Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 10月, 2015 3 次提交
  3. 24 7月, 2015 1 次提交
  5. 01 6月, 2015 1 次提交
    • T
      ext4 crypto: encrypt tmpfile located in encryption protected directory · e709e9df
      由 Theodore Ts'o 提交于 
      Factor out calls to ext4_inherit_context() and move them to
__ext4_new_inode(); this fixes a problem where ext4_tmpfile() wasn't
calling calling ext4_inherit_context(), so the temporary file wasn't
getting protected.  Since the blocks for the tmpfile could end up on
disk, they really should be protected if the tmpfile is created within
the context of an encrypted directory.
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      e709e9df
  7. 19 5月, 2015 1 次提交
    • T
      ext4: clean up superblock encryption mode fields · f5aed2c2
      由 Theodore Ts'o 提交于 
      The superblock fields s_file_encryption_mode and s_dir_encryption_mode
are vestigal, so remove them as a cleanup.  While we're at it, allow
file systems with both encryption and inline_data enabled at the same
time to work correctly.  We can't have encrypted inodes with inline
data, but there's no reason to prohibit unencrypted inodes from using
the inline data feature.
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      f5aed2c2
  9. 16 4月, 2015 2 次提交
  11. 12 4月, 2015 2 次提交
  13. 03 4月, 2015 1 次提交
  15. 30 10月, 2014 1 次提交
  17. 13 10月, 2014 1 次提交
  19. 13 7月, 2014 1 次提交
  21. 06 7月, 2014 1 次提交
    • T
      ext4: fix unjournalled bg descriptor while initializing inode bitmap · 61c219f5
      由 Theodore Ts'o 提交于 
      The first time that we allocate from an uninitialized inode allocation
bitmap, if the block allocation bitmap is also uninitalized, we need
to get write access to the block group descriptor before we start
modifying the block group descriptor flags and updating the free block
count, etc.  Otherwise, there is the potential of a bad journal
checksum (if journal checksums are enabled), and of the file system
becoming inconsistent if we crash at exactly the wrong time.
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
      61c219f5
  23. 26 6月, 2014 1 次提交
  25. 08 11月, 2013 1 次提交
  27. 29 8月, 2013 2 次提交
  29. 17 8月, 2013 1 次提交
    • T
      ext4: avoid reusing recently deleted inodes in no journal mode · 19883bd9
      由 Theodore Ts'o 提交于 
      In no journal mode, if an inode has recently been deleted, we
shouldn't reuse it right away.  Otherwise it's possible, after an
unclean shutdown, to hit a situation where a recently deleted inode
gets reused for some other purpose before the inode table block has
been written to disk.  However, if the directory entry has been
updated, then the directory entry will be pointing at the old inode
contents.

E2fsck will make sure the file system is consistent after the
unclean shutdown.  However, if the recently deleted inode is a
character mode device, or an inode with the immutable bit set, even
after the file system has been fixed up by e2fsck, it can be
possible for a *.pyc file to be pointing at a character mode
device, and when python tries to open the *.pyc file, Hilarity
Ensues.  We could change all of userspace to be very suspicious
about stat'ing files before opening them, and clearing the
immutable flag if necessary --- or we can just avoid reusing an
inode number if it has been recently deleted.

Google-Bug-Id: 10017573
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      19883bd9
  31. 27 7月, 2013 1 次提交
    • T
      ext4: make sure group number is bumped after a inode allocation race · a34eb503
      由 Theodore Ts'o 提交于 
      When we try to allocate an inode, and there is a race between two
CPU's trying to grab the same inode, _and_ this inode is the last free
inode in the block group, make sure the group number is bumped before
we continue searching the rest of the block groups.  Otherwise, we end
up searching the current block group twice, and we end up skipping
searching the last block group.  So in the unlikely situation where
almost all of the inodes are allocated, it's possible that we will
return ENOSPC even though there might be free inodes in that last
block group.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
      a34eb503
  33. 05 6月, 2013 1 次提交
  35. 21 4月, 2013 1 次提交
  37. 20 4月, 2013 1 次提交
    • J
      ext4: move quota initialization out of inode allocation transaction · eb9cc7e1
      由 Jan Kara 提交于 
      Inode allocation transaction is pretty heavy (246 credits with quotas
and extents before previous patch, still around 200 after it).  This is
mostly due to credits required for allocation of quota structures
(credits there are heavily overestimated but it's difficult to make
better estimates if we don't want to wire non-trivial assumptions about
quota format into filesystem).

So move quota initialization out of allocation transaction. That way
transaction for quota structure allocation will be started only if we
need to look up quota structure on disk (rare) and furthermore it will
be started for each quota type separately, not for all of them at once.
This reduces maximum transaction size to 34 is most cases and to 73 in
the worst case.

[ Modified by tytso to clean up the cleanup paths for error handling.
  Also use a separate call to ext4_std_error() for each failure so it
  is easier for someone who is debugging a problem in this function to
  determine which function call failed. ]
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      eb9cc7e1
  39. 10 4月, 2013 1 次提交
  41. 12 3月, 2013 1 次提交
  43. 15 2月, 2013 1 次提交
  45. 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
  47. 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
  49. 11 12月, 2012 1 次提交
  51. 30 11月, 2012 1 次提交
  53. 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
  55. 22 10月, 2012 1 次提交
  57. 24 9月, 2012 1 次提交
  59. 23 7月, 2012 1 次提交
  61. 01 7月, 2012 1 次提交
  63. 29 5月, 2012 2 次提交
  65. 16 5月, 2012 1 次提交
  67. 30 4月, 2012 1 次提交