lkml.org 
[lkml]   [2012]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
    Date
    "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>


    \
     
     \ /
      Last update: 2012-07-12 22:41    [W:2.047 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site