Re: [libvirt] [PATCH] create a thread to handle MigrationParamResetto avoid deadlock

On Mon, Dec 23, 2019 at 04:50:00PM +0100, Michal Prívozník wrote: > On 12/23/19 11:12 AM, Daniel P. Berrangé wrote: > > On Mon, Dec 23, 2019 at 03:13:10PM +0800, Yi Wang wrote: > >> From: Li XueLei <li.xuelei1(a)zte.com.cn&gt; > >> > >> Libvirtd no longer receives external requests, after I do the following. > >>

> > > > Libvirt allows multiple connections concurrently and changes made by one > > connection are supposed to apply globally. No per-VM state should be tied > > to a particular connection. > > This is generally very true, except for migration. Hmm, so in that case we do need to make sure this runs from a non-main event thread as this patch does. I'm surprised we've not seen this before though - i'd think it should be a guaranteed deadlock anytime someone tests this scenario. > > > > > IOW, I don't think we need a thread. We should just stop calling > > qemuMigrationSrcCleanup from the connection close callback entirely > > But I agree that something fishy is going on and this doesn't look like > proper solution. Yi, can you please share the backtrace of other threads > too? Why aren't we getting any reply on the monitor? qemuMonitorSend() just puts date onto the TX queue & waits for the main event loop to send it. We're invoking qemuMonitorSend from the main event loop in this backtrace, hence it'll wait forever for the thread to send it. qemuMonitorSend must never be invoked from the main event thread.

Regards, Daniel