public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: "Steven J. Magnani" <steve@digidescorp.com>
Cc: Stevie Trujillo <stevie.trujillo@gmail.com>,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
Date: Fri, 13 Jul 2012 04:21:44 +0900	[thread overview]
Message-ID: <87k3y8yed3.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <1342106206.2156.2.camel@iscandar.digidescorp.com> (Steven J. Magnani's message of "Thu, 12 Jul 2012 10:16:46 -0500")

"Steven J. Magnani" <steve@digidescorp.com> writes:

> On Thu, 2012-07-12 at 16:28 +0200, Stevie Trujillo wrote: 
>> Hello,
>> 
>> I was trying to create a bootdisk to update my BIOS, and accidentially
>> made a 512byte image with only the FreeDOS header in it.
>> 
>> ( Linux 3.4.4 )
>> # mount -o loop dosdisk.img /tmp
>> ^C^C^C
>> It uses 100% CPU and doesn't listen to me when I do ^C, kill -9 etc. I
>> think this means it's stuck in the kernel?
>
> Here is the stack trace I get for the mount process:
>
> [root@telezart smagnani]# cat /proc/1334/stack
> [<ffffffff81077a5a>] __cond_resched+0x2a/0x40
> [<ffffffff8110c4bb>] find_lock_page+0x3b/0x80
> [<ffffffff8110cbaf>] find_or_create_page+0x3f/0xb0
> [<ffffffff8119a692>] __getblk+0xf2/0x2a0
> [<ffffffff8119a893>] __bread+0x13/0xb0
> [<ffffffffa00fd1fe>] fat__get_entry+0x14e/0x220 [fat]
> [<ffffffffa00fd596>] fat_get_short_entry+0x66/0xc0 [fat]
> [<ffffffffa00ff765>] fat_subdirs+0x55/0x80 [fat]
> [<ffffffffa0103d30>] fat_fill_super+0x810/0xa80 [fat]
> [<ffffffffa00e821a>] vfat_fill_super+0x1a/0x20 [vfat]
> [<ffffffff8116d61b>] mount_bdev+0x1cb/0x210
> [<ffffffffa00e81f5>] vfat_mount+0x15/0x20 [vfat]
> [<ffffffff8116e410>] mount_fs+0x20/0xd0
> [<ffffffff81186e4f>] vfs_kern_mount+0x6f/0x100
> [<ffffffff81187804>] do_kern_mount+0x54/0x110
> [<ffffffff811891d6>] do_mount+0x306/0x8b0
> [<ffffffff811898cd>] sys_mount+0x8d/0xe0
> [<ffffffff81583629>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> I would think this is more likely a bug in the loopback driver than the
> FAT filesystem...

It looks like the bug of __getblk_slow(). If requested block was beyond
end of device, __find_get_block() will find buffer_mapped()'s buffer,
but block >= end_block is unmapped. So, it can be loop.

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;
_

-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2012-07-12 19:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-12 14:28 mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed Stevie Trujillo
2012-07-12 15:16 ` Steven J. Magnani
2012-07-12 19:21   ` OGAWA Hirofumi [this message]
2012-07-12 19:39     ` Steven J. Magnani
2012-07-12 19:49       ` OGAWA Hirofumi
2012-07-13 15:43     ` Jan Kara
2012-07-13 15:52       ` Jeff Moyer
2012-07-13 20:51       ` Jeff Moyer
  -- strict thread matches above, loose matches on Subject: below --
2012-07-13  9:18 Wolfram Gloger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k3y8yed3.fsf@devron.myhome.or.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steve@digidescorp.com \
    --cc=stevie.trujillo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox