From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757971Ab2GLTVu (ORCPT ); Thu, 12 Jul 2012 15:21:50 -0400 Received: from mail.parknet.co.jp ([210.171.160.6]:44175 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755774Ab2GLTVs (ORCPT ); Thu, 12 Jul 2012 15:21:48 -0400 From: OGAWA Hirofumi To: "Steven J. Magnani" Cc: Stevie Trujillo , linux-kernel@vger.kernel.org, Jens Axboe Subject: Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed References: <20120712162828.3f561315@localhost> <1342106206.2156.2.camel@iscandar.digidescorp.com> Date: Fri, 13 Jul 2012 04:21:44 +0900 In-Reply-To: <1342106206.2156.2.camel@iscandar.digidescorp.com> (Steven J. Magnani's message of "Thu, 12 Jul 2012 10:16:46 -0500") Message-ID: <87k3y8yed3.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Steven J. Magnani" 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 > [] __cond_resched+0x2a/0x40 > [] find_lock_page+0x3b/0x80 > [] find_or_create_page+0x3f/0xb0 > [] __getblk+0xf2/0x2a0 > [] __bread+0x13/0xb0 > [] fat__get_entry+0x14e/0x220 [fat] > [] fat_get_short_entry+0x66/0xc0 [fat] > [] fat_subdirs+0x55/0x80 [fat] > [] fat_fill_super+0x810/0xa80 [fat] > [] vfat_fill_super+0x1a/0x20 [vfat] > [] mount_bdev+0x1cb/0x210 > [] vfat_mount+0x15/0x20 [vfat] > [] mount_fs+0x20/0xd0 > [] vfs_kern_mount+0x6f/0x100 > [] do_kern_mount+0x54/0x110 > [] do_mount+0x306/0x8b0 > [] sys_mount+0x8d/0xe0 > [] system_call_fastpath+0x16/0x1b > [] 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 --- 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