From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmKri-0003HC-VT for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:23:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmKrc-0002C4-M7 for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:23:14 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:63457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmKrc-0002Bs-Dr for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:23:08 -0400 Received: by pbbro12 with SMTP id ro12so11776598pbb.4 for ; Wed, 04 Jul 2012 01:23:05 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4FF3FD5D.9020201@redhat.com> Date: Wed, 04 Jul 2012 10:22:53 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20120704041748.19100.95271.stgit@bling.home> In-Reply-To: <20120704041748.19100.95271.stgit@bling.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/2] pci: exit path cleanup and fix List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: qemu-devel@nongnu.org, mst@redhat.com Il 04/07/2012 06:39, Alex Williamson ha scritto: > We've currently got a bug in pci_unregister_device in the ordering of > calling the driver exit function and unregistering io regions. In > every driver memory regions are created in the init function and > destroyed in the exit function. By calling pci_unregister_io_regions > after the exit function, we're calling memory_region_del_subregion > with a pointer to a MemoryRegion that has already been destroyed. > > It's easy enough to change the ordering, but the exit function is > currently allowed to fail. Even if we wanted to restore the device > at that point, we've interrupted the mappings from the guest > perspective and it seems precarious at best whether an exit function > can fail and leave a usable device. Fortunately nobody has any > possibility of actually failing the exit path. Normally I'm a > proponent of error paths, but allowing an exit to fail is like > allowing free(3) to fail. > > So, firt redefine that exit can't fail, then fix the ordering of > pci_unregister_device(). If anyone has plans for a failure case in > the exit path, please speak now. Thanks, > > Alex > > --- > > Alex Williamson (2): > pci: Unregister BARs before device exit > pci: convert PCIUnregisterFunc to void > > > hw/ac97.c | 3 +-- > hw/e1000.c | 3 +-- > hw/eepro100.c | 3 +-- > hw/es1370.c | 3 +-- > hw/ide/cmd646.c | 4 +--- > hw/ide/ich.c | 4 +--- > hw/ide/piix.c | 4 +--- > hw/ide/via.c | 4 +--- > hw/intel-hda.c | 3 +-- > hw/ioh3420.c | 8 +++----- > hw/ivshmem.c | 4 +--- > hw/lsi53c895a.c | 4 +--- > hw/ne2000.c | 3 +-- > hw/pci.c | 11 +++++------ > hw/pci.h | 2 +- > hw/pci_bridge.c | 3 +-- > hw/pci_bridge.h | 2 +- > hw/pci_bridge_dev.c | 12 ++++-------- > hw/pcnet-pci.c | 3 +-- > hw/rtl8139.c | 3 +-- > hw/usb/hcd-uhci.c | 3 +-- > hw/virtio-pci.c | 23 +++++++++++------------ > hw/wdt_i6300esb.c | 4 +--- > hw/xio3130_downstream.c | 8 +++----- > hw/xio3130_upstream.c | 8 +++----- > 25 files changed, 48 insertions(+), 84 deletions(-) > > The diffstat caught my eye. :) Reviewed-by: Paolo Bonzini