Bug 42778
Summary: | Partition checking code hangs on empty virtio disk | ||
---|---|---|---|
Product: | File System | Reporter: | Richard W.M. Jones (rjones) |
Component: | Other | Assignee: | fs_other |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | amon |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: |
Description
Richard W.M. Jones
2012-02-15 19:49:19 UTC
Still happening with 3.4.0-rc2+. It happens when CONFIG_ACORN_PARTITION_ICS=y (not "ADFS" as previously stated). I've updated the summary to reflect this. I can reproduce it easily using my own kernel compiled from Linus's git tree. I can only reproduce it in an Ubuntu VM (not on Fedora baremetal) although that is probably just a timing issue. More oddness. I disabled all CONFIG_ACORN_PARTITION settings. The bug still happens! But in another partition function. [ 240.632690] INFO: task swapper/0:1 blocked for more than 120 seconds. [ 240.632891] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.633222] swapper/0 D ffffffff8180ca80 0 1 0 0x00000000 [ 240.633623] ffff88001e911750 0000000000000046 0000000000000000 000000004e14c044 [ 240.633930] ffff88001e908000 ffff88001e911fd8 ffff88001e911fd8 ffff88001e911fd8 [ 240.634167] ffffffff81c13020 ffff88001e908000 ffff88001e911730 ffff88001ec140e8 [ 240.634461] Call Trace: [ 240.635197] [<ffffffff81119840>] ? __lock_page+0x70/0x70 [ 240.635428] [<ffffffff81655979>] schedule+0x29/0x70 [ 240.635602] [<ffffffff81655a4f>] io_schedule+0x8f/0xd0 [ 240.635755] [<ffffffff8111984e>] sleep_on_page+0xe/0x20 [ 240.635907] [<ffffffff816540fa>] __wait_on_bit_lock+0x5a/0xc0 [ 240.636130] [<ffffffff81119837>] __lock_page+0x67/0x70 [ 240.636283] [<ffffffff81073840>] ? autoremove_wake_function+0x40/0x40 [ 240.636472] [<ffffffff8111aa70>] do_read_cache_page+0x160/0x180 [ 240.636486] [<ffffffff811b0170>] ? blkdev_write_begin+0x30/0x30 [ 240.636486] [<ffffffff8111aad9>] read_cache_page_async+0x19/0x20 [ 240.636486] [<ffffffff8111aaee>] read_cache_page+0xe/0x20 [ 240.636486] [<ffffffff812f832d>] read_dev_sector+0x2d/0x90 [ 240.636486] [<ffffffff812fe68c>] read_lba+0xbc/0x120 [ 240.636486] [<ffffffff812feaeb>] find_valid_gpt+0xbb/0x610 [ 240.636486] [<ffffffff81316d7e>] ? string.isra.4+0x3e/0xd0 [ 240.636486] [<ffffffff812ff040>] ? find_valid_gpt+0x610/0x610 [ 240.636486] [<ffffffff812ff0c2>] efi_partition+0x82/0x3b0 [ 240.636486] [<ffffffff813182c4>] ? snprintf+0x34/0x40 [ 240.636486] [<ffffffff812ff040>] ? find_valid_gpt+0x610/0x610 [ 240.636486] [<ffffffff812f93b8>] check_partition+0xf8/0x200 [ 240.636486] [<ffffffff812f9017>] rescan_partitions+0xb7/0x2b0 [ 240.636486] [<ffffffff811b13cb>] __blkdev_get+0x39b/0x480 [ 240.636486] [<ffffffff811937f2>] ? inode_init_always+0x102/0x1d0 [ 240.636486] [<ffffffff811b1503>] blkdev_get+0x53/0x310 [ 240.636486] [<ffffffff8119311c>] ? unlock_new_inode+0x5c/0x90 [ 240.636486] [<ffffffff811b0021>] ? bdget+0x121/0x140 [ 240.636486] [<ffffffff812f6885>] add_disk+0x3f5/0x490 [ 240.636486] [<ffffffff816343ff>] virtblk_probe+0x45f/0x503 [ 240.636486] [<ffffffff81413c20>] ? lo_release+0x90/0x90 [ 240.636486] [<ffffffff813a9af0>] ? vp_reset+0x90/0x90 [ 240.640804] [<ffffffff813a8053>] virtio_dev_probe+0xe3/0x140 [ 240.641851] [<ffffffff813fa30e>] driver_probe_device+0x7e/0x220 [ 240.642170] [<ffffffff813fa55b>] __driver_attach+0xab/0xb0 [ 240.642518] [<ffffffff813fa4b0>] ? driver_probe_device+0x220/0x220 [ 240.642821] [<ffffffff813f8746>] bus_for_each_dev+0x56/0x90 [ 240.643101] [<ffffffff813f9e2e>] driver_attach+0x1e/0x20 [ 240.643372] [<ffffffff813f99e0>] bus_add_driver+0x1a0/0x270 [ 240.643665] [<ffffffff81d28240>] ? loop_init+0x12e/0x12e [ 240.643939] [<ffffffff81d28240>] ? loop_init+0x12e/0x12e [ 240.644282] [<ffffffff813faab6>] driver_register+0x76/0x130 [ 240.644613] [<ffffffff81d28240>] ? loop_init+0x12e/0x12e [ 240.644887] [<ffffffff813a82b0>] register_virtio_driver+0x20/0x30 [ 240.644989] [<ffffffff81d28294>] init+0x54/0x7e [ 240.644989] [<ffffffff8100203f>] do_one_initcall+0x3f/0x170 [ 240.644989] [<ffffffff81cf2d53>] kernel_init+0x134/0x1b8 [ 240.644989] [<ffffffff81cf2549>] ? rdinit_setup+0x28/0x28 [ 240.644989] [<ffffffff8165fe64>] kernel_thread_helper+0x4/0x10 [ 240.644989] [<ffffffff81cf2c1f>] ? start_kernel+0x3ce/0x3ce [ 240.644989] [<ffffffff8165fe60>] ? gs_change+0x13/0x13 I have seen the same condition as Richard, using the same applications, but on a raw virtual disk with multiple primary and extended partitions and a functioning MBR using the most recent Precise Pangolin release's Ubuntu kernel. So it is more general than just a blank disk. It fails on a fully functional virtual disk. I now believe this is a bug in the Ubuntu qemu package. |