On Thu, 7 Jan 2021 10:45:26 +0100 BALATON Zoltan <bala...@eik.bme.hu> wrote:
> On Thu, 7 Jan 2021, Greg Kurz wrote: > > On Wed, 6 Jan 2021 16:24:01 +0100 > > BALATON Zoltan via <qemu-...@nongnu.org> wrote: > > > >> Use the PCI_BUS type cast macro to convert result of > >> qdev_get_child_bus(). Also remove the check for NULL afterwards which > >> should not be needed because sysbus_create_simple() uses error_abort > > > > It seems to me that sysbus_create_simple() doesn't return NULL because > > it ends up calling object_new_with_type(). This allocates the object > > with either g_malloc() or qemu_memalign(), both of which abort on > > failure. > > > >> and PCI_BUS macro also checks its argument by default so this > > > > AFAICT, PCI_BUS() and all other instance type checking macros are > > happy with a NULL argument. They simply return NULL in this case. > > This wasn't my experience when I've got an error in code and got a NULL > pointer here (on pegasos2 board but same situation). At least with > qom-debug enabled (which I think is on by default unless explicitly > disabled in configure) this will abort if the object is not the right > type. > You're right that qom-cast-debug is enabled by default and that it causes object_dynamic_cast_assert() to abort on type mismatch, but definitely not with a NULL value, as mentioned in this very old commit: commit b7f43fe46029d8fd0594cd599fa2599dcce0f553 Author: Paolo Bonzini <pbonz...@redhat.com> Date: Fri Nov 23 16:56:17 2012 +0100 qom: dynamic_cast of NULL is always NULL Trying to cast a NULL value will cause a crash. Returning NULL is also sensible, and it is also what the type-unsafe DO_UPCAST macro does. Reported-by: Markus Armbruster <arm...@redhat.com> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Anthony Liguori <aligu...@us.ibm.com> Maybe this should be documented in the function header in "qom/object.h". > >> shouldn't fail here. > >> > >> Signed-off-by: BALATON Zoltan <bala...@eik.bme.hu> > >> --- > >> hw/ppc/sam460ex.c | 7 ++----- > >> 1 file changed, 2 insertions(+), 5 deletions(-) > >> > >> diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c > >> index 14e6583eb0..cc67e9c39b 100644 > >> --- a/hw/ppc/sam460ex.c > >> +++ b/hw/ppc/sam460ex.c > >> @@ -384,11 +384,8 @@ static void sam460ex_init(MachineState *machine) > >> ppc460ex_pcie_init(env); > >> /* All PCI irqs are connected to the same UIC pin (cf. UBoot source) > >> */ > >> dev = sysbus_create_simple("ppc440-pcix-host", 0xc0ec00000, > >> uic[1][0]); > >> - pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci.0"); > >> - if (!pci_bus) { > >> - error_report("couldn't create PCI controller!"); > >> - exit(1); > >> - } > >> + pci_bus = PCI_BUS(qdev_get_child_bus(dev, "pci.0")); > >> + > > > > But PCI_BUS() is being passed qdev_get_child_bus(dev, "pci.0"), not > > dev... so the real question here is whether this can return NULL > > or not. And if this happens, is this a (1) user or (2) programming > > error ? > > > > If (1) then the "if (!pci_bus) { }" should be kept. If (2) then > > it should be converted to an assert(). > > I think it can only fail if the ppc440-pcix-host type is changed to not > have a pci.0 child any more which is a programming error that's very > unlikely to happen but if needed an assert could be added but I don't > think that's really necessary. The error_report was definitely not needed > as it's not a user error in any case. > I was also thinking about a programming error. Whether to add an assert() or not is up to you, you're the maintainer for this code :) > Regards, > BALATON Zoltan > > >> memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(), > >> 0, 0x10000); > >> memory_region_add_subregion(get_system_memory(), 0xc08000000, isa); > > > >