On Mon, May 6, 2024 at 8:41 PM Han Zhou wrote:
>
>
> On Thu, May 2, 2024 at 10:35 PM Ales Musil wrote:
> >
> > On Thu, May 2, 2024 at 6:23 PM Han Zhou wrote:
> > >
> > >
> > >
> > > On Thu, May 2, 2024 at 6:29 AM Ales Musil wrote:
> > > >
> > > > Instead of tracking address set per struct
On Mon, Apr 22, 2024 at 9:02 AM Felix Huettner via dev
wrote:
>
> In most cases IPv4 packets are routed only over other IPv4 networks and
> IPv6 packets are routed only over IPv6 networks. However there is no
> inherent reason for this limitation. Routing IPv4 packets over IPv6
> networks just
John Hubbard wrote:
> When building with clang, via:
>
> make LLVM=1 -C tools/testing/selftest
>
> ...clang warns about three variables that are not initialized in all
> cases:
>
> 1) The opt_ipproto_off variable is used uninitialized if "testname" is
> not "ip". Willem de Bruijn pointed
Bleep bloop. Greetings John Hubbard, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
git-am:
error: sha1 information is lacking or useless
(tools/testing/selftests/net/gro.c).
error: could
When building with clang, via:
make LLVM=1 -C tools/testing/selftest
...clang warns about three variables that are not initialized in all
cases:
1) The opt_ipproto_off variable is used uninitialized if "testname" is
not "ip". Willem de Bruijn pointed out that this is an actual bug, and
John Hubbard wrote:
> When building with clang, via:
>
> make LLVM=1 -C tools/testing/selftest
>
> ...clang warns about three variables that are not initialized in all
> cases:
>
> 1) The opt_ipproto_off variable is used uninitialized if "testname" is
> not "ip". This seems like an actual
On 5/6/24 11:00 AM, Willem de Bruijn wrote:
John Hubbard wrote:
...
diff --git a/tools/testing/selftests/net/gro.c
b/tools/testing/selftests/net/gro.c
index 353e1e867fbb..0eb61edaad83 100644
--- a/tools/testing/selftests/net/gro.c
+++ b/tools/testing/selftests/net/gro.c
@@ -110,7 +110,8 @@
On Thu, May 2, 2024 at 10:35 PM Ales Musil wrote:
>
> On Thu, May 2, 2024 at 6:23 PM Han Zhou wrote:
> >
> >
> >
> > On Thu, May 2, 2024 at 6:29 AM Ales Musil wrote:
> > >
> > > Instead of tracking address set per struct expr_constant_set track it
> > > per individual struct expr_constant. This
Unlike the C IDL code, the Python version still monitors the
_Server DB with "monitor" instead of "monitor_cond". This results
in receiving an entire Database row every time the "index" value
is updated which includes the 'schema' column. Using "monitor_cond"
will result in "update2" notifications
There was a Python-only test for ensuring that the library would
work when connecting to an older ovsdb-server that did not support
monitor_cond. This adds a C IDL version of that test.
Signed-off-by: Terry Wilson
---
tests/ovsdb-idl.at | 16 +++-
1 file changed, 15 insertions(+), 1
Using "monitor" for _Server means that every bump to Database.index
sends a large "update" notification containing a lot of data
including the Database schema text. This updates the Python IDL to
use "monitor_cond" as the C IDL does.
There is a difference in logic between the two IDL
On Tue, Apr 23, 2024 at 3:44 PM Mark Michelson wrote:
>
> Hi Ales, thanks for this. I always like a change that results in a net
> loss of lines of code :)
>
> For the series,
>
> Acked-by: Mark Michelson
Hi Ales,
Can you please rebase the series ? It has some conflicts.
Numan
>
> On
Bleep bloop. Greetings Terry Wilson, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: The subject summary should end with a dot.
Subject: python: ovsdb-idl: Use
Bleep bloop. Greetings Terry Wilson, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: The subject summary should end with a dot.
Subject: ovsdb-idl: Add C IDL test for
Unlike the C IDL code, the Python version still monitors the
_Server DB with "monitor" instead of "monitor_cond". This results
in receiving an entire Database row every time the "index" value
is updated which includes the 'schema' column. Using "monitor_cond"
will result in "update2" notifications
There was a Python-only test for ensuring that the library would
work when connecting to an older ovsdb-server that did not support
monitor_cond. This adds a C IDL version of that test.
Signed-off-by: Terry Wilson
---
tests/ovsdb-idl.at | 16 +++-
1 file changed, 15 insertions(+), 1
Using "monitor" for _Server means that every bump to Database.index
sends a large "update" notification containing a lot of data
including the Database schema text. This updates the Python IDL to
use "monitor_cond" as the C IDL does.
There is a difference in logic between the two IDL
>From 5b4d479a9083272e56c51ef9521e6ef665dd534d Mon Sep 17 00:00:00 2001
From: chandlerwu
Date: Mon, 6 May 2024 11:58:21 +0800
Subject: [PATCH] Subject:[PATCH] fix ct tp policy when create zone.
Signed-off-by: chandlerwu
---
vswitchd/bridge.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi John,
On 06/05/2024 00:26, John Hubbard wrote:
> When building with clang, via:
>
> make LLVM=1 -C tools/testing/selftest
>
> ...clang warns about three variables that are not initialized in all
> cases:
>
> 1) The opt_ipproto_off variable is used uninitialized if "testname" is
> not
When building with clang, via:
make LLVM=1 -C tools/testing/selftest
...clang warns that "a variable sized type not at the end of a struct or
class is a GNU extension".
These cases are not easily changed, because they involve structs that
are part of the API. Fortunately, however, the tests
When building with clang, via:
make LLVM=1 -C tools/testing/selftest
...clang warns about three variables that are not initialized in all
cases:
1) The opt_ipproto_off variable is used uninitialized if "testname" is
not "ip". This seems like an actual bug.
2) The addr_len is used
On 06/05/2024 14:05, Ilya Maximets wrote:
> On 5/5/24 08:42, Roi Dayan via dev wrote:
>> From: Eli Britstein
>>
>> In case of a malformed packet, its parsing fails. Instead of continuing
>> and possible form a wrong flow, drop the packet.
>
> Hi, Eli and Roi. Thanks for the patch!
>
> But I
On 5/5/24 08:42, Roi Dayan via dev wrote:
> From: Eli Britstein
>
> In case of a malformed packet, its parsing fails. Instead of continuing
> and possible form a wrong flow, drop the packet.
Hi, Eli and Roi. Thanks for the patch!
But I don't think we can do that. There are few reasons why
Avoid use after free in scenario when controller received LB deletion
after the DB was reconnected. The reconnect led to idl clearing up
the "old" structs, one of them being the LB. However, during recompute
the struct was referenced when it was already gone.
Clear the whole objdep_mgr instead of
24 matches
Mail list logo
