[PATCH v2 0/6] Introduce active RBD disk snapshot support
by Or Ozeri
Internal disk snapshots are currently only supported on non-active VMs.
For RBD disks only, this patch series extends this support for active VMs running with qemu.
We also add the option to set a name for each RBD snapshot, and allow taking them alongside other external disk snapshots (mixing).
Deletion and reverting to snapshots containing RBD snapshots is not allowed, and is validated.
Note that taking RBD snapshots on a non-active VM is still unsupported.
Changes in v2:
- reduce patch to RBD use-case only (e.g. not including qcow2 internal snapshots)
- add validation to disallow RBD snapshots deletion / reverting
Or Ozeri (6):
conf: Add snapshotName attribute for internal disk snapshot
qemu: Block deletion and reverting on non-full internal snapshots
qemu: Add internal support for active disk internal snapshots
qemu: Allow active disk snapshots for RBD disks
qemu: Allow setting per-disk snapshot name for RBD disks
qemu: Allow mixing active internal and external active disk snapshots
docs/formatsnapshot.rst | 5 +
src/conf/schemas/domainsnapshot.rng | 4 +
src/conf/snapshot_conf.c | 56 ++++++++++
src/conf/snapshot_conf.h | 5 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_monitor.c | 9 ++
src/qemu/qemu_monitor.h | 5 +
src/qemu/qemu_monitor_json.c | 14 +++
src/qemu/qemu_monitor_json.h | 5 +
src/qemu/qemu_snapshot.c | 105 ++++++++++++------
.../disk_snapshot.xml | 2 +-
.../disk_snapshot.xml | 2 +-
.../disk_snapshot_redefine.xml | 2 +-
tests/qemumonitorjsontest.c | 1 +
14 files changed, 181 insertions(+), 35 deletions(-)
--
2.25.1
1 year, 8 months
[libvirt PATCH 0/1] qemu: Fix memory leaks in firmware selection code
by Andrea Bolognani
Reported when building with gcc and clang both.
==10909==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 128 byte(s) in 4 object(s) allocated from:
#0 0x7f191d4a2808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7f191987ae98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98)
SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s).
This patch is a requirement for pushing my recent improvements to
firmware selection[1] without further degrading the CI pipeline.
[1] https://listman.redhat.com/archives/libvir-list/2023-March/238890.html
Andrea Bolognani (1):
qemu: Fix memory leaks in firmware selection code
src/qemu/qemu_firmware.c | 4 ++++
1 file changed, 4 insertions(+)
--
2.39.2
1 year, 8 months
[libvirt PATCH 00/15] qemu: Further improvements to firmware selection
by Andrea Bolognani
More information in the commit message for 11/15.
Ideally this would make it into 9.2.0 along with the other
changes to firmware selection I've made in this cycle[1].
[1] https://listman.redhat.com/archives/libvir-list/2023-February/237806.html
Andrea Bolognani (15):
tests: Rename a few firmware tests
tests: Fix firmware-auto-efi-loader-path-nonstandard
tests: Add firmware-auto-efi-loader-path
tests: Add more tests for manual Secure Boot configuration
tests: Fix firmware descriptor masking test
qemu: Introduce qemuFirmwareMatchesPaths()
qemu: Discard requires-smm firmware when loader.secure=no
qemu: Always go through firmware autoselection
conf: Remove some firmware validation checks
conf: Don't format firmware type/features when migrating
qemu: Don't drop firmware type/features information
qemu: Automatically add firmware type/features information
conf: Don't explicitly set the secure-boot feature
conf: Move validation check out of postparse
qemu: Move validation check out of postparse
src/conf/domain_conf.c | 5 +-
src/conf/domain_postparse.c | 16 --
src/conf/domain_validate.c | 42 +---
src/qemu/qemu_domain.c | 6 -
src/qemu/qemu_firmware.c | 186 +++++++++++++-----
src/qemu/qemu_validate.c | 6 +
.../{60-ovmf-sb.json => 42-masked.json} | 0
.../usr/share/qemu/firmware/42-masked.json | 37 ++++
tests/qemufirmwaretest.c | 2 +
...to-efi-loader-insecure.x86_64-latest.args} | 0
...auto-efi-loader-insecure.x86_64-latest.err | 1 -
...-loader-path-nonstandard.x86_64-latest.err | 1 +
...ware-auto-efi-loader-path-nonstandard.xml} | 2 +-
...e-auto-efi-loader-path.x86_64-latest.args} | 0
...are-auto-efi-loader-path.x86_64-latest.err | 1 -
.../firmware-auto-efi-loader-path.xml | 2 +-
...to-efi-no-enrolled-keys.x86_64-latest.args | 5 +-
...nual-efi-loader-no-path.x86_64-latest.err} | 0
...=> firmware-manual-efi-loader-no-path.xml} | 0
...nual-efi-loader-secure.x86_64-latest.args} | 0
... => firmware-manual-efi-loader-secure.xml} | 0
...l-efi-no-enrolled-keys.x86_64-latest.args} | 0
... firmware-manual-efi-no-enrolled-keys.xml} | 2 +-
...-manual-efi-no-secboot.x86_64-latest.args} | 4 +-
...xml => firmware-manual-efi-no-secboot.xml} | 5 +-
...are-manual-efi-secboot.x86_64-latest.args} | 0
...re.xml => firmware-manual-efi-secboot.xml} | 2 +-
tests/qemuxml2argvtest.c | 12 +-
...ware-auto-bios-stateless.x86_64-latest.xml | 6 +-
.../firmware-auto-bios.x86_64-latest.xml | 6 +-
...rmware-auto-efi-aarch64.aarch64-latest.xml | 6 +-
...e-auto-efi-enrolled-keys.x86_64-latest.xml | 6 +-
...-efi-format-loader-qcow2.x86_64-latest.xml | 6 +-
...o-efi-format-loader-raw.aarch64-latest.xml | 6 +-
...-nvram-qcow2-network-nbd.x86_64-latest.xml | 5 +-
...-format-nvram-qcow2-path.x86_64-latest.xml | 6 +-
...o-efi-format-nvram-qcow2.x86_64-latest.xml | 6 +-
...uto-efi-loader-insecure.x86_64-latest.xml} | 8 +-
...loader-path-nonstandard.x86_64-latest.xml} | 4 +-
...re-auto-efi-loader-path.x86_64-latest.xml} | 6 +-
...e-auto-efi-loader-secure.x86_64-latest.xml | 6 +-
...uto-efi-no-enrolled-keys.x86_64-latest.xml | 9 +-
...ware-auto-efi-no-secboot.x86_64-latest.xml | 6 +-
...ware-auto-efi-nvram-file.x86_64-latest.xml | 6 +-
...-efi-nvram-network-iscsi.x86_64-latest.xml | 5 +-
...to-efi-nvram-network-nbd.x86_64-latest.xml | 5 +-
.../firmware-auto-efi-nvram.x86_64-latest.xml | 6 +-
...irmware-auto-efi-secboot.x86_64-latest.xml | 6 +-
...irmware-auto-efi-smm-off.x86_64-latest.xml | 6 +-
...mware-auto-efi-stateless.x86_64-latest.xml | 6 +-
.../firmware-auto-efi.x86_64-latest.xml | 6 +-
...manual-efi-acpi-aarch64.aarch64-latest.xml | 6 +-
...ware-manual-efi-acpi-q35.x86_64-latest.xml | 6 +-
...anual-efi-loader-secure.x86_64-latest.xml} | 6 +-
...al-efi-no-enrolled-keys.x86_64-latest.xml} | 8 +-
...e-manual-efi-no-secboot.x86_64-latest.xml} | 6 +-
...nual-efi-noacpi-aarch64.aarch64-latest.xml | 6 +-
...re-manual-efi-nvram-file.x86_64-latest.xml | 6 +-
...-efi-nvram-network-iscsi.x86_64-latest.xml | 5 +-
...al-efi-nvram-network-nbd.x86_64-latest.xml | 5 +-
...anual-efi-nvram-template.x86_64-latest.xml | 6 +-
...ware-manual-efi-secboot.x86_64-latest.xml} | 6 +-
.../firmware-manual-efi.x86_64-latest.xml | 6 +-
.../pvpanic-pci-aarch64.aarch64-latest.xml | 6 +-
...-pci-no-address-aarch64.aarch64-latest.xml | 6 +-
.../virtio-iommu-aarch64.aarch64-latest.xml | 6 +-
tests/qemuxml2xmltest.c | 8 +-
67 files changed, 409 insertions(+), 164 deletions(-)
rename tests/qemufirmwaredata/etc/qemu/firmware/{60-ovmf-sb.json => 42-masked.json} (100%)
create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/42-masked.json
copy tests/qemuxml2argvdata/{firmware-auto-efi-no-enrolled-keys.x86_64-latest.args => firmware-auto-efi-loader-insecure.x86_64-latest.args} (100%)
delete mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-loader-insecure.x86_64-latest.err
create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-loader-path-nonstandard.x86_64-latest.err
copy tests/qemuxml2argvdata/{firmware-auto-efi-loader-path.xml => firmware-auto-efi-loader-path-nonstandard.xml} (86%)
copy tests/qemuxml2argvdata/{firmware-auto-efi-no-enrolled-keys.x86_64-latest.args => firmware-auto-efi-loader-path.x86_64-latest.args} (100%)
delete mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-loader-path.x86_64-latest.err
rename tests/qemuxml2argvdata/{firmware-manual-efi-no-path.x86_64-latest.err => firmware-manual-efi-loader-no-path.x86_64-latest.err} (100%)
rename tests/qemuxml2argvdata/{firmware-manual-efi-no-path.xml => firmware-manual-efi-loader-no-path.xml} (100%)
copy tests/qemuxml2argvdata/{firmware-manual-efi-secure.x86_64-latest.args => firmware-manual-efi-loader-secure.x86_64-latest.args} (100%)
copy tests/qemuxml2argvdata/{firmware-manual-efi-secure.xml => firmware-manual-efi-loader-secure.xml} (100%)
copy tests/qemuxml2argvdata/{firmware-manual-efi-secure.x86_64-latest.args => firmware-manual-efi-no-enrolled-keys.x86_64-latest.args} (100%)
copy tests/qemuxml2argvdata/{firmware-manual-efi-secure.xml => firmware-manual-efi-no-enrolled-keys.xml} (87%)
copy tests/qemuxml2argvdata/{firmware-auto-efi-no-enrolled-keys.x86_64-latest.args => firmware-manual-efi-no-secboot.x86_64-latest.args} (90%)
copy tests/qemuxml2argvdata/{firmware-manual-efi-secure.xml => firmware-manual-efi-no-secboot.xml} (72%)
rename tests/qemuxml2argvdata/{firmware-manual-efi-secure.x86_64-latest.args => firmware-manual-efi-secboot.x86_64-latest.args} (100%)
rename tests/qemuxml2argvdata/{firmware-manual-efi-secure.xml => firmware-manual-efi-secboot.xml} (86%)
copy tests/qemuxml2xmloutdata/{firmware-auto-efi-no-enrolled-keys.x86_64-latest.xml => firmware-auto-efi-loader-insecure.x86_64-latest.xml} (82%)
copy tests/qemuxml2xmloutdata/{firmware-auto-bios-stateless.x86_64-latest.xml => firmware-auto-efi-loader-path-nonstandard.x86_64-latest.xml} (92%)
copy tests/qemuxml2xmloutdata/{firmware-auto-efi-no-enrolled-keys.x86_64-latest.xml => firmware-auto-efi-loader-path.x86_64-latest.xml} (89%)
copy tests/qemuxml2xmloutdata/{firmware-manual-efi-secure.x86_64-latest.xml => firmware-manual-efi-loader-secure.x86_64-latest.xml} (89%)
copy tests/qemuxml2xmloutdata/{firmware-manual-efi-secure.x86_64-latest.xml => firmware-manual-efi-no-enrolled-keys.x86_64-latest.xml} (83%)
copy tests/qemuxml2xmloutdata/{firmware-manual-efi-acpi-q35.x86_64-latest.xml => firmware-manual-efi-no-secboot.x86_64-latest.xml} (89%)
rename tests/qemuxml2xmloutdata/{firmware-manual-efi-secure.x86_64-latest.xml => firmware-manual-efi-secboot.x86_64-latest.xml} (89%)
--
2.39.2
1 year, 8 months
[PATCH] meson: Disable optimizations if CLang doesn't support -fsemantic-interposition
by Michal Privoznik
For some older CLang (or in combination with !intel arch) the
-fsemantic-interposition might be not present. But in that case,
we still want our mocking in test suite to work properly. Disable
optimizations as that seems to be the only way.
Also, don't forget to drop this when FreeBSD 11 and macOS 12 are
dropped.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
This still doesn't work when somebody overrides CFLAGS as those are
placed AFTER our supported_cc_flags:
$ export CFLAGS="-O2 -ggdb"
$ meson setup _build
$ ninja -v -C _build/
[1/1202] clang ... -O2 -g ... -O0 -O2 -ggdb -fPIC ... -c ../src/util/glibcompat.c
meson.build | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/meson.build b/meson.build
index a0682e8d0b..249505d474 100644
--- a/meson.build
+++ b/meson.build
@@ -492,6 +492,13 @@ if get_option('warning_level') == '2'
endif
endif
+
+if cc.get_id() == 'clang' and not supported_cc_flags.contains('-fsemantic-interposition')
+ # If CLang is old enough to not support -fsemantic-interposition
+ # then this is our best bet to make mocking in tests working properly.
+ supported_cc_flags += [ '-O0' ]
+endif
+
add_project_arguments(supported_cc_flags, language: 'c')
if cc.has_argument('-Wsuggest-attribute=format')
--
2.39.2
1 year, 8 months
[PATCH 0/2] Work around broken clang. Again.
by Michal Privoznik
We ran into so many clang bugs recently, that I'm strongly in favor of
making it optional and aim on gcc only. Debugging these issues burns our
time needlessly. Just consider what's happening here.
I've pushed patches recently that call some virNuma*() APIs during QEMU
cmd line generation. And while at it, I removed virNuma*() mocks from
qemuxml2argvmock.c (v9.1.0-213-g95ae91fdd4). Andrea told me in review to
make sure our CI works. So I've fired up my freebsd VM and compiled my
code there. It worked. Except, I'm compiling with -O0 and our CI
compiles with the default (-O2). And of course this is the source of the
current build breakage.
Long story short, clang is so eager to produce the fastest code that it
simply ignores written code and generates what it *assumes* behaves the
same. Well, it doesn't and this breaks our mocking and thus our tests.
And of course it's happening only with optimizations.
In this particular case, I've noticed that while
virNumaNodesetIsAvailable() calls virNumaNodeIsAvailable(), it
disregards the return value and virReportError()-s immediately.
This is because the !WITH_NUMACTL variant of virNumaNodeIsAvailable()
calls virNumaGetMaxNode() which fails and thus false is returned.
WORSE, then I stepped in gdb into the mock, I've seen random numbers as
integers. This is because the function from virnumamock.c wasn't
optimized as much and followed standard calling convention (it grabbed
the integer argument from the stack). But the caller
(virNumaNodesetIsAvailable()) was so optimized that it did not even
bothered to push anything onto stack.
After these patches, there is still one qemuxml2argvtest case failing,
and it's simply because no matter how hard I try, I can't stop clang
from optimizing the function. Consider the following code:
virNumaCPUSetToNodeset(virBitmap *cpuset,
virBitmap **nodeset)
{
g_autoptr(virBitmap) nodes = virBitmapNew(0);
ssize_t pos = -1;
while ((pos = virBitmapNextSetBit(cpuset, pos)) >= 0) {
int node = virNumaGetNodeOfCPU(pos);
if (node < 0) {
virReportSystemError(errno,
_("Unable to get NUMA node of cpu %zd"),
pos);
return -1;
}
...
}
...
}
And this is the assembly code that clang generates (even after
VIR_OPTNONE treatment):
116f5f: e8 0c b7 f9 ff call b2670 <virBitmapNew@plt>
116f64: 48 89 44 24 40 mov %rax,0x40(%rsp)
116f69: 48 c7 44 24 18 ff ff movq $0xffffffffffffffff,0x18(%rsp)
116f70: ff ff
116f72: 48 8b 7c 24 38 mov 0x38(%rsp),%rdi
116f77: 48 8b 74 24 18 mov 0x18(%rsp),%rsi
116f7c: e8 0f 74 f9 ff call ae390 <virBitmapNextSetBit@plt>
116f81: eb 00 jmp 116f83 <virNumaCPUSetToNodeset+0x43>
116f83: 48 89 44 24 18 mov %rax,0x18(%rsp)
116f88: 48 83 f8 00 cmp $0x0,%rax
116f8c: 0f 8c b2 00 00 00 jl 117044 <virNumaCPUSetToNodeset+0x104>
116f92: 48 8b 7c 24 18 mov 0x18(%rsp),%rdi
116f97: e8 d4 a1 f9 ff call b1170 <virNumaGetNodeOfCPU@plt>
116f9c: c7 44 24 10 ff ff ff movl $0xffffffff,0x10(%rsp)
116fa3: ff
116fa4: 83 7c 24 10 00 cmpl $0x0,0x10(%rsp)
116fa9: 7d 74 jge 11701f <virNumaCPUSetToNodeset+0xdf>
116fab: e8 80 72 f9 ff call ae230 <__errno_location@plt>
116fb0: 8b 18 mov (%rax),%ebx
116fb2: 48 8d 3d 27 35 2b 00 lea 0x2b3527(%rip),%rdi # 3ca4e0 <vmdk4GetBackingStore.prefix+0xf260>
116fb9: 48 8d 35 8c e3 25 00 lea 0x25e38c(%rip),%rsi # 37534c <modeMap+0x215c>
116fc0: ba 05 00 00 00 mov $0x5,%edx
116fc5: e8 e6 a7 f9 ff call b17b0 <dcgettext@plt>
116fca: 48 8b 4c 24 18 mov 0x18(%rsp),%rcx
116fcf: 48 89 0c 24 mov %rcx,(%rsp)
116fd3: 48 8d 15 ea e0 25 00 lea 0x25e0ea(%rip),%rdx # 3750c4 <modeMap+0x1ed4>
116fda: 48 8d 0d 54 e3 25 00 lea 0x25e354(%rip),%rcx # 375335 <modeMap+0x2145>
116fe1: 31 ff xor %edi,%edi
116fe3: 89 de mov %ebx,%esi
116fe5: 41 b8 10 04 00 00 mov $0x410,%r8d
116feb: 49 89 c1 mov %rax,%r9
116fee: 31 c0 xor %eax,%eax
116ff0: e8 8b c1 f9 ff call b3180 <virReportSystemErrorFull@plt>
My assembler is a bit rusty, but at virNumaGetNodeOfCPU@plt is called
116f97, after which, -1 is stored on a stack (which corresponds to @pos
variable), after which comparison against 0 is made and the jump happens
iff the value (-1) is greater or equal than zero. Otherwise
virReportSystemError() is called.
To reproduce this issue even on Linux, configure with:
export CC=clang
meson setup -Dsystem=true -Dexpensive_tests=enabled -Dnumactl=disabled _build
At this point, I think we can call clang broken and focus our time on
developing libvirt. Not coming up with hacks around broken compilers.
Michal Prívozník (2):
internal.h: Invent VIR_OPTNONE
virnuma: Annotate some functions as VIR_OPTNONE
src/internal.h | 20 ++++++++++++++++++++
src/util/virnuma.c | 20 ++++++++++----------
2 files changed, 30 insertions(+), 10 deletions(-)
--
2.39.2
1 year, 8 months
[PATCH v2] meson: Stop detecting -Wl,--version-script=
by Michal Privoznik
With its version 16.0, the LLVM's linker turned on
--no-undefined-version by default [1]. This breaks how we detect
--version-script= detection, because at the compile time there's
no library built yet that we can use to make --version-script=
happy. Unfortunately, meson does not provide a way to detect this
either [2].
But there's not much sense in detecting the argument either. We
already special case some systems (windows, darwin) and do the
check for others, which are expected to support versioned
symbols, because of ELF. Worst case scenario - the error is
reported during compile time rather than configure time.
1: https://reviews.llvm.org/D135402
2: https://github.com/mesonbuild/meson/issues/3047
Resolves: https://bugs.gentoo.org/902211
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
v2 of:
https://listman.redhat.com/archives/libvir-list/2023-March/238923.html
diff to v1:
- Instead of fixing the detection, drop it completely.
meson.build | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/meson.build b/meson.build
index c35823a79a..a0682e8d0b 100644
--- a/meson.build
+++ b/meson.build
@@ -534,12 +534,7 @@ elif host_machine.system() == 'darwin'
# macOS libraries don't support symbol versioning
version_script_flags = ''
else
- test_file = '@0(a)/src/libvirt_qemu.syms'.format(meson.project_source_root())
- if cc.has_link_argument('-Wl,--version-script=@0@'.format(test_file))
- version_script_flags = '-Wl,--version-script='
- else
- error('No supported version script link argument found.')
- endif
+ version_script_flags = '-Wl,--version-script='
endif
libvirt_flat_namespace = []
--
2.39.2
1 year, 8 months
[PATCH] meson: Work around too strict lld
by Michal Privoznik
With its version 16.0, the LLVM's linker turned on
--no-undefined-version by default [1]. This breaks how we detect
--version-script= detection, because at the compile time there's
no library built yet that we can use to make --version-script=
happy. To cancel their choice of defaults, pass
--undefined-version. Unfortunately, this flag is LLVM's invention
and is not supported by GNU's ld.
This all could be avoided if meson provided proper detection of
supported linker arguments, but we are far away from that [2].
1: https://reviews.llvm.org/D135402
2: https://github.com/mesonbuild/meson/issues/3047
Resolves: https://bugs.gentoo.org/902211
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Compile Libvirt? Absolutely Not Gonna.
The choice of defaults for LLVM and related subprojects continues
to surprise me.
meson.build | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index c35823a79a..df0d75449a 100644
--- a/meson.build
+++ b/meson.build
@@ -535,9 +535,13 @@ elif host_machine.system() == 'darwin'
version_script_flags = ''
else
test_file = '@0(a)/src/libvirt_qemu.syms'.format(meson.project_source_root())
+ version_script_flags = ''
if cc.has_link_argument('-Wl,--version-script=@0@'.format(test_file))
version_script_flags = '-Wl,--version-script='
- else
+ elif cc.has_multi_link_arguments('-Wl,--undefined-version', '-Wl,--version-script=@0@'.format(test_file))
+ version_script_flags = '-Wl,--version-script='
+ endif
+ if version_script_flags == ''
error('No supported version script link argument found.')
endif
endif
--
2.39.2
1 year, 8 months
[PATCH 0/2] Fix clang build without numactl and without any code/optimization changes
by Martin Kletzander
See 1/2 for details, pipeline for this is here:
https://gitlab.com/nertpinx/libvirt/-/pipelines/811802916
Martin Kletzander (2):
util: Separate numactl and stubs into different source files
Revert "meson: stop CLang doing inter-procedural analysis"
meson.build | 20 --
po/POTFILES | 2 +
src/util/meson.build | 10 +
src/util/virnuma.c | 427 +------------------------------------
src/util/virnuma_common.h | 57 +++++
src/util/virnuma_numactl.c | 357 +++++++++++++++++++++++++++++++
src/util/virnuma_stubs.c | 124 +++++++++++
7 files changed, 551 insertions(+), 446 deletions(-)
create mode 100644 src/util/virnuma_common.h
create mode 100644 src/util/virnuma_numactl.c
create mode 100644 src/util/virnuma_stubs.c
--
2.40.0
1 year, 8 months
[PATCH 1/1] capabilities: reduce scope in virCapabilitiesInitCaches()
by Shaleen Bathla
over-writing a variable in inner while-loop without freeing previous memory
leaks it over time.
To fix this, we can just change scope of bank variable to the inner loop.
Signed-off-by: Shaleen Bathla <shaleen.bathla(a)oracle.com>
---
src/conf/capabilities.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c
index 34770fc4165f..9144ced4984f 100644
--- a/src/conf/capabilities.c
+++ b/src/conf/capabilities.c
@@ -2178,7 +2178,6 @@ virCapabilitiesInitCaches(virCaps *caps)
int rv = -1;
g_autoptr(DIR) dirp = NULL;
g_autofree char *path = g_strdup_printf("%s/cpu/cpu%zd/cache/", SYSFS_SYSTEM_PATH, pos);
- g_autoptr(virCapsHostCacheBank) bank = NULL;
rv = virDirOpenIfExists(&dirp, path);
if (rv < 0)
@@ -2189,6 +2188,7 @@ virCapabilitiesInitCaches(virCaps *caps)
while ((rv = virDirRead(dirp, &ent, path)) > 0) {
g_autofree char *type = NULL;
+ g_autoptr(virCapsHostCacheBank) bank = NULL;
int kernel_type;
unsigned int level;
int ret;
--
2.31.1
1 year, 8 months
[libvirt PATCH 0/8] Slightly reduce the number of translatable strings
by Ján Tomko
*** BLURB HERE ***
Ján Tomko (8):
bhyve: fix typo in error message
src: unify symlink creation error message
bhyve: unify error message for UUID generation
vbox: remove unreachable error in virVBoxSnapshotConfLoadVboxFile
vbox: remove unreachable error in virVBoxSnapshotConfSaveVboxFile
util: xml: remove function names from error messages
Unify error message when namespaces are unsupported
vbox: unify "unable to get hard disk id" message
src/bhyve/bhyve_parse_command.c | 2 +-
src/bhyve/bhyve_process.c | 2 +-
src/libxl/libxl_driver.c | 2 +-
src/lxc/lxc_driver.c | 2 +-
src/qemu/qemu_driver.c | 4 ++--
src/qemu/qemu_namespace.c | 2 +-
src/util/virprocess.c | 6 +++---
src/util/virxml.c | 6 +++---
src/vbox/vbox_common.c | 4 ++--
src/vbox/vbox_snapshot_conf.c | 11 -----------
10 files changed, 15 insertions(+), 26 deletions(-)
--
2.39.2
1 year, 8 months
