On Thu, Aug 13, 2020 at 12:24:50PM +0800, Jason Wang wrote:
>
> On 2020/8/10 下午3:46, Yan Zhao wrote:
> > > driver is it handled by?
> > It looks that the devlink is for network device specific, and in
> > devlink.h, it says
> > include/uapi/linux/devlink.h - Network physical device Netlink
> >
On 8/13/20 11:33 AM, Cornelia Huck wrote:
> On Fri, 7 Aug 2020 13:59:42 +0200
> Cornelia Huck wrote:
>
>> On Wed, 05 Aug 2020 12:35:01 +0100
>> Sean Mooney wrote:
>>
>>> On Wed, 2020-08-05 at 12:53 +0200, Jiri Pirko wrote:
Wed, Aug 05, 2020 at 11:33:38AM CEST, yan.y.z...@intel.com
On 8/13/20 12:37 AM, Jin Yan wrote:
These leaks were introduced in commit 15d280fa97b0, use g_autofree for all
cert_path pointers.
Signed-off-by: Jin Yan
---
Reviewed-by: Daniel Henrique Barboza
src/rpc/virnettlscontext.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
On 7/23/20 7:14 AM, Nikolay Shirokovskiy wrote:
We are dropping the only reference here so that the event loop thread
is going to be exited synchronously. In order to avoid deadlocks we
need to unlock the VM so that any handler being called can finish
execution and thus even loop thread be
On 8/11/20 3:39 AM, Nikolay Shirokovskiy wrote:
On 10.08.2020 20:40, Daniel Henrique Barboza wrote:
On 7/23/20 7:14 AM, Nikolay Shirokovskiy wrote:
We are dropping the only reference here so that the event loop thread
is going to be exited synchronously. In order to avoid deadlocks we
On Fri, 7 Aug 2020 13:59:42 +0200
Cornelia Huck wrote:
> On Wed, 05 Aug 2020 12:35:01 +0100
> Sean Mooney wrote:
>
> > On Wed, 2020-08-05 at 12:53 +0200, Jiri Pirko wrote:
> > > Wed, Aug 05, 2020 at 11:33:38AM CEST, yan.y.z...@intel.com wrote:
>
> (...)
>
> > > >software_version:
GCC 10 complains about "well_formed_uri" may be used uninitialzed.
Even though it is a false positive, we can easily avoid it.
Avoiding
../src/qemu/qemu_migration.c: In function ‘qemuMigrationDstPrepareDirect’:
../src/qemu/qemu_migration.c:2920:16: error: ‘well_formed_uri’ may be used
Caught these when switching to F32 using GCC v10.2.1 on s390x.
Boris Fiuczynski (3):
qemu: avoid maybe-uninitialized warning by GCC 10
tools: avoid potential null pointer dereference by GCC 10
storage: avoid maybe-uninitialized warning by GCC 10
src/qemu/qemu_migration.c
GCC 10 complains about "arg" possibly being a NULL dereference.
Even though it might be a false positive, we can easily avoid it.
Avoiding
../tools/vsh.c: In function ‘vshCommandOptStringReq’:
../tools/vsh.c:1034:19: error: potential null pointer dereference
[-Werror=null-dereference]
1034 |
GCC 10 complains about variables may be used uninitialized.
Even though it might be false positives, we can easily avoid them.
Avoiding
../src/storage/storage_backend_iscsi_direct.c:634:11: error: ‘nb_block’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
634 |
On 30.07.2020 18:49, Nikolay Shirokovskiy wrote:
>
>
> On 30.07.2020 17:56, Peter Krempa wrote:
>> On Thu, Jul 30, 2020 at 17:27:35 +0300, Nikolay Shirokovskiy wrote:
>>> Most of bitmap setBit/clearBit/getBit users know that the bitmap index is
>>> not out of bound and thus don't check the
On Fri, Aug 7, 2020 at 6:14 PM Daniel P. Berrangé
wrote:
> On Fri, Aug 07, 2020 at 12:21:19PM +0200, Christian Ehrhardt wrote:
> > The design of apparmor in libvirt always had a way to define custom
> > per-guest rules as described in docs/drvqemu.html and [1].
> >
> > A fix meant to clean the
On Fri, Aug 7, 2020 at 6:14 PM Daniel P. Berrangé
wrote:
> On Fri, Aug 07, 2020 at 12:21:20PM +0200, Christian Ehrhardt wrote:
> > With qemu 5.0 and libvirt 6.6 there are new apparmor denials:
> > apparmor="DENIED" operation="umount" profile="libvirtd"
> >
I'm sending this quite early this month as I'm on vacation tomorrow and
next week and I wanted to make sure the plan for the release is
advertised earlier than just a day or two before the freeze.
To aim for the release on Sep 01 I suggest entering the freeze in two
weeks on Wednesday Aug 26 and
14 matches
Mail list logo
