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
7ae0778 xfs: remote attribute lookups require the value length
cf257ab xfs: xfs_attr_shortform_allfit() does not handle attr3 format.
7ced60c xfs: xfs_da3_node_read_verify() doesn't handle XFS_ATTR3_LEAF_MAGIC
b17cb36 xfs: fix missing KM_NOFS tags to keep lockdep happy
509e708 xfs: Don't reference the EFI after it is freed
7031d0e xfs: fix rounding in xfs_free_file_space
480d746 xfs: fix sub-page blocksize data integrity writes
8769e07 Merge tag 'for-linus-v3.10-rc1-2' of git://oss.sgi.com/xfs/xfs
a27bb33 aio: don't include aio.h in sched.h
c8d8566 Merge tag 'for-linus-v3.10-rc1' of git://oss.sgi.com/xfs/xfs
8d71db4 lift sb_start_write/sb_end_write out of ->aio_write()
10b3866 Merge tag 'for-linus-v3.9-rc4' of git://oss.sgi.com/xfs/xfs
e001873 xfs: ensure we capture IO errors correctly
3325bee xfs: fix xfs_iomap_eof_prealloc_initial_size type
83cdadd xfs: fix potential infinite loop in xfs_iomap_prealloc_size()
7f78e03 fs: Limit sys_mount to only request filesystem modules.
from 7dfbcbefad4b24d9822d04dbd7b5dd5c3fd45076 (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 7ae077802c9f12959a81fa1a16c1ec2842dbae05
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Mon May 20 09:51:16 2013 +1000
xfs: remote attribute lookups require the value length
When reading a remote attribute, to correctly calculate the length
of the data buffer for CRC enable filesystems, we need to know the
length of the attribute data. We get this information when we look
up the attribute, but we don't store it in the args structure along
with the other remote attr information we get from the lookup. Add
this information to the args structure so we can use it
appropriately.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Ben Myers <bpm@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
(cherry picked from commit e461fcb194172b3f709e0b478d2ac1bdac7ab9a3)
commit cf257abf02709dba3cc745d950f144ce49432b4f
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Mon May 20 09:51:14 2013 +1000
xfs: xfs_attr_shortform_allfit() does not handle attr3 format.
xfstests generic/117 fails with:
XFS: Assertion failed: leaf->hdr.info.magic == cpu_to_be16(XFS_ATTR_LEAF_MAGIC)
indicating a function that does not handle the attr3 format
correctly. Fix it.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Ben Myers <bpm@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
(cherry picked from commit b38958d715316031fe9ea0cc6c22043072a55f49)
commit 7ced60cae46cb37273a03c196e6f473b089bd8e1
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Mon May 20 09:51:13 2013 +1000
xfs: xfs_da3_node_read_verify() doesn't handle XFS_ATTR3_LEAF_MAGIC
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Ben Myers <bpm@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
(cherry picked from commit 72916fb8cbcf0c2928f56cdc2fbe8c7bf5517758)
commit b17cb364dbbbf65add79f1610599d01bcb6851f9
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Mon May 20 09:51:12 2013 +1000
xfs: fix missing KM_NOFS tags to keep lockdep happy
There are several places where we use KM_SLEEP allocation contexts
and use the fact that they are called from transaction context to
add KM_NOFS where appropriate. Unfortunately, there are several
places where the code makes this assumption but can be called from
outside transaction context but with filesystem locks held. These
places need explicit KM_NOFS annotations to avoid lockdep
complaining about reclaim contexts.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Ben Myers <bpm@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
(cherry picked from commit ac14876cf9255175bf3bdad645bf8aa2b8fb2d7c)
commit 509e708a8929c5b75a16c985c03db5329e09cad4
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Mon May 20 09:51:10 2013 +1000
xfs: Don't reference the EFI after it is freed
Checking the EFI for whether it is being released from recovery
after we've already released the known active reference is a mistake
worthy of a brown paper bag. Fix the (now) obvious use after free
that it can cause.
Reported-by: Dave Jones <davej@xxxxxxxxxx>
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
(cherry picked from commit 52c24ad39ff02d7bd73c92eb0c926fb44984a41d)
commit 7031d0e1c46e2b1c869458233dd216cb72af41b2
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Mon May 20 09:51:09 2013 +1000
xfs: fix rounding in xfs_free_file_space
The offset passed into xfs_free_file_space() needs to be rounded
down to a certain size, but the rounding mask is built by a 32 bit
variable. Hence the mask will always mask off the upper 32 bits of
the offset and lead to incorrect writeback and invalidation ranges.
This is not actually exposed as a bug because we writeback and
invalidate from the rounded offset to the end of the file, and hence
the offset we are actually punching a hole out of will always be
covered by the code. This needs fixing, however, if we ever want to
use exact ranges for writeback/invalidation here...
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
(cherry picked from commit 28ca489c63e9aceed8801d2f82d731b3c9aa50f5)
commit 480d7467e4aaa3dc38088baf56bc3eb3599f5d26
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Mon May 20 09:51:08 2013 +1000
xfs: fix sub-page blocksize data integrity writes
FSX on 512 byte block size filesystems has been failing for some
time with corrupted data. The fault dates back to the change in
the writeback data integrity algorithm that uses a mark-and-sweep
approach to avoid data writeback livelocks.
Unfortunately, a side effect of this mark-and-sweep approach is that
each page will only be written once for a data integrity sync, and
there is a condition in writeback in XFS where a page may require
two writeback attempts to be fully written. As a result of the high
level change, we now only get a partial page writeback during the
integrity sync because the first pass through writeback clears the
mark left on the page index to tell writeback that the page needs
writeback....
The cause is writing a partial page in the clustering code. This can
happen when a mapping boundary falls in the middle of a page - we
end up writing back the first part of the page that the mapping
covers, but then never revisit the page to have the remainder mapped
and written.
The fix is simple - if the mapping boundary falls inside a page,
then simple abort clustering without touching the page. This means
that the next ->writepage entry that write_cache_pages() will make
is the page we aborted on, and xfs_vm_writepage() will map all
sections of the page correctly. This behaviour is also optimal for
non-data integrity writes, as it results in contiguous sequential
writeback of the file rather than missing small holes and having to
write them a "random" writes in a future pass.
With this fix, all the fsx tests in xfstests now pass on a 512 byte
block size filesystem on a 4k page machine.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
(cherry picked from commit 49b137cbbcc836ef231866c137d24f42c42bb483)
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/xfs_aops.c | 20 ++++++++++++++++++++
fs/xfs/xfs_attr_leaf.c | 27 +++++++++++++++------------
fs/xfs/xfs_buf.c | 2 +-
fs/xfs/xfs_da_btree.c | 7 +++++--
fs/xfs/xfs_dir2_leaf.c | 2 +-
fs/xfs/xfs_extfree_item.c | 5 +++--
fs/xfs/xfs_file.c | 4 +---
fs/xfs/xfs_log_cil.c | 2 +-
fs/xfs/xfs_super.c | 1 +
fs/xfs/xfs_vnodeops.c | 4 ++--
10 files changed, 50 insertions(+), 24 deletions(-)
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
