xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, master, updated. v2.6.30-rc4-

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.30-rc4-12986-g943c7bf
From: xfs@xxxxxxxxxxx
Date: Thu, 5 Nov 2009 21:33:13 -0600
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, master has been updated
  943c7bf xfs: cleanup data end I/O handlers
  c4d388b xfs: use WRITE_SYNC_PLUG for synchronous writeout
  a319636 xfs: reset the i_iolock lock class in the reclaim path
  ec92487 xfs: I/O completion handlers must use NOFS allocations
  74695bf xfs: fix mmap_sem/iolock inversion in xfs_free_eofblocks
  e4b9f7d xfs: simplify inode teardown
      from  fd683eac8259109c468e643e323c2b6aa989bd1a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 943c7bf944d496529dcc41ad602b120252ac91bc
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Fri Oct 30 09:11:47 2009 +0000

    xfs: cleanup data end I/O handlers
    
    Currently we have different end I/O handlers for read vs the different
    types of write I/O.  But they are all very similar so we could just
    use one with a few conditionals and reduce code size a lot.
    
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Reviewed-by: Alex Elder <aelder@xxxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

commit c4d388bbbb27f4fbb5a71eaaa8804db1ad7fd688
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Fri Oct 30 09:09:15 2009 +0000

    xfs: use WRITE_SYNC_PLUG for synchronous writeout
    
    The VM and I/O schedulers now expect us to use WRITE_SYNC_PLUG for
    synchronous writeout.  Right now I can't see any changes in performance
    numbers with this, but we're getting some beating for not using it,
    and the knowledge definitely could help the block code to make better
    decisions.
    
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Reviewed-by: Alex Elder <aelder@xxxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

commit a319636ee28e9e8f2375ba693d446880e6de9bb0
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Mon Oct 19 04:05:26 2009 +0000

    xfs: reset the i_iolock lock class in the reclaim path
    
    The iolock is used for protecting reads, writes and block truncates
    against each other.  We have two classes of callers, the first one is
    induced by a file operation and requires a reference to the inode be
    held and not dropped after the operation is done:
    
     - xfs_vm_vmap, xfs_vn_fallocate, xfs_read, xfs_write, xfs_splice_read,
       xfs_splice_write and xfs_setattr are all implementations of VFS
       methods that require a live inode
     - xfs_getbmap and xfs_swap_extents are ioctl subcommand for which the
       same is true
     - xfs_truncate_file is only called on quota inodes just returned from
       xfs_iget
     - xfs_sync_inode_data does the lock just after an igrab()
     - xfs_filestream_associate and xfs_filestream_new_ag take the iolock
       on the parent inode of an inode which by VFS rules must be referenced
    
    And we have various calls to truncate blocks past EOF or the whole
    file when dropping the last reference to an inode.  Unfortunately
    lockdep complains when we do memory allocations that can recurse into
    the filesystem in the first class because the second class happens to
    take the same lock.  To avoid this re-init the iolock in the beginning
    of xfs_fs_clear_inode to get a new lock class.
    
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Reviewed-by: Alex Elder <aelder@xxxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

commit ec92487ac99dff821a05ad9fe8dc7efcc36252ae
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Mon Oct 19 04:00:03 2009 +0000

    xfs: I/O completion handlers must use NOFS allocations
    
    When completing I/O requests we must not allow the memory allocator to
    recurse into the filesystem, as we might deadlock on waiting for the
    I/O completion otherwise.  The only thing currently allocating normal
    GFP_KERNEL memory is the allocation of the transaction structure for
    the unwritten extent conversion.  Add a memflags argument to
    _xfs_trans_alloc to allow controlling the allocator behaviour.
    
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Reported-by: Thomas Neumann <tneumann@xxxxxxxxxxxxxxxxxxxxx>
    Tested-by: Thomas Neumann <tneumann@xxxxxxxxxxxxxxxxxxxxx>
    Reviewed-by: Alex Elder <aelder@xxxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

commit 74695bf50ee5d3cd85e57fe4aa241b6b95b08fbb
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Mon Oct 19 04:03:46 2009 +0000

    xfs: fix mmap_sem/iolock inversion in xfs_free_eofblocks
    
    When xfs_free_eofblocks is called from ->release the VM might already
    hold the mmap_sem, but in the write path we take the iolock before
    taking the mmap_sem in the generic write code.
    
    Switch xfs_free_eofblocks to only trylock the iolock if called from
    ->release and skip trimming the prellocated blocks in that case.
    We'll still free them later on the final iput.
    
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Reviewed-by: Alex Elder <aelder@xxxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

commit e4b9f7d64a951ab2cddf387ae16e68c3f00fc7ee
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Tue Sep 29 13:48:56 2009 +0000

    xfs: simplify inode teardown
    
    Currently the reclaim code for the case where we don't reclaim the
    final reclaim is overly complicated.  We know that the inode is clean
    but instead of just directly reclaiming the clean inode we go through
    the whole process of marking the inode reclaimable just to directly
    reclaim it from the calling context.  Besides being overly complicated
    this introduces a race where iget could recycle an inode between
    marked reclaimable and actually being reclaimed leading to panics.
    
    This patch gets rid of the existing reclaim path, and replaces it with
    a simple call to xfs_ireclaim if the inode was clean.  While we're at
    it we also use the slightly more lax xfs_inode_clean check we'd use
    later to determine if we need to flush the inode here.
    
    Finally get rid of xfs_reclaim function and place the remaining small
    bits of reclaim code directly into xfs_fs_destroy_inode.
    
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Reported-by: Patrick Schreurs <patrick@xxxxxxxxxxxxxxxx>
    Reported-by: Tommy van Leeuwen <tommy@xxxxxxxxxxxxxxxx>
    Tested-by: Patrick Schreurs <patrick@xxxxxxxxxxxxxxxx>
    Reviewed-by: Alex Elder <aelder@xxxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/linux-2.6/xfs_aops.c  |  112 +++++++++++++----------------------------
 fs/xfs/linux-2.6/xfs_super.c |   49 ++++++++++++++++--
 fs/xfs/linux-2.6/xfs_sync.c  |   15 ++----
 fs/xfs/linux-2.6/xfs_sync.h  |    1 -
 fs/xfs/xfs_fsops.c           |    2 +-
 fs/xfs/xfs_iget.c            |    3 +
 fs/xfs/xfs_iomap.c           |    9 +++-
 fs/xfs/xfs_mount.c           |    2 +-
 fs/xfs/xfs_rw.h              |    7 ---
 fs/xfs/xfs_trans.c           |    7 ++-
 fs/xfs/xfs_trans.h           |    2 +-
 fs/xfs/xfs_vnodeops.c        |   74 ++++++++++------------------
 fs/xfs/xfs_vnodeops.h        |    1 -
 13 files changed, 128 insertions(+), 156 deletions(-)


hooks/post-receive
-- 
XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, master, updated. v2.6.30-rc4-12986-g943c7bf, xfs <=