From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38454 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxGAK-0004Ud-L6 for qemu-devel@nongnu.org; Wed, 09 Mar 2011 04:58:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxGAJ-0001eC-MP for qemu-devel@nongnu.org; Wed, 09 Mar 2011 04:58:48 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:48776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxGAJ-0001dt-AD for qemu-devel@nongnu.org; Wed, 09 Mar 2011 04:58:47 -0500 Message-ID: <4D774F54.2050004@web.de> Date: Wed, 09 Mar 2011 10:58:44 +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> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig069FB6B9D7E37844FB8682F3" 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) --------------enig069FB6B9D7E37844FB8682F3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-03-09 10:54, Corentin Chary wrote: > Re-reading: >=20 >>> 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 withou= t >>> the global mutex held. >=20 > 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. >=20 > 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. 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. >=20 > 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(). >=20 > Maybe qemu_mutex_lock_iothread() should also be defined when > CONFIG_VNC_THREAD=3Dy ? >=20 >> But I'm also not sure about vnc_send_framebuffer_update. Someone has t= o >> go through the threaded vnc code again, very thoroughly. It looks frag= ile. >=20 > 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. >=20 > The is only two functions calls that break this isolation are the two > that I pointed out earlier. Probably the best way is to make vnc stop fiddling with qemu_set_fd_handler2, specifically in threaded mode. Why does it need to set/reset the write handler all the time? Jan --------------enig069FB6B9D7E37844FB8682F3 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/ iEYEARECAAYFAk13T1QACgkQitSsb3rl5xSbAACfZjYpxtANtE/Joit/Q3/AFsgS CHsAoM3FBjAVbm3AW/yjcaJg0Pjdf4e2 =0WMT -----END PGP SIGNATURE----- --------------enig069FB6B9D7E37844FB8682F3--