Hi On Sun, Aug 5, 2012 at 7:02 PM, Alan Curry <pacman@xxxxxxxxxxxxx> wrote: > I got an Oops from running "losetup -d /dev/loop2". The trace shows > loop_clr_fd calling bd_set_size, and the parameter bdev appears to have a > NULL in its bd_disk field. > > The losetup command was run as part of a script that did this: > losetup -d /dev/loop5 > losetup -d /dev/loop4 > losetup -d /dev/loop3 > losetup -d /dev/loop2 > losetup -d /dev/loop1 > The kernel was processing a lot of loop_clr_fd's in a quick sequence. The > first three worked, and the loop2 Oopsed. > > After that I ran the losetup -d /dev/loop1 separately and it worked. The > process that caused the Oops didn't die: > PID TTY STAT TIME COMMAND > 5055 pts/1 D 0:00 [losetup] > > I also tried to query the current state of the device with "losetup loop2" > after the Oops. That gave me a second stuck process: > PID TTY STAT TIME COMMAND > 5059 pts/1 D+ 0:00 losetup /dev/loop2 > > These processes are still alive, in their permanent D state. The rest of > the system is still functional. I'll try to keep it that way for now, in > case anyone wants to suggest some debugging actions that I can take. > > The loop devices were set up to handle an unusual situation: I have a whole > hard drive image contained within a partition on another hard drive. Each > loop device corresponds to a partition of the imaged drive. They were set > up like this, with numbers taken from its partition table: > > cyl=516096 > losetup -o $((1*$cyl)) --sizelimit $(((2080-1+1)*$cyl)) /dev/loop1 /dev/sda6 > losetup -o $((2081*$cyl)) --sizelimit $(((4160-2081+1)*$cyl)) /dev/loop2 /dev/sda6 > losetup -o $((4161*$cyl)) --sizelimit $(((24965-4161+1)*$cyl)) /dev/loop3 /dev/sda6 > losetup -o $((24966*$cyl)) --sizelimit $(((45770-24966+1)*$cyl)) /dev/loop4 /dev/sda6 > losetup -o $((45771*$cyl)) --sizelimit $(((158815-45771+1)*$cyl)) /dev/loop5 /dev/sda6 > > So all the loop devices were referencing the same backing device, with > different (adjacent but non-overlapping) offsets. > > I had also done blockdev --setro on sda6 and all of the loop devices as > soon as they were created. The devices were successfully dm_snapshot'ed, > fscked, mounted, and all data was copied off of them before I did the > losetup -d that caused the oops. The one that failed, loop2, actually > corresponded to the swap partition of the imaged drive so I didn't copy > anything off of it, but I know it was working because I used "strings > /dev/loop2" to figure out what it was. > > That's all the information I can think of that might be relevant. I'm > willing to dig deeper if there's anything that can be retrieved from the > two stuck processes, or I could reboot and try to repeat the incident. > > Here is the Oops: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000328 > IP: [<ffffffff8110ffed>] bd_set_size+0x7/0x5e > PGD 156eb067 PUD 102aa067 PMD 0 > Oops: 0000 [#1] SMP > CPU 1 > Modules linked in: dm_snapshot ext3 jbd ext2 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc arc4 carl9170 ehci_hcd mac80211 usbcore usb_common led_class ath cfg80211 rfkill sha256_generic aes_x86_64 aes_generic cbc crc32c_intel loop dm_crypt dm_mod sd_mod crc_t10dif ata_piix libata scsi_mod > > Pid: 5055, comm: losetup Not tainted 3.5.0 #17 BIOSTAR Group TH61 ITX/TH61 ITX > RIP: 0010:[<ffffffff8110ffed>] [<ffffffff8110ffed>] bd_set_size+0x7/0x5e > RSP: 0018:ffff88001113ddd0 EFLAGS: 00010246 > RAX: 0000000000000000 RBX: ffff8800721b4a00 RCX: 0000000180240011 > RDX: 0000000180240012 RSI: 0000000000000000 RDI: ffff880100385d40 > RBP: ffff880100385d40 R08: ffff880072dcb8c0 R09: 0000000180240011 > R10: 0000000080240011 R11: 0000000000000000 R12: ffff880073712300 > R13: 0000000000020010 R14: ffff8800721b4b14 R15: 0000000000000000 > FS: 00007f98183ba700(0000) GS:ffff880100300000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000328 CR3: 000000001adcb000 CR4: 00000000000407e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process losetup (pid: 5055, threadinfo ffff88001113c000, task ffff8800732c8640) > Stack: > ffffffffa00b251c ffff8800721b4a00 ffff8800739ec9c0 0000000000004c01 > 0000000000000000 ffff8800721b4b30 ffffffffa00b315d ffff880072209c20 > ffff88000f9f6900 00007f9817f09430 000000000000001d ffff880031878840 > Call Trace: > [<ffffffffa00b251c>] ? loop_clr_fd+0x154/0x1f5 [loop] > [<ffffffffa00b315d>] ? lo_ioctl+0x4af/0x657 [loop] > [<ffffffff811a38f4>] ? blkdev_ioctl+0x632/0x666 > [<ffffffff811100de>] ? block_ioctl+0x32/0x36 > [<ffffffff810f54f0>] ? do_vfs_ioctl+0x44b/0x490 > [<ffffffff810df6b7>] ? virt_to_head_page+0x9/0x2c > [<ffffffff810e1814>] ? kmem_cache_free+0x12/0x9e > [<ffffffff810f5571>] ? sys_ioctl+0x3c/0x5f > [<ffffffff81346422>] ? system_call_fastpath+0x16/0x1b > Code: 20 31 c0 48 85 c9 75 1b 48 39 7f 70 74 13 48 8b 46 50 48 3d ba ff 10 81 74 07 48 85 c0 0f 94 c0 c3 b0 01 c3 48 8b 87 90 00 00 00 <48> 8b 80 28 03 00 00 48 85 c0 74 0e 8b 90 d0 04 00 00 66 85 d2 > RIP [<ffffffff8110ffed>] bd_set_size+0x7/0x5e > RSP <ffff88001113ddd0> > CR2: 0000000000000328 > ---[ end trace 149557d36d01641b ]--- Here is proposed fix http://marc.info/?l=linux-kernel&m=136481752606623&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
