xencommons: kill xenstored when stop xencommons
PATCH 1/1 xencommons: kill xenstored when stop xencommons
xenstored should be killed when stop xencommons.
tools/hotplug/Linux/init.d/xencommons +8 -1
@@ -21,6 +21,7 @@ test -f /etc/sysconfig/xencommons && . /etc/sysconfig/xencommons +XENSTORED_PIDFILE=/var/run/xenstore.pid XENCONSOLED_PIDFILE=/var/run/xenconsoled.pid shopt -s extglob
@@ -43,7 +44,7 @@ test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored" rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log" - xenstored --pid-file=/var/run/xenstore.pid $XENSTORED_ARGS + xenstored --pid-file=$XENSTORED_PIDFILE $XENSTORED_ARGS xenstore-write "/local/domain/0/name" "Domain-0" fi
@@ -53,6 +54,12 @@ test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS } do_stop () { + if read 2>/dev/null <$XENSTORED_PIDFILE pid; then + kill $pid + while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done + rm -f $XENSTORED_PIDFILE + fi + if read 2>/dev/null <$XENCONSOLED_PIDFILE pid; then kill $pid while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
Hi,
tools/hotplug/Linux/init.d/xencommons line 62
Quoted 10 lines · Yu Zhiguo
xenstored should be killed when stop xencommons.
do_stop() {tools/hotplug/Linux/init.d/xencommons +6
-0+ if read 2>/dev/null <$XENSTORED_PIDFILE pid; then + kill $pid + while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done + rm -f $XENSTORED_PIDFILE + fi +
It seems that kill xenstored will get taint message about 'HARDIRQ-safe -> HARDIRQ-unsafe'.
Maybe some fix is needed here...
# service xencommons start # cat /var/run/xenstore.pid 1446 # kill -9 1446
Jun 22 22:51:10 localhost kernel: ======================================================
Jun 22 22:51:10 localhost kernel: [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
Jun 22 22:51:10 localhost kernel: 2.6.31.13 #2
Jun 22 22:51:10 localhost kernel: ------------------------------------------------------
Jun 22 22:51:10 localhost kernel: xenstored/1446 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
Jun 22 22:51:10 localhost kernel: (proc_subdir_lock){+.+...}, at: [<ffffffff8119c60f>] xlate_proc_name+0x4c/0xde
Jun 22 22:51:10 localhost kernel:
Jun 22 22:51:10 localhost kernel: and this task is already holding:
Jun 22 22:51:10 localhost kernel: (&port_user_lock){-.....}, at: [<ffffffff8131d3fe>] evtchn_release+0x3a/0xb8
Jun 22 22:51:10 localhost kernel: which would create a new lock dependency:
Jun 22 22:51:10 localhost kernel: (&port_user_lock){-.....} -> (proc_subdir_lock){+.+...}
Jun 22 22:51:10 localhost kernel:
Jun 22 22:51:10 localhost kernel: but this new dependency connects a HARDIRQ-irq-safe lock:
Jun 22 22:51:10 localhost kernel: (&port_user_lock){-.....}
Jun 22 22:51:10 localhost kernel: ... which became HARDIRQ-irq-safe at:
Jun 22 22:51:10 localhost kernel: [<ffffffff8109915d>] __lock_acquire+0x254/0xc0e
Jun 22 22:51:10 localhost kernel: [<ffffffff81099c05>] lock_acquire+0xee/0x12e
Jun 22 22:51:10 localhost kernel: [<ffffffff81521f7f>] _spin_lock+0x45/0x8e
Jun 22 22:51:10 localhost kernel: [<ffffffff8131dbfd>] evtchn_interrupt+0x3a/0x13f
Jun 22 22:51:10 localhost kernel: [<ffffffff810c7dd4>] handle_IRQ_event+0x62/0x148
Jun 22 22:51:10 localhost kernel: [<ffffffff810ca367>] handle_level_irq+0x90/0xf9
Jun 22 22:51:10 localhost kernel: [<ffffffff813151f1>] xen_evtchn_do_upcall+0x120/0x1c7
Jun 22 22:51:10 localhost kernel: [<ffffffff8101637e>] xen_do_hypervisor_callback+0x1e/0x30
Jun 22 22:51:10 localhost kernel: [<ffffffffffffffff>] 0xffffffffffffffff
Jun 22 22:51:10 localhost kernel:
Jun 22 22:51:10 localhost kernel: to a HARDIRQ-irq-unsafe lock:
Jun 22 22:51:10 localhost kernel: (proc_subdir_lock){+.+...}
Jun 22 22:51:10 localhost kernel: ... which became HARDIRQ-irq-unsafe at:
Jun 22 22:51:10 localhost kernel: ... [<ffffffff810991d1>] __lock_acquire+0x2c8/0xc0e
Jun 22 22:51:10 localhost kernel: [<ffffffff81099c05>] lock_acquire+0xee/0x12e
Jun 22 22:51:10 localhost kernel: [<ffffffff81521f7f>] _spin_lock+0x45/0x8e
Jun 22 22:51:10 localhost kernel: [<ffffffff8119c60f>] xlate_proc_name+0x4c/0xde
Jun 22 22:51:10 localhost kernel: [<ffffffff8119d370>] __proc_create+0x53/0x148
Jun 22 22:51:10 localhost kernel: [<ffffffff8119d75d>] proc_symlink+0x3e/0xc5
Jun 22 22:51:10 localhost kernel: [<ffffffff81a49c03>] proc_root_init+0x75/0xe0
Jun 22 22:51:10 localhost kernel: [<ffffffff81a2063b>] start_kernel+0x403/0x44c
Jun 22 22:51:10 localhost kernel: [<ffffffff81a1f930>] x86_64_start_reservations+0xbb/0xd6
Jun 22 22:51:10 localhost kernel: [<ffffffff81a23e98>] xen_start_kernel+0x5e3/0x5ea
Jun 22 22:51:10 localhost kernel: [<ffffffffffffffff>] 0xffffffffffffffff
Jun 22 22:51:10 localhost kernel:
Jun 22 22:51:10 localhost kernel: other info that might help us debug this:...
Quoted 6 lines · Yu Zhiguo
Hi,
Quoted 2 lines · Yu Zhiguo
xenstored should be killed when stop xencommons.
Quoted 12 lines
tools/hotplug/Linux/init.d/xencommons line 62
Quoted 7 lines
do_stop() {tools/hotplug/Linux/init.d/xencommons +6
-0+ if read 2>/dev/null <$XENSTORED_PIDFILE pid; then + kill $pid + while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done + rm -f $XENSTORED_PIDFILE + fi +It seems that kill xenstored will get taint message about 'HARDIRQ-safe -> HARDIRQ-unsafe'.
Maybe some fix is needed here...
Killing xenstored has never been a "supported" operation so far. In fact before xencommons was introduced, xenstored was never killed AFAIK.
Quoted 3 lines · Stefano Stabellini
Killing xenstored has never been a "supported" operation so far. In fact before xencommons was introduced, xenstored was never killed AFAIK.
ocaml xenstored supports (or use to [1]) the restart operation. IIRC,
even domU can be kept running without problems providing xenstored is restarted at some point and the domain wasn't doing anything over xenstored at the stop time.
[1] and can be remade to work easily if beeing broken
Signature · 1 line
Vincent
Yu Zhiguo writes ("[PATCH] xencommons: kill xenstored when stop xencommons"):
Quoted 1 line
xenstored should be killed when stop xencommons.
No, it should not. xenstored should not normally be stopped. If you don't stop xenstored you can switch toolstacks, restart xend, etc. etc. without disruption to running domains.
Ian.