From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Max Reitz <mreitz@redhat.com>, John Snow <jsnow@redhat.com>,
BALATON Zoltan <balaton@eik.bme.hu>
Cc: qemu-ppc <qemu-ppc@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: Coverity CID 1421984
Date: Mon, 23 Mar 2020 12:58:56 +0100 [thread overview]
Message-ID: <88618db3-cb48-12bd-6152-b642b25a0287@redhat.com> (raw)
In-Reply-To: <d9b7d8d8-1640-7d69-cd16-66e6d9cef3d1@redhat.com>
Cc'ing qemu-ppc since this is restricted to the aCube Sam460ex board.
On 3/23/20 12:46 PM, Max Reitz wrote:
> Hi,
>
> I was triaging new Coverity block layer reports today, and one that
> seemed like a real bug was CID 1421984:
>
> It complains about a memleak in sii3112_pci_realize() in
> hw/ide/sii3112.c, specifically about @irq being leaked (it’s allocated
> by qemu_allocate_irqs(), but never put anywhere or freed).
>
> I’m not really well-versed in anything under hw/ide, so I was wondering
> whether you agree it’s a bug and whether you know the correct way to fix
> it. (I assume it’s just a g_free(irqs), but maybe there’s a more
> specific way that’s applicable here.)
What does other devices is hold a reference in the DeviceState
(SiI3112PCIState) to make static analyzers happy.
Ideally we should free such memory in the DeviceUnrealize handler, but
we in the reality we only care for hotunpluggable devices.
PCI devices usually are. There is a trick however, you can mark
overwrite the DeviceClass::hotpluggable field in sii3112_pci_class_init:
dc->hotpluggable = false;
next prev parent reply other threads:[~2020-03-23 11:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 11:46 Coverity CID 1421984 Max Reitz
2020-03-23 11:58 ` Philippe Mathieu-Daudé [this message]
2020-03-23 13:11 ` BALATON Zoltan
2020-03-23 13:26 ` Max Reitz
2020-03-23 13:35 ` Peter Maydell
2020-03-23 14:06 ` BALATON Zoltan
2020-03-23 14:35 ` Peter Maydell
2020-03-23 14:43 ` BALATON Zoltan
2020-03-23 14:46 ` Peter Maydell
2020-03-23 15:28 ` BALATON Zoltan
2020-03-23 15:33 ` Peter Maydell
2020-03-23 15:28 ` Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=88618db3-cb48-12bd-6152-b642b25a0287@redhat.com \
--to=philmd@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=david@gibson.dropbear.id.au \
--cc=jsnow@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).