Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1717090
Signed-off-by: Erik Skultety
---
Pushed as trivial.
tests/testutilsqemu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c
index bce847ce5e..9ac9f9bd39 100644
---
On 04.06.2019 17:23, Michal Privoznik wrote:
> On 6/4/19 11:07 AM, Nikolay Shirokovskiy wrote:
>>
>>
>> On 30.05.2019 12:34, Michal Privoznik wrote:
>>> Changing domain definition must be guarded with acquiring modify
>>> job. The problem is if there is a thread executing say
>>>
On 6/4/19 12:53 PM, Nikolay Shirokovskiy wrote:
On 30.05.2019 12:33, Michal Privoznik wrote:
This is an alternative proposal to:
https://www.redhat.com/archives/libvir-list/2019-May/msg00830.html
The problem I'm trying to fix is described here:
On 6/4/19 11:07 AM, Nikolay Shirokovskiy wrote:
On 30.05.2019 12:34, Michal Privoznik wrote:
Changing domain definition must be guarded with acquiring modify
job. The problem is if there is a thread executing say
qemuDomainSetMemoryStatsPeriod() which is an API that acquires
modify job and
On Tue, Jun 04, 2019 at 02:46:47PM +0200, Andrea Bolognani wrote:
We're using VIR_AUTOPTR() for everything now, plus the
cleanup section was not doing anything useful anyway.
Signed-off-by: Andrea Bolognani
---
src/qemu/qemu_process.c | 18 --
1 file changed, 8 insertions(+), 10
On Tue, 2019-06-04 at 15:37 +0200, Ján Tomko wrote:
> On Tue, Jun 04, 2019 at 02:46:46PM +0200, Andrea Bolognani wrote:
> > In two out of three scenarios we were cleaning up properly
> > after ourselves, but in the remaining one we were leaking
> > cpumapToSet.
>
> Given that the leak was
On Tue, Jun 04, 2019 at 02:46:46PM +0200, Andrea Bolognani wrote:
In two out of three scenarios we were cleaning up properly
after ourselves, but in the remaining one we were leaking
cpumapToSet.
Given that the leak was introduced recently by commit 5f2212c, not mentioning
it here seems
Only succeed when @pid_value is 1, since according to the docs this is
the minimum requirement for any driver to implement this API.
>From man 2 kill:
The only signals that can be sent to process ID 1, the init process, are
those for which init has explicitly installed signal handlers.
Regarding
On Tue, 2019-06-04 at 07:03 -0400, John Ferlan wrote:
> On 5/31/19 11:22 AM, Andrea Bolognani wrote:
> > @@ -2489,11 +2489,16 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm)
> > if (virDomainNumaGetNodeCount(vm->def->numa) <= 1 &&
> > virDomainNumatuneGetMode(vm->def->numa, -1,
We're using VIR_AUTOPTR() for everything now, plus the
cleanup section was not doing anything useful anyway.
Signed-off-by: Andrea Bolognani
---
src/qemu/qemu_process.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/qemu/qemu_process.c
In two out of three scenarios we were cleaning up properly
after ourselves, but in the remaining one we were leaking
cpumapToSet.
Refactor the logic so that cpumapToSet is always a freshly
allocated bitmap that gets cleaned up automatically thanks
to VIR_AUTOPTR(); this also allows us to remove
Spotted by John through Coverity.
Andrea Bolognani (2):
qemu: Fix leak in qemuProcessInitCpuAffinity()
qemu: Drop cleanup label from qemuProcessInitCpuAffinity()
src/qemu/qemu_process.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
--
2.21.0
--
On 5/31/19 11:22 AM, Andrea Bolognani wrote:
> Commit f136b83139c6 made some changes in the way we set CPU
> affinity for QEMU processes, and while doing so unfortunately
> also introduced a logic bug in that it tried to use a NUMA node
> map where a CPU map was expected.
>
> Because of that,
On 30.05.2019 12:33, Michal Privoznik wrote:
> This is an alternative proposal to:
>
> https://www.redhat.com/archives/libvir-list/2019-May/msg00830.html
>
> The problem I'm trying to fix is described here:
>
> https://www.redhat.com/archives/libvir-list/2019-May/msg00810.html
>
> Michal
On 30.05.2019 12:34, Michal Privoznik wrote:
> Changing domain definition must be guarded with acquiring modify
> job. The problem is if there is a thread executing say
> qemuDomainSetMemoryStatsPeriod() which is an API that acquires
> modify job and then possibly unlock the domain object and
On 30.05.2019 12:34, Michal Privoznik wrote:
> Soon we will be acquiring job for every virDomainObjAssignDef()
> call. This, however, means that in some cases vm->def might not
> be set just yet. Fortunately, the only thing from domain
> definition used in
On Mon, Jun 03, 2019 at 07:14:37PM +0200, Andrea Bolognani wrote:
Right now, if numad fails, we raise an error but return an
empty string to the caller instead of a NULL pointer, which
means processing will continue and the user will see
# virsh start guest
error: Failed to start domain guest
On 30.05.2019 12:34, Michal Privoznik wrote:
> Some driver have concept of jobs (e.g. qemu, lxc, libxl and vz).
> This means that whenever something wants to modify a domain
> object it needs to acquire job (to mutually exclude with other
> threads trying to modify the same object). And
On 30.05.2019 12:33, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik
> ---
> src/conf/domain_conf.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> index fa0756b634..e1b5df7e46 100644
> ---
On 30.05.2019 12:33, Michal Privoznik wrote:
> Because of past limitation of virDomainObjListAddObjLocked() we
> had to set vm->def even before the object was on the domains
> list.
>
> Signed-off-by: Michal Privoznik
> ---
> src/conf/virdomainobjlist.c | 9 -
> 1 file changed, 4
On 30.05.2019 12:33, Michal Privoznik wrote:
> In near future vm->def might be not set when calling this
> function. Therefore, have caller explicitly state what UUID and
> name the domain object should be stored under.
>
> Signed-off-by: Michal Privoznik
> ---
> src/conf/virdomainobjlist.c
On 30.05.2019 12:33, Michal Privoznik wrote:
> It's a premature optimization. It's perfectly acceptable for
> 'error' label to deal with @vm == NULL case.
>
> Signed-off-by: Michal Privoznik
> ---
> src/conf/virdomainobjlist.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
On Mon, Jun 03, 2019 at 08:27:29PM +0200, Ilias Stamatis wrote:
> On Mon, Jun 3, 2019 at 1:50 PM Pavel Hrdina wrote:
> >
> > On Mon, Jun 03, 2019 at 10:36:58AM +0200, Erik Skultety wrote:
> > > On Wed, May 29, 2019 at 02:22:55PM +0200, Ilias Stamatis wrote:
> > > > While implementing
On Mon, 2019-06-03 at 15:41 -0600, Jim Fehlig wrote:
> On 5/30/19 10:00 AM, Andrea Bolognani wrote:
> > Actually I'd go one further and adopt what Xen tests are doing:
> > there's an explicit
> >
> >libxl_LDADDS += $(LDADDS)
> >
> > and then most tests include at least $(libxl_LDADDS) in
We've discussed possible solutions. Is anyone working or intending to
work on patches?
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Jun 03, 2019 at 05:04:51PM +0200, Andrea Bolognani wrote:
On Mon, 2019-06-03 at 16:43 +0200, Ján Tomko wrote:
On Mon, Jun 03, 2019 at 04:31:51PM +0200, Andrea Bolognani wrote:
> On Mon, 2019-06-03 at 14:10 +0200, Ján Tomko wrote:
> > if (b->nbits &&
> > a->nbits < b->nbits &&
> >
26 matches
Mail list logo
