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, for-linus has been updated
5a5881c xfs: add lots of attribute trace points
d97d32e xfs: Fix oops on IO error during xlog_recover_process_iunlinks()
a66d636 xfs: fix fstrim offset calculations
3948659 xfs: Account log unmount transaction correctly
5132ba8 xfs: don't cache inodes read through bulkstat
f616137 xfs: trace xfs_name strings correctly
c999a22 xfs: introduce an allocation workqueue
1a1d772 xfs: Fix open flag handling in open_by_handle code
5575acc xfs: fix deadlock in xfs_rtfree_extent
1c2ccc6 fs: xfs: fix section mismatch in linux-next
from f074211f6041305b645669464343d504f4e6a290 (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 5a5881cdeec2c019b5c9a307800218ee029f7f61
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Thu Mar 22 05:15:13 2012 +0000
xfs: add lots of attribute trace points
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit d97d32edcd732110758799ae60af725e5110b3dc
Author: Jan Kara <jack@xxxxxxx>
Date: Thu Mar 15 09:34:02 2012 +0000
xfs: Fix oops on IO error during xlog_recover_process_iunlinks()
When an IO error happens during inode deletion run from
xlog_recover_process_iunlinks() filesystem gets shutdown. Thus any subsequent
attempt to read buffers fails. Code in xlog_recover_process_iunlinks() does not
count with the fact that read of a buffer which was read a while ago can
really fail which results in the oops on
agi = XFS_BUF_TO_AGI(agibp);
Fix the problem by cleaning up the buffer handling in
xlog_recover_process_iunlinks() as suggested by Dave Chinner. We release buffer
lock but keep buffer reference to AG buffer. That is enough for buffer to stay
pinned in memory and we don't have to call xfs_read_agi() all the time.
CC: stable@xxxxxxxxxx
Signed-off-by: Jan Kara <jack@xxxxxxx>
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit a66d636385d621e98a915233250356c394a437de
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Thu Mar 22 05:15:12 2012 +0000
xfs: fix fstrim offset calculations
xfs_ioc_fstrim() doesn't treat the incoming offset and length
correctly. It treats them as a filesystem block address, rather than
a disk address. This is wrong because the range passed in is a
linear representation, while the filesystem block address notation
is a sparse representation. Hence we cannot convert the range direct
to filesystem block units and then use that for calculating the
range to trim.
While this sounds dangerous, the problem is limited to calculating
what AGs need to be trimmed. The code that calcuates the actual
ranges to trim gets the right result (i.e. only ever discards free
space), even though it uses the wrong ranges to limit what is
trimmed. Hence this is not a bug that endangers user data.
Fix this by treating the range as a disk address range and use the
appropriate functions to convert the range into the desired formats
for calculations.
Further, fix the first free extent lookup (the longest) to actually
find the largest free extent. Currently this lookup uses a <=
lookup, which results in finding the extent to the left of the
largest because we can never get an exact match on the largest
extent. This is due to the fact that while we know it's size, we
don't know it's location and so the exact match fails and we move
one record to the left to get the next largest extent. Instead, use
a >= search so that the lookup returns the largest extent regardless
of the fact we don't get an exact match on it.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 3948659e30808fbaa7673bbe89de2ae9769e20a7
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Thu Mar 22 05:15:11 2012 +0000
xfs: Account log unmount transaction correctly
There have been a few reports of this warning appearing recently:
XFS (dm-4): xlog_space_left: head behind tail
tail_cycle = 129, tail_bytes = 20163072
GH cycle = 129, GH bytes = 20162880
The common cause appears to be lots of freeze and unfreeze cycles,
and the output from the warnings indicates that we are leaking
around 8 bytes of log space per freeze/unfreeze cycle.
When we freeze the filesystem, we write an unmount record and that
uses xlog_write directly - a special type of transaction,
effectively. What it doesn't do, however, is correctly account for
the log space it uses. The unmount record writes an 8 byte structure
with a special magic number into the log, and the space this
consumes is not accounted for in the log ticket tracking the
operation. Hence we leak 8 bytes every unmount record that is
written.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 5132ba8f2b7705fb6b06fa6ad3d009233c816b67
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Thu Mar 22 05:15:10 2012 +0000
xfs: don't cache inodes read through bulkstat
When we read inodes via bulkstat, we generally only read them once
and then throw them away - they never get used again. If we retain
them in cache, then it simply causes the working set of inodes and
other cached items to be reclaimed just so the inode cache can grow.
Avoid this problem by marking inodes read by bulkstat not to be
cached and check this flag in .drop_inode to determine whether the
inode should be added to the VFS LRU or not. If the inode lookup
hits an already cached inode, then don't set the flag. If the inode
lookup hits an inode marked with no cache flag, remove the flag and
allow it to be cached once the current reference goes away.
Inodes marked as not cached will get cleaned up by the background
inode reclaim or via memory pressure, so they will still generate
some short term cache pressure. They will, however, be reclaimed
much sooner and in preference to cache hot inodes.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit f616137519feb17b849894fcbe634a021d3fa7db
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue Feb 28 11:01:40 2012 +0000
xfs: trace xfs_name strings correctly
Strings store in an xfs_name structure are often not NUL terminated,
print them using the correct printf specifiers that make use of the
string length store in the xfs_name structure.
Reported-by: Brian Candler <B.Candler@xxxxxxxxx>
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit c999a223c2f0d31c64ef7379814cea1378b2b800
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Thu Mar 22 05:15:07 2012 +0000
xfs: introduce an allocation workqueue
We currently have significant issues with the amount of stack that
allocation in XFS uses, especially in the writeback path. We can
easily consume 4k of stack between mapping the page, manipulating
the bmap btree and allocating blocks from the free list. Not to
mention btree block readahead and other functionality that issues IO
in the allocation path.
As a result, we can no longer fit allocation in the writeback path
in the stack space provided on x86_64. To alleviate this problem,
introduce an allocation workqueue and move all allocations to a
seperate context. This can be easily added as an interposing layer
into xfs_alloc_vextent(), which takes a single argument structure
and does not return until the allocation is complete or has failed.
To do this, add a work structure and a completion to the allocation
args structure. This allows xfs_alloc_vextent to queue the args onto
the workqueue and wait for it to be completed by the worker. This
can be done completely transparently to the caller.
The worker function needs to ensure that it sets and clears the
PF_TRANS flag appropriately as it is being run in an active
transaction context. Work can also be queued in a memory reclaim
context, so a rescuer is needed for the workqueue.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 1a1d772433d42aaff7315b3468fef5951604f5c6
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Thu Mar 22 05:15:06 2012 +0000
xfs: Fix open flag handling in open_by_handle code
Sparse identified some unsafe handling of open flags in the xfs open
by handle ioctl code. Update the code to use the correct access
macros to ensure that we handle the open flags correctly.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 5575acc7807595687288b3bbac15103f2a5462e1
Author: Kamal Dasu <kdasu.kdev@xxxxxxxxx>
Date: Thu Feb 23 00:41:39 2012 +0000
xfs: fix deadlock in xfs_rtfree_extent
To fix the deadlock caused by repeatedly calling xfs_rtfree_extent
- removed xfs_ilock() and xfs_trans_ijoin() from xfs_rtfree_extent(),
instead added asserts that the inode is locked and has an inode_item
attached to it.
- in xfs_bunmapi() when dealing with an inode with the rt flag
call xfs_ilock() and xfs_trans_ijoin() so that the
reference count is bumped on the inode and attached it to the
transaction before calling into xfs_bmap_del_extent, similar to
what we do in xfs_bmap_rtalloc.
Signed-off-by: Kamal Dasu <kdasu.kdev@xxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 1c2ccc66bcef992bec7bad6d52cade66d632d7fb
Author: Gerard Snitselaar <dev@xxxxxxxxxxxxxx>
Date: Fri Mar 16 18:36:18 2012 +0000
fs: xfs: fix section mismatch in linux-next
xfs_qm_exit() is called in init_xfs_fs().
Signed-off-by: Gerard Snitselaar <dev@xxxxxxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/xfs_alloc.c | 36 ++++++++++++++++++++-
fs/xfs/xfs_alloc.h | 12 +++++++
fs/xfs/xfs_attr.c | 16 +++++++++
fs/xfs/xfs_attr_leaf.c | 40 +++++++++++++++++++++--
fs/xfs/xfs_bmap.c | 9 +++++
fs/xfs/xfs_da_btree.c | 32 +++++++++++++++++++
fs/xfs/xfs_discard.c | 61 ++++++++++++++++++++++-------------
fs/xfs/xfs_dquot.c | 2 +-
fs/xfs/xfs_iget.c | 8 +++-
fs/xfs/xfs_inode.h | 4 ++-
fs/xfs/xfs_ioctl.c | 14 +++-----
fs/xfs/xfs_itable.c | 3 +-
fs/xfs/xfs_log.c | 3 +-
fs/xfs/xfs_log_recover.c | 33 ++++++-------------
fs/xfs/xfs_rtalloc.c | 9 ++---
fs/xfs/xfs_super.c | 33 +++++++++++++++++++
fs/xfs/xfs_trace.h | 78 +++++++++++++++++++++++++++++++++++++++++++---
17 files changed, 317 insertions(+), 76 deletions(-)
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
