[XFS updates] XFS development tree branch, master, updated. for-linus-v3.10-rc1-2-14684-g52c24ad

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
  52c24ad xfs: Don't reference the EFI after it is freed
  28ca489 xfs: fix rounding in xfs_free_file_space
  49b137c xfs: fix sub-page blocksize data integrity writes
      from  211d022c43cac3aecbe967fcaf9b10156bfa63ad (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 52c24ad39ff02d7bd73c92eb0c926fb44984a41d
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>

commit 28ca489c63e9aceed8801d2f82d731b3c9aa50f5
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>

commit 49b137cbbcc836ef231866c137d24f42c42bb483
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>

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

Summary of changes:
 fs/xfs/xfs_aops.c         | 19 +++++++++++++++++++
 fs/xfs/xfs_extfree_item.c |  5 +++--
 fs/xfs/xfs_vnodeops.c     |  4 ++--
 3 files changed, 24 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
XFS development tree

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux