1. 11 6月, 2014 1 次提交
  2. 07 6月, 2014 2 次提交
  3. 22 5月, 2014 1 次提交
    • J
      reiserfs: call truncate_setsize under tailpack mutex · 22e7478d
      Jeff Mahoney 提交于
      Prior to commit 0e4f6a79 (Fix reiserfs_file_release()), reiserfs
      truncates serialized on i_mutex. They mostly still do, with the exception
      of reiserfs_file_release. That blocks out other writers via the tailpack
      mutex and the inode openers counter adjusted in reiserfs_file_open.
      
      However, NFS will call reiserfs_setattr without having called ->open, so
      we end up with a race when nfs is calling ->setattr while another
      process is releasing the file. Ultimately, it triggers the
      BUG_ON(inode->i_size != new_file_size) check in maybe_indirect_to_direct.
      
      The solution is to pull the lock into reiserfs_setattr to encompass the
      truncate_setsize call as well.
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      22e7478d
  4. 15 5月, 2014 1 次提交
  5. 13 5月, 2014 3 次提交
  6. 08 5月, 2014 14 次提交
  7. 07 5月, 2014 12 次提交
  8. 04 4月, 2014 3 次提交
  9. 03 4月, 2014 1 次提交
    • J
      reiserfs: fix race in readdir · 01d88857
      Jeff Mahoney 提交于
      jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2)
      
      The -ENOENT is due to readdir calling dir_emit on the same entry twice.
      
      If the dir_emit callback sleeps and the tree is changed underneath us,
      we won't be able to trust deh_offset(deh) anymore. We need to save
      next_pos before we might sleep so we can find the next entry.
      
      CC: stable@vger.kernel.org
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      01d88857
  10. 13 3月, 2014 1 次提交
    • T
      fs: push sync_filesystem() down to the file system's remount_fs() · 02b9984d
      Theodore Ts'o 提交于
      Previously, the no-op "mount -o mount /dev/xxx" operation when the
      file system is already mounted read-write causes an implied,
      unconditional syncfs().  This seems pretty stupid, and it's certainly
      documented or guaraunteed to do this, nor is it particularly useful,
      except in the case where the file system was mounted rw and is getting
      remounted read-only.
      
      However, it's possible that there might be some file systems that are
      actually depending on this behavior.  In most file systems, it's
      probably fine to only call sync_filesystem() when transitioning from
      read-write to read-only, and there are some file systems where this is
      not needed at all (for example, for a pseudo-filesystem or something
      like romfs).
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: Jan Kara <jack@suse.cz>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Anders Larsen <al@alarsen.net>
      Cc: Phillip Lougher <phillip@squashfs.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: xfs@oss.sgi.com
      Cc: linux-btrfs@vger.kernel.org
      Cc: linux-cifs@vger.kernel.org
      Cc: samba-technical@lists.samba.org
      Cc: codalist@coda.cs.cmu.edu
      Cc: linux-ext4@vger.kernel.org
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: fuse-devel@lists.sourceforge.net
      Cc: cluster-devel@redhat.com
      Cc: linux-mtd@lists.infradead.org
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: linux-nfs@vger.kernel.org
      Cc: linux-nilfs@vger.kernel.org
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: ocfs2-devel@oss.oracle.com
      Cc: reiserfs-devel@vger.kernel.org
      02b9984d
  11. 18 2月, 2014 1 次提交
    • D
      reiserfs: fix utterly brain-damaged indentation. · 416e2abd
      Dave Jones 提交于
      This has been this way for years, and every time I stumble across it I
      lose my lunch.  After coming across it for the nth time in the Coverity
      results, I had to overcome the bystander effect and do something about
      it.
      
      This ignores the 79 column limit in favor of making it look like C
      instead of gibberish.
      
      The correct thing to do here would be to lose some of the indentation by
      breaking this function up into several smaller ones.  I might do that at
      some point if I have the stomach to look at this again.
      
      (Also some of those overlong ternary operations would likely be more
      readable as regular if's)
      Signed-off-by: NDave Jones <davej@fedoraproject.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      416e2abd