[PATCH] xencommons: kill xenstored when stop xencommons

[PATCH] xencommons: kill xenstored when stop xencommons

[Yu Zhiguo]

xenstored should be killed when stop xencommons.

Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>

diff -r 72c6228b5f0f -r be32d4fe1e8a tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Mon Jun 21 19:19:25 2010 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Jun 22 17:39:37 2010 +0800
@@ -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

Re: [PATCH] xencommons: kill xenstored when stop xencommons

[Yu Zhiguo]

Hi,

Yu Zhiguo wrote:
> xenstored should be killed when stop xencommons.
> 

>  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
> +


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:
...

Re: [PATCH] xencommons: kill xenstored when stop xencommons

[Stefano Stabellini]

On Tue, 22 Jun 2010, Yu Zhiguo wrote:
> Hi,
> 
> Yu Zhiguo wrote:
> > xenstored should be killed when stop xencommons.
> > 
> 
> >  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
> > +
> 
> 
> 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.

Re: [PATCH] xencommons: kill xenstored when stop xencommons

[Ian Jackson]

Yu Zhiguo writes ("[PATCH] xencommons: kill xenstored when stop xencommons"):
> 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.

Re: [PATCH] xencommons: kill xenstored when stop xencommons

[Vincent Hanquez]

On 22/06/10 11:07, Stefano Stabellini wrote:
> 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
-- 
Vincent