1. 19 9月, 2016 1 次提交
  2. 31 7月, 2016 1 次提交
  3. 06 7月, 2016 1 次提交
    • C
      ext2: fix filesystem deadlock while reading corrupted xattr block · ff0031d8
      Carlos Maiolino 提交于
      This bug can be reproducible with fsfuzzer, although, I couldn't reproduce it
      100% of my tries, it is quite easily reproducible.
      
      During the deletion of an inode, ext2_xattr_delete_inode() does not check if the
      block pointed by EXT2_I(inode)->i_file_acl is a valid data block, this might
      lead to a deadlock, when i_file_acl == 1, and the filesystem block size is 1024.
      
      In that situation, ext2_xattr_delete_inode, will load the superblock's buffer
      head (instead of a valid i_file_acl block), and then lock that buffer head,
      which, ext2_sync_super will also try to lock, making the filesystem deadlock in
      the following stack trace:
      
      root     17180  0.0  0.0 113660   660 pts/0    D+   07:08   0:00 rmdir
      /media/test/dir1
      
      [<ffffffff8125da9f>] __sync_dirty_buffer+0xaf/0x100
      [<ffffffff8125db03>] sync_dirty_buffer+0x13/0x20
      [<ffffffffa03f0d57>] ext2_sync_super+0xb7/0xc0 [ext2]
      [<ffffffffa03f10b9>] ext2_error+0x119/0x130 [ext2]
      [<ffffffffa03e9d93>] ext2_free_blocks+0x83/0x350 [ext2]
      [<ffffffffa03f3d03>] ext2_xattr_delete_inode+0x173/0x190 [ext2]
      [<ffffffffa03ee9e9>] ext2_evict_inode+0xc9/0x130 [ext2]
      [<ffffffff8123fd23>] evict+0xb3/0x180
      [<ffffffff81240008>] iput+0x1b8/0x240
      [<ffffffff8123c4ac>] d_delete+0x11c/0x150
      [<ffffffff8122fa7e>] vfs_rmdir+0xfe/0x120
      [<ffffffff812340ee>] do_rmdir+0x17e/0x1f0
      [<ffffffff81234dd6>] SyS_rmdir+0x16/0x20
      [<ffffffff81838cf2>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      [<ffffffffffffffff>] 0xffffffffffffffff
      
      Fix this by using the same approach ext4 uses to test data blocks validity,
      implementing ext2_data_block_valid.
      
      An another possibility when the superblock is very corrupted, is that i_file_acl
      is 1, block_count is 1 and first_data_block is 0. For such situations, we might
      have i_file_acl pointing to a 'valid' block, but still step over the superblock.
      The approach I used was to also test if the superblock is not in the range
      described by ext2_data_block_valid() arguments
      Signed-off-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      ff0031d8
  4. 23 2月, 2016 2 次提交
  5. 19 10月, 2015 1 次提交
    • R
      ext2: Add locking for DAX faults · 5726b27b
      Ross Zwisler 提交于
      Add locking to ensure that DAX faults are isolated from ext2 operations
      that modify the data blocks allocation for an inode.  This is intended to
      be analogous to the work being done in XFS by Dave Chinner:
      
      http://www.spinics.net/lists/linux-fsdevel/msg90260.html
      
      Compared with XFS the ext2 case is greatly simplified by the fact that ext2
      already allocates and zeros new blocks before they are returned as part of
      ext2_get_block(), so DAX doesn't need to worry about getting unmapped or
      unwritten buffer heads.
      
      This means that the only work we need to do in ext2 is to isolate the DAX
      faults from inode block allocation changes.  I believe this just means that
      we need to isolate the DAX faults from truncate operations.
      
      The newly introduced dax_sem is intended to replicate the protection
      offered by i_mmaplock in XFS.  In addition to truncate the i_mmaplock also
      protects XFS operations like hole punching, fallocate down, extent
      manipulation IOCTLS like xfs_ioc_space() and extent swapping.  Truncate is
      the only one of these operations supported by ext2.
      Signed-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: NJan Kara <jack@suse.com>
      5726b27b
  6. 16 4月, 2015 1 次提交
    • B
      dax: unify ext2/4_{dax,}_file_operations · be64f884
      Boaz Harrosh 提交于
      The original dax patchset split the ext2/4_file_operations because of the
      two NULL splice_read/splice_write in the dax case.
      
      In the vfs if splice_read/splice_write are NULL we then call
      default_splice_read/write.
      
      What we do here is make generic_file_splice_read aware of IS_DAX() so the
      original ext2/4_file_operations can be used as is.
      
      For write it appears that iter_file_splice_write is just fine.  It uses
      the regular f_op->write(file,..) or new_sync_write(file, ...).
      Signed-off-by: NBoaz Harrosh <boaz@plexistor.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Cc: Dave Chinner <dchinner@redhat.com>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      be64f884
  7. 17 2月, 2015 4 次提交
  8. 10 11月, 2014 1 次提交
  9. 16 5月, 2012 1 次提交
  10. 01 4月, 2012 1 次提交
  11. 04 1月, 2012 1 次提交
  12. 01 11月, 2011 1 次提交
  13. 21 7月, 2011 1 次提交
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik 提交于
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
      in fsync to make it less of a painful operation, so push down taking i_mutex and
      the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
      file systems can drop taking the i_mutex altogether it seems, like ext3 and
      ocfs2.  For correctness sake I just pushed everything down in all cases to make
      sure that we keep the current behavior the same for everybody, and then each
      individual fs maintainer can make up their mind about what to do from there.
      Thanks,
      Acked-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  14. 24 3月, 2011 1 次提交
  15. 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
  16. 26 10月, 2010 1 次提交
  17. 10 8月, 2010 2 次提交
  18. 28 5月, 2010 2 次提交
  19. 06 3月, 2010 1 次提交
  20. 16 12月, 2009 1 次提交
    • J
      ext2: report metadata errors during fsync · 48bde86d
      Jan Kara 提交于
      When an IO error happens while writing metadata buffers, we should better
      report it and call ext2_error since the filesystem is probably no longer
      consistent.  Sometimes such IO errors happen while flushing thread does
      background writeback, the buffer gets later evicted from memory, and thus
      the only trace of the error remains as AS_EIO bit set in blockdevice's
      mapping.  So we check this bit in ext2_fsync and report the error although
      we cannot be really sure which buffer we failed to write.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Cc: Chris Mason <chris.mason@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48bde86d
  21. 10 12月, 2009 1 次提交
    • A
      ext2: Unify log messages in ext2 · 2314b07c
      Alexey Fisher 提交于
      make messages produced by ext2 more unified. It should be
      easy to parse.
      
      dmesg before patch:
      [ 4893.684892] reservations ON
      [ 4893.684896] xip option not supported
      [ 4893.684961] EXT2-fs warning: mounting ext3 filesystem as ext2
      [ 4893.684964] EXT2-fs warning: maximal mount count reached, running
      e2fsck is recommended
      [ 4893.684990] EXT II FS: 0.5b, 95/08/09, bs=1024, fs=1024, gc=2,
      bpg=8192, ipg=1280, mo=80010]
      
      dmesg after patch:
      [ 4893.684892] EXT2-fs (loop0): reservations ON
      [ 4893.684896] EXT2-fs (loop0): xip option not supported
      [ 4893.684961] EXT2-fs (loop0): warning: mounting ext3 filesystem as
      ext2
      [ 4893.684964] EXT2-fs (loop0): warning: maximal mount count reached,
      running e2fsck is recommended
      [ 4893.684990] EXT2-fs (loop0): 0.5b, 95/08/09, bs=1024, fs=1024, gc=2,
      bpg=8192, ipg=1280, mo=80010]
      Signed-off-by: NAlexey Fisher <bug-track@fisher-privat.net>
      Reviewed-by: NAndreas Dilger <adilger@sun.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      2314b07c
  22. 24 6月, 2009 1 次提交
  23. 19 6月, 2009 1 次提交
    • J
      ext2: Do not update mtime of a moved directory · 39fe7557
      Jan Kara 提交于
      One of our users is complaining that his backup tool is upset on ext2
      (while it's happy on ext3, xfs, ...) because of the mtime change.
      
      The problem is:
      
          mkdir foo
          mkdir bar
          mkdir foo/a
      
      Now under ext2:
          mv foo/a foo/b
      
      changes mtime of 'foo/a' (foo/b after the move).  That does not really
      make sense and it does not happen under any other filesystem I've seen.
      
      More complicated is:
          mv foo/a bar/a
      
      This changes mtime of foo/a (bar/a after the move) and it makes some
      sense since we had to update parent directory pointer of foo/a.  But
      again, no other filesystem does this.  So after some thoughts I'd vote
      for consistency and change ext2 to behave the same as other filesystems.
      
      Do not update mtime of a moved directory.  Specs don't say anything
      about it (neither that it should, nor that it should not be updated) and
      other common filesystems (ext3, ext4, xfs, reiserfs, fat, ...) don't do
      it.  So let's become more consistent.
      
      Spotted by ronny.pretzsch@dfs.de, initial fix by Jörn Engel.
      
      Reported-by: <ronny.pretzsch@dfs.de>
      Cc: <hare@suse.de>
      Cc: Jörn Engel <joern@logfs.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      39fe7557
  24. 13 6月, 2009 1 次提交
  25. 12 6月, 2009 1 次提交
  26. 23 10月, 2008 1 次提交
  27. 04 10月, 2008 1 次提交
    • J
      generic block based fiemap implementation · 68c9d702
      Josef Bacik 提交于
      Any block based fs (this patch includes ext3) just has to declare its own
      fiemap() function and then call this generic function with its own
      get_block_t. This works well for block based filesystems that will map
      multiple contiguous blocks at one time, but will work for filesystems that
      only map one block at a time, you will just end up with an "extent" for each
      block. One gotcha is this will not play nicely where there is hole+data
      after the EOF. This function will assume its hit the end of the data as soon
      as it hits a hole after the EOF, so if there is any data past that it will
      not pick that up. AFAIK no block based fs does this anyway, but its in the
      comments of the function anyway just in case.
      Signed-off-by: NJosef Bacik <jbacik@redhat.com>
      Signed-off-by: NMark Fasheh <mfasheh@suse.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      68c9d702
  28. 09 2月, 2008 1 次提交
  29. 08 2月, 2008 1 次提交
  30. 07 2月, 2008 1 次提交
  31. 30 11月, 2007 1 次提交
  32. 17 10月, 2007 2 次提交
  33. 09 5月, 2007 1 次提交