1. 03 4月, 2009 3 次提交
  2. 26 3月, 2009 1 次提交
  3. 17 1月, 2009 1 次提交
  4. 09 1月, 2009 1 次提交
  5. 05 1月, 2009 1 次提交
    • N
      fs: symlink write_begin allocation context fix · 54566b2c
      Nick Piggin 提交于
      With the write_begin/write_end aops, page_symlink was broken because it
      could no longer pass a GFP_NOFS type mask into the point where the
      allocations happened.  They are done in write_begin, which would always
      assume that the filesystem can be entered from reclaim.  This bug could
      cause filesystem deadlocks.
      
      The funny thing with having a gfp_t mask there is that it doesn't really
      allow the caller to arbitrarily tinker with the context in which it can be
      called.  It couldn't ever be GFP_ATOMIC, for example, because it needs to
      take the page lock.  The only thing any callers care about is __GFP_FS
      anyway, so turn that into a single flag.
      
      Add a new flag for write_begin, AOP_FLAG_NOFS.  Filesystems can now act on
      this flag in their write_begin function.  Change __grab_cache_page to
      accept a nofs argument as well, to honour that flag (while we're there,
      change the name to grab_cache_page_write_begin which is more instructive
      and does away with random leading underscores).
      
      This is really a more flexible way to go in the end anyway -- if a
      filesystem happens to want any extra allocations aside from the pagecache
      ones in ints write_begin function, it may now use GFP_KERNEL (rather than
      GFP_NOFS) for common case allocations (eg.  ocfs2_alloc_write_ctxt, for a
      random example).
      
      [kosaki.motohiro@jp.fujitsu.com: fix ubifs]
      [kosaki.motohiro@jp.fujitsu.com: fix fuse]
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Reviewed-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: <stable@kernel.org>		[2.6.28.x]
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      [ Cleaned up the calling convention: just pass in the AOP flags
        untouched to the grab_cache_page_write_begin() function.  That
        just simplifies everybody, and may even allow future expansion of the
        logic.   - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      54566b2c
  6. 01 1月, 2009 1 次提交
  7. 07 12月, 2008 1 次提交
  8. 29 10月, 2008 1 次提交
    • T
      ext3: Add support for non-native signed/unsigned htree hash algorithms · 5e1f8c9e
      Theodore Ts'o 提交于
      The original ext3 hash algorithms assumed that variables of type char
      were signed, as God and K&R intended.  Unfortunately, this assumption
      is not true on some architectures.  Userspace support for marking
      filesystems with non-native signed/unsigned chars was added two years
      ago, but the kernel-side support was never added (until now).
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: akpm@linux-foundation.org
      Cc: linux-kernel@vger.kernel.org
      5e1f8c9e
  9. 23 10月, 2008 2 次提交
  10. 26 7月, 2008 2 次提交
  11. 28 4月, 2008 3 次提交
  12. 08 2月, 2008 1 次提交
  13. 07 2月, 2008 1 次提交
  14. 15 11月, 2007 1 次提交
  15. 17 10月, 2007 1 次提交
  16. 20 9月, 2007 2 次提交
  17. 17 7月, 2007 1 次提交
    • V
      ext3/ext4: orphan list corruption due bad inode · a6c15c2b
      Vasily Averin 提交于
      After ext3 orphan list check has been added into ext3_destroy_inode()
      (please see my previous patch) the following situation has been detected:
      
       EXT3-fs warning (device sda6): ext3_unlink: Deleting nonexistent file (37901290), 0
       Inode 00000101a15b7840: orphan list check failed!
       00000773 6f665f00 74616d72 00000573 65725f00 06737270 66000000 616d726f
      ...
       Call Trace: [<ffffffff80211ea9>] ext3_destroy_inode+0x79/0x90
        [<ffffffff801a2b16>] sys_unlink+0x126/0x1a0
        [<ffffffff80111479>] error_exit+0x0/0x81
        [<ffffffff80110aba>] system_call+0x7e/0x83
      
      First messages said that unlinked inode has i_nlink=0, then ext3_unlink()
      adds this inode into orphan list.
      
      Second message means that this inode has not been removed from orphan list.
       Inode dump has showed that i_fop = &bad_file_ops and it can be set in
      make_bad_inode() only.  Then I've found that ext3_read_inode() can call
      make_bad_inode() without any error/warning messages, for example in the
      following case:
      
      ...
              if (inode->i_nlink == 0) {
                      if (inode->i_mode == 0 ||
                          !(EXT3_SB(inode->i_sb)->s_mount_state & EXT3_ORPHAN_FS)) {
                              /* this inode is deleted */
                              brelse (bh);
                              goto bad_inode;
      ...
      
      Bad inode can live some time, ext3_unlink can add it to orphan list, but
      ext3_delete_inode() do not deleted this inode from orphan list.  As result
      we can have orphan list corruption detected in ext3_destroy_inode().
      
      However it is not clear for me how to fix this issue correctly.
      
      As far as i see is_bad_inode() is called after iget() in all places
      excluding ext3_lookup() and ext3_get_parent().  I believe it makes sense to
      add bad inode check to these functions too and call iput if bad inode
      detected.
      Signed-off-by: NVasily Averin <vvs@sw.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6c15c2b
  18. 09 5月, 2007 2 次提交
  19. 13 2月, 2007 1 次提交
  20. 12 2月, 2007 2 次提交
  21. 09 12月, 2006 1 次提交
  22. 08 12月, 2006 1 次提交
    • E
      [PATCH] handle ext3 directory corruption better · 40b85134
      Eric Sandeen 提交于
      I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
      http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
      
      Basically it makes a filesystem, splats some random bits over it, then
      tries to mount it and do some simple filesystem actions.
      
      At best, the filesystem catches the corruption gracefully.  At worst,
      things spin out of control.
      
      As you might guess, we found a couple places in ext3 where things spin out
      of control :)
      
      First, we had a corrupted directory that was never checked for
      consistency...  it was corrupt, and pointed to another bad "entry" of
      length 0.  The for() loop looped forever, since the length of
      ext3_next_entry(de) was 0, and we kept looking at the same pointer over and
      over and over and over...  I modeled this check and subsequent action on
      what is done for other directory types in ext3_readdir...
      
      (adding this check adds some computational expense; I am testing a followup
      patch to reduce the number of times we check and re-check these directory
      entries, in all cases.  Thanks for the idea, Andreas).
      
      Next we had a root directory inode which had a corrupted size, claimed to
      be > 200M on a 4M filesystem.  There was only really 1 block in the
      directory, but because the size was so large, readdir kept coming back for
      more, spewing thousands of printk's along the way.
      
      Per Andreas' suggestion, if we're in this read error condition and we're
      trying to read an offset which is greater than i_blocks worth of bytes,
      stop trying, and break out of the loop.
      
      With these two changes fsfuzz test survives quite well on ext3.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      40b85134
  23. 01 10月, 2006 4 次提交
  24. 27 9月, 2006 3 次提交
  25. 01 8月, 2006 1 次提交
    • N
      [PATCH] ext3: avoid triggering ext3_error on bad NFS file handle · 2ccb48eb
      Neil Brown 提交于
      The inode number out of an NFS file handle gets passed eventually to
      ext3_get_inode_block() without any checking.  If ext3_get_inode_block()
      allows it to trigger an error, then bad filehandles can have unpleasant
      effect - ext3_error() will usually cause a forced read-only remount, or a
      panic if `errors=panic' was used.
      
      So remove the call to ext3_error there and put a matching check in
      ext3/namei.c where inode numbers are read off storage.
      
      [akpm@osdl.org: fix off-by-one error]
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: <stable@kernel.org>
      Cc: "Stephen C. Tweedie" <sct@redhat.com>
      Cc: Eric Sandeen <esandeen@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2ccb48eb
  26. 26 6月, 2006 1 次提交