All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Fehlig <jfehlig@suse.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: libvir-list@redhat.com, andrew.cooper3@citrix.com,
	xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [libvirt] [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when doing 'virsh <domid> save /tmp/blah' with guest corrupting memory (on purpose).
Date: Thu, 16 Apr 2015 10:44:51 -0600	[thread overview]
Message-ID: <552FE703.3080208@suse.com> (raw)
In-Reply-To: <21805.20207.220139.608551@mariner.uk.xensource.com>

On 04/14/2015 11:31 AM, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("libvirtd live-locking on CTX_LOCK when doing 'virsh <domid> save /tmp/blah' with guest corrupting memory (on purpose)."):
>> It looks like thread #10 is blocking in libxl_read_exactly waiting
>> for 'libxl-save-helper'. Said application (see below) has dispatched
>> an message through helper_getreply and is blocking on __read_nocancel.
> This is not supposed to block.
>
> helper_stdout_readable assumes that the fd is actually readable.
> However, for complicated reasons it can happen in a multithreaded
> program that the fd was _reviously_ readable and is now no longer.
>
> This was not clearly documented in the internal API documentation.
>
> I have produced what I think are two patches that will fix this.  I
> have compiled them but I haven't tested them.  Konrad, are you able to
> check whether they fix your bug ?

I too saw this bug just before Konrad's report, but the patches don't seem to 
help.  Running a script that continually saves and restores domains will 
eventually lock libvirtd with essentially the same traces reported by Konrad

Thread 4 (Thread 0x7fffee3a0700 (LWP 39068)):
#0  0x00007ffff3a9aa9d in read () from /lib64/libpthread.so.0
#1  0x00007ffff4540ea0 in libxl_read_exactly (ctx=0x7fffe00445e0, fd=37, 
data=0x7fffee39f36e,
     sz=2, source=0x7fffc80010c0 "domain 6 save/restore helper stdout pipe",
     what=0x7ffff458112a "ipc msg header") at libxl_utils.c:430
#2  0x00007ffff454913a in helper_stdout_readable (egc=0x7fffee39f540, 
ev=0x7fffc8002038, fd=37,
     events=3, revents=1) at libxl_save_callout.c:281
#3  0x00007ffff454fafb in afterpoll_internal (egc=0x7fffee39f540, 
poller=0x7fffe0000a00, nfds=4,
     fds=0x7fffe0000930, now=...) at libxl_event.c:1185
#4  0x00007ffff455127a in eventloop_iteration (egc=0x7fffee39f540, 
poller=0x7fffe0000a00)
     at libxl_event.c:1645
#5  0x00007ffff4551df1 in libxl__ao_inprogress (ao=0x7fffc8001060, 
file=0x7ffff4575e1b "libxl.c",
     line=982, func=0x7ffff4578750 <__func__.17561> "libxl_domain_suspend") at 
libxl_event.c:1896
#6  0x00007ffff450e051 in libxl_domain_suspend (ctx=0x7fffe00445e0, domid=6, 
fd=29, flags=0,
     ao_how=0x0) at libxl.c:982
#7  0x00007fffe8774636 in libxlDoDomainSave (driver=0x7fffe011f1c0, 
vm=0x7fffe004f950,
     to=0x7fffc8000990 "/tmp/sles12gm-pv.img") at libxl/libxl_driver.c:1584
#8  0x00007fffe8774a35 in libxlDomainSaveFlags (dom=0x7fffc8000de0,
     to=0x7fffc8000990 "/tmp/sles12gm-pv.img", dxml=0x0, flags=0) at 
libxl/libxl_driver.c:1653
#9  0x00007fffe8774b11 in libxlDomainSave (dom=0x7fffc8000de0,
     to=0x7fffc8000990 "/tmp/sles12gm-pv.img") at libxl/libxl_driver.c:1678
#10 0x00007ffff751db15 in virDomainSave (domain=0x7fffc8000de0,
     to=0x7fffc80009d0 "/tmp/sles12gm-pv.img") at libvirt-domain.c:839
...

Thread 1 (Thread 0x7ffff7fc18c0 (LWP 39059)):
#0  0x00007ffff3a9a7bc in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007ffff3a964a4 in _L_lock_952 () from /lib64/libpthread.so.0
#2  0x00007ffff3a96306 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00007ffff454caf6 in libxl__ctx_lock (ctx=0x7fffe00445e0) at 
libxl_internal.h:3268
#4  0x00007ffff454fe98 in libxl_osevent_occurred_fd (ctx=0x7fffe00445e0,
     for_libxl=0x7fffe004f210, fd=32, events_ign=0, revents_ign=1) at 
libxl_event.c:1242
#5  0x00007fffe8770573 in libxlFDEventCallback (watch=24, fd=32, vir_events=1,
     fd_info=0x555555896c60) at libxl/libxl_driver.c:123
#6  0x00007ffff73f71bc in virEventPollDispatchHandles (nfds=14, fds=0x555555897fa0)
     at util/vireventpoll.c:508
#7  0x00007ffff73f79f9 in virEventPollRunOnce () at util/vireventpoll.c:657
#8  0x00007ffff73f58fa in virEventRunDefaultImpl () at util/virevent.c:308
#9  0x00005555555c2131 in virNetServerRun (srv=0x555555889980) at 
rpc/virnetserver.c:1139
#10 0x000055555556cf88 in main (argc=2, argv=0x7fffffffe378) at libvirtd.c:1489

Regards,
Jim

  parent reply	other threads:[~2015-04-16 16:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 14:47 [libvirt] libvirtd live-locking on CTX_LOCK when doing 'virsh <domid> save /tmp/blah' with guest corrupting memory (on purpose) Konrad Rzeszutek Wilk
2015-04-08 15:45 ` Andrew Cooper
2015-04-10 15:44   ` Konrad Rzeszutek Wilk
2015-04-10 16:05     ` Andrew Cooper
2015-04-14 17:31 ` [libvirt] [PATCH 0/2] " Ian Jackson
2015-04-14 17:31   ` [PATCH 1/2] libxl: fd events: Document spurious callbacks, break out libxl__ev_fd_recheck Ian Jackson
2015-04-14 17:31     ` [PATCH 2/2] libxl: save helper: Recheck fd events Ian Jackson
2015-04-16 13:02       ` Ian Campbell
2015-04-16 14:23         ` Ian Jackson
2015-04-16 13:01     ` [PATCH 1/2] libxl: fd events: Document spurious callbacks, break out libxl__ev_fd_recheck Ian Campbell
2015-04-16 16:44   ` Jim Fehlig [this message]
2015-04-16 17:18     ` [libvirt] [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when doing 'virsh <domid> save /tmp/blah' with guest corrupting memory (on purpose) Ian Jackson
2015-04-17  8:58       ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=552FE703.3080208@suse.com \
    --to=jfehlig@suse.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=libvir-list@redhat.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.