diff options
author | Eric Sandeen <sandeen@sandeen.net> | 2009-09-25 19:42:26 +0000 |
---|---|---|
committer | Alex Elder <aelder@sgi.com> | 2009-10-08 12:02:12 -0500 |
commit | 8e69ce147127a0235e8d1f2b75ea214be78c61b3 (patch) | |
tree | 9de85d2c0e0527e7821f6844b03ef8ca47ed00f8 /fs/super.c | |
parent | dce5065a57c158e0ca5db8e63c50118b2ecf4ac5 (diff) | |
download | op-kernel-dev-8e69ce147127a0235e8d1f2b75ea214be78c61b3.zip op-kernel-dev-8e69ce147127a0235e8d1f2b75ea214be78c61b3.tar.gz |
fix readahead calculations in xfs_dir2_leaf_getdents()
This is for bug #850,
http://oss.sgi.com/bugzilla/show_bug.cgi?id=850
XFS file system segfaults , repeatedly and 100% reproducable in 2.6.30 , 2.6.31
The above only showed up on a CONFIG_XFS_DEBUG=y kernel, because
xfs_bmapi() ASSERTs that it has been asked for at least one map,
and it was getting 0.
The root cause is that our guesstimated "bufsize" from xfs_file_readdir
was fairly small, and the
bufsize -= length;
in the loop was going negative - except bufsize is a size_t, so it
was wrapping to a very large number.
Then when we did
ra_want = howmany(bufsize + mp->m_dirblksize,
mp->m_sb.sb_blocksize) - 1;
with that very large number, the (int) ra_want was coming out
negative, and a subsequent compare:
if (1 + ra_want > map_blocks ...
was coming out -true- (negative int compare w/ uint) and we went
back to xfs_bmapi() for more, even though we did not need more,
and asked for 0 maps, and hit the ASSERT.
We have kind of a type mess here, but just keeping bufsize from
going negative is probably sufficient to avoid the problem.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Alex Elder <aelder@sgi.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
Diffstat (limited to 'fs/super.c')
0 files changed, 0 insertions, 0 deletions