WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] A small issue with multiple xs_daemon_open

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] A small issue with multiple xs_daemon_open
From: Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 8 Jun 2010 12:15:37 +0200
Delivery-date: Tue, 08 Jun 2010 03:16:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.17 (2007-11-01)
Hello,
I am experiencing a problem when opening two simultaneous connections (in a
single process) to xenstored via xs_daemon_open(). I would think such
an operation is supported and should work (no static variables in
libxenstore are involved); is it a correct assumption ? If so, the issue 
should be fixed.

The environment is xen-3.4.3, 2.6.32.9-xxx pvops dom0. The order of
operations is
xs1=xs_daemon_open()
xs_watch(xs1,...)
xs_read_watch(xs1,...)
xs2=xs_daemon_open()
xs_read(xs2,...)
xs_daemon_close(xs2)
xs_read(xs1,...)
xs_daemon_close(xs1)

There seems to be some sort of a race when calling the second 
xs_daemon_close() - sometimes it hangs infinitely. Backtrace:
(gdb) info threads
  2 Thread 0x7fe64697c710 (LWP 4154)  0x00007fe646b8dc44 in __lll_lock_wait()
   from /lib64/libpthread.so.0
* 1 Thread 0x7fe6482d2700 (LWP 4153)  0x00007fe646b87bfd in pthread_join ()
   from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007fe646b87bfd in pthread_join () from /lib64/libpthread.so.0
#1  0x00007fe647776fdc in xs_daemon_close () from /usr/lib64/libxenstore.so.3.0
#2  0x000000000040660a in peer_client_init ()
#3  0x0000000000405808 in main ()
(gdb) thread 2 
[Switching to thread 2 (Thread 0x7fe64697c710 (LWP 4154))]#0
0x00007fe646b8dc44 in __lll_lock_wait ()
   from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007fe646b8dc44 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007fe646b88f15 in _L_lock_1017 () from /lib64/libpthread.so.0
#2  0x00007fe646b88de7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00007fe647775db8 in ?? () from /usr/lib64/libxenstore.so.3.0
#4  0x00007fe647775e3c in ?? () from /usr/lib64/libxenstore.so.3.0
#5  0x00007fe646b86a3a in start_thread () from /lib64/libpthread.so.0
#6  0x00007fe64729967d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()
(gdb) 

You can see the code for peer_client_init() at
http://qubes-os.org/gitweb/?p=rafal/gui.git;a=blob;f=gui-common/txrx-vchan.c;h=afc691e922edce61683e46203fd9597d029052d3;hb=93f0509b791f8fc433675c58c81f6ea9469d2c91#l168
it calls libvchan_client_init, code at
http://qubes-os.org/gitweb/?p=rafal/gui.git;a=blob;f=vchan/vchan/init.c;h=4a3da4f22907445160a6fe3db9ed357f89ebc301;hb=93f0509b791f8fc433675c58c81f6ea9469d2c91#l212
note that libvchan_client_init calls xs_daemon_open/close by itself, too.

Naturally it is posible to change peer_client_init() to not call 
xs_daemon_open twice, but the title issue itself remains.

Regards,
Rafal Wojtczuk
Principal Researcher
Invisible Things Lab, Qubes-os project

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

<Prev in Thread] Current Thread [Next in Thread>