On Mon, 2006-12-18 at 19:51 +0100, Eric Sesterhenn wrote: > hi, > > while playing around with fsfuzzer, i got the following oops with jfs: > > [ 851.804875] BUG at fs/jfs/jfs_xtree.c:760 assert(!BT_STACK_FULL(btstack)) > [ 851.805179] ------------[ cut here ]------------ > [ 851.805238] kernel BUG at fs/jfs/jfs_xtree.c:760!
... > On a damaged filesystem we might have a full stack and should > not progress further, and return instead of calling BUG() > > Signed-off-by: Eric Sesterhenn > > --- linux-2.6.19/fs/jfs/jfs_xtree.c.orig 2006-12-18 14:37:07.000000000 > +0100 > +++ linux-2.6.19/fs/jfs/jfs_xtree.c 2006-12-18 14:37:55.000000000 +0100 > @@ -757,6 +757,8 @@ static int xtSearch(struct inode *ip, s6 > nsplit = 0; > > /* push (bn, index) of the parent page/entry */ > + if (BT_STACK_FULL(btstack)) > + return -EINVAL; This leaks a reference on an xtree page. I'd also like to mark the superblock dirty here, so that fsck.jfs will fix the file system on the next boot. jfs_error does this as well as the requested error action. The default is to remount read-only. > BT_PUSH(btstack, bn, index); > > /* get the child page block number */ > Do you want to retry your fsfuzzer testing with this patch? I'm going to take a look at the other calls to BT_PUSH in xtTruncate and xtTruncate_pmap, but I'm too busy now, so I'll send you what I have so far (untested). Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]> diff --git a/fs/jfs/jfs_xtree.c b/fs/jfs/jfs_xtree.c index e98eb03..176e984 100644 --- a/fs/jfs/jfs_xtree.c +++ b/fs/jfs/jfs_xtree.c @@ -757,6 +757,11 @@ static int xtSearch(struct inode *ip, s64 xoff, s64 *nextp, nsplit = 0; /* push (bn, index) of the parent page/entry */ + if (BT_STACK_FULL(btstack)) { + jfs_error(ip->i_sb, "stack overrun in xtSearch!"); + XT_PUTPAGE(mp); + return -EIO; + } BT_PUSH(btstack, bn, index); /* get the child page block number */ -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/