From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK71J-0001ef-1n for qemu-devel@nongnu.org; Mon, 04 Jul 2016 12:46:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bK71H-00029t-7B for qemu-devel@nongnu.org; Mon, 04 Jul 2016 12:46:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK71H-00029d-1A for qemu-devel@nongnu.org; Mon, 04 Jul 2016 12:46:51 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 973553B716 for ; Mon, 4 Jul 2016 16:46:50 +0000 (UTC) References: <20160704153823.16879-1-marcandre.lureau@redhat.com> <20160704163139.GM3763@redhat.com> From: Paolo Bonzini Message-ID: Date: Mon, 4 Jul 2016 18:46:47 +0200 MIME-Version: 1.0 In-Reply-To: <20160704163139.GM3763@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] char: do not use atexit cleanup handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , marcandre.lureau@redhat.com Cc: qemu-devel@nongnu.org On 04/07/2016 18:31, Daniel P. Berrange wrote: >> > Instead of using a atexit() handler, only run the chardev cleanup as >> > initially proposed at the end of main(), where there are less chance= s >> > (hic) of conflicts or other races. > This doesn't really seem all that much safer. There's still plenty of > chance that threads are running in the background at the end of the > main() method, so plenty of scope for the qemu_chr_cleanup() call to > cause threads to segv by destroying the chardevs they're using behind > their back. At this point you have stopped all CPUs and block devices. There is not much else that is going on in QEMU at all, at this point. The solution would be to stop those threads. Paolo > IIUC, the original intent here was that we call unlink() on the UNIX > socket paths when QEMU exits. >=20 > Surely we can come up with a way to that, and only that, upon exit, > without actually having to free the chardev memory with all the risks > that entails. >=20 > eg, have a qemu_chr_close() method that closes & cleans up resources, > separately from actually free'ing the Chardev struct with all the > risk of crashing concurrent threads that entails. >=20