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-next 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
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
