* mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed @ 2012-07-12 14:28 Stevie Trujillo 2012-07-12 15:16 ` Steven J. Magnani 0 siblings, 1 reply; 9+ messages in thread From: Stevie Trujillo @ 2012-07-12 14:28 UTC (permalink / raw) To: OGAWA Hirofumi, linux-kernel 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 base64 encoded image (use base64 -d command to unpack it). 6zyQRnJlZURPUyAAAgEBAALgAEAL8AkAEgACAAAAAAAAAAAAAAApOATF6E5PIE5BTUUgICAgRkFU MTIgICD6/DHAjti9AHy44B+OwInuie+5AAHzpepefOAfAABgAI7YjtCNZqD7gH4k/3UDiFYkx0bA EADHRsIBAOjpAEZyZWVET1MAi3Yci34eA3YOg9cAiXbSiX7UikYQmPdmFgHGEdeJdtaJftiLXgux BdPri0YRMdL384lG0AHGg9cAiXbaiX7ci0bWi1bYi37QxF5a6JsAci/Eflq5CwC+8X1X86ZfJotF GnQLg8cgJoA9AHXncllQxF5ai34Wi0bSi1bU6GsAWHJGHgeOXly/ACCricYB9gHG0e6tcwSxBNPo gOQPPfgPcugxwKsOH8ReWr4AIK0JwHQkSEiLfg2B5/8A9+cDRtoTVtzoJABz5egXACBlcnIAMOTN Fs0Zil4k/25aMdu0Ds0QXqxWPAB188NWiUbIiVbKjEbGiV7EtEG7qlWKViSE0nQZzRNyFdHpgdtU qnUNjXbAiV7MiV7OtELrLItOyItWyopGGPZmGpH38ZL2dhiJ0YjGhunQydDJikYYKOD+xAjhxF7E uAECilYkzRNzBjDkzRProotGC/Z2wAFGxoNGyAGDVsoAT3XqjkbGXsNLRVJORUwgIFNZUwAAVao= -- Stevie Trujillo ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed 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 0 siblings, 1 reply; 9+ messages in thread From: Steven J. Magnani @ 2012-07-12 15:16 UTC (permalink / raw) To: Stevie Trujillo; +Cc: OGAWA Hirofumi, linux-kernel 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... ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include <standard.disclaimer> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed 2012-07-12 15:16 ` Steven J. Magnani @ 2012-07-12 19:21 ` OGAWA Hirofumi 2012-07-12 19:39 ` Steven J. Magnani 2012-07-13 15:43 ` Jan Kara 0 siblings, 2 replies; 9+ messages in thread From: OGAWA Hirofumi @ 2012-07-12 19:21 UTC (permalink / raw) To: Steven J. Magnani; +Cc: Stevie Trujillo, linux-kernel, Jens Axboe "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> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed 2012-07-12 19:21 ` OGAWA Hirofumi @ 2012-07-12 19:39 ` Steven J. Magnani 2012-07-12 19:49 ` OGAWA Hirofumi 2012-07-13 15:43 ` Jan Kara 1 sibling, 1 reply; 9+ messages in thread From: Steven J. Magnani @ 2012-07-12 19:39 UTC (permalink / raw) To: OGAWA Hirofumi; +Cc: Stevie Trujillo, linux-kernel, Jens Axboe On Fri, 2012-07-13 at 04:21 +0900, OGAWA Hirofumi wrote: > > 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? > 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; > _ 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. ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include <standard.disclaimer> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed 2012-07-12 19:39 ` Steven J. Magnani @ 2012-07-12 19:49 ` OGAWA Hirofumi 0 siblings, 0 replies; 9+ messages in thread From: OGAWA Hirofumi @ 2012-07-12 19:49 UTC (permalink / raw) To: Steven J. Magnani; +Cc: Stevie Trujillo, linux-kernel, Jens Axboe "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> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed 2012-07-12 19:21 ` OGAWA Hirofumi 2012-07-12 19:39 ` Steven J. Magnani @ 2012-07-13 15:43 ` Jan Kara 2012-07-13 15:52 ` Jeff Moyer 2012-07-13 20:51 ` Jeff Moyer 1 sibling, 2 replies; 9+ messages in thread From: Jan Kara @ 2012-07-13 15:43 UTC (permalink / raw) To: OGAWA Hirofumi Cc: Steven J. Magnani, Stevie Trujillo, linux-kernel, Jens Axboe, Jeff Moyer On Fri 13-07-12 04:21:44, OGAWA Hirofumi wrote: > "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> I think Jeff Moyer has sent a similar fix recently. It may even be already queued in Jens' tree. Jeff? Honza > --- > > 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> > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Jan Kara <jack@suse.cz> SUSE Labs, CR ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed 2012-07-13 15:43 ` Jan Kara @ 2012-07-13 15:52 ` Jeff Moyer 2012-07-13 20:51 ` Jeff Moyer 1 sibling, 0 replies; 9+ messages in thread From: Jeff Moyer @ 2012-07-13 15:52 UTC (permalink / raw) To: Jan Kara Cc: OGAWA Hirofumi, Steven J. Magnani, Stevie Trujillo, linux-kernel, Jens Axboe Jan Kara <jack@suse.cz> writes: >> 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> > I think Jeff Moyer has sent a similar fix recently. It may even be > already queued in Jens' tree. Jeff? I haven't heard a peep from Jens (I believe he's been on vacation), so I forwarded the patch along to Linus (but haven't heard anything from him, either). See my email with Subject: [patch] block: fix infinite loop in __getblk_slow https://lkml.org/lkml/2012/6/26/252 Cheers, Jeff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed 2012-07-13 15:43 ` Jan Kara 2012-07-13 15:52 ` Jeff Moyer @ 2012-07-13 20:51 ` Jeff Moyer 1 sibling, 0 replies; 9+ messages in thread From: Jeff Moyer @ 2012-07-13 20:51 UTC (permalink / raw) To: Jan Kara Cc: OGAWA Hirofumi, Steven J. Magnani, Stevie Trujillo, linux-kernel, Jens Axboe Jan Kara <jack@suse.cz> writes: >> 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> > I think Jeff Moyer has sent a similar fix recently. It may even be > already queued in Jens' tree. Jeff? A fix for this has now been committed in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=91f68c89d8f35fe98ea04159b9a3b42d0149478f Cheers, Jeff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed @ 2012-07-13 9:18 Wolfram Gloger 0 siblings, 0 replies; 9+ messages in thread From: Wolfram Gloger @ 2012-07-13 9:18 UTC (permalink / raw) To: linux-kernel Hi, Maybe the patch referenced in http://lkml.indiana.edu/hypermail/linux/kernel/1206.2/02163.html also relevant in -stable as noted in http://lkml.indiana.edu/hypermail/linux/kernel/1206.2/02717.html is also relevant here? Regards, Wolfram. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-07-13 20:52 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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 2012-07-13 9:18 Wolfram Gloger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.