[Top][All Lists]

[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: BALATON Zoltan
Subject: Re: [PATCH 3/3] sam460ex: Use type cast macro instead of simple cast
Date: Thu, 7 Jan 2021 20:37:52 +0100 (CET)

On Thu, 7 Jan 2021, Greg Kurz wrote:
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

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

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

Indeed, PCI_BUS(NULL) does not abort just returns NULL. I think I remembered wrong and had dev==NULL so qdev_get_child_bus() was aborting.

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)
     /* 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 :)

In that case I think I keep it simple and don't add an assert because I think this error is highly unlikely (we create a pci host object that should have a pci bus child) and it would crash anyway shortly when trying to add devices so an additional assert here does not seem to help much catching a bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]