xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, master, updated. xfs-for-linu

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, master, updated. xfs-for-linus-v3.12-rc3-44-g10e6e65
From: xfs@xxxxxxxxxxx
Date: Thu, 31 Oct 2013 10:57:03 -0500 (CDT)
Delivered-to: xfs@xxxxxxxxxxx
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
  10e6e65 xfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields
  643f7c4 xfs: fix possible NULL dereference in xlog_verify_iclog
  5bf1f43 xfs:xfs_dir2_node.c: pointer use before check for null
  ad22c7a xfs: prevent stack overflows from page cache allocation
      from  632b89e82bf1c04c251924b49adc689f7b346321 (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 10e6e65dfcedff63275c3d649d329c044caa8e26
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date:   Mon Sep 9 15:33:29 2013 -0500

    xfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields
    
    Today, if xfs_sb_read_verify encounters a v4 superblock
    with junk past v4 fields which includes data in sb_crc,
    it will be treated as a failing checksum and a significant
    corruption.
    
    There are known prior bugs which leave junk at the end
    of the V4 superblock; we don't need to actually fail the
    verification in this case if other checks pan out ok.
    
    So if this is a secondary superblock, and the primary
    superblock doesn't indicate that this is a V5 filesystem,
    don't treat this as an actual checksum failure.
    
    We should probably check the garbage condition as
    we do in xfs_repair, and possibly warn about it
    or self-heal, but that's a different scope of work.
    
    Stable folks: This can go back to v3.10, which is what
    introduced the sb CRC checking that is tripped up by old,
    stale, incorrect V4 superblocks w/ unzeroed bits.
    
    Cc: stable@xxxxxxxxxxxxxxx
    Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
    Acked-by: Dave Chinner <david@xxxxxxxxxxxxx>
    Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 643f7c4e5656bd18c769211f933190f7bb738245
Author: Geyslan G. Bem <geyslan@xxxxxxxxx>
Date:   Wed Oct 30 16:01:00 2013 -0500

    xfs: fix possible NULL dereference in xlog_verify_iclog
    
    In xlog_verify_iclog a debug check of the incore log buffers prints an
    error if icptr is null and then goes on to dereference the pointer
    regardless.  Convert this to an assert so that the intention is clear.
    This was reported by Coverty.
    
    Signed-off-by: Ben Myers <bpm@xxxxxxx>
    Reviewed-by: Eric Sandeen <sandeen@xxxxxxxxxx>

commit 5bf1f439c89d4653f8cc8f8aa303e0d6991aba4b
Author: Denis Efremov <yefremov.denis@xxxxxxxxx>
Date:   Fri Oct 25 15:53:25 2013 +0400

    xfs:xfs_dir2_node.c: pointer use before check for null
    
    ASSERT on args takes place after args dereference.
    This assertion is redundant since we are going to panic anyway.
    
    Found by Linux Driver Verification project (linuxtesting.org) -
    PVS-Studio analyzer.
    
    Signed-off-by: Denis Efremov <yefremov.denis@xxxxxxxxx>
    Reviewed-by: Ben Myers <bpm@xxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit ad22c7a043c2cc6792820e6c5da699935933e87d
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Tue Oct 29 22:11:57 2013 +1100

    xfs: prevent stack overflows from page cache allocation
    
    Page cache allocation doesn't always go through ->begin_write and
    hence we don't always get the opportunity to set the allocation
    context to GFP_NOFS. Failing to do this means we open up the direct
    relcaim stack to recurse into the filesystem and consume a
    significant amount of stack.
    
    On RHEL6.4 kernels we are seeing ra_submit() and
    generic_file_splice_read() from an nfsd context recursing into the
    filesystem via the inode cache shrinker and evicting inodes. This is
    causing truncation to be run (e.g EOF block freeing) and causing
    bmap btree block merges and free space btree block splits to occur.
    These btree manipulations are occurring with the call chain already
    30 functions deep and hence there is not enough stack space to
    complete such operations.
    
    To avoid these specific overruns, we need to prevent the page cache
    allocation from recursing via direct reclaim. We can do that because
    the allocation functions take the allocation context from that which
    is stored in the mapping for the inode. We don't set that right now,
    so the default is GFP_HIGHUSER_MOVABLE, which is effectively a
    GFP_KERNEL context. We need it to be the equivalent of GFP_NOFS, so
    when we initialise an inode, set the mapping gfp mask appropriately.
    
    This makes the use of AOP_FLAG_NOFS redundant from other parts of
    the XFS IO path, so get rid of it.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

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

Summary of changes:
 fs/xfs/xfs_aops.c      |  3 +--
 fs/xfs/xfs_dir2_node.c |  1 -
 fs/xfs/xfs_iops.c      |  9 +++++++++
 fs/xfs/xfs_log.c       |  8 +++-----
 fs/xfs/xfs_sb.c        | 13 +++++++++++--
 5 files changed, 24 insertions(+), 10 deletions(-)


hooks/post-receive
-- 
XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, master, updated. xfs-for-linus-v3.12-rc3-44-g10e6e65, xfs <=