Messages in this thread | | | From | OGAWA Hirofumi <> | Subject | Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed | Date | Fri, 13 Jul 2012 04:49:47 +0900 |
| |
"Steven J. Magnani" <steve@digidescorp.com> 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 <hirofumi@mail.parknet.co.jp> >> --- >> >> 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 <hirofumi@mail.parknet.co.jp>
| |