Creating a vm with a non-existent /dev/mapper/ tap2 device effectively hangs dom0 system

[Nathan March <nathan@gt.net>]

Have an interesting one here, originally found on xen 4.1.0 but just 
upgraded to xen 4.1.1 and it's still here.

Creating a VM with a tap2 device pointed at /dev/mapper/something, when 
that device doesn't exist, causes the tapdisk2 process to go into D mode 
and also manages to take out any process that queries it.

For example, I have /dev/mapper/nathanxenuk1 as a valid disk and 
/dev/mapper/test which doesn't exist. Creating using libvirt:

<opt type="xen">
<name>nathanxenuk1</name>
<devices>
<disk type="file">
<driver name="tap2" cache="default" type="aio" />
<source file="/dev/mapper/nathanxenuk1" />
<target dev="xvda" />
</disk>
<disk type="file">
<driver name="tap2" cache="default" type="aio" />
<source file="/dev/mapper/test" />
<target dev="xvdc" />
</disk>
<interface type="bridge">
<mac address="00:16:3E:10:00:01" />
<script path="/etc/xen/scripts/vif-bridge" />
<source bridge="vlan91" />
</interface>
</devices>
<memory>4194304</memory>
<os>
<bootloader>/usr/bin/pygrub</bootloader>
<type>linux</type>
</os>
<vcpu>12</vcpu>
</opt>

Results in:
libvirt error code: 11, message: POST operation failed: xend_post: error 
from xen daemon: (xend.err "Error creating domain: ('create', 
'-aaio:/dev/mapper/test') failed (512  )")

Normal so far and what I'd expect. At this point however doing anything 
that queries that tapdisk2 pid in /proc/ will fully hang.

Doing an "strace -f ps auxf &" (Backgrounding so I can keep my console), 
it ends here and I can find the pid causing it:

open("/proc/11327/status", O_RDONLY)    = 6
read(6, "Name:\ttapdisk2\nState:\tD (disk sl"..., 1023) = 706
close(6)                                = 0
open("/proc/11327/cmdline", O_RDONLY)   = 6
read(6,

Trying to do almost anything against /proc/11327/ results in a hang, but 
I can see the FD's ok:

ukxen2 ~ # cd /proc/11327
ukxen2 11327 # ls -al &
[2] 12144

ukxen2 11327 # cd fd
ukxen2 fd # ls -al &
[3] 12211
ukxen2 fd # total 0
dr-x------ 2 root root  0 Jul 27 16:24 .
dr-xr-xr-x 7 root root  0 Jul 27 16:16 ..
lrwx------ 1 root root 64 Jul 27 16:27 0 -> /dev/null
lrwx------ 1 root root 64 Jul 27 16:27 1 -> /dev/null
lrwx------ 1 root root 64 Jul 27 16:27 2 -> /dev/null
lrwx------ 1 root root 64 Jul 27 16:27 3 -> socket:[39528]
lrwx------ 1 root root 64 Jul 27 16:27 4 -> anon_inode:[eventfd]
lrwx------ 1 root root 64 Jul 27 16:27 5 -> socket:[39531]
lrwx------ 1 root root 64 Jul 27 16:27 6 -> socket:[40730]
[3]+  Done                    ls --color=auto -al
ukxen2 fd #

And /proc/11327/status works:

ukxen2 11327 # cat status &
[3] 12236
ukxen2 11327 # Name:    tapdisk2
State:  D (disk sleep)
Tgid:   11327
Pid:    11327
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 64
Groups:
VmPeak:    23056 kB
VmSize:    21644 kB
VmLck:     21640 kB
VmHWM:      3848 kB
VmRSS:      3232 kB
VmData:      364 kB
VmStk:        88 kB
VmExe:       224 kB
VmLib:      2460 kB
VmPTE:        64 kB
Threads:        1
SigQ:   2/6081
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000181000242
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed:   1
Cpus_allowed_list:      0
Mems_allowed:   1
Mems_allowed_list:      0
voluntary_ctxt_switches:        4155
nonvoluntary_ctxt_switches:     3559

Even doing an ls or trying to use tab completion in /proc/11327/ will 
result in your proc going into D mode.

Any existing VM's stay running fine and I can manage them remotely via 
libvirt, so only the dom0 is affected.

Any ideas? =)

Thanks,
Nathan

-- 
Nathan March<nathan@gt.net>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806