[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] kernel NULL pointer after snapshot remove on 2.6.17



Hi,

I just found the following oops after lvremove'ing a snapshot which was
used to backup a mysql database.

This oops happened because I mistakenly copied a part of the snapshot
back to the original volume. This apparently exhausted the capacity of
the snapshot and triggered the following oops.

lvremove after the oops was stuck in D+ state. 
Any lv* command was also stuck after that.
After that the server was stuck while rebooting with the error message:
"snapshot is marked invalid", then nothing else.

I cured the problem by booting a rescue CD, and hand-lvremoving the
offending snapshot.

All this is on an amd64 debian etch with custom compiled kernel version
2.6.17, and lvm2 version 2.02.06-2, and libdevmapper is at 1.02.08-1.

Here is the trace information:

attempt to access beyond end of device
dm-8: rw=17, want=4194320, limit=4194304
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: 
<ffffffff8804c121>{:dm_snapshot:exit_exception_table+81}
PGD 5e9eb067 PUD 1d537067 PMD 0 
Oops: 0000 [1] SMP 
CPU 1 
Modules linked in: ip_conntrack_ftp ipt_REJECT xt_tcpudp ipt_LOG xt_limit xt_state iptable_filter ip_conntrack nfnetlink ipmi_watchdog button ac battery ip_tables x_tables megaraid ipmi_devintf ipmi_si ipmi_msghandler psmouse e752x_edac serio_raw pcspkr hw_random edac_mc dm_mirror dm_snapshot dm_mod megaraid_mbox ehci_hcd uhci_hcd megaraid_mm thermal processor fan
Pid: 4452, comm: lvremove Not tainted 2.6.17 #2
RIP: 0010:[<ffffffff8804c121>] <ffffffff8804c121>{:dm_snapshot:exit_exception_table+81}
RSP: 0018:ffff810076957c38  EFLAGS: 00010282
RAX: 0000000000000001 RBX: ffffc20010400e00 RCX: 0000000000000004
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81007f5eb200
RBP: ffff810076957c68 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff81007f5eb200 R14: 00000000000021e0 R15: ffff8100770b86e8
FS:  00002b05cb22bc80(0000) GS:ffff81007ffae3c0(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000063d52000 CR4: 00000000000006e0
Process lvremove (pid: 4452, threadinfo ffff810076956000, task ffff81007e89eb50)
Stack: 0000400000000282 ffff8100770b8680 ffffc20000061080 0000000000000000 
       00000000005b7cd0 ffffffff8803d330 ffff810076957c88 ffffffff8804c7ba 
       ffffc20000061080 ffff81007e9bbc00 
Call Trace: <ffffffff8803d330>{:dm_mod:dev_remove+0}
       <ffffffff8804c7ba>{:dm_snapshot:snapshot_dtr+170} <ffffffff8803ab09>{:dm_mod:dm_table_put+121}
       <ffffffff8803a107>{:dm_mod:dm_put+87} <ffffffff8803c9c0>{:dm_mod:__hash_remove+144}
       <ffffffff8803d37c>{:dm_mod:dev_remove+76} <ffffffff8803e370>{:dm_mod:ctl_ioctl+640}
       <ffffffff8028bffd>{do_ioctl+125} <ffffffff8028c2cd>{vfs_ioctl+685}
       <ffffffff8028c33d>{sys_ioctl+77} <ffffffff80209c8a>{system_call+126}


Thank you for your help, if someone needs more information I can produce
it.
-- 
Brice Figureau <brice+dm daysofwonder com>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]