From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36908 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxGEB-0006h4-Vu for qemu-devel@nongnu.org; Wed, 09 Mar 2011 05:02:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxGE9-0002Ta-Te for qemu-devel@nongnu.org; Wed, 09 Mar 2011 05:02:46 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:54859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxGE9-0002Sl-J3 for qemu-devel@nongnu.org; Wed, 09 Mar 2011 05:02:45 -0500 Message-ID: <4D77503D.6070605@web.de> Date: Wed, 09 Mar 2011 11:02:37 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: segmentation fault in qemu-kvm-0.14.0 References: <2640D58E-2101-47FA-99B6-28815666651E@dlh.net> <4D772E4C.6020604@web.de> <4D774282.9060102@web.de> <4D774F54.2050004@web.de> In-Reply-To: <4D774F54.2050004@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E6A631001F3FBF3FCD658E7" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corentin Chary Cc: Peter Lieven , qemu-devel , kvm@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E6A631001F3FBF3FCD658E7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-03-09 10:58, Jan Kiszka wrote: > On 2011-03-09 10:54, Corentin Chary wrote: >> Re-reading: >> >>>> So we are calling a IOHandlerRecord::fd_write handler that is NULL. >>>> Looking at qemu_set_fd_handler2, this may happen if that function is= >>>> called for an existing io-handler entry with non-NULL write handler,= >>>> passing a NULL write and a non-NULL read handler. And all this witho= ut >>>> the global mutex held. >> >> When using the vnc thread, nothing in the vnc thread will never be >> called directly by an IO-handler. So I don't really how in would >> trigger this. >> And since there is a lock for accessing the output buffer (and the >> network actually), there should not be any race condition either. >> >> So the real issue, is that qemu_set_fd_handler2() is called outside of= >> the main thread by those two vnc_write() and vnc_flush() calls, >> without any kind of locking. >=20 > Yes, that's what I was referring to. >=20 >> >>> In upstream qemu, the latter - if it exists (which is not the case in= >>> non-io-thread mode). >>> In qemu-kvm, those locks are yet unused. Rather the code in qemu-kvm.= c >>> implements the global lock. >> >> So there is currently no lock for that when io-thread is disabled :/. >> Spice also seems to project this kind of thing with >> qemu_mutex_lock_iothread(). >> >> Maybe qemu_mutex_lock_iothread() should also be defined when >> CONFIG_VNC_THREAD=3Dy ? >> >>> But I'm also not sure about vnc_send_framebuffer_update. Someone has = to >>> go through the threaded vnc code again, very thoroughly. It looks fra= gile. >> >> while vnc-thread is enabled vnc_send_framebuffer_update() will always >> call vnc_write() with csock =3D -1 in a temporary buffer. Check >> vnc_async_encoding_start() and vnc_async_encoding_end(), they provide >> a kind of "sandbox" that prevent the thread to write anything the >> main-thread will use. You can also see that as a "transaction": the >> thread compute the update in a temporary buffer, and only send it to >> the network (real vnc_write calls with csock correctly set) once it's >> successfully finished. >> >> The is only two functions calls that break this isolation are the two >> that I pointed out earlier. >=20 > Probably the best way is to make vnc stop fiddling with > qemu_set_fd_handler2, specifically in threaded mode. Why does it need t= o > set/reset the write handler all the time? The other question is: Who's responsible for writing to the client socket in threaded mode? Only the vnc thread(s), or also other qemu threads? In the former case, just avoid setting a write handler at all. Jan --------------enig4E6A631001F3FBF3FCD658E7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk13UD4ACgkQitSsb3rl5xQ5JwCgrd9TKz12ByUi8Aebi1AJsven /9wAoJcS6rPwHNvHi+xSidFjzKeb+lXH =to1/ -----END PGP SIGNATURE----- --------------enig4E6A631001F3FBF3FCD658E7--