"Steven J. Magnani" <[email protected]> writes: >> The following patch fixes it? If it fix, there are some options to check >> it. >> >> a) Check it like this patch and warn. >> b) (a), but without warn. >> c) Check it in init_page_buffers() and return -EIO or such >> >> Well, anyway, Cc to Jens. >> >> Signed-off-by: OGAWA Hirofumi <[email protected]> >> --- >> >> fs/buffer.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff -puN fs/buffer.c~debug fs/buffer.c >> --- tux3fs/fs/buffer.c~debug 2012-07-13 04:10:40.000000000 +0900 >> +++ tux3fs-hirofumi/fs/buffer.c 2012-07-13 04:11:50.000000000 +0900 >> @@ -1055,6 +1055,13 @@ __getblk_slow(struct block_device *bdev, >> dump_stack(); >> return NULL; >> } >> + if (block >= blkdev_max_block(I_BDEV(bdev->bd_inode))) { >> + printk(KERN_ERR "getblk(): block %llu, end_block %llu\n", >> + (unsigned long long)block, >> + (unsigned long >> long)blkdev_max_block(I_BDEV(bdev->bd_inode))); >> + dump_stack(); >> + return NULL; >> + } >> >> for (;;) { >> struct buffer_head * bh; >> _ > > This fixes the hang, but I'm not sure dump_stack() is a good idea. I get > almost 100 lines of stack dumps and error messages in my kernel log. > Also, I was a little surprised to see that mount completes successfully.
So, it sounds like the good choice would be (b) or (c). Well, I guess Jens would choose what to do. -- OGAWA Hirofumi <[email protected]> -- 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/
