| commit | 27607c1cdc0d2939cc3059106f919bf6271ae652 | |
| author | Greg Kurz <groug@kaod.org> | |
| Thu, 14 Jun 2018 21:50:27 +0000 (14 23:50 +0200) | ||
| committer | David Gibson <david@gibson.dropbear.id.au> | |
| Sat, 16 Jun 2018 06:32:33 +0000 (16 16:32 +1000) | ||
| tree | 984217ed39274ac4cd048da4508e4cf76fcc875b | treesnapshot (tar.gz zip) |
| parent | dbb3e8d5da028a6cc4c576c6a0960bcf740cb035 | commitdiff |
spapr_cpu_core: fix potential leak in spapr_cpu_core_realize()
Commit 94ad93bd97684 (QEMU 2.12) switched to instantiate CPUs separately
but it missed to adapt the error path accordingly. If something fails in
the CPU creation loop, then the CPU object that was just created is leaked.
The error paths in this function are a bit obfuscated, and adding
yet another label to free this CPU object makes it worse. We should
move the block of the loop to a separate function, with a proper
rollback path, but this is a bigger cleanup.
For now, let's just fix the bug by adding the missing calls to
object_unref(). This will allow easier backport to older QEMU
versions.
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 94ad93bd97684 (QEMU 2.12) switched to instantiate CPUs separately
but it missed to adapt the error path accordingly. If something fails in
the CPU creation loop, then the CPU object that was just created is leaked.
The error paths in this function are a bit obfuscated, and adding
yet another label to free this CPU object makes it worse. We should
move the block of the loop to a separate function, with a proper
rollback path, but this is a bigger cleanup.
For now, let's just fix the bug by adding the missing calls to
object_unref(). This will allow easier backport to older QEMU
versions.
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| hw/ppc/spapr_cpu_core.c | diffblobblamehistory |