[Xen-devel] dom0 panic when using xm block-attach/block-detach -f

[Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>]

Hi list,

I have an image with a bootable system and do the following steps:
# xm block-attach 0 tap:aio:my-image.iso xvda r
mount the root partition:
# mount /dev/xvda2 /mnt
Now forcing block-detach:
# xm block-detach 0 51712 -f

This leads to an inconsistent sysfs in dom0.
The xen device /sys/devices/xen/vbd-51712 gets removed but lots of links remain.

In the log I can see the message:
[  349.928350] vbd vbd-51712: 16 Device in use; refusing to close

The next call of
# xm block-attach 0 tap:aio:my-image.iso xvda r
leads to the panic, because creating of a sysfs entry failed
(it's already there) and a not existing failure handling (return of
register_disk() in add_disk()) leads to the panic later.

[  210.184660] WARNING: at /usr/src/linux-2.6.31.5-0.1/fs/sysfs/dir.c:489 
sysfs_add_one+0xde/0x150()
[  210.184662] Hardware name: CELSIUS H270
[  210.184663] sysfs: cannot create duplicate filename '/dev/block/202:0'
[  210.184664] Modules linked in: ext4 jbd2 crc16 netbk blkbk blkback_pagemap 
snd_pcm_oss snd_mixer_oss blktap snd_seq snd_seq_device edd ipv6 af_packet 
bridge stp llc fuse loop dm_mod arc4 ecb cryptomgr aead pcompress 
snd_hda_codec_realtek crypto_blkcipher crypto_hash crypto_algapi snd_hda_intel 
iwlagn snd_hda_codec iwlcore pcmcia snd_hwdep led_class snd_pcm ppdev mac80211 
snd_timer 8250_pci yenta_socket parport_pc 8250_pnp snd tpm_infineon 
rsrc_nonstatic i2c_i801 parport iTCO_wdt 8250 soundcore cfg80211 intel_agp tpm 
e1000e video pcmcia_core i2c_core heci(C) iTCO_vendor_support sr_mod sg pcspkr 
serio_raw joydev serial_core snd_page_alloc rfkill agpgart tpm_bios output 
container battery button ac usbhid hid uhci_hcd ehci_hcd xenblk cdrom xennet 
fan thermal processor thermal_sys hwmon ide_pci_generic ide_core sata_sil24 
ata_generic
[  210.184697] Pid: 15, comm: xenwatch Tainted: G         C 
2.6.31.5-0.1-xen-hahn #9
[  210.184698] Call Trace:
[  210.184701]  [<ffffffff800117e9>] try_stack_unwind+0x189/0x1b0
[  210.184704]  [<ffffffff8000f2c6>] dump_trace+0xa6/0x1e0
[  210.184707]  [<ffffffff800112f4>] show_trace_log_lvl+0x64/0x90
[  210.184710]  [<ffffffff80011343>] show_trace+0x23/0x40
[  210.184712]  [<ffffffff80460e6e>] dump_stack+0x81/0x9e
[  210.184717]  [<ffffffff8004cf50>] warn_slowpath_common+0x80/0xd0
[  210.184720]  [<ffffffff8004d02b>] warn_slowpath_fmt+0x4b/0x70
[  210.184723]  [<ffffffff8018f48e>] sysfs_add_one+0xde/0x150
[  210.184726]  [<ffffffff8018fb3b>] sysfs_do_create_link+0x17b/0x200
[  210.184729]  [<ffffffff8018fc21>] sysfs_create_link+0x21/0x40
[  210.184732]  [<ffffffff802e0375>] device_add+0x1d5/0x620
[  210.184734]  [<ffffffff80185e76>] register_disk+0x66/0x1c0
[  210.184737]  [<ffffffff8022212b>] add_disk+0xcb/0x1b0
[  210.184742]  [<ffffffffa0098cb4>] backend_changed+0x354/0x3a0 [xenblk]
[  210.184746]  [<ffffffff802fb952>] otherend_changed+0xf2/0x1c0
[  210.184749]  [<ffffffff802f931c>] xenwatch_handle_callback+0x2c/0x80
[  210.184752]  [<ffffffff802f9538>] xenwatch_thread+0x1c8/0x200
[  210.184755]  [<ffffffff8006cf96>] kthread+0xb6/0xc0
[  210.184758]  [<ffffffff8000d25a>] child_rip+0xa/0x20
[  210.184760] ---[ end trace 2db54c629bf6d53c ]---
...

The problem seems to be that in backend_changed() the device is seen as in use
and so blkfront_closing() -> xlvbd_del() -> del_gendisk()
isn't called to remove the links but later the xen device gets removed.

What to do here?
If a user of the -f flag "SHOULD know what he is doing" than the manual page
of the xm command has to be changed.
Ohterwise how can this be solved?

Thanks.
Dietmar.

This was testet on OpenSuSE-11.2 with xen-3.4 and linux-2.6.31.5,
don't know about xen-unstable!

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel