[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/3] sam460ex: Use type cast macro instead of simple cast
From: |
Greg Kurz |
Subject: |
Re: [PATCH 3/3] sam460ex: Use type cast macro instead of simple cast |
Date: |
Thu, 7 Jan 2021 12:13:04 +0100 |
On Thu, 7 Jan 2021 10:45:26 +0100
BALATON Zoltan <balaton@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-ppc@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 <pbonzini@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 <armbru@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@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 <balaton@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);
> >
> >