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
51c8422 xfs: fix typo in comment of xfs_dinode_t.
5276432 xfs: kill copy and paste segment checks in xfs_file_aio_read
3297238 xfs: make largest supported offset less shouty
d2c2819 xfs: m_maxioffset is redundant
0f2cf9d xfs: fix debug_object WARN at xfs_alloc_vextent()
7d0fa3e xfs: xfs_vm_writepage clear iomap_valid when !buffer_uptodate (REV2)
from f8f5701bdaf9134b1f90e5044a82c66324d2073f (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 51c84223af604ce2d00d0416c30a38c50aed00bd
Author: Chen Baozi <baozich@xxxxxxxxx>
Date: Sat May 26 00:48:47 2012 +0800
xfs: fix typo in comment of xfs_dinode_t.
There should be "XFS_DFORK_DPTR, XFS_DFORK_APTR, and XFS_DFORK_PTR" instead
of "XFS_DFORK_PTR, XFS_DFORK_DPTR, and XFS_DFORK_PTR".
Signed-off-by: Chen Baozi <baozich@xxxxxxxxx>
Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 5276432997feb2366ac1e77949e94fe86a394813
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Fri Jun 8 15:45:44 2012 +1000
xfs: kill copy and paste segment checks in xfs_file_aio_read
The generic segment check code now returns a count of the number of
bytes in the iovec, so we don't need to roll our own anymore.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 32972383ca46223aa2b129826b3789721ec147aa
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Fri Jun 8 15:44:54 2012 +1000
xfs: make largest supported offset less shouty
XFS_MAXIOFFSET() is just a simple macro that resolves to
mp->m_maxioffset. It doesn't need to exist, and it just makes the
code unnecessarily loud and shouty.
Make it quiet and easy to read.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Eric Sandeen <sandeen@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit d2c2819117176e139dc761873c664aaa770c79c9
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Fri Jun 8 15:44:53 2012 +1000
xfs: m_maxioffset is redundant
The m_maxioffset field in the struct xfs_mount contains the same
value as the superblock s_maxbytes field. There is no need to carry
two copies of this limit around, so use the VFS superblock version.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Reviewed-by: Eric Sandeen <sandeen@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 0f2cf9d3d917b269645902506adaa4ff92b5e506
Author: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Thu Jun 7 15:44:32 2012 +0800
xfs: fix debug_object WARN at xfs_alloc_vextent()
Fengguang reports:
[ 780.529603] XFS (vdd): Ending clean mount
[ 781.454590] ODEBUG: object is on stack, but not annotated
[ 781.455433] ------------[ cut here ]------------
[ 781.455433] WARNING: at /c/kernel-tests/sound/lib/debugobjects.c:301 __debug_object_init+0x173/0x1f1()
[ 781.455433] Hardware name: Bochs
[ 781.455433] Modules linked in:
[ 781.455433] Pid: 26910, comm: kworker/0:2 Not tainted 3.4.0+ #51
[ 781.455433] Call Trace:
[ 781.455433] [<ffffffff8106bc84>] warn_slowpath_common+0x83/0x9b
[ 781.455433] [<ffffffff8106bcb6>] warn_slowpath_null+0x1a/0x1c
[ 781.455433] [<ffffffff814919a5>] __debug_object_init+0x173/0x1f1
[ 781.455433] [<ffffffff81491c65>] debug_object_init+0x14/0x16
[ 781.455433] [<ffffffff8108842a>] __init_work+0x20/0x22
[ 781.455433] [<ffffffff8134ea56>] xfs_alloc_vextent+0x6c/0xd5
Use INIT_WORK_ONSTACK in xfs_alloc_vextent instead of INIT_WORK.
Reported-by: Wu Fengguang <wfg@xxxxxxxxxxxxxxx>
Signed-off-by: Jie Liu <jeff.liu@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
commit 7d0fa3ecba2f12ceef93fffe615e5dd9b50bb794
Author: Alain Renaud <arenaud@xxxxxxx>
Date: Fri Jun 8 15:34:46 2012 -0400
xfs: xfs_vm_writepage clear iomap_valid when !buffer_uptodate (REV2)
On filesytems with a block size smaller than PAGE_SIZE we currently have
a problem with unwritten extents. If a we have multi-block page for
which an unwritten extent has been allocated, and only some of the
buffers have been written to, and they are not contiguous, we can expose
stale data from disk in the blocks between the writes after extent
conversion.
Example of a page with unwritten and real data.
buffer content
0 empty b_state = 0
1 DATA b_state = 0x1023 Uptodate,Dirty,Mapped,Unwritten
2 DATA b_state = 0x1023 Uptodate,Dirty,Mapped,Unwritten
3 empty b_state = 0
4 empty b_state = 0
5 DATA b_state = 0x1023 Uptodate,Dirty,Mapped,Unwritten
6 DATA b_state = 0x1023 Uptodate,Dirty,Mapped,Unwritten
7 empty b_state = 0
Buffers 1, 2, 5, and 6 have been written to, leaving 0, 3, 4, and 7
empty. Currently buffers 1, 2, 5, and 6 are added to a single ioend,
and when IO has completed, extent conversion creates a real extent from
block 1 through block 6, leaving 0 and 7 unwritten. However buffers 3
and 4 were not written to disk, so stale data is exposed from those
blocks on a subsequent read.
Fix this by setting iomap_valid = 0 when we find a buffer that is not
Uptodate. This ensures that buffers 5 and 6 are not added to the same
ioend as buffers 1 and 2. Later these blocks will be converted into two
separate real extents, leaving the blocks in between unwritten.
Signed-off-by: Alain Renaud <arenaud@xxxxxxx>
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/xfs_alloc.c | 2 +-
fs/xfs/xfs_aops.c | 23 ++++++++++++++---------
fs/xfs/xfs_bmap.c | 2 +-
fs/xfs/xfs_dinode.h | 2 +-
fs/xfs/xfs_file.c | 19 ++++---------------
fs/xfs/xfs_inode.c | 2 +-
fs/xfs/xfs_iomap.c | 6 +++---
fs/xfs/xfs_mount.c | 2 --
fs/xfs/xfs_mount.h | 3 ---
fs/xfs/xfs_qm.c | 2 +-
fs/xfs/xfs_vnodeops.c | 10 +++++-----
11 files changed, 31 insertions(+), 42 deletions(-)
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
