summaryrefslogtreecommitdiffstats
path: root/fs/reiserfs/stree.c
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@sandeen.net>2009-09-25 19:42:26 +0000
committerAlex Elder <aelder@sgi.com>2009-10-08 12:02:12 -0500
commit8e69ce147127a0235e8d1f2b75ea214be78c61b3 (patch)
tree9de85d2c0e0527e7821f6844b03ef8ca47ed00f8 /fs/reiserfs/stree.c
parentdce5065a57c158e0ca5db8e63c50118b2ecf4ac5 (diff)
downloadop-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/reiserfs/stree.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud