Bug 701136 - dm's hard days of corrupting kernel space AKA resuming suspended blockdev for a table reload
Summary: dm's hard days of corrupting kernel space AKA resuming suspended blockdev for...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-01 13:09 UTC by Yuri Arabadji
Modified: 2011-05-01 15:16 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-01 13:28:57 UTC
Type: ---


Attachments (Terms of Use)
fc14 kernel crash info (9.52 KB, text/plain)
2011-05-01 13:09 UTC, Yuri Arabadji
no flags Details
fc15 kernel crash info (17.33 KB, text/plain)
2011-05-01 13:10 UTC, Yuri Arabadji
no flags Details
centos 5.6 kernel trace (30.01 KB, text/plain)
2011-05-01 13:28 UTC, Yuri Arabadji
no flags Details

Description Yuri Arabadji 2011-05-01 13:09:16 UTC
Created attachment 496058 [details]
fc14 kernel crash info

The thing's happening everywhere, on each latest FC and, more importantly (for me), on CentOS 5.6.

Description of problem:

dm's doing bad things where it shouldn't. I would be fine with just "doesn't compute" in case it's supplied wrong or meaningless parameters.

As discussed in IRC, i'm trying to implement pvmove-like functionality using userspace and for general blockdevs. That is, a live data migration from one blockdev to another.

Here's a test case #1, centos 5.6:
==============================
root.net [~]# dmsetup create src.ptr
0 2097152 linear /dev/fused/src 0

root.net [~]# dmsetup suspend /dev/fused/src
root.net [~]# dmsetup create src.mir
0 2097152  mirror core 2 1024 block_on_error 2 /dev/mapper/src.ptr 0 /dev/fused/dst 0
root.net [~]# dmsetup reload /dev/fused/src
0 2097152 linear /dev/mapper/src.mir 0
root.net [~]# dmsetup resume fused-src
Read from remote host x30.fused.net: Connection reset by peer
==============================

test case #2, FC14,15, essentially the same. I've tried various combinations of suspension and resuming, no one worked.

==============================
echo '0 1048576 linear /dev/base/src 0' | dmsetup create src.ptr
dmsetup suspend /dev/base/src
echo '0 1048576 linear /dev/sdb 0' | dmsetup create dst.ptr

echo '0 1048576 mirror core      1        1024    2 /dev/mapper/src.ptr 0 /dev/mapper/dst.ptr 0' |  dmsetup create src.mir

echo '0 1048576 linear /dev/mapper/src.mir 0' | dmsetup reload /dev/base/src

dmsetup resume /dev/base/src
==============================

I would be highly grateful if you could fix this or at least tell me the right way to do it.

Thanks.

Comment 1 Yuri Arabadji 2011-05-01 13:10:21 UTC
Created attachment 496059 [details]
fc15 kernel crash info

Comment 2 Yuri Arabadji 2011-05-01 13:28:11 UTC
Created attachment 496060 [details]
centos 5.6 kernel trace

Comment 3 Alasdair Kergon 2011-05-01 13:28:57 UTC
I glanced at the first example - it's not a bug, you created a loop!
Bugzilla is for dealing with bugs - please use mailing lists (e.g. dm-devel) or IRC if you need usage help.

Comment 4 Yuri Arabadji 2011-05-01 15:16:28 UTC
Indeed I did! What a stupid mistake, src.ptr supposed to have src's table, not pointer to src :) And with that error corrected, everything works as it should. What a flexible software this device-mapper is :)

Alasdair, thanks for pointing out the mistake and for suggestions on IRC, it will make my journey through dm land much easier.


And for anyone coming here from google, if you've got that stack trace, you have a loop :)


Note You need to log in before you can comment on or make changes to this bug.