Paolo Valerio writes:
> Connections that need to be removed, e.g. while forcing a direction,
> were invalidated forcing them to be expired.
> This is not actually needed, as it's typically a one-time
> operation.
> The patch replaces a call to conn_force_expire() with a call to
> conn_clean().
>
During the creation of a new connection, there's a chance both key and
rev_key end up having the same hash. This is more common in the case
of all-zero snat with no collisions. In that case, once the
connection is expired, but not cleaned up, if a new packet with the
same 5-tuple is received, an
Connections that need to be removed, e.g. while forcing a direction,
were invalidated forcing them to be expired.
This is not actually needed, as it's typically a one-time
operation.
The patch replaces a call to conn_force_expire() with a call to
conn_clean().
Signed-off-by: Paolo Valerio
---
The series addresses the issue reported here [0] by Michael Plato and
confirmed by Lazuardi Nasution.
More details in the patch descriptions.
The first patch is mostly a clean up and not necessarily required,
whereas the second one contains the actual fix.
[0]
Bleep bloop. Greetings Stefan Hoffmann, 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:
ERROR: Co-author Luca Czesla needs to sign off.
Lines checked: 81, Warnings: 0, Errors: 1
In some cases ovsdb server or relay gets restarted, ovsdb python clients
may keep the local socket open. Instead of reconnecting a lot of failures
will be logged.
This can be reproduced with ssl connections to the server/relay and
restarting it, so it has the same IP after restart.
This patch
On 19 Apr 2023, at 3:38, Songtao Zhan wrote:
> To: d...@openvswitch.org,
> i.maxim...@ovn.org
>
> The name of the current thread consists of a name with a maximum
> length of 16 bytes and a thread ID. The final name may be longer
> than 16 bytes. If the name is longer than 16 bytes, the
On Fri, Nov 18, 2022 at 4:08 PM Ihar Hrachyshka wrote:
> On Wed, Nov 16, 2022 at 3:55 AM Ales Musil wrote:
>
>>
>>
>> On Thu, Nov 3, 2022 at 4:46 AM Ihar Hrachyshka
>> wrote:
>>
>>> When multichassis ports attached to localnet switches are forced to use
>>> tunneling to communicate with other
On 4/14/23 23:12, Ihar Hrachyshka wrote:
> When setting flows for LS, OVN distinguishes between two states: where
> there’s a stateful ACL present in its list (has_stateful == true *)
> and when it’s missing (all ACLs are stateless).
>
> When has_stateful == true, the following is done (among
On 4/14/23 23:12, Ihar Hrachyshka wrote:
> Scapy allows to define packets in descriptive form that is easier to
> digest and debug.
>
> Signed-off-by: Ihar Hrachyshka
> Acked-by: Ales Musil
> Acked-by: Dumitru Ceara
> ---
> v1: initial version.
> v2: use .decode() instead of sed to truncate
On 4/14/23 12:46, Ales Musil wrote:
> On Fri, Apr 14, 2023 at 12:26 PM Ales Musil wrote:
>
>> There was a chance for race condition when
>> idl_txn wasn't available and the current_br_int_name
>> changed before that old tunnels were cleaned up.
>> To prevent the race condition update
>> the
On 4/19/23 07:32, Ales Musil wrote:
> On Tue, Apr 18, 2023 at 11:39 PM Dumitru Ceara wrote:
>
>> On 4/12/23 07:56, Ales Musil wrote:
>>> There are essentially three problems with the current
>>> combination of DGP + SNAT + LB:
>>>
>>> 1) The first packet is being SNATed in common zone due
>>> to
On 4/12/23 07:56, Ales Musil wrote:
> Use "distributed_nat" instead of just "distributed" in
> functions generating router NAT logical flows to avoid
> confusion.
>
> Signed-off-by: Ales Musil
> ---
Applied to the main branch, thanks!
___
dev mailing
On 4/19/23 07:39, Ales Musil wrote:
> On Tue, Apr 18, 2023 at 4:17 PM Dumitru Ceara wrote:
>
>> Hi Ales,
>>
>> On 4/17/23 16:50, Enrique Llorente Pastora wrote:
>>> This is better than nothing, copr would be the usually thing to have,
>>> but looks like it needs
>>> a lot of administrative
> On Wed, Apr 19, 2023 at 01:39:00PM +0200, Dumitru Ceara wrote:
> > On 4/19/23 12:55, Simon Horman wrote:
> > > On Wed, Apr 19, 2023 at 12:44:52PM +0200, Lorenzo Bianconi wrote:
> > >>> On Tue, Apr 18, 2023 at 04:14:36PM +0200, Lorenzo Bianconi wrote:
> > Remove ovn-egress-iface paramter
User has an option to leave the test environment in error state so that system
can be poked around to get more information. User can enable this option by
setting
environment variable OVS_PAUSE_TEST=1. User needs to press CTRL-D to resume the
cleanup operation.
When OVS_PAUSE_TEST=1 and the test
OVN checks whether ovn-installed is already present (in OVS) before updating it.
This might cause ovn-installed related issues in the following case:
- (1) ovn-installed is present
- (2) we claim the interface
- (3) we update ovs, removing ovn-installed and start installing flows
- (4) (next
When interface was unbound, the port was not always set down and the
port_binding->chassis not always removed.
Fixes: a7c7d4519e50 ("controller: avoid recomputes triggered by SBDB
Port_Binding updates.")
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2150905
Signed-off-by: Xavier
On Wed, Apr 19, 2023 at 01:39:00PM +0200, Dumitru Ceara wrote:
> On 4/19/23 12:55, Simon Horman wrote:
> > On Wed, Apr 19, 2023 at 12:44:52PM +0200, Lorenzo Bianconi wrote:
> >>> On Tue, Apr 18, 2023 at 04:14:36PM +0200, Lorenzo Bianconi wrote:
> Remove ovn-egress-iface paramter since it is
On 4/19/23 12:55, Simon Horman wrote:
> On Wed, Apr 19, 2023 at 12:44:52PM +0200, Lorenzo Bianconi wrote:
>>> On Tue, Apr 18, 2023 at 04:14:36PM +0200, Lorenzo Bianconi wrote:
Remove ovn-egress-iface paramter since it is no longer used.
>>>
>>> Hi Lorenzo,
>>
>> Hi Simon,
>>
>>>
>>> are there
On Wed, Apr 19, 2023 at 12:44:52PM +0200, Lorenzo Bianconi wrote:
> > On Tue, Apr 18, 2023 at 04:14:36PM +0200, Lorenzo Bianconi wrote:
> > > Remove ovn-egress-iface paramter since it is no longer used.
> >
> > Hi Lorenzo,
>
> Hi Simon,
>
> >
> > are there any backwards compatibility issues
> On Tue, Apr 18, 2023 at 04:14:36PM +0200, Lorenzo Bianconi wrote:
> > Remove ovn-egress-iface paramter since it is no longer used.
>
> Hi Lorenzo,
Hi Simon,
>
> are there any backwards compatibility issues from a user
> perspective with this change?
>
If we want to shape the aggregate
On Apr 19, Simon Horman wrote:
> On Tue, Apr 18, 2023 at 12:16:28PM -0400, Ihar Hrachyshka wrote:
> > Acked-By: Ihar Hrachyshka
> >
> > On Tue, Apr 18, 2023 at 10:14 AM Lorenzo Bianconi
> > wrote:
> > >
> > > Rework OVN QoS implementation in order to configure it through OVS QoS
> > > table
On Tue, Apr 18, 2023 at 04:14:36PM +0200, Lorenzo Bianconi wrote:
> Remove ovn-egress-iface paramter since it is no longer used.
Hi Lorenzo,
are there any backwards compatibility issues from a user
perspective with this change?
___
dev mailing list
On Tue, Apr 18, 2023 at 12:16:28PM -0400, Ihar Hrachyshka wrote:
> Acked-By: Ihar Hrachyshka
>
> On Tue, Apr 18, 2023 at 10:14 AM Lorenzo Bianconi
> wrote:
> >
> > Rework OVN QoS implementation in order to configure it through OVS QoS
> > table instead of running tc command directly bypassing
Hi Han, all
On Mon, Apr 17, 2023 at 8:02 PM Han Zhou wrote:
>
>
>
> On Mon, Apr 17, 2023 at 7:18 AM Lucas Martins wrote:
> >
> > Thanks all for the discussion and all the ideas here.
> >
> > After reading the emails, I think it boils down to two proposed approaches:
> >
> > 1) CMS to continue
On Tue, Apr 18, 2023 at 04:14:31PM +0200, Lorenzo Bianconi wrote:
> This is a preliminary patch to allow OVN to configure QoS through OvS
> db instead of running tc directly.
>
> Acked-By: Ihar Hrachyshka
> https://bugzilla.redhat.com/show_bug.cgi?id=2129742
> Tested-by: Rodolfo Alonso
>
On Tue, Apr 18, 2023 at 04:14:30PM +0200, Lorenzo Bianconi wrote:
> Remove tunnel interfaces from egress list in order to not shape them.
>
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2129742
> Tested-by: Rodolfo Alonso
> Signed-off-by: Lorenzo Bianconi
Reviewed-by: Simon Horman
On Mon, Mar 27, 2023 at 06:50:13AM -0400, Mike Pattrick wrote:
> From: Flavio Leitner
>
> The netdev receiving packets is supposed to provide the flags
> indicating if the L4 checksum was verified and it is OK or BAD,
> otherwise the stack will check when appropriate by software.
>
> If the
On Mon, Mar 27, 2023 at 06:50:12AM -0400, Mike Pattrick wrote:
> From: Flavio Leitner
>
> The netdev receiving packets is supposed to provide the flags
> indicating if the IP checksum was verified and it is GOOD or BAD,
> otherwise the stack will check when appropriate by software.
>
> If the
> -Original Message-
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Wednesday, April 19, 2023 2:44 PM
> To: wangyunjian
> Cc: d...@openvswitch.org; i.maxim...@ovn.org; luyicai
> Subject: Re: [ovs-dev] [PATCH] dpif-netlink: Fix memory leak
> dpif_netlink_open().
>
>
Reported by Address Sanitizer.
Indirect leak of 1024 byte(s) in 1 object(s) allocated from:
#0 0x7fe09d3bfe70 in __interceptor_malloc (/usr/lib64/libasan.so.4+0xe0e70)
#1 0x8759be in xmalloc__ lib/util.c:140
#2 0x875a9a in xmalloc lib/util.c:175
#3 0x7ba0d2 in ofpbuf_init
On Tue, Apr 18, 2023 at 02:58:07PM +0200, David Marchand wrote:
> Caught during some code review.
> SUPPORT_TC_INGRESS_PPS has been replaced with CHECK_TC_INGRESS_PPS().
>
> Fixes: 5f0fdf5e2c2e ("test: Move check for tc ingress pps support to test
> script.")
> Signed-off-by: David Marchand
On Tue, Apr 18, 2023 at 3:16 PM wangyunjian wrote:
> > I wonder though if we should pass any ofpbuf at all, as we don't care about
> > the
> > reply from the kernel for this case.
> > Something like:
> >
> > $ git diff
> > diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index
> >
Currently, bundle->cvlans and xbundle->cvlans are pointing to the
same memory location. This can cause issues if the main thread
modifies bundle->cvlans and frees it while the revalidator thread
is still accessing xbundle->cvlans. This can result in use after
free errors.
AddressSanitizer:
35 matches
Mail list logo
