1. 01 5月, 2009 1 次提交
    • T
      ext4: Avoid races caused by on-line resizing and SMP memory reordering · 8df9675f
      Theodore Ts'o 提交于
      Ext4's on-line resizing adds a new block group and then, only at the
      last step adjusts s_groups_count.  However, it's possible on SMP
      systems that another CPU could see the updated the s_group_count and
      not see the newly initialized data structures for the just-added block
      group.  For this reason, it's important to insert a SMP read barrier
      after reading s_groups_count and before reading any (for example) the
      new block group descriptors allowed by the increased value of
      s_groups_count.
      
      Unfortunately, we rather blatently violate this locking protocol
      documented in fs/ext4/resize.c.  Fortunately, (1) on-line resizes
      happen relatively rarely, and (2) it seems rare that the filesystem
      code will immediately try to use just-added block group before any
      memory ordering issues resolve themselves.  So apparently problems
      here are relatively hard to hit, since ext3 has been vulnerable to the
      same issue for years with no one apparently complaining.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      8df9675f
  2. 02 5月, 2009 1 次提交
  3. 01 5月, 2009 2 次提交
    • T
      ext4: Fix and simplify s_dirt handling · 7234ab2a
      Theodore Ts'o 提交于
      The s_dirt flag wasn't completely handled correctly, but it didn't
      really matter when journalling was enabled.  It turns out that when
      ext4 runs without a journal, we don't clear s_dirt in places where we
      should have, with the result that the high-level write_super()
      function was writing the superblock when it wasn't necessary.
      
      So we fix this by making ext4_commit_super() clear the s_dirt flag,
      and removing many of the other places where s_dirt is manipulated.
      When journalling is enabled, the s_dirt flag might be left set more
      often, but s_dirt really doesn't matter when journalling is enabled.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      7234ab2a
    • T
      ext4: Simplify ext4_commit_super()'s function signature · e2d67052
      Theodore Ts'o 提交于
      The ext4_commit_super() function took both a struct super_block * and
      a struct ext4_super_block *, but the struct ext4_super_block can be
      derived from the struct super_block.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      e2d67052
  4. 25 4月, 2009 1 次提交
  5. 28 4月, 2009 1 次提交
    • T
      ext4: Fallback to vmalloc if kmalloc can't allocate s_flex_groups array · c5ca7c76
      Theodore Ts'o 提交于
      For very large filesystems, the s_flex_groups array can get quite big.
      For example, a filesystem that can be resized up to 16TB will have
      8192 flex groups (assuming the default flex_bg size of 16), so the
      array is 96k, which is *very* marginal for kmalloc().  On the other
      hand, a 160GB filesystem without the resize_inode feature will only
      require 960 bytes.  So we try to allocate the array first using
      kmalloc(), and if that fails, we'll try to use vmalloc() instead.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      c5ca7c76
  6. 13 5月, 2009 2 次提交
    • A
      ext4: Mark the unwritten buffer_head as mapped during write_begin · 29fa89d0
      Aneesh Kumar K.V 提交于
      Setting BH_Unwritten buffer_heads as BH_Mapped avoids multiple
      (unnecessary) calls to get_block() during the call to the write(2)
      system call.  Setting BH_Unwritten buffer heads as BH_Mapped requires
      that the writepages() functions can handle BH_Unwritten buffer_heads.
      
      After this commit, things work as follows:
      
      ext4_ext_get_block() returns unmapped, unwritten, buffer head when
      called with create = 0 for prealloc space. This makes sure we handle
      the read path and non-delayed allocation case correctly.  Even though
      the buffer head is marked unmapped we have valid b_blocknr and b_bdev
      values in the buffer_head.
      
      ext4_da_get_block_prep() called for block resrevation will now return
      mapped, unwritten, new buffer_head for prealloc space. This avoids
      multiple calls to get_block() for write to same offset. By making such
      buffers as BH_New, we also assure that sub-block zeroing of buffered
      writes happens correctly.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      29fa89d0
    • A
      vfs: Add BUG_ON for delayed and unwritten flags in submit_bh() · 8fb0e342
      Aneesh Kumar K.V 提交于
      The BH_Delay and BH_Unwritten flags should never leak out to
      submit_bh().  So add some BUG_ON() checks to submit_bh so we can get a
      stack trace and determine how and why this might have happened.
      
      (Note that only XFS and ext4 use these buffer head flags, and XFS does
      not use submit_bh().  So this patch should only modify behavior for
      ext4.)
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      8fb0e342
  7. 14 5月, 2009 1 次提交
  8. 02 6月, 2009 3 次提交
  9. 30 5月, 2009 1 次提交
  10. 29 5月, 2009 4 次提交
  11. 28 5月, 2009 3 次提交
  12. 27 5月, 2009 2 次提交
  13. 24 5月, 2009 1 次提交
    • S
      [CIFS] Avoid open on possible directories since Samba now rejects them · 8db14ca1
      Steve French 提交于
      Small change (mostly formatting) to limit lookup based open calls to
      file create only.
      
      After discussion yesteday on samba-technical about the posix lookup
      regression,  and looking at a problem with cifs posix open to one
      particular Samba version, Jeff and JRA realized that Samba server's
      behavior changed in this area (posix open behavior on files vs.
      directories).   To make this behavior consistent, JRA just made a
      fix to Samba server to alter how it handles open of directories (now
      returning the equivalent of EISDIR instead of success). Since we don't
      know at lookup time whether the inode is a directory or file (and
      thus whether posix open will succeed with most current Samba server),
      this change avoids the posix open code on lookup open (just issues
      posix open on creates).    This gets the semantic benefits we want
      (atomicity, posix byte range locks, improved write semantics on newly
      created files) and file create still is fast, and we avoid the problem
      that Jeff noticed yesterday with "openat" (and some open directory
      calls) of non-cached directories to one version of Samba server, and
      will work with future Samba versions (which include the fix jra just
      pushed into Samba server).  I confirmed this approach with jra
      yesterday and with Shirish today.
      
      Posix open is only called (at lookup time) for file create now.
      For opens (rather than creates), because we do not know if it
      is a file or directory yet, and current Samba no longer allows
      us to do posix open on dirs, we could end up wasting an open call
      on what turns out to be a dir. For file opens, we wait to call posix
      open till cifs_open.  It could be added here (lookup) in the future
      but the performance tradeoff of the extra network request when EISDIR
      or EACCES is returned would have to be weighed against the 50%
      reduction in network traffic in the other paths.
      Reviewed-by: NShirish Pargaonkar <shirishp@us.ibm.com>
      Tested-by: NJeff Layton <jlayton@redhat.com>
      CC: Jeremy Allison <jra@samba.org>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      8db14ca1
  14. 22 5月, 2009 2 次提交
  15. 19 5月, 2009 2 次提交
  16. 18 5月, 2009 3 次提交
  17. 15 5月, 2009 9 次提交
  18. 14 5月, 2009 1 次提交