[Btrfs-devel] Oops

[Christian Hesse]

On Friday 07 December 2007, Chris Mason wrote:
> On Fri, 7 Dec 2007 19:27:43 +0100
> Christian Hesse <list at eworm.de> wrote:
> > Hello everybody,
> >
> > I've my Gentoo's /usr/portage on a loopback btrfs. Just wanted to
> > sync and got an oops. I've a rsync and a ls process in status D now.
> > The system has been in suspend (tuxonice 3.0-rc3) with mounted btrfs,
> > perhaps that is related?
>
> Could be, but only if other filesystems get problems during suspend as
> well.

No, other filesystems are fine.

> Which version of btrfs was used to format this disk, and which one was
> in use when you got the oops?

Both 0.9, kernel and userspace.

> You're oopsing because the parent pointer for btrfs_cow_block was null,
> but the buffer you were trying to cow wasn't the root.  That's not
> supposed to happen ;)

I think so. ;) Let me know if I can help to debug that.

> > Dec  7 19:18:38 revo BUG: unable to handle kernel NULL pointer
> > dereference at virtual address 0000000c
> > Dec  7 19:18:38 revo printing eip: b01dcd24 *pde = 00000000
> > Dec  7 19:18:38 revo Oops: 0000 [#1] SMP
> > Dec  7 19:18:38 revo Modules linked in: iwl3945 vboxdrv
> > Dec  7 19:18:38 revo
> > Dec  7 19:18:38 revo Pid: 9464, comm: rsync Not tainted (2.6.24-rc4
> > #1) Dec  7 19:18:38 revo EIP: 0060:[<b01dcd24>] EFLAGS: 00210282 CPU:
> > 0 Dec  7 19:18:38 revo EIP is at btrfs_set_key_blockptr+0x14/0x100
> > Dec  7 19:18:38 revo EAX: 00000000 EBX: 00000060 ECX: 10006000 EDX:
> > 0000004f Dec  7 19:18:38 revo ESI: 00000000 EDI: eb1293e4 EBP:
> > eec7cbd4 ESP: c4d99c34 Dec  7 19:18:38 revo dhcpcd[8448]: wlan0:
> > renewing lease of 192.168.182.74 Dec  7 19:18:38 revo DS: 007b ES:
> > 007b FS: 00d8 GS: 0033 SS: 0068 Dec  7 19:18:38 revo Process rsync
> > (pid: 9464, ti=c4d98000 task=e0544ab0 task.ti=c4d98000)
> > Dec  7 19:18:38 revo Stack: 00000000 eb1293e4 eec7c6f4 06040048
> > 00000000 20000000 000000dd 00000000
> > Dec  7 19:18:38 revo 00000000 00000000 00000000 eb1293e4 b01bf3e7
> > 10006000 00000000 00000000
> > Dec  7 19:18:38 revo 00000000 da25be70 ee8e1400 eec7c6f4 00000000
> > 000001df 00000000 eb1293e4
> > Dec  7 19:18:38 revo Call Trace:
> > Dec  7 19:18:38 revo [<b01bf3e7>] __btrfs_cow_block+0x1c7/0x390
> > Dec  7 19:18:38 revo [<b01bf726>] btrfs_cow_block+0x176/0x1a0
> > Dec  7 19:18:38 revo [<b01c1303>] btrfs_search_slot+0x103/0xe70
> > Dec  7 19:18:38 revo [<b02c5965>] dma_pool_alloc+0x155/0x1f0
> > Dec  7 19:18:38 revo [<b0121d7b>] enqueue_entity+0x2b/0x60
> > Dec  7 19:18:38 revo [<b0121dd7>] enqueue_task_fair+0x27/0x30
> > Dec  7 19:18:38 revo [<b0120b72>] enqueue_task+0x12/0x30
> > Dec  7 19:18:38 revo [<b0122d6e>] try_to_wake_up+0x4e/0x2b0
> > Dec  7 19:18:38 revo [<b01c9168>] btrfs_lookup_inode+0x38/0xc0
> > Dec  7 19:18:38 revo [<b01cd4c5>] btrfs_update_inode+0x45/0xc0
> > Dec  7 19:18:38 revo [<b01cf329>] btrfs_dirty_inode+0x49/0x80
> > Dec  7 19:18:38 revo [<b019e950>] __mark_inode_dirty+0x30/0x180
> > Dec  7 19:18:38 revo [<b0196197>] inode_setattr+0xb7/0x180
> > Dec  7 19:18:38 revo [<b01cee9e>] btrfs_setattr+0x3e/0x2a0
> > Dec  7 19:18:38 revo [<b01712e2>] handle_mm_fault+0xf2/0x570
> > Dec  7 19:18:38 revo [<b019633c>] notify_change+0xdc/0x2c0
> > Dec  7 19:18:38 revo [<b01a1611>] do_utimes+0x161/0x250
> > Dec  7 19:18:38 revo [<b01712e2>] handle_mm_fault+0xf2/0x570
> > Dec  7 19:18:38 revo [<b01a1721>] sys_futimesat+0x21/0xa0
> > Dec  7 19:18:38 revo [<b01a17bf>] sys_utimes+0x1f/0x30
> > Dec  7 19:18:38 revo [<b0104256>] sysenter_past_esp+0x5f/0x85
> > Dec  7 19:18:38 revo =======================
> > Dec  7 19:18:38 revo Code: 28 8b 74 24 2c 8b 7c 24 30 83 c4 34 c3 8d
> > 76 00 8d bc 27 00 00 00 00 83 ec 30 89 5c 24 24 8d 5a 11 89 74 24 28 8
> > 9 c6 89 7c 24 2c <8b> 78 0c 85 ff 74 45 8b 48 14 39 cb 72 3e 89 c8 83
> > c2 19 03 46
> > Dec  7 19:18:38 revo EIP: [<b01dcd24>]
> > btrfs_set_key_blockptr+0x14/0x100 SS:ESP 0068:c4d99c34
> >
> > Just wondering, is it safe to mount a btrfs root when a subvolume is
> > already mounted?
>
> Should be, but could you please send along the exact sequence of
> commands you ran?

Ok, as far as I can remember:

$ mount -o loop /usr/portage.img /usr/portage/
[ sync data to the fs, run emerge, update meta database, etc. ]
$ mount -o loop,subvol=. /usr/portage.img /mnt/tmp/
$ btrfsctl -s 2007-12-07 /mnt/tmp
[ remember that I just created a new subvol, not a snapshot ]
$ btrfsctl -s 2007-12-07-0 /mnt/tmp/default
$ umount /mnt/tmp
[ suspend and resume the system ]
$ emerge sync

It hang after touching the first file on the fs I think. Now even a simple ls 
got status D.
-- 
Regards,
Chris