From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwpx4-0001t7-EJ for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:26:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwpx1-0004Ix-AC for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:26:34 -0400 Received: from mail-lf0-x230.google.com ([2a00:1450:4010:c07::230]:34146) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bwpx1-0004IN-1Z for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:26:31 -0400 Received: by mail-lf0-x230.google.com with SMTP id b81so21885762lfe.1 for ; Wed, 19 Oct 2016 05:26:30 -0700 (PDT) Sender: Paolo Bonzini References: <20161012191502.GC16187@work-vm> <20161018100409.GH4349@redhat.com> <20161018113202.GE2190@work-vm> <20161018120121.GN4349@redhat.com> <20161018132524.GG2190@work-vm> <20161018133528.GD12728@redhat.com> <20161018135213.GI2190@work-vm> <20161018140141.GF12728@redhat.com> From: Paolo Bonzini Message-ID: Date: Wed, 19 Oct 2016 14:26:26 +0200 MIME-Version: 1.0 In-Reply-To: <20161018140141.GF12728@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] chardev's and fd's in monitors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , "Dr. David Alan Gilbert" Cc: qemu-devel@nongnu.org, armbru@redhat.com On 18/10/2016 16:01, Daniel P. Berrange wrote: >> > >> > I already use error_report's in places in migration threads of various >> > types; I'm not sure if that's a problem. > Unless those places are protected by the big qemu lock, that sounds > not good. error_report calls into error_vprintf which checks the > 'cur_mon' global "Monitor" pointer. This variable is updated at > runtime - eg in qmp_human_monitor_command(), monitor_qmp_read(), > monitor_read(), etc. So if migration threads outside the BQL are > calling error_report() that could well cause problems. If you > are lucky messages will merely end up going to stderr instead of > the monitor, but in worst case I wouldn't be surprised if there > is a crash possibility in some race conditions. Writes to chardevs *are* thread-safe (assuming qio_channel_create_watch is thread-safe; it seems to be). Only reads aren't, in the sense that they require an event loop so they use that event loop for serialization. Paolo