On Wed, Jul 18, 2018 at 9:12 AM, Stephen Hemminger
wrote:
> The call to nla_nest_start when forming packet messages can lead to a NULL
> return so it's possible for attr to become NULL and we can potentially
> get a NULL pointer dereference on attr. Fix this by checking for
> a NULL return.
>
> B
On Wed, Jul 18, 2018 at 9:12 AM, Stephen Hemminger
wrote:
> The call to nla_nest_start in conntrack can lead to a NULL
> return so it's possible for attr to become NULL and we can potentially
> get a NULL pointer dereference on attr. Fix this by checking for
> a NULL return.
>
> Bugzilla: https:/
---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
On Tue, Jul 17, 2018 at 12:59 AM, Lam, Tiago wrote:
> On 16/07/2018 09:37, Lam, Tiago wrote:
> > On 13/07/2018 18:54, Darrell Ball wrote:
> >> Thanks for the patch.
> >>
> >> A few queries inline.
> >>
> >
> > Hi Darrell,
> >
> > Thanks for your inputs. I've replied in-line as well.
> >
> >> On W
sorry, several distractions delayed response.
On Mon, Jul 16, 2018 at 1:37 AM, Lam, Tiago wrote:
> On 13/07/2018 18:54, Darrell Ball wrote:
> > Thanks for the patch.
> >
> > A few queries inline.
> >
>
> Hi Darrell,
>
> Thanks for your inputs. I've replied in-line as well.
>
> > On Wed, Jul 11,
Bleep bloop. Greetings Qiuyu Xiao, 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: Inappropriate bracing around statement
#65 FILE: ovn/controller/encaps.c:100:
else
Bleep bloop. Greetings Qiuyu Xiao, 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: Too many signoffs; are you missing Co-authored-by lines?
WARNING: Line is 80 characters lo
This patch adds IPsec support for OVN tunnel. Basically, OVN offers a
binary option to its user for encryption configuration. If the IPsec
option is turned on, all tunnels will be encrypted. Otherwise, no tunnel
will be encrypted.
The changes are summarized as below:
1) Added a ipsec column on the
This patch reintroduces ovs-monitor-ipsec daemon that
was previously removed by commit 2b02d770 ("openvswitch:
Allow external IPsec tunnel management.")
After this patch, there are no IPsec flavored tunnels anymore.
IPsec is enabled by setting up the right values in:
1. OVSDB:Interface:options col
This patch modifies ovs-pki to generate x.509 version 3 certificate.
Compared with the x.509 v1 certificate generated by ovs-pki, version 3
certificate adds subjectAltName field and sets its value the same as
common name (CN). The main reason for this change is to enable
strongSwan IKE daemon to ex
This patch adds transport ports information for route lookup so that IPsec
can select tunnel traffic (geneve, stt, vxlan) to do encryption.
The patch was tested for geneve, stt, and vxlan tunnel and the results
show that IPsec policy can be set to only match the corresponding tunnel
traffic.
Sign
This patch series reintroduce IPsec support for OVS tunneling and enable OVN to
use IPsec tunnels. GRE, VXLAN, GENEVE, and STT IPsec tunnels are supported.
StrongSwan and LibreSwan IKE daemons are supported.
Changes from v1 to v2:
1) Merged the ovs-monitor-ipsec code to a single patch. Added Libr
On Wed, Jul 18, 2018 at 11:24:43AM -0400, Aaron Conole wrote:
> Markos Chandras writes:
>
> > When ovsdb-server is starting, it performs some DB steps such as
> > creating and upgrading the OvS DB. When we are running as
> > 'non-root' user, the 'runuser' tool is used to manage the privileges.
>
On 7/18/2018 10:34 AM, William Tu wrote:
On Wed, Jul 18, 2018 at 9:22 AM, Greg Rose wrote:
Upstream commit:
Before the patch, the erspan BSO bit (Bad/Short/Oversized) is not
handled. BSO has 4 possible values:
00 --> Good frame with no error, or unknown integrity
11 -
Hello all,
We are able to reproduce this issue on OVS 2.9.2 at will. The OVSDB NB
server or OVSDB SB server dumps core while it is trying to compact the
database.
You can reproduce the issue by using:
root@u1804-HVM-domU:/var/crash# ovs-appctl -t
/var/run/openvswitch/ovnsb_db.ctl ovsdb-server/co
On Wed, Jul 18, 2018 at 9:22 AM, Greg Rose wrote:
> Upstream commit:
> Before the patch, the erspan BSO bit (Bad/Short/Oversized) is not
> handled. BSO has 4 possible values:
> 00 --> Good frame with no error, or unknown integrity
> 11 --> Payload is a Bad Frame with CRC or Al
Sorry I made a mistake in the previous review. Operator '||' has higher
precedence
than operator '?:'. So the patch is correct.
Thanks,
Yifeng
On Tue, Jul 17, 2018 at 1:57 PM, Yifeng Sun wrote:
> Hi Ben,
>
> I found a small issue:
>
> +{
> +uint32_t mid = a->meter_id;
> +return mid == 0
This patch backports the commit from the latest OVS master to OVS-2.7.
Configuring flow control at ixgbe netdev-init is throwing error in port
start.
For eg: without this fix, user cannot configure flow control on ixgbe dpdk
port as below,
"
ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk
Upstream commit:
Before the patch, the erspan BSO bit (Bad/Short/Oversized) is not
handled. BSO has 4 possible values:
00 --> Good frame with no error, or unknown integrity
11 --> Payload is a Bad Frame with CRC or Alignment Error
01 --> Payload is a Short Frame
10
The call to nla_nest_start when forming packet messages can lead to a NULL
return so it's possible for attr to become NULL and we can potentially
get a NULL pointer dereference on attr. Fix this by checking for
a NULL return.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200537
Fixes: 8f0
Coverity is looking for bugs here, and a couple of new bugzilla
reports showed up where nla_nest_start return is not checked
for NULL.
Stephen Hemminger (2):
openvswitch: check for null return for nla_nest_start
openvswitch: check for null return for nla_nest_start in datapath
net/openvswitc
The call to nla_nest_start in conntrack can lead to a NULL
return so it's possible for attr to become NULL and we can potentially
get a NULL pointer dereference on attr. Fix this by checking for
a NULL return.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200533
Fixes: 11efd5cb04a1 ("open
Greg Rose writes:
> Add netstat when mentioning testing. Many check-kmod failures result
> when it is not present.
>
> Signed-off-by: Greg Rose
>
> ---
Acked-by: Aaron Conole
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mai
Gregory Rose writes:
> On 7/18/2018 8:03 AM, Aaron Conole wrote:
>> Hi Greg,
>>
>> Greg Rose writes:
>>
>>> Add netstat when mentioning testing. Many check-kmod failures result
>>> when it is not present.
>>>
>>> Signed-off-by: Greg Rose
>>> ---
>> Just wanted to point out that the subject loo
On 7/18/2018 8:03 AM, Aaron Conole wrote:
Hi Greg,
Greg Rose writes:
Add netstat when mentioning testing. Many check-kmod failures result
when it is not present.
Signed-off-by: Greg Rose
---
Just wanted to point out that the subject looks incomplete.
Otherwise:
Acked-by: Aaron Conole
Hello Aaron,
On 18/07/18 16:24, Aaron Conole wrote:
>
> I think there's actually a race condition here. Most likely,
> ovsdb-server doesn't need to be started before network.service.
>
> Looking at the bug, I think we can unroll some of the dependencies that
> each unit file has and get a clean
Markos Chandras writes:
> When ovsdb-server is starting, it performs some DB steps such as
> creating and upgrading the OvS DB. When we are running as
> 'non-root' user, the 'runuser' tool is used to manage the privileges.
> However, when this happens during systemd boot, we observe the following
Hi Greg,
Greg Rose writes:
> Add netstat when mentioning testing. Many check-kmod failures result
> when it is not present.
>
> Signed-off-by: Greg Rose
> ---
Just wanted to point out that the subject looks incomplete.
Otherwise:
Acked-by: Aaron Conole
_
Hi Alin,
0-day Robot writes:
> Bleep bloop. Greetings Alin Gabriel Serdean, 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.
>
>
I suggest folding in something like the following (sinc
Newer selinux base policies now split out 'map' actions, as well as
adding more explicit checks for hugetlbfs objects. Where previously these
weren't required, recent changes have flagged the allocation of hugepages
and subsequent clearing. This means that the hugepage storage information
for the
On Wed, Jul 18, 2018 at 6:52 PM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:
>
> I have been testing the patches, and seeing them work as expected
> (L3HA failovers, N/S, E/W, etc...), but I have found a couple of
> issues, one of them, "2", I'm not sure it's an issue, but I will
> descr
Hello,
Is anyone posting blog about openvswitch development environment ?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
I have been testing the patches, and seeing them work as expected
(L3HA failovers, N/S, E/W, etc...), but I have found a couple of
issues, one of them, "2", I'm not sure it's an issue, but I will
describe it too, in case it's not a real issue we can move it to
disc...@openvswitch.org then.
1) The
33 matches
Mail list logo
