From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJkIM-0007Kj-T7 for qemu-devel@nongnu.org; Sun, 24 Mar 2013 08:45:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJkIL-00031g-W5 for qemu-devel@nongnu.org; Sun, 24 Mar 2013 08:45:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJkIL-0002tO-Ol for qemu-devel@nongnu.org; Sun, 24 Mar 2013 08:45:05 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2OCj22G001013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 24 Mar 2013 08:45:02 -0400 From: Hans de Goede Date: Sun, 24 Mar 2013 13:48:26 +0100 Message-Id: <1364129307-12873-1-git-send-email-hdegoede@redhat.com> Subject: [Qemu-devel] [PATCH 0/1] usb-serial: Remove double call to qemu_chr_add_handlers( NULL ) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org usb-serial has a qdev chardev property, and hw/qdev-properties-system.c already contains: static void release_chr(Object *obj, const char *name, void *opaque) { DeviceState *dev = DEVICE(obj); Property *prop = opaque; CharDriverState **ptr = qdev_get_prop_ptr(dev, prop); if (*ptr) { qemu_chr_add_handlers(*ptr, NULL, NULL, NULL, NULL); } } So doing the qemu_chr_add_handlers(s->cs, NULL, NULL, NULL, NULL); from the usb handle_destroy function too will lead to it being done twice, which will result in a wrong value for cs->avail_connections. Note: 1) I noticed this will working on other stuff, but I've not actually seen this happening (I did not try to trigger it), so please review carefully. 2) There are other places which are doing a qemu_chr_add_handlers( NULL ) too, but those don't use a qdev chardev property, so this does not apply: backends/rng-egd.c hw/serial.c hw/xen_console.c backends/rng-egd.c is weird / suspect here since it uses a qdev string property for the chardev and then uses qemu_chr_find to get it. I wonder why it is not simply using a chardev property rather then a string property? Regards, Hans