Re: [ovs-dev] [PATCH] ofp-actions: Correct execution of encap/decap actions in action set

2018-05-07 Thread Yang, Yi Y 
Jan, sorry for late reply, I have been waiting for Sangfor guy's confirmation.

With this patch https://patchwork.ozlabs.org/patch/895405/, they won't have any 
issue any more. So now it can work well, thank you so much.

-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] 
Sent: Monday, April 9, 2018 3:12 PM
To: Yang, Yi Y ; d...@openvswitch.org
Subject: RE: [PATCH] ofp-actions: Correct execution of encap/decap actions in 
action set

Hi Yi,

The assertion failure is indeed caused by the incorrect implementation of 
double encap() and should be fixed by the patch you mention (which is merged to 
master by now).

Prior to the below fix this happened with every encap(nsh) in an group bucket. 

I can't say why it still happens periodically every few minutes in your test. 
You'd need to carefully analyze a crash dump to try to understand the packet 
processing history that leads to a double encap() or perhaps decap().

It is definitely worth trying whether the problem is already resolved on the 
latest master.

BR, Jan

> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Sunday, 08 April, 2018 10:27
> To: Jan Scheurich ; d...@openvswitch.org
> Subject: RE: [PATCH] ofp-actions: Correct execution of encap/decap 
> actions in action set
> 
> Hi, Jan
> 
> Sangfor guy tried this one, he still encountered assert issue after 
> ovs ran for about 20 minutes, moreover it appeared periodically. I'm not sure 
> if https://patchwork.ozlabs.org/patch/895405/ is helpful for this issue. Do 
> you think what the root cause is?
> 
> -Original Message-
> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
> Sent: Monday, March 26, 2018 3:36 PM
> To: d...@openvswitch.org
> Cc: Yang, Yi Y ; Jan Scheurich 
> 
> Subject: [PATCH] ofp-actions: Correct execution of encap/decap actions 
> in action set
> 
> The actions encap, decap and dec_nsh_ttl were wrongly flagged as 
> set_field actions in ofpact_is_set_or_move_action(). This caused them 
> to be executed twice in the action set or a group bucket, once 
> explicitly in
> ofpacts_execute_action_set() and once again as part of the list of set_field 
> or move actions.
> 
> Fixes: f839892a ("OF support and translation of generic encap and 
> decap")
> Fixes: 491e05c2 ("nsh: add dec_nsh_ttl action")
> 
> Signed-off-by: Jan Scheurich 
> 
> ---
> 
> The fix should be backported to OVS 2.9 and OVS 2.8 (without the case for 
> OFPACT_DEC_NSH_TTL introduced in 2.9).
> 
> 
>  lib/ofp-actions.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index 
> db85716..87797bc 100644
> --- a/lib/ofp-actions.c
> +++ b/lib/ofp-actions.c
> @@ -6985,9 +6985,6 @@ ofpact_is_set_or_move_action(const struct ofpact *a)
>  case OFPACT_SET_TUNNEL:
>  case OFPACT_SET_VLAN_PCP:
>  case OFPACT_SET_VLAN_VID:
> -case OFPACT_ENCAP:
> -case OFPACT_DECAP:
> -case OFPACT_DEC_NSH_TTL:
>  return true;
>  case OFPACT_BUNDLE:
>  case OFPACT_CLEAR_ACTIONS:
> @@ -7025,6 +7022,9 @@ ofpact_is_set_or_move_action(const struct ofpact *a)
>  case OFPACT_WRITE_METADATA:
>  case OFPACT_DEBUG_RECIRC:
>  case OFPACT_DEBUG_SLOW:
> +case OFPACT_ENCAP:
> +case OFPACT_DECAP:
> +case OFPACT_DEC_NSH_TTL:
>  return false;
>  default:
>  OVS_NOT_REACHED();
> --
> 1.9.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ovn-controller.at: fix occasional ovn-bridge-mappings test failure

2018-05-07 Thread Han Zhou 
This patch fixes the time issue in the test case so that when external-ids
is updated in Open_vSwitch OVSDB, give some time for SB OVSDB to get
updated by ovn-controller.

Signed-off-by: Han Zhou 
---
 tests/ovn-controller.at | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/ovn-controller.at b/tests/ovn-controller.at
index 3244707..a51f79e 100644
--- a/tests/ovn-controller.at
+++ b/tests/ovn-controller.at
@@ -62,6 +62,7 @@ check_patches
 
 # Configure two ovn-bridge mappings, but no patch ports should be created yet
 AT_CHECK([ovs-vsctl set Open_vSwitch . 
external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1])
+sleep 1
 check_bridge_mappings "physnet1:br-eth0,physnet2:br-eth1"
 check_patches
 
@@ -109,6 +110,7 @@ check_patches \
 
 # Delete the mapping and the ovn-bridge-mapping patch ports should go away.
 AT_CHECK([ovs-vsctl remove Open_vSwitch . external-ids ovn-bridge-mappings])
+sleep 1
 check_bridge_mappings
 check_patches
 
-- 
2.1.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ovn.at: fix occasional failure - send gratuitous ARP for NAT rules on HA distributed router

2018-05-07 Thread Han Zhou 
In this test case it didn't wait for all HVs to catch up, which
leads to occasional failures due to timing. This fix updates
the --wait=sb to --wait=hv, which fixes the problem.

Signed-off-by: Han Zhou 
---
 tests/ovn.at | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/ovn.at b/tests/ovn.at
index 4a53165..5554a24 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -8866,7 +8866,7 @@ AT_CHECK([ovn-nbctl lsp-set-type ln_port localnet])
 AT_CHECK([ovn-nbctl lsp-set-options ln_port network_name=physnet1])
 
 # wait for earlier changes to take effect
-AT_CHECK([ovn-nbctl --timeout=3 --wait=sb sync], [0], [ignore])
+AT_CHECK([ovn-nbctl --timeout=3 --wait=hv sync], [0], [ignore])
 
 reset_pcap_file() {
 local iface=$1
@@ -8882,7 +8882,7 @@ as hv1 reset_pcap_file snoopvif hv1/snoopvif
 as hv2 reset_pcap_file br-phys_n1 hv2/br-phys_n1
 as hv3 reset_pcap_file br-phys_n1 hv3/br-phys_n1
 # add nat-addresses option
-ovn-nbctl --wait=sb lsp-set-options lrp0-rp router-port=lrp0 
nat-addresses="router"
+ovn-nbctl --wait=hv lsp-set-options lrp0-rp router-port=lrp0 
nat-addresses="router"
 
 # Wait for packets to be received through hv2.
 OVS_WAIT_UNTIL([test `wc -c < "hv1/snoopvif-tx.pcap"` -ge 100])
@@ -8942,11 +8942,11 @@ AT_CHECK([grep $garp hv2_br_phys_tx | sort], [0], [])
 AT_CHECK([ovn-nbctl set Logical_Switch_Port ln_port tag=2014])
 
 # wait for earlier changes to take effect
-AT_CHECK([ovn-nbctl --timeout=3 --wait=sb sync], [0], [ignore])
+AT_CHECK([ovn-nbctl --timeout=3 --wait=hv sync], [0], [ignore])
 
 # update nat-addresses option
-ovn-nbctl --wait=sb lsp-set-options lrp0-rp router-port=lrp0
-ovn-nbctl --wait=sb lsp-set-options lrp0-rp router-port=lrp0 
nat-addresses="router"
+ovn-nbctl --wait=hv lsp-set-options lrp0-rp router-port=lrp0
+ovn-nbctl --wait=hv lsp-set-options lrp0-rp router-port=lrp0 
nat-addresses="router"
 
 as hv1 reset_pcap_file snoopvif hv1/snoopvif
 as hv2 reset_pcap_file br-phys_n1 hv2/br-phys_n1
-- 
2.1.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Does ovs support OpenFlow 1.3 meter table now?

2018-05-07 Thread Mingming Chen 
Hi all,


According to my prior experience, ovs 2.5.0 doesn't support meter table. Now I 
am using ovs 2.5.4, and I want to test meter table. So, does ovs 2.5.4 supports 
openflow 1.3 meter table? If not, is there any version of ovs could support 
meter table? Thanks a lot!




Best wishes,
Mingming
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1 0/2] ovs-vsctl segfaults on del-port of fake-bridge when parent is provided

2018-05-07 Thread Ben Pfaff 
Thanks a lot for the report and the fix!

Our usual practice is to put the test and the fix into the same patch,
so I squashed these together.  I applied the squashed patches to master
and backported as far as branch-2.5.  I see that the bug probably
existed before that, but there was a patch reject at that point and I
didn't see too many value in going farther.

Thanks,

Ben.

On Tue, May 01, 2018 at 07:07:35PM -0400, Flavio Fernandes wrote:
> Greetings!
> 
> I was lucky enough to spend some time having fun with OVS recently and 
> encountered
> a bug that may be worth sharing with you.
> 
> The code path in the error case when bridge's del-port is attempted for the
> parent (instead of the fake-bridge) segfaults. Here are some simple steps for
> reproducing this issue:
> 
> ./boot.sh ; ./configure ; make -j4 ; make sandbox
> 
> PARENT_BRIDGE=br0 ; FAKE_BRIDGE=br0c ; VLAN_TAG=666
> ovs-vsctl add-br ${PARENT_BRIDGE}
> ovs-vsctl add-br $FAKE_BRIDGE $PARENT_BRIDGE $VLAN_TAG
> 
> # Add a port to parent bridge, which happens to have same tag as the 
> fake_bridge
> # Note: The port could be have been added directly to the fake bridge too, of 
> course.
> # The end result of the add-port is the same.
> ovs-vsctl add-port $PARENT_BRIDGE p1 -- set port p1 tag=${VLAN_TAG}
> # ovs-vsctl add-port $FAKE_BRIDGE p1
> 
> # removing p1 will make a segfault
> ovs-vsctl del-port $PARENT_BRIDGE p1  ; # sad panda moment
> 
> # Here are 3 ways of working around this segfault
> 
> # workaround 1: remove tag before removing port from parent
> ovs-vsctl remove port p1 tag $VLAN_TAG && \
> ovs-vsctl del-port $PARENT_BRIDGE p1  && echo ok
> # workaround 2: remove port as if it belongs to fake bridge
> ovs-vsctl del-port $FAKE_BRIDGE p1  && echo ok
> # workaround 3: remove port w/out specifying a bridge
> ovs-vsctl del-port p1  && echo ok
> 
> 
> This issue appears to exist since commit 7c79588e , which dates back to 
> Feb/2010.
> I see it in OVS 2.3.2.
> 
> -- flaviof
> 
> 
> 
> More details about the segfault:
> 
> |main: Ubuntu ~/ovs.git/_ffbuilddir/utilities/sandbox on devel
> $ sudo ovs-vsctl show
> fa096c6f-8f5f-49ae-92b4-e94ce58aceec
> Bridge "br0"
> Port "br0"
> Interface "br0"
> type: internal
> Port "p1"
> tag: 666
> Interface "p1"
> Port "br0c"
> tag: 666
> Interface "br0c"
> type: internal
> |main: Ubuntu ~/ovs.git/_ffbuilddir/utilities/sandbox on devel
> $ gdb /home/ff/ovs.git/_ffbuilddir/utilities/ovs-vsctl
> ...
> Reading symbols from /home/ff/ovs.git/_ffbuilddir/utilities/ovs-vsctl...done.
> (gdb) run del-port br0 p1
> Starting program: /home/ff/ovs.git/_ffbuilddir/utilities/ovs-vsctl del-port 
> br0 p1
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0040a945 in cmd_del_port (ctx=0x7fffc5d0) at 
> ../utilities/ovs-vsctl.c:1750
> 1750ctl_fatal("bridge %s does not have a port %s 
> (although "
> (gdb) bt
> #0  0x0040a945 in cmd_del_port (ctx=0x7fffc5d0) at 
> ../utilities/ovs-vsctl.c:1750
> #1  0x004075dd in do_vsctl (args=0xc8f7f0 
> "/home/ff/ovs.git/_ffbuilddir/utilities/ovs-vsctl del-port br0 p1", 
> commands=0xc8fd50, n_commands=1, idl=0xc8fdb0)
> at ../utilities/ovs-vsctl.c:2623
> #2  0x00405e7e in main (argc=4, argv=0x7fffc868) at 
> ../utilities/ovs-vsctl.c:184
> (gdb) list
> 1745struct vsctl_bridge *bridge;
> 1746
> 1747bridge = find_bridge(vsctl_ctx, ctx->argv[1], true);
> 1748if (port->bridge != bridge) {
> 1749if (port->bridge->parent == bridge) {
> 1750ctl_fatal("bridge %s does not have a port %s 
> (although "
> 1751"its parent bridge %s does)",
> 1752ctx->argv[1], ctx->argv[2],
> 1753bridge->parent->name);
> 1754} else {
> (gdb) p ctx->argv[1]
> $1 = 0x7fffcba5 "br0"
> (gdb) p ctx->argv[2]
> $2 = 0x7fffcba9 "p1"
> (gdb) p port->bridge->name
> $3 = 0xc9a290 "br0c"
> (gdb) p bridge
> $4 = (struct vsctl_bridge *) 0xcc9d60
> (gdb) p bridge->parent
> $5 = (struct vsctl_bridge *) 0x0
> (gdb) p port->bridge
> $6 = (struct vsctl_bridge *) 0xccb440
> (gdb) p bridge->name
> $7 = 0xcc8da0 "br0"
> (gdb)
> 
> 
> Flavio Fernandes (2):
>   ovs-vsctl.at: deleting a port from fake bridge
>   ovs-vsctl: Fix segfault when attempting to del-port from parent
> bridge.
> 
>  tests/ovs-vsctl.at| 17 +
>  utilities/ovs-vsctl.c |  4 ++--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> -- 
> 1.9.1
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4] ovn-ctl: Handle whitespaces when using eval for start_ovsdb:

2018-05-07 Thread Ben Pfaff 
On Mon, Apr 16, 2018 at 09:55:38PM -0700, aginwala wrote:
> eval doesn't understand white space for local var which was introduced in 
> commit
> 79c7961b8b3c4b7ea0251dea2ffacfa84c84fecb for starting clustered ovn dbs.
> As ovn-ctl uses sh instead of bash, parsing local var with white space will 
> fail.
> 
> e.g. /usr/share/openvswitch/scripts/ovn-ctl --db-nb-addr=192.168.220.101 
> --db-nb-create-insecure-remote=yes \
>  --db-sb-addr=192.168.220.101 --db-sb-create-insecure-remote=yes \
>  --db-nb-cluster-local-addr=192.168.220.101 \
>  --db-sb-cluster-local-addr=192.168.220.101 \
>  
> --ovn-northd-nb-db=tcp:192.168.220.101:6641,tcp:192.168.220.102:6641,tcp:192.168.220.103:6641
>  \
>  
> --ovn-northd-sb-db=tcp:192.168.220.101:6642,tcp:192.168.220.102:6642,tcp:192.168.220.103:6642
>  \
>  start_northd
> 
> gives error: /usr/share/openvswitch/scripts/ovn-ctl: 1: local: -vfile:info: 
> bad variable name
> 
> As a result ovsdb fails to even initialize and start. Hence, we need to 
> seperate local keyword for all
> variables used with eval to make it work with both dash and bash.
> 
> Signed-off-by: aginwala 

Thanks, applied to master and branch-2.9.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovs-vswitchd: Better document that ovs-vswitchd manages its own datapaths.

2018-05-07 Thread Ben Pfaff 
On Fri, May 04, 2018 at 09:17:12AM -0700, Justin Pettit wrote:
> 
> > On May 3, 2018, at 11:27 PM, Ben Pfaff  wrote:
> > 
> > More explicitly discourage users from managing them themselves.
> > 
> > Signed-off-by: Ben Pfaff 
> 
> Acked-by: Justin Pettit 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] openvswitch: make vport_ops:send()'s return type consistent

2018-05-07 Thread Gregory Rose 

On 4/24/2018 6:19 AM, Luc Van Oostenryck wrote:

The method struct vport_ops:send() is defined as returning an
'netdev_tx_t', which is defined as a typedef for a bitwise type
and otherwise used for the start_xmit() methods.
However, most openvswitch drivers use for this method dev_queue_xmit()
which returns an 'int' and the return value of vport_ops:send() is
in fact never used.

Make things typewise consistent and use 'int' for vport_ops:send()
as well for internal_dev_recv() (which is the only proper send method)
as using 'netdev_tx_t' doesn't offer any advantages and in fact seems,
if not wrong at least, inadequate.

Signed-off-by: Luc Van Oostenryck 
---
  net/openvswitch/vport-internal_dev.c | 6 +++---
  net/openvswitch/vport.h  | 2 +-
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/openvswitch/vport-internal_dev.c 
b/net/openvswitch/vport-internal_dev.c
index 3ea55618e..2fd68c2fb 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -231,7 +231,7 @@ static void internal_dev_destroy(struct vport *vport)
rtnl_unlock();
  }
  
-static netdev_tx_t internal_dev_recv(struct sk_buff *skb)

+static int internal_dev_recv(struct sk_buff *skb)
  {
struct net_device *netdev = skb->dev;
struct pcpu_sw_netstats *stats;
@@ -239,7 +239,7 @@ static netdev_tx_t internal_dev_recv(struct sk_buff *skb)
if (unlikely(!(netdev->flags & IFF_UP))) {
kfree_skb(skb);
netdev->stats.rx_dropped++;
-   return NETDEV_TX_OK;
+   return 0;
}
  
  	skb_dst_drop(skb);

@@ -257,7 +257,7 @@ static netdev_tx_t internal_dev_recv(struct sk_buff *skb)
u64_stats_update_end(>syncp);
  
  	netif_rx(skb);

-   return NETDEV_TX_OK;
+   return 0;
  }
  
  static struct vport_ops ovs_internal_vport_ops = {

diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
index cda66c26a..8dcb48fe8 100644
--- a/net/openvswitch/vport.h
+++ b/net/openvswitch/vport.h
@@ -141,7 +141,7 @@ struct vport_ops {
int (*set_options)(struct vport *, struct nlattr *);
int (*get_options)(const struct vport *, struct sk_buff *);
  
-	netdev_tx_t (*send) (struct sk_buff *skb);

+   int (*send) (struct sk_buff *skb);
struct module *owner;
struct list_head list;
  };


Yes, it does seem odd to use a tx return type for receive.  Nice fixup.

Reviewed-by: Greg Rose 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] openvswitch: fix internal_dev_xmit()'s return type

2018-05-07 Thread Gregory Rose 

On 4/24/2018 6:17 AM, Luc Van Oostenryck wrote:

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.

Fix this by returning 'netdev_tx_t' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
  net/openvswitch/vport-internal_dev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/openvswitch/vport-internal_dev.c 
b/net/openvswitch/vport-internal_dev.c
index bb95c43aa..3ea55618e 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -43,7 +43,7 @@ static struct internal_dev *internal_dev_priv(struct 
net_device *netdev)
  }
  
  /* Called with rcu_read_lock_bh. */

-static int internal_dev_xmit(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t internal_dev_xmit(struct sk_buff *skb, struct net_device 
*netdev)
  {
int len, err;
  


LGTM

Reviewed-by: Greg Rose 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] compat: Fix upstream 4.4.119 kernel

2018-05-07 Thread Gregory Rose 

On 4/20/2018 11:13 AM, Greg Rose wrote:

The Linux 4.4.119 kernel (and perhaps others) from kernel.org
backports some dst_cache code that breaks the openvswitch kernel
due to a duplicated name "dst_cache_destroy".  For most cases the
"USE_UPSTREAM_TUNNEL" covers this but in this case the dst_cache
feature needs to be separated out.

Add the necessary compatibility detection layer in acinclude.m4 and
then fixup the source files so that if the built-in kernel includes
dst_cache support then exclude our own compatibility code.

Signed-off-by: Greg Rose 


Ping?

- Greg

---
  acinclude.m4  | 2 ++
  datapath/linux/compat/dst_cache.c | 2 ++
  datapath/linux/compat/include/net/dst_cache.h | 5 +
  3 files changed, 9 insertions(+)

diff --git a/acinclude.m4 b/acinclude.m4
index dd264b3..60186d3 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -533,6 +533,8 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
  [OVS_GREP_IFELSE([$KSRC/include/net/dst_cache.h], 
[dst_cache],
   
[OVS_DEFINE([USE_UPSTREAM_TUNNEL])])])])
  
+  OVS_GREP_IFELSE([$KSRC/include/net/dst_cache.h], [dst_cache],

+  [OVS_DEFINE([USE_BUILTIN_DST_CACHE])])
OVS_GREP_IFELSE([$KSRC/include/net/mpls.h], [mpls_hdr],
[OVS_DEFINE([MPLS_HEADER_IS_L3])])
OVS_GREP_IFELSE([$KSRC/include/linux/net.h], [sock_create_kern.*net],
diff --git a/datapath/linux/compat/dst_cache.c 
b/datapath/linux/compat/dst_cache.c
index b936516..45990cb 100644
--- a/datapath/linux/compat/dst_cache.c
+++ b/datapath/linux/compat/dst_cache.c
@@ -9,6 +9,7 @@
   * (at your option) any later version.
   */
  
+#ifndef USE_BUILTIN_DST_CACHE

  #include 
  #include 
  #include 
@@ -169,3 +170,4 @@ void rpl_dst_cache_destroy(struct dst_cache *dst_cache)
  }
  EXPORT_SYMBOL_GPL(rpl_dst_cache_destroy);
  #endif /*USE_UPSTREAM_TUNNEL */
+#endif /* USE_BUILTIN_DST_CACHE */
diff --git a/datapath/linux/compat/include/net/dst_cache.h 
b/datapath/linux/compat/include/net/dst_cache.h
index ff4d83b..6084d4e 100644
--- a/datapath/linux/compat/include/net/dst_cache.h
+++ b/datapath/linux/compat/include/net/dst_cache.h
@@ -1,6 +1,10 @@
  #ifndef _NET_DST_CACHE_WRAPPER_H
  #define _NET_DST_CACHE_WRAPPER_H
  
+#ifdef USE_BUILTIN_DST_CACHE

+#include_next 
+#else
+
  #include 
  #include 
  #if IS_ENABLED(CONFIG_IPV6)
@@ -106,4 +110,5 @@ int rpl_dst_cache_init(struct dst_cache *dst_cache, gfp_t 
gfp);
  void rpl_dst_cache_destroy(struct dst_cache *dst_cache);
  
  #endif /* USE_UPSTREAM_TUNNEL */

+#endif /* USE_BUILTIN_DST_CACHE */
  #endif


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn: Add a new action 'nd_na_router' to handle NS requests for router IPs

2018-05-07 Thread Mark Michelson 

Hi Numan, thanks for the fix.

Out of curiosity, why did you add a new action instead of adding a new 
logical field (something like nd.rso)?


On 05/07/2018 02:36 PM, nusid...@redhat.com wrote:

From: Numan Siddique 

Presently when a VM's IPv6 stack sends a Neighbor Solicitation request for its
router IP, (mostly when the ND cache entry for the router is in STALE state)
ovn-controller responds with a Neighbor Adv packet (using the action nd_na).
But it doesn't set 'ND_RSO_ROUTER' in the RSO flags. Because of which, the
VM deletes the default route. The default route gets added again when the next
RA is received (but would again gets deleted if its sends NS request). And this
results in disruption of IPv6 traffic.

This patch addresses this issue by adding a new action 'nd_na_router' which is
same as 'nd_na' but it sets the 'ND_RSO_ROUTER' in the RSO flags. ovn-northd
uses this action. A new action is added instead of modifying the existing 
'nd_na'
action. This is because
   - We cannot set the RSO flags in the "nd_na { ..actions .. }"
   - It would be ugly to have something like nd_na { router_flags, ...actions 
.. }

(Please note: There are 3 'Line length is >79-characters' warnings in ovn.at 
which
I couldn't resolve.)

Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1567735
CC: Justin Pettit 
CC: Mark Michelson 
Signed-off-by: Numan Siddique 
---
  include/ovn/actions.h |  7 +++
  ovn/controller/pinctrl.c  | 23 +++
  ovn/lib/actions.c | 22 ++
  ovn/northd/ovn-northd.c   |  2 +-
  ovn/utilities/ovn-trace.c |  1 +
  tests/ovn.at  |  5 +
  6 files changed, 51 insertions(+), 9 deletions(-)

diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index fb8f51509..638465193 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -68,6 +68,7 @@ struct ovn_extend_table;
  OVNACT(ICMP6, ovnact_nest)\
  OVNACT(TCP_RESET, ovnact_nest)\
  OVNACT(ND_NA, ovnact_nest)\
+OVNACT(ND_NA_ROUTER,  ovnact_nest)\
  OVNACT(GET_ARP,   ovnact_get_mac_bind)\
  OVNACT(PUT_ARP,   ovnact_put_mac_bind)\
  OVNACT(GET_ND,ovnact_get_mac_bind)\
@@ -444,6 +445,12 @@ enum action_opcode {
   * The actions, in OpenFlow 1.3 format, follow the action_header.
   */
  ACTION_OPCODE_TCP_RESET,
+
+/* "nd_na_router { ...actions... }" with rso flag 'ND_RSO_ROUTER' set.
+*
+* The actions, in OpenFlow 1.3 format, follow the action_header.
+*/
+ACTION_OPCODE_ND_NA_ROUTER,
  };
  
  /* Header. */

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 6e6aa1caa..305f20649 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -81,7 +81,8 @@ static void send_garp_run(struct controller_ctx *ctx,
struct sset *active_tunnels);
  static void pinctrl_handle_nd_na(const struct flow *ip_flow,
   const struct match *md,
- struct ofpbuf *userdata);
+ struct ofpbuf *userdata,
+ bool is_router);
  static void reload_metadata(struct ofpbuf *ofpacts,
  const struct match *md);
  static void pinctrl_handle_put_nd_ra_opts(
@@ -1154,7 +1155,11 @@ process_packet_in(const struct ofp_header *msg, struct 
controller_ctx *ctx)
  break;
  
  case ACTION_OPCODE_ND_NA:

-pinctrl_handle_nd_na(, _metadata, );
+pinctrl_handle_nd_na(, _metadata, , false);
+break;
+
+case ACTION_OPCODE_ND_NA_ROUTER:
+pinctrl_handle_nd_na(, _metadata, , true);
  break;
  
  case ACTION_OPCODE_PUT_ND:

@@ -2308,7 +2313,7 @@ reload_metadata(struct ofpbuf *ofpacts, const struct 
match *md)
  
  static void

  pinctrl_handle_nd_na(const struct flow *ip_flow, const struct match *md,
- struct ofpbuf *userdata)
+ struct ofpbuf *userdata, bool is_router)
  {
  /* This action only works for IPv6 ND packets, and the switch should only
   * send us ND packets this way, but check here just to be sure. */
@@ -2322,13 +2327,15 @@ pinctrl_handle_nd_na(const struct flow *ip_flow, const 
struct match *md,
  struct dp_packet packet;
  dp_packet_use_stub(, packet_stub, sizeof packet_stub);
  
-/* xxx These flags are not exactly correct.  Look at section 7.2.4

- * xxx of RFC 4861.  For example, we need to set ND_RSO_ROUTER for
- * xxx router's interfaces and ND_RSO_SOLICITED only if it was
- * xxx requested. */
+/* These flags are not exactly correct.  Look at section 7.2.4
+ * of RFC 4861. */
+uint32_t rso_flags = ND_RSO_SOLICITED | ND_RSO_OVERRIDE;
+if (is_router) {
+rso_flags |=

[ovs-dev] [PATCH] ovn: Add a new action 'nd_na_router' to handle NS requests for router IPs

2018-05-07 Thread nusiddiq 
From: Numan Siddique 

Presently when a VM's IPv6 stack sends a Neighbor Solicitation request for its
router IP, (mostly when the ND cache entry for the router is in STALE state)
ovn-controller responds with a Neighbor Adv packet (using the action nd_na).
But it doesn't set 'ND_RSO_ROUTER' in the RSO flags. Because of which, the
VM deletes the default route. The default route gets added again when the next
RA is received (but would again gets deleted if its sends NS request). And this
results in disruption of IPv6 traffic.

This patch addresses this issue by adding a new action 'nd_na_router' which is
same as 'nd_na' but it sets the 'ND_RSO_ROUTER' in the RSO flags. ovn-northd
uses this action. A new action is added instead of modifying the existing 
'nd_na'
action. This is because
  - We cannot set the RSO flags in the "nd_na { ..actions .. }"
  - It would be ugly to have something like nd_na { router_flags, ...actions .. 
}

(Please note: There are 3 'Line length is >79-characters' warnings in ovn.at 
which
I couldn't resolve.)

Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1567735
CC: Justin Pettit 
CC: Mark Michelson 
Signed-off-by: Numan Siddique 
---
 include/ovn/actions.h |  7 +++
 ovn/controller/pinctrl.c  | 23 +++
 ovn/lib/actions.c | 22 ++
 ovn/northd/ovn-northd.c   |  2 +-
 ovn/utilities/ovn-trace.c |  1 +
 tests/ovn.at  |  5 +
 6 files changed, 51 insertions(+), 9 deletions(-)

diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index fb8f51509..638465193 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -68,6 +68,7 @@ struct ovn_extend_table;
 OVNACT(ICMP6, ovnact_nest)\
 OVNACT(TCP_RESET, ovnact_nest)\
 OVNACT(ND_NA, ovnact_nest)\
+OVNACT(ND_NA_ROUTER,  ovnact_nest)\
 OVNACT(GET_ARP,   ovnact_get_mac_bind)\
 OVNACT(PUT_ARP,   ovnact_put_mac_bind)\
 OVNACT(GET_ND,ovnact_get_mac_bind)\
@@ -444,6 +445,12 @@ enum action_opcode {
  * The actions, in OpenFlow 1.3 format, follow the action_header.
  */
 ACTION_OPCODE_TCP_RESET,
+
+/* "nd_na_router { ...actions... }" with rso flag 'ND_RSO_ROUTER' set.
+*
+* The actions, in OpenFlow 1.3 format, follow the action_header.
+*/
+ACTION_OPCODE_ND_NA_ROUTER,
 };
 
 /* Header. */
diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 6e6aa1caa..305f20649 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -81,7 +81,8 @@ static void send_garp_run(struct controller_ctx *ctx,
   struct sset *active_tunnels);
 static void pinctrl_handle_nd_na(const struct flow *ip_flow,
  const struct match *md,
- struct ofpbuf *userdata);
+ struct ofpbuf *userdata,
+ bool is_router);
 static void reload_metadata(struct ofpbuf *ofpacts,
 const struct match *md);
 static void pinctrl_handle_put_nd_ra_opts(
@@ -1154,7 +1155,11 @@ process_packet_in(const struct ofp_header *msg, struct 
controller_ctx *ctx)
 break;
 
 case ACTION_OPCODE_ND_NA:
-pinctrl_handle_nd_na(, _metadata, );
+pinctrl_handle_nd_na(, _metadata, , false);
+break;
+
+case ACTION_OPCODE_ND_NA_ROUTER:
+pinctrl_handle_nd_na(, _metadata, , true);
 break;
 
 case ACTION_OPCODE_PUT_ND:
@@ -2308,7 +2313,7 @@ reload_metadata(struct ofpbuf *ofpacts, const struct 
match *md)
 
 static void
 pinctrl_handle_nd_na(const struct flow *ip_flow, const struct match *md,
- struct ofpbuf *userdata)
+ struct ofpbuf *userdata, bool is_router)
 {
 /* This action only works for IPv6 ND packets, and the switch should only
  * send us ND packets this way, but check here just to be sure. */
@@ -2322,13 +2327,15 @@ pinctrl_handle_nd_na(const struct flow *ip_flow, const 
struct match *md,
 struct dp_packet packet;
 dp_packet_use_stub(, packet_stub, sizeof packet_stub);
 
-/* xxx These flags are not exactly correct.  Look at section 7.2.4
- * xxx of RFC 4861.  For example, we need to set ND_RSO_ROUTER for
- * xxx router's interfaces and ND_RSO_SOLICITED only if it was
- * xxx requested. */
+/* These flags are not exactly correct.  Look at section 7.2.4
+ * of RFC 4861. */
+uint32_t rso_flags = ND_RSO_SOLICITED | ND_RSO_OVERRIDE;
+if (is_router) {
+rso_flags |= ND_RSO_ROUTER;
+}
 compose_nd_na(, ip_flow->dl_dst, ip_flow->dl_src,
   _flow->nd_target, _flow->ipv6_src,
-  htonl(ND_RSO_SOLICITED | ND_RSO_OVERRIDE));
+  htonl(rso_flags));
 
 /*

Re: [ovs-dev] [PATCH] ovn-controller: handle multicast group for local datapath only

2018-05-07 Thread Mark Michelson 

Looks good to me.

Acked-by: Mark Michelson 

On 05/03/2018 10:30 PM, Han Zhou wrote:

Most mc related flows are added only if the mc is related to local
datapath, but there is a flow added before the local datapath
check, out of the function consider_mc_group(). This patch fixes it.

Signed-off-by: Han Zhou 
---
  ovn/controller/physical.c | 31 +++
  1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 8c92c1d..ab86b52 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -742,8 +742,22 @@ consider_mc_group(enum mf_field_id mff_ovn_geneve,
  return;
  }
  
+/* Table 32, priority 150.

+ * ===
+ *
+ * Multicast packets that should not be sent to other hypervisors.
+ */
+struct match match = MATCH_CATCHALL_INITIALIZER;
+match_set_metadata(, htonll(mc->datapath->tunnel_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, mc->tunnel_key);
+match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
+ MLF_LOCAL_ONLY, MLF_LOCAL_ONLY);
+ofpbuf_clear(ofpacts_p);
+put_resubmit(OFTABLE_LOCAL_OUTPUT, ofpacts_p);
+ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, 0, ,
+ofpacts_p);
+
  struct sset remote_chassis = SSET_INITIALIZER(_chassis);
-struct match match;
  
  match_init_catchall();

  match_set_metadata(, htonll(dp_key));
@@ -1006,21 +1020,6 @@ physical_run(struct controller_ctx *ctx, enum 
mf_field_id mff_ovn_geneve,
  struct ofpbuf remote_ofpacts;
  ofpbuf_init(_ofpacts, 0);
  SBREC_MULTICAST_GROUP_FOR_EACH (mc, ctx->ovnsb_idl) {
-/* Table 32, priority 150.
- * ===
- *
- * Multicast packets that should not be sent to other hypervisors.
- */
-struct match match = MATCH_CATCHALL_INITIALIZER;
-match_set_metadata(, htonll(mc->datapath->tunnel_key));
-match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, mc->tunnel_key);
-match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
- MLF_LOCAL_ONLY, MLF_LOCAL_ONLY);
-ofpbuf_clear();
-put_resubmit(OFTABLE_LOCAL_OUTPUT, );
-ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, 0, ,
-);
-
  consider_mc_group(mff_ovn_geneve, ct_zones, local_datapaths, chassis,
mc, , _ofpacts, flow_table);
  }



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Cannot open /dev/vfio/noiommu-0: Permission denied

2018-05-07 Thread Leon Goldberg 
On Mon, May 7, 2018 at 9:00 PM, Aaron Conole  wrote:

> Leon Goldberg  writes:
>
> > I stand correct, I was not using permissive mode. With permissive mode,
> noiommu-0 issue seems to
> > be resolved, however:
>
> Cool.  I caught other issues turning on the -DB flag... although maybe
> that was using enforcing mode as well.
>
> > type=AVC msg=audit(1525707587.009:447): avc:  denied  { remove_name }
> for  pid=4497
> > comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> > scontext=system_u:system_r:svirt_t:s0:c794,c950
> tcontext=unconfined_u:object_r:default_t:s0
> > tclass=dir
> > type=AVC msg=audit(1525707587.009:447): avc:  denied  { unlink } for
> pid=4497
> > comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> > scontext=system_u:system_r:svirt_t:s0:c794,c950
> tcontext=system_u:object_r:default_t:s0
> > tclass=sock_file
> > type=AVC msg=audit(1525707587.009:448): avc:  denied  { add_name } for
> pid=4497
> > comm="qemu-kvm" name="vhost-user-5" scontext=system_u:system_r:
> svirt_t:s0:c794,c950
> > tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> > type=AVC msg=audit(1525707587.009:448): avc:  denied  { create } for
> pid=4497
> > comm="qemu-kvm" name="vhost-user-5" scontext=system_u:system_r:
> svirt_t:s0:c794,c950
> > tcontext=system_u:object_r:default_t:s0 tclass=sock_file
> >
> > Still occurs.
> >
> > OVS log shows:
> >
> > 2018-05-07T15:27:15.059Z|00072|dpdk|INFO|VHOST_CONFIG: vhost-user
> client: socket created, fd:
> > 55
> > 2018-05-07T15:27:15.059Z|00073|netdev_dpdk|INFO|vHost User device
> 'dpdkvhostclient1' created
> > in 'client' mode, using client socket '/vhostusers/vhost-user-5'
> > 2018-05-07T15:27:15.062Z|00074|dpdk|WARN|VHOST_CONFIG: failed to
> connect to
> > /vhostusers/vhost-user-5: Permission denied
>
> Does that directory exist?  What are the permissions?  What are the
> permissions of the sock file that exist in that directory?
>

[root@lago-network-suite-master-host-0 ~]# ll /vhostusers/
total 0
srwxrwxr-x. 1 qemu kvm 0 May  7 11:55 vhost-user-5


>
> > On Mon, May 7, 2018 at 6:21 PM, Leon Goldberg 
> wrote:
> >
> >  Aha, indeed, I see:
> >
> >  type=AVC msg=audit(1525649015.102:1305): avc:  denied  { open } for
> pid=12993
> >  comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs" ino=708920
> >  scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:
> device_t:s0
> >  tclass=chr_file
> >  type=AVC msg=audit(1525649177.311:1326): avc:  denied  { open } for
> pid=13241
> >  comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs" ino=708920
> >  scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:
> device_t:s0
> >  tclass=chr_file
> >
> >  and I'm using permissive mode.
> >
> >  I also see:
> >
> >  [root@lago-network-suite-master-host-0 ~]# cat
> /var/log/audit/audit.log | grep vhost-user-5
> >  type=AVC msg=audit(1525636067.061:757): avc:  denied  { create } for
> pid=7533
> >  comm="qemu-kvm" name="vhost-user-5" scontext=system_u:system_r:
> svirt_t:s0:c423,c510
> >  tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
> >  type=AVC msg=audit(1525648910.361:1276): avc:  denied  { add_name }
> for  pid=12734
> >  comm="qemu-kvm" name="vhost-user-5" scontext=system_u:system_r:
> svirt_t:s0:c245,c301
> >  tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> >  type=AVC msg=audit(1525648910.361:1276): avc:  denied  { create } for
> pid=12734
> >  comm="qemu-kvm" name="vhost-user-5" scontext=system_u:system_r:
> svirt_t:s0:c245,c301
> >  tcontext=system_u:object_r:default_t:s0 tclass=sock_file
> >  type=AVC msg=audit(1525648979.442:1290): avc:  denied  { remove_name }
> for  pid=12822
> >  comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> >  scontext=system_u:system_r:svirt_t:s0:c515,c819
> tcontext=unconfined_u:object_r:default_t:s0
> >  tclass=dir
> >  type=AVC msg=audit(1525648979.442:1290): avc:  denied  { unlink } for
> pid=12822
> >  comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> >  scontext=system_u:system_r:svirt_t:s0:c515,c819
> tcontext=system_u:object_r:default_t:s0
> >  tclass=sock_file
> >  type=AVC msg=audit(1525648979.442:1291): avc:  denied  { add_name }
> for  pid=12822
> >  comm="qemu-kvm" name="vhost-user-5" scontext=system_u:system_r:
> svirt_t:s0:c515,c819
> >  tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> >  type=AVC msg=audit(1525648979.442:1291): avc:  denied  { create } for
> pid=12822
> >  comm="qemu-kvm" name="vhost-user-5" scontext=system_u:system_r:
> svirt_t:s0:c515,c819
> >  tcontext=system_u:object_r:default_t:s0 tclass=sock_file
> >
> >  This is my vhostuser client.
> >
> >  On Mon, May 7, 2018 at 4:39 PM, Aaron Conole 
> wrote:
> >
> >  Leon Goldberg  writes:
> >
> >  > On Fri, May 4, 2018 at 10:19 PM, Aaron Conole 
> wrote:
> >  >
> >  >  Leon Goldberg  writes:
> >  >
> >  >  > Hi list,
>

Re: [ovs-dev] Cannot open /dev/vfio/noiommu-0: Permission denied

2018-05-07 Thread Aaron Conole 
Leon Goldberg  writes:

> I stand correct, I was not using permissive mode. With permissive mode, 
> noiommu-0 issue seems to
> be resolved, however:

Cool.  I caught other issues turning on the -DB flag... although maybe
that was using enforcing mode as well.

> type=AVC msg=audit(1525707587.009:447): avc:  denied  { remove_name } for  
> pid=4497
> comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> scontext=system_u:system_r:svirt_t:s0:c794,c950 
> tcontext=unconfined_u:object_r:default_t:s0
> tclass=dir
> type=AVC msg=audit(1525707587.009:447): avc:  denied  { unlink } for  pid=4497
> comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> scontext=system_u:system_r:svirt_t:s0:c794,c950 
> tcontext=system_u:object_r:default_t:s0
> tclass=sock_file
> type=AVC msg=audit(1525707587.009:448): avc:  denied  { add_name } for  
> pid=4497
> comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c794,c950
> tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> type=AVC msg=audit(1525707587.009:448): avc:  denied  { create } for  pid=4497
> comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c794,c950
> tcontext=system_u:object_r:default_t:s0 tclass=sock_file
>
> Still occurs.
>
> OVS log shows:
>
> 2018-05-07T15:27:15.059Z|00072|dpdk|INFO|VHOST_CONFIG: vhost-user client: 
> socket created, fd:
> 55
> 2018-05-07T15:27:15.059Z|00073|netdev_dpdk|INFO|vHost User device 
> 'dpdkvhostclient1' created
> in 'client' mode, using client socket '/vhostusers/vhost-user-5'
> 2018-05-07T15:27:15.062Z|00074|dpdk|WARN|VHOST_CONFIG: failed to connect to
> /vhostusers/vhost-user-5: Permission denied

Does that directory exist?  What are the permissions?  What are the
permissions of the sock file that exist in that directory?

> On Mon, May 7, 2018 at 6:21 PM, Leon Goldberg  wrote:
>
>  Aha, indeed, I see:
>
>  type=AVC msg=audit(1525649015.102:1305): avc:  denied  { open } for  
> pid=12993
>  comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs" ino=708920
>  scontext=system_u:system_r:openvswitch_t:s0 
> tcontext=system_u:object_r:device_t:s0
>  tclass=chr_file
>  type=AVC msg=audit(1525649177.311:1326): avc:  denied  { open } for  
> pid=13241
>  comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs" ino=708920
>  scontext=system_u:system_r:openvswitch_t:s0 
> tcontext=system_u:object_r:device_t:s0
>  tclass=chr_file
>
>  and I'm using permissive mode.
>
>  I also see:
>
>  [root@lago-network-suite-master-host-0 ~]# cat /var/log/audit/audit.log | 
> grep vhost-user-5
>  type=AVC msg=audit(1525636067.061:757): avc:  denied  { create } for  
> pid=7533
>  comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c423,c510
>  tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
>  type=AVC msg=audit(1525648910.361:1276): avc:  denied  { add_name } for  
> pid=12734
>  comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c245,c301
>  tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
>  type=AVC msg=audit(1525648910.361:1276): avc:  denied  { create } for  
> pid=12734
>  comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c245,c301
>  tcontext=system_u:object_r:default_t:s0 tclass=sock_file
>  type=AVC msg=audit(1525648979.442:1290): avc:  denied  { remove_name } for  
> pid=12822
>  comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
>  scontext=system_u:system_r:svirt_t:s0:c515,c819 
> tcontext=unconfined_u:object_r:default_t:s0
>  tclass=dir
>  type=AVC msg=audit(1525648979.442:1290): avc:  denied  { unlink } for  
> pid=12822
>  comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
>  scontext=system_u:system_r:svirt_t:s0:c515,c819 
> tcontext=system_u:object_r:default_t:s0
>  tclass=sock_file
>  type=AVC msg=audit(1525648979.442:1291): avc:  denied  { add_name } for  
> pid=12822
>  comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c515,c819
>  tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
>  type=AVC msg=audit(1525648979.442:1291): avc:  denied  { create } for  
> pid=12822
>  comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c515,c819
>  tcontext=system_u:object_r:default_t:s0 tclass=sock_file
>
>  This is my vhostuser client.
>
>  On Mon, May 7, 2018 at 4:39 PM, Aaron Conole  wrote:
>
>  Leon Goldberg  writes:
>
>  > On Fri, May 4, 2018 at 10:19 PM, Aaron Conole  wrote:
>  >
>  >  Leon Goldberg  writes:
>  >
>  >  > Hi list,
>  >  >
>  >  > I'm trying to integrate ovs-dpdk into oVirt. For testing purposes, I'm
>  >  > writing a test that looks to run a VM on top of a dpdk port.
>  >  >
>  >  > The testing environment consists of nested virtualization:
>  >  >
>  >  > Physical machine -> Jenkins CI VM -> Target VM
>  >  >
>  >  > The test merely looks to see that the various

Re: [ovs-dev] Cannot open /dev/vfio/noiommu-0: Permission denied

2018-05-07 Thread Aaron Conole 
Leon Goldberg  writes:

> Aha, indeed, I see:
>
> type=AVC msg=audit(1525649015.102:1305): avc:  denied  { open } for  pid=12993
> comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs" ino=708920
> scontext=system_u:system_r:openvswitch_t:s0 
> tcontext=system_u:object_r:device_t:s0
> tclass=chr_file
> type=AVC msg=audit(1525649177.311:1326): avc:  denied  { open } for  pid=13241
> comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs" ino=708920
> scontext=system_u:system_r:openvswitch_t:s0 
> tcontext=system_u:object_r:device_t:s0
> tclass=chr_file
>
> and I'm using permissive mode.

There are some required permissions that also don't show up in the
audit-log.  If possible, can you install the selinux policy included in
the upstream repository and see if it resolves the issue?

> I also see:
>
> [root@lago-network-suite-master-host-0 ~]# cat /var/log/audit/audit.log | 
> grep vhost-user-5
> type=AVC msg=audit(1525636067.061:757): avc:  denied  { create } for  pid=7533
> comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c423,c510
> tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
> type=AVC msg=audit(1525648910.361:1276): avc:  denied  { add_name } for  
> pid=12734
> comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c245,c301
> tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> type=AVC msg=audit(1525648910.361:1276): avc:  denied  { create } for  
> pid=12734
> comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c245,c301
> tcontext=system_u:object_r:default_t:s0 tclass=sock_file
> type=AVC msg=audit(1525648979.442:1290): avc:  denied  { remove_name } for  
> pid=12822
> comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> scontext=system_u:system_r:svirt_t:s0:c515,c819 
> tcontext=unconfined_u:object_r:default_t:s0
> tclass=dir
> type=AVC msg=audit(1525648979.442:1290): avc:  denied  { unlink } for  
> pid=12822
> comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> scontext=system_u:system_r:svirt_t:s0:c515,c819 
> tcontext=system_u:object_r:default_t:s0
> tclass=sock_file
> type=AVC msg=audit(1525648979.442:1291): avc:  denied  { add_name } for  
> pid=12822
> comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c515,c819
> tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> type=AVC msg=audit(1525648979.442:1291): avc:  denied  { create } for  
> pid=12822
> comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c515,c819
> tcontext=system_u:object_r:default_t:s0 tclass=sock_file
>
> This is my vhostuser client.
>
> On Mon, May 7, 2018 at 4:39 PM, Aaron Conole  wrote:
>
>  Leon Goldberg  writes:
>
>  > On Fri, May 4, 2018 at 10:19 PM, Aaron Conole  wrote:
>  >
>  >  Leon Goldberg  writes:
>  >
>  >  > Hi list,
>  >  >
>  >  > I'm trying to integrate ovs-dpdk into oVirt. For testing purposes, I'm
>  >  > writing a test that looks to run a VM on top of a dpdk port.
>  >  >
>  >  > The testing environment consists of nested virtualization:
>  >  >
>  >  > Physical machine -> Jenkins CI VM -> Target VM
>  >  >
>  >  > The test merely looks to see that the various components are properly
>  >  > configured for the real world. For that purpose, I'm using NOIOMMU mode 
> of
>  >  > VFIO.
>  >  >
>  >  > The select virtio device fails to to be attached to dpdk, and I suspect 
> it
>  >  > is due to $subject.
>  >  >
>  >  > Here are the CI logs[1]. I see some other red lights, but $subject seems
>  >  > the brightest.
>  >
>  >  Can you provide:
>  >
>  >  $ ps aux | grep ovs-vswitchd
>  >  $ ls -lah /dev/vfio
>  >
>  > Hey Aaron,
>  >
>  > Here it is:
>  >
>  > [root@lago-network-suite-master-host-0 ~]# ps aux | grep ovs-vswitchd
>  > openvsw+   840  0.6  6.2 1273732 116716 ?  S ovs-vswitchd
>  > unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info 
> --mlockall --user
>  > openvswitch:hugetlbfs --no-chdir 
> --log-file=/var/log/openvswitch/ovs-vswitchd.log
>  > --pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach
>  > root  4425  0.0  0.0 112660   976 pts/0R+   07:55   0:00 grep 
> --color=auto ovs-vswitchd
>  >
>  > [root@lago-network-suite-master-host-0 ~]# ls -lah /dev/vfio
>  > total 0
>  > drwxr-xr-x.  2 root root80 May  6 07:28 .
>  > drwxr-xr-x. 19 root root  3.2K May  6 07:28 ..
>  > crw-rw.  1 root hugetlbfs 244,   0 May  6 07:28 noiommu-0
>  > crw-rw-rw-.  1 root root   10, 196 May  6 07:28 vfio 
>
>  Okay - that looks like it should be okay.
>
>  Can you check if there are any selinux violations in audit.log
>  (specifically from the openvswitch_t domain)?  Maybe there is a missing
>  selinux policy directive.
>
>  >  Just want to see if there's a disconnect between the userid for ovs
>  >  and the permissions on the vfio file.  If that's the case, we may need

[ovs-dev] [PATCH] OF1.5/EXT-334 OXS/Extensible Flow Entry Statistics Support

2018-05-07 Thread SatyaValli 
From: SatyaValli 

This Patch provides implementation Existing flow entry statistics are
redefined as standard OXS(OpenFlow Extensible Statistics) fields for
displaying the arbitrary flow stats.

To support this implementation below messages are newly added

OFPRAW_OFPT15_FLOW_REMOVED,
OFPRAW_OFPST15_FLOW_REQUEST,
OFPRAW_OFPST15_LW_FLOW_REQUEST,
OFPRAW_OFPST15_AGGREGATE_REQUEST,
OFPRAW_OFPST15_FLOW_REPLY,
OFPRAW_OFPST15_LW_FLOW_REPLY,
OFPRAW_OFPST15_AGGREGATE_REPLY,

The current commit adds support for the new feature in flow statistics
multipart messages,aggregate multipart messages and OXS support for flow
removal message, individual flow description messages.

"ovs-ofctl dump-flows" & "ovs-ofctl dump-aggregate" now accepts a new option
"--oxs-stats" provided with the arbitrary OXS fields for displaying the
desired flow stats.

Below are Commands to display OXS stats field wise

Flow Statistics Multipart
ovs-ofctl dump-flows -O OpenFlow15  --oxs-stats=idle_time
ovs-ofctl dump-flows -O OpenFlow15  --oxs-stats=packet_count
ovs-ofctl dump-flows -O OpenFlow15  --oxs-stats=byte_count
ovs-ofctl dump-flows -O OpenFlow15  --oxs-stats=duration

Flow Statistics Multipart
ovs-ofctl dump-flows -O OpenFlow15  --oxs-stats=idle_time
ovs-ofctl dump-flows -O OpenFlow15  --oxs-stats=packet_count
ovs-ofctl dump-flows -O OpenFlow15  --oxs-stats=byte_count
ovs-ofctl dump-flows -O OpenFlow15  --oxs-stats=duration

Aggregate Flow Statistics Multipart
ovs-ofctl dump-aggregate -O OpenFlow15  --oxs-stats=packet_count
ovs-ofctl dump-aggregate -O OpenFlow15  --oxs-stats=byte_count
ovs-ofctl dump-aggregate -O OpenFlow15  --oxs-stats=flow_count

Signed-off-by: Satya Valli 
Co-authored-by: Lavanya Harivelam 
Signed-off-by: Lavanya Harivelam 
Co-authored-by: Surya Muttamsetty 
Signed-off-by: Surya Muttamsetty 
Co-authored-by: Manasa Cherukupally 
Signed-off-by: Manasa Cherukupally 
Co-authored-by: Pavani Panthagada 
Signed-off-by: Pavani Panthagada 

---
 NEWS|6 +
 include/openflow/openflow-1.5.h |   59 +++
 include/openvswitch/ofp-msgs.h  |   31 +-
 include/openvswitch/ofp-print.h |7 +
 lib/automake.mk |2 +
 lib/ofp-bundle.c|2 +
 lib/ofp-flow.c  |  194 +++-
 lib/ofp-monitor.c   |   46 +-
 lib/ofp-print.c |   55 +++
 lib/ox-stat.c   | 1015 +++
 lib/ox-stat.h   |   54 +++
 lib/rconn.c |2 +
 lib/vconn.c |3 +-
 ofproto/ofproto.c   |2 +
 tests/ofp-print.at  |   80 +++
 tests/ofproto-dpif.at   |   85 
 tests/ofproto.at|1 +
 utilities/ovs-ofctl.8.in|   31 +-
 utilities/ovs-ofctl.c   |  127 -
 19 files changed, 1759 insertions(+), 43 deletions(-)
 create mode 100644 lib/ox-stat.c
 create mode 100644 lib/ox-stat.h

diff --git a/NEWS b/NEWS
index d22ad14..7132b0d 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,12 @@ Post-v2.9.0
  * Add minimum network namespace support for Linux.
  * New command "lacp/show-stats"
- ovs-ofctl:
+ * Existing flow entry statistics are redefined as standard OXS(OpenFlow
+   Extensible Statistics) fields for displaying the arbitrary flow stats.
+ * Now "ovs-ofctl dump-flows" and "ovs-ofctl dump-aggregate" accepts a new
+   option --oxs-stats provided with the arbitrary OXS fields i.e
+   flow duration, flow count, packet count, byte count for displaying
+   the desired flow stats. See ovs-ofctl(8) for details.
  * ovs-ofctl now accepts and display table names in place of numbers.  By
default it always accepts names and in interactive use it displays them;
use --names or --no-names to override.  See ovs-ofctl(8) for details.
diff --git a/include/openflow/openflow-1.5.h b/include/openflow/openflow-1.5.h
index 73b76d8..6a5e369 100644
--- a/include/openflow/openflow-1.5.h
+++ b/include/openflow/openflow-1.5.h
@@ -163,4 +163,63 @@ struct ofp15_packet_out {
 };
 OFP_ASSERT(sizeof(struct ofp15_packet_out) == 8);
 
+struct ofp_oxs_stat {
+ovs_be16 reserved;  /* Reserved for future use,
+ * currently zeroed. */
+ovs_be16 length;/* Stats Length */
+};
+
+OFP_ASSERT(sizeof(struct ofp_oxs_stat) == 4);
+
+/* Body of reply to OFPMP_FLOW_DESC request. */
+struct ofp15_flow_desc {
+ovs_be16 length;  /* Length of this entry. */
+uint8_t pad2[2];  /* Align to 64 bits. */
+uint8_t table_id; /* ID of table flow came from. */
+uint8_t pad;
+ovs_be16 priority;/* Priority of the entry. */
+ovs_be16 idle_timeout;

Re: [ovs-dev] [PATCH] Factor prerequisites out of AND/OR trees with unique symbol

2018-05-07 Thread Mark Michelson 

Hi Jakub,

I finally got around to taking a look at this. I made up some imaginary 
expressions to try to see if I could find a way that this would break, 
but it looks good to me in each case.


Acked-by: Mark Michelson 

On 04/26/2018 03:54 PM, Jakub Sitnicki wrote:

Appending prerequisites to sub-expressions of OR that are all over one
symbol prevents the expression-to-matches converter from applying
conjunctive matching. This happens during the annotation phase.

input:  s1 == { c1, c2 } && s2 == { c3, c4 }
expanded:   (s1 == c1 || s1 == c2) && (s2 == c3 || s2 == c4)
annotated:  ((p1 && s1 == c1) || (p1 && s1 == c2)) &&
 ((p2 && s2 == c3) || (p2 && s2 == c4))
normalized: (p1 && p2 && s1 == c1 && s2 == c3) ||
 (p1 && p2 && s1 == c1 && s2 == c4) ||
(p1 && p2 && s1 == c2 && s2 == c3) ||
(p1 && p2 && s1 == c2 && s2 == c4)

Where s1,s2 - symbols, c1..c4 - constants, p1,p2 - prerequisites.

Since sub-expressions of OR trees that are over one symbol all have the
same prerequisites, we can factor them out leaving the OR tree in tact,
and enabling the converter to apply conjunctive matching to
AND(OR(clause)) trees.

Going back to our example this change gives us:

input:  s1 == { c1, c2 } && s2 == { c3, c4 }
expanded:   (s1 == c1 || s1 == c2) && (s2 == c3 || s2 == c4)
annotated:  (s1 == c1 || s1 == c2) && p1 && (s2 == c3 || s2 == c4) && p2
normalized: p1 && p2 && (s1 == c1 || s1 == c2) && (s2 == c3 || s2 == c4)

We also factor out the prerequisites out of pure AND or mixed AND/OR
trees to keep the common code path, but in this case we don't gain
anything.

Signed-off-by: Jakub Sitnicki 
---

This is an alternative to "Enhance conjunctive match support in OVN" patch from
Numan Siddique [1].

[1] https://patchwork.ozlabs.org/patch/874433/

  ovn/lib/expr.c | 55 +--
  tests/ovn.at   |  4 ++--
  2 files changed, 47 insertions(+), 12 deletions(-)

diff --git a/ovn/lib/expr.c b/ovn/lib/expr.c
index 5840ef871..9dd8d6f17 100644
--- a/ovn/lib/expr.c
+++ b/ovn/lib/expr.c
@@ -32,6 +32,13 @@

  VLOG_DEFINE_THIS_MODULE(expr);

+static const struct expr_symbol *
+expr_get_unique_symbol(const struct expr *expr);
+
+struct expr *
+expr_annotate__(struct expr *expr, const struct shash *symtab,
+bool append_prereqs, struct ovs_list *nesting, char **errorp);
+
  static struct expr *parse_and_annotate(const char *s,
 const struct shash *symtab,
 struct ovs_list *nesting,
@@ -1658,9 +1665,6 @@ struct annotation_nesting {
  const struct expr_symbol *symbol;
  };

-struct expr *expr_annotate__(struct expr *, const struct shash *symtab,
- struct ovs_list *nesting, char **errorp);
-
  static struct expr *
  parse_and_annotate(const char *s, const struct shash *symtab,
 struct ovs_list *nesting, char **errorp)
@@ -1670,7 +1674,7 @@ parse_and_annotate(const char *s, const struct shash 
*symtab,

  expr = expr_parse_string(s, symtab, NULL, NULL, );
  if (expr) {
-expr = expr_annotate__(expr, symtab, nesting, );
+expr = expr_annotate__(expr, symtab, true, nesting, );
  }
  if (expr) {
  *errorp = NULL;
@@ -1685,7 +1689,7 @@ parse_and_annotate(const char *s, const struct shash 
*symtab,

  static struct expr *
  expr_annotate_cmp(struct expr *expr, const struct shash *symtab,
-  struct ovs_list *nesting, char **errorp)
+  bool append_prereqs, struct ovs_list *nesting, char **errorp)
  {
  const struct expr_symbol *symbol = expr->cmp.symbol;
  const struct annotation_nesting *iter;
@@ -1703,7 +1707,7 @@ expr_annotate_cmp(struct expr *expr, const struct shash 
*symtab,
  ovs_list_push_back(nesting, );

  struct expr *prereqs = NULL;
-if (symbol->prereqs) {
+if (append_prereqs && symbol->prereqs) {
  prereqs = parse_and_annotate(symbol->prereqs, symtab, nesting, 
errorp);
  if (!prereqs) {
  goto error;
@@ -1744,21 +1748,46 @@ expr_annotate_cmp(struct expr *expr, const struct shash 
*symtab,
  return NULL;
  }

+/* Append (logical AND) prereqs for given symbol to the expression. */
+static struct expr *
+expr_append_prereqs(struct expr *expr, const struct expr_symbol *symbol,
+const struct shash *symtab, struct ovs_list *nesting,
+char **errorp)
+{
+struct expr *prereqs = NULL;
+
+if (symbol->prereqs) {
+prereqs = parse_and_annotate(symbol->prereqs, symtab, nesting, errorp);
+if (!prereqs) {
+goto error;
+}
+}
+
+return prereqs ? expr_combine(EXPR_T_AND, expr, prereqs) : expr;
+
+error:
+expr_destroy(expr);
+expr_destroy(prereqs);
+return NULL;
+}
+
  struct expr *
  expr_annotate__(struct expr *expr, const struct shash

[ovs-dev] Gerentes y Supervisores

2018-05-07 Thread Administración Efectica del tiempo 
 
Administración Efectica del tiempo para 
GERENTES o SUPERVISORES.
 Fecha: 17/Mayo/2018
 

Horario: 10:00 a 13:00 y 15:00 a 18:00 horas
 


"Elimine para siempre la frase “No nos alcanza el tiempo” "



En este seminario online en vivo aprenderá:

Aprenda a planificar y organizar.
10 Soluciones para el control.
Tiempos y movimientos. 

Medición de la efectividad. 


Cómo controlar verdaderamente la jornada laboral.
 
Responda este correo con el asunto Gerentes, con los siguientes datos:

Nombre: 
Correo: 
Teléfono: 

 
Si lo que usted desea dejar de recibir este tipo de mensajes responder este 
correo con el asunto BAJA
 



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Cannot open /dev/vfio/noiommu-0: Permission denied

2018-05-07 Thread Leon Goldberg 
I stand correct, I was not using permissive mode. With permissive mode,
noiommu-0 issue seems to be resolved, however:

type=AVC msg=audit(1525707587.009:447): avc:  denied  { remove_name } for
pid=4497 comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
scontext=system_u:system_r:svirt_t:s0:c794,c950
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
type=AVC msg=audit(1525707587.009:447): avc:  denied  { unlink } for
pid=4497 comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
scontext=system_u:system_r:svirt_t:s0:c794,c950
tcontext=system_u:object_r:default_t:s0 tclass=sock_file
type=AVC msg=audit(1525707587.009:448): avc:  denied  { add_name } for
pid=4497 comm="qemu-kvm" name="vhost-user-5"
scontext=system_u:system_r:svirt_t:s0:c794,c950
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
type=AVC msg=audit(1525707587.009:448): avc:  denied  { create } for
pid=4497 comm="qemu-kvm" name="vhost-user-5"
scontext=system_u:system_r:svirt_t:s0:c794,c950
tcontext=system_u:object_r:default_t:s0 tclass=sock_file

Still occurs.

OVS log shows:

2018-05-07T15:27:15.059Z|00072|dpdk|INFO|VHOST_CONFIG: vhost-user client:
socket created, fd: 55
2018-05-07T15:27:15.059Z|00073|netdev_dpdk|INFO|vHost User device
'dpdkvhostclient1' created in 'client' mode, using client socket
'/vhostusers/vhost-user-5'
2018-05-07T15:27:15.062Z|00074|dpdk|WARN|VHOST_CONFIG: failed to connect to
/vhostusers/vhost-user-5: Permission denied


On Mon, May 7, 2018 at 6:21 PM, Leon Goldberg  wrote:

> Aha, indeed, I see:
>
> type=AVC msg=audit(1525649015.102:1305): avc:  denied  { open } for
> pid=12993 comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs"
> ino=708920 scontext=system_u:system_r:openvswitch_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=chr_file
> type=AVC msg=audit(1525649177.311:1326): avc:  denied  { open } for
> pid=13241 comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs"
> ino=708920 scontext=system_u:system_r:openvswitch_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=chr_file
>
> and I'm using permissive mode.
>
> I also see:
>
> [root@lago-network-suite-master-host-0 ~]# cat /var/log/audit/audit.log |
> grep vhost-user-5
> type=AVC msg=audit(1525636067.061:757): avc:  denied  { create } for
> pid=7533 comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c423,c510
> tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
> type=AVC msg=audit(1525648910.361:1276): avc:  denied  { add_name } for
> pid=12734 comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c245,c301
> tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> type=AVC msg=audit(1525648910.361:1276): avc:  denied  { create } for
> pid=12734 comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c245,c301
> tcontext=system_u:object_r:default_t:s0 tclass=sock_file
> type=AVC msg=audit(1525648979.442:1290): avc:  denied  { remove_name }
> for  pid=12822 comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> scontext=system_u:system_r:svirt_t:s0:c515,c819
> tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> type=AVC msg=audit(1525648979.442:1290): avc:  denied  { unlink } for
> pid=12822 comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
> scontext=system_u:system_r:svirt_t:s0:c515,c819
> tcontext=system_u:object_r:default_t:s0 tclass=sock_file
> type=AVC msg=audit(1525648979.442:1291): avc:  denied  { add_name } for
> pid=12822 comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c515,c819
> tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
> type=AVC msg=audit(1525648979.442:1291): avc:  denied  { create } for
> pid=12822 comm="qemu-kvm" name="vhost-user-5" 
> scontext=system_u:system_r:svirt_t:s0:c515,c819
> tcontext=system_u:object_r:default_t:s0 tclass=sock_file
>
> This is my vhostuser client.
>
>
>
> On Mon, May 7, 2018 at 4:39 PM, Aaron Conole  wrote:
>
>> Leon Goldberg  writes:
>>
>> > On Fri, May 4, 2018 at 10:19 PM, Aaron Conole 
>> wrote:
>> >
>> >  Leon Goldberg  writes:
>> >
>> >  > Hi list,
>> >  >
>> >  > I'm trying to integrate ovs-dpdk into oVirt. For testing purposes,
>> I'm
>> >  > writing a test that looks to run a VM on top of a dpdk port.
>> >  >
>> >  > The testing environment consists of nested virtualization:
>> >  >
>> >  > Physical machine -> Jenkins CI VM -> Target VM
>> >  >
>> >  > The test merely looks to see that the various components are properly
>> >  > configured for the real world. For that purpose, I'm using NOIOMMU
>> mode of
>> >  > VFIO.
>> >  >
>> >  > The select virtio device fails to to be attached to dpdk, and I
>> suspect it
>> >  > is due to $subject.
>> >  >
>> >  > Here are the CI logs[1]. I see some other red lights, but $subject
>> seems
>> >  > the brightest.
>> >
>> >  Can you provide:
>> >
>> >  $ ps aux | grep ovs-vswitchd
>> >  $ ls

Re: [ovs-dev] Cannot open /dev/vfio/noiommu-0: Permission denied

2018-05-07 Thread Leon Goldberg 
Aha, indeed, I see:

type=AVC msg=audit(1525649015.102:1305): avc:  denied  { open } for
pid=12993 comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs"
ino=708920 scontext=system_u:system_r:openvswitch_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
type=AVC msg=audit(1525649177.311:1326): avc:  denied  { open } for
pid=13241 comm="ovs-vswitchd" path="/dev/vfio/noiommu-0" dev="devtmpfs"
ino=708920 scontext=system_u:system_r:openvswitch_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file

and I'm using permissive mode.

I also see:

[root@lago-network-suite-master-host-0 ~]# cat /var/log/audit/audit.log |
grep vhost-user-5
type=AVC msg=audit(1525636067.061:757): avc:  denied  { create } for
pid=7533 comm="qemu-kvm" name="vhost-user-5"
scontext=system_u:system_r:svirt_t:s0:c423,c510
tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file
type=AVC msg=audit(1525648910.361:1276): avc:  denied  { add_name } for
pid=12734 comm="qemu-kvm" name="vhost-user-5"
scontext=system_u:system_r:svirt_t:s0:c245,c301
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
type=AVC msg=audit(1525648910.361:1276): avc:  denied  { create } for
pid=12734 comm="qemu-kvm" name="vhost-user-5"
scontext=system_u:system_r:svirt_t:s0:c245,c301
tcontext=system_u:object_r:default_t:s0 tclass=sock_file
type=AVC msg=audit(1525648979.442:1290): avc:  denied  { remove_name } for
pid=12822 comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
scontext=system_u:system_r:svirt_t:s0:c515,c819
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
type=AVC msg=audit(1525648979.442:1290): avc:  denied  { unlink } for
pid=12822 comm="qemu-kvm" name="vhost-user-5" dev="vda3" ino=8742121
scontext=system_u:system_r:svirt_t:s0:c515,c819
tcontext=system_u:object_r:default_t:s0 tclass=sock_file
type=AVC msg=audit(1525648979.442:1291): avc:  denied  { add_name } for
pid=12822 comm="qemu-kvm" name="vhost-user-5"
scontext=system_u:system_r:svirt_t:s0:c515,c819
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
type=AVC msg=audit(1525648979.442:1291): avc:  denied  { create } for
pid=12822 comm="qemu-kvm" name="vhost-user-5"
scontext=system_u:system_r:svirt_t:s0:c515,c819
tcontext=system_u:object_r:default_t:s0 tclass=sock_file

This is my vhostuser client.



On Mon, May 7, 2018 at 4:39 PM, Aaron Conole  wrote:

> Leon Goldberg  writes:
>
> > On Fri, May 4, 2018 at 10:19 PM, Aaron Conole 
> wrote:
> >
> >  Leon Goldberg  writes:
> >
> >  > Hi list,
> >  >
> >  > I'm trying to integrate ovs-dpdk into oVirt. For testing purposes, I'm
> >  > writing a test that looks to run a VM on top of a dpdk port.
> >  >
> >  > The testing environment consists of nested virtualization:
> >  >
> >  > Physical machine -> Jenkins CI VM -> Target VM
> >  >
> >  > The test merely looks to see that the various components are properly
> >  > configured for the real world. For that purpose, I'm using NOIOMMU
> mode of
> >  > VFIO.
> >  >
> >  > The select virtio device fails to to be attached to dpdk, and I
> suspect it
> >  > is due to $subject.
> >  >
> >  > Here are the CI logs[1]. I see some other red lights, but $subject
> seems
> >  > the brightest.
> >
> >  Can you provide:
> >
> >  $ ps aux | grep ovs-vswitchd
> >  $ ls -lah /dev/vfio
> >
> > Hey Aaron,
> >
> > Here it is:
> >
> > [root@lago-network-suite-master-host-0 ~]# ps aux | grep ovs-vswitchd
> > openvsw+   840  0.6  6.2 1273732 116716 ?  S ovs-vswitchd
> > unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err
> -vfile:info --mlockall --user
> > openvswitch:hugetlbfs --no-chdir --log-file=/var/log/
> openvswitch/ovs-vswitchd.log
> > --pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach
> > root  4425  0.0  0.0 112660   976 pts/0R+   07:55   0:00 grep
> --color=auto ovs-vswitchd
> >
> > [root@lago-network-suite-master-host-0 ~]# ls -lah /dev/vfio
> > total 0
> > drwxr-xr-x.  2 root root80 May  6 07:28 .
> > drwxr-xr-x. 19 root root  3.2K May  6 07:28 ..
> > crw-rw.  1 root hugetlbfs 244,   0 May  6 07:28 noiommu-0
> > crw-rw-rw-.  1 root root   10, 196 May  6 07:28 vfio
>
> Okay - that looks like it should be okay.
>
> Can you check if there are any selinux violations in audit.log
> (specifically from the openvswitch_t domain)?  Maybe there is a missing
> selinux policy directive.
>
> >  Just want to see if there's a disconnect between the userid for ovs
> >  and the permissions on the vfio file.  If that's the case, we may need
> >  to update the vfio rules.
> >
> >  > Any tips will be greatly appreciated!
> >  >
> >  > Thanks,
> >  > Leon
> >  >
> >  > [1]
> >  >
> >  http://jenkins.ovirt.org/job/ovirt-system-tests_standard-
> check-patch/642/artifact/exported-artifacts/check-
> patch.network_suite_master.el7.x86_64/tests.test_dpdk/
> lago-network-suite-master-host-0/_var_log/openvswitch/ovs-vswitchd.log
> >
> >  >
> >

Re: [ovs-dev] Cannot open /dev/vfio/noiommu-0: Permission denied

2018-05-07 Thread Aaron Conole 
Leon Goldberg  writes:

> On Fri, May 4, 2018 at 10:19 PM, Aaron Conole  wrote:
>
>  Leon Goldberg  writes:
>
>  > Hi list,
>  >
>  > I'm trying to integrate ovs-dpdk into oVirt. For testing purposes, I'm
>  > writing a test that looks to run a VM on top of a dpdk port.
>  >
>  > The testing environment consists of nested virtualization:
>  >
>  > Physical machine -> Jenkins CI VM -> Target VM
>  >
>  > The test merely looks to see that the various components are properly
>  > configured for the real world. For that purpose, I'm using NOIOMMU mode of
>  > VFIO.
>  >
>  > The select virtio device fails to to be attached to dpdk, and I suspect it
>  > is due to $subject.
>  >
>  > Here are the CI logs[1]. I see some other red lights, but $subject seems
>  > the brightest.
>
>  Can you provide:
>
>  $ ps aux | grep ovs-vswitchd
>  $ ls -lah /dev/vfio
>
> Hey Aaron,
>
> Here it is:
>
> [root@lago-network-suite-master-host-0 ~]# ps aux | grep ovs-vswitchd
> openvsw+   840  0.6  6.2 1273732 116716 ?  S unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info 
> --mlockall --user
> openvswitch:hugetlbfs --no-chdir 
> --log-file=/var/log/openvswitch/ovs-vswitchd.log
> --pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach
> root  4425  0.0  0.0 112660   976 pts/0R+   07:55   0:00 grep 
> --color=auto ovs-vswitchd
>
> [root@lago-network-suite-master-host-0 ~]# ls -lah /dev/vfio
> total 0
> drwxr-xr-x.  2 root root80 May  6 07:28 .
> drwxr-xr-x. 19 root root  3.2K May  6 07:28 ..
> crw-rw.  1 root hugetlbfs 244,   0 May  6 07:28 noiommu-0
> crw-rw-rw-.  1 root root   10, 196 May  6 07:28 vfio 

Okay - that looks like it should be okay.

Can you check if there are any selinux violations in audit.log
(specifically from the openvswitch_t domain)?  Maybe there is a missing
selinux policy directive.

>  Just want to see if there's a disconnect between the userid for ovs
>  and the permissions on the vfio file.  If that's the case, we may need
>  to update the vfio rules.
>
>  > Any tips will be greatly appreciated!
>  >
>  > Thanks,
>  > Leon
>  >
>  > [1]
>  >
>  
> http://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/642/artifact/exported-artifacts/check-patch.network_suite_master.el7.x86_64/tests.test_dpdk/lago-network-suite-master-host-0/_var_log/openvswitch/ovs-vswitchd.log
>  
>  >
>  
> 
>  
>  > ___
>  > dev mailing list
>  > d...@openvswitch.org
>  > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v1] Fix crash due to multiple tnl push action

2018-05-07 Thread Anju Thomas 
During slow path packet processing, if the action is to output to a
tunnel port, the slow path processing of the encapsulated packet
continues on the underlay bridge and additional actions (e.g. optional
VLAN encapsulation, bond link selection and finally output to port) are
collected there.

To prepare for a continuation of the processing of the original packet
(e.g. output to other tunnel ports in a flooding scenario), the
“tunnel_push” action and the actions of the underlay bridge are
encapsulated in a clone() action to preserve the original packet.

If the underlay bridge decides to drop the tunnel packet (for example if
both bonded ports are down simultaneously), the clone(tunnel_push))
actions previously generated as part of translation of the output to
tunnel port are discarded and a stand-alone tunnel_push action is added
instead. Thus the tunnel header is pushed on to the original packet.
This is the bug.

Consequences: If packet processing continues with sending to further
tunnel ports, multiple tunnel header pushes will happen on the original
packet as typically the tunnels all traverse the same underlay bond
which is down. The packet may not have enough headroom to accommodate
all the tunnel headers. OVS crashes if it runs out of space while trying
to push the tunnel headers.

Even in case there is enough headroom, the packet will not be freed
since the accumulated action list contains only the tunnel header push
action without any output port action. Thus, we either have a crash or a
packet buffer leak.

Signed-off-by: Anju Thomas 
---
 ofproto/ofproto-dpif-xlate.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 5641724..5706675 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3521,13 +3521,6 @@ native_tunnel_output(struct xlate_ctx *ctx, const struct 
xport *xport,
 nl_msg_end_non_empty_nested(ctx->odp_actions, clone_ofs);
 } else {
 nl_msg_cancel_nested(ctx->odp_actions, clone_ofs);
-/* XXX : There is no real use-case for a tunnel push without
- * any post actions. However keeping it now
- * as is to make the 'make check' happy. Should remove when all the
- * make check tunnel test case does something meaningful on a
- * tunnel encap packets.
- */
-odp_put_tnl_push_action(ctx->odp_actions, _push_data);
 }
 
 /* Restore context status. */
-- 
1.9.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3] Upcall/Slowpath rate limiter for OVS

2018-05-07 Thread Manohar Krishnappa Chidambaraswamy 
Hi

Rebased to master and adapted to the new dpif-netdev-perf counters.
As explained in v2 thread, OFPM_SLOWPATH meters cannot be used as is
for rate-limiting upcalls, hence reverted back to the simpler method
using token bucket.

Could you please review this patch?

Thanx
Manu

v2: https://patchwork.ozlabs.org/patch/860687/
v1: https://patchwork.ozlabs.org/patch/836737/

Signed-off-by: Manohar K C

CC: Jan Scheurich 
---
 Documentation/howto/dpdk.rst | 21 +++
 lib/dpif-netdev-perf.h   |  1 +
 lib/dpif-netdev.c| 83 
 vswitchd/vswitch.xml | 47 +
 4 files changed, 146 insertions(+), 6 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index 79b626c..bd1eaac 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -739,3 +739,24 @@ devices to bridge ``br0``. Once complete, follow the below 
steps:
Check traffic on multiple queues::
 
$ cat /proc/interrupts | grep virtio
+
+Upcall rate limiting
+
+ovs-vsctl can be used to enable and configure upcall rate limit parameters.
+There are 2 configurable values ``upcall-rate`` and ``upcall-burst`` which
+take effect when global enable knob ``upcall-rl`` is set to true.
+
+Upcall rate should be set using ``upcall-rate`` in packets-per-sec. For
+example::
+
+$ ovs-vsctl set Open_vSwitch . other_config:upcall-rate=2000
+
+Upcall burst should be set using ``upcall-burst`` in packets-per-sec. For
+example::
+
+$ ovs-vsctl set Open_vSwitch . other_config:upcall-burst=2000
+
+Upcall ratelimit feature should be globally enabled using ``upcall-rl``. For
+example::
+
+$ ovs-vsctl set Open_vSwitch . other_config:upcall-rl=true
diff --git a/lib/dpif-netdev-perf.h b/lib/dpif-netdev-perf.h
index 5993c25..189213c 100644
--- a/lib/dpif-netdev-perf.h
+++ b/lib/dpif-netdev-perf.h
@@ -64,6 +64,7 @@ enum pmd_stat_type {
  * recirculation. */
 PMD_STAT_SENT_PKTS, /* Packets that have been sent. */
 PMD_STAT_SENT_BATCHES,  /* Number of batches sent. */
+PMD_STAT_RATELIMIT_DROP,/* Packets dropped due to upcall policer. */
 PMD_CYCLES_ITER_IDLE,   /* Cycles spent in idle iterations. */
 PMD_CYCLES_ITER_BUSY,   /* Cycles spent in busy iterations. */
 PMD_N_STATS
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index be31fd0..eebab89 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -101,6 +101,16 @@ static struct shash dp_netdevs 
OVS_GUARDED_BY(dp_netdev_mutex)
 
 static struct vlog_rate_limit upcall_rl = VLOG_RATE_LIMIT_INIT(600, 600);
 
+/* Upcall rate-limit parameters */
+static bool upcall_ratelimit;
+static unsigned int upcall_rate;
+static unsigned int upcall_burst;
+
+/* These default values may be tuned based on upcall performance */
+#define UPCALL_RATELIMIT_DEFAULT false /* Disabled by default */
+#define UPCALL_RATE_DEFAULT  1000  /* pps */
+#define UPCALL_BURST_DEFAULT 1000  /* pps */
+
 #define DP_NETDEV_CS_SUPPORTED_MASK (CS_NEW | CS_ESTABLISHED | CS_RELATED \
  | CS_INVALID | CS_REPLY_DIR | CS_TRACKED \
  | CS_SRC_NAT | CS_DST_NAT)
@@ -615,6 +625,9 @@ struct dp_netdev_pmd_thread {
 /* Keep track of detailed PMD performance statistics. */
 struct pmd_perf_stats perf_stats;
 
+/* Policer to rate limit slow-path */
+struct token_bucket upcall_tb;
+
 /* Set to true if the pmd thread needs to be reloaded. */
 bool need_reload;
 };
@@ -856,12 +869,13 @@ pmd_info_show_stats(struct ds *reply,
   "\tavg. subtable lookups per megaflow hit: %.02f\n"
   "\tmiss with success upcall: %"PRIu64"\n"
   "\tmiss with failed upcall: %"PRIu64"\n"
+  "\tmiss with ratelimit dropped upcall: %"PRIu64"\n"
   "\tavg. packets per output batch: %.02f\n",
   total_packets, stats[PMD_STAT_RECIRC],
   passes_per_pkt, stats[PMD_STAT_EXACT_HIT],
   stats[PMD_STAT_MASKED_HIT], lookups_per_hit,
   stats[PMD_STAT_MISS], stats[PMD_STAT_LOST],
-  packets_per_batch);
+  stats[PMD_STAT_RATELIMIT_DROP], packets_per_batch);
 
 if (total_cycles == 0) {
 return;
@@ -2987,6 +3001,8 @@ dpif_netdev_set_config(struct dpif *dpif, const struct 
smap *other_config)
 DEFAULT_EM_FLOW_INSERT_INV_PROB);
 uint32_t insert_min, cur_min;
 uint32_t tx_flush_interval, cur_tx_flush_interval;
+unsigned int rate, burst;
+bool ratelimit;
 
 tx_flush_interval = smap_get_int(other_config, "tx-flush-interval",
  DEFAULT_TX_FLUSH_INTERVAL);
@@ -3021,6 +3037,32 @@ dpif_netdev_set_config(struct dpif *dpif, const struct 
smap *other_config)

[ovs-dev] [PATCH v1] Fix crash when processing malformed Bundle Add message in OVS

2018-05-07 Thread Anju Thomas 
When an OpenFlow Bundle Add message is received, a bundle entry is
created and the OpenFlow message embedded in the bundle add message is
processed.  If any error is encountered while processing the embedded
message, the bundle entry is freed. The bundle entry free function
assumes that the entry has been populated with a properly formatted
OpenFlow message and performs some message specific cleanup actions .
This assumption does not hold true in the error case and OVS crashes
when performing the cleanup.

The fix is in case of errors, simply free the bundle entry without
attempting to perform any embedded message cleanup

Signed-off-by: Anju Thomas 
---
 ofproto/bundles.c |  2 +-
 ofproto/bundles.h | 18 ++
 ofproto/ofproto.c | 19 ---
 3 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/ofproto/bundles.c b/ofproto/bundles.c
index 405ec8c..628ba0a 100644
--- a/ofproto/bundles.c
+++ b/ofproto/bundles.c
@@ -63,7 +63,7 @@ ofp_bundle_remove__(struct ofconn *ofconn, struct ofp_bundle 
*bundle)
 struct ofp_bundle_entry *msg;
 
 LIST_FOR_EACH_POP (msg, node, >msg_list) {
-ofp_bundle_entry_free(msg);
+ofp_bundle_entry_free(msg, true);
 }
 
 ofconn_remove_bundle(ofconn, bundle);
diff --git a/ofproto/bundles.h b/ofproto/bundles.h
index 806e853..7fc731c 100644
--- a/ofproto/bundles.h
+++ b/ofproto/bundles.h
@@ -60,7 +60,7 @@ struct ofp_bundle {
 
 static inline struct ofp_bundle_entry *ofp_bundle_entry_alloc(
 enum ofptype type, const struct ofp_header *oh);
-static inline void ofp_bundle_entry_free(struct ofp_bundle_entry *);
+static inline void ofp_bundle_entry_free(struct ofp_bundle_entry *, bool);
 
 enum ofperr ofp_bundle_open(struct ofconn *, uint32_t id, uint16_t flags,
 const struct ofp_header *);
@@ -84,15 +84,17 @@ ofp_bundle_entry_alloc(enum ofptype type, const struct 
ofp_header *oh)
 }
 
 static inline void
-ofp_bundle_entry_free(struct ofp_bundle_entry *entry)
+ofp_bundle_entry_free(struct ofp_bundle_entry *entry, bool cleanup)
 {
 if (entry) {
-if (entry->type == OFPTYPE_FLOW_MOD) {
-ofproto_flow_mod_uninit(>ofm);
-} else if (entry->type == OFPTYPE_GROUP_MOD) {
-ofputil_uninit_group_mod(>ogm.gm);
-} else if (entry->type == OFPTYPE_PACKET_OUT) {
-ofproto_packet_out_uninit(>opo);
+if (cleanup) {
+if (entry->type == OFPTYPE_FLOW_MOD) {
+ofproto_flow_mod_uninit(>ofm);
+} else if (entry->type == OFPTYPE_GROUP_MOD) {
+ofputil_uninit_group_mod(>ogm.gm);
+} else if (entry->type == OFPTYPE_PACKET_OUT) {
+ofproto_packet_out_uninit(>opo);
+}
 }
 free(entry->msg);
 free(entry);
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 36f4c0b..bfbc043 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -7901,6 +7901,7 @@ handle_bundle_add(struct ofconn *ofconn, const struct 
ofp_header *oh)
 struct ofputil_bundle_add_msg badd;
 struct ofp_bundle_entry *bmsg;
 enum ofptype type;
+bool cleanup=true;
 
 error = reject_slave_controller(ofconn);
 if (error) {
@@ -7929,7 +7930,13 @@ handle_bundle_add(struct ofconn *ofconn, const struct 
ofp_header *oh)
 >vl_mff_map, ,
 u16_to_ofp(ofproto->max_ports),
 ofproto->n_tables);
-if (!error) {
+if (error) {
+VLOG_WARN("Unable to parse OFPTYPE_FLOW_MOD message in "
+   "OFPTYPE_BUNDLE_ADD_MESSAGE(bundle idx = %x)"
+   "successfully",
+ badd.bundle_id);
+cleanup=false;
+} else {
 error = ofproto_flow_mod_init(ofproto, >ofm, , NULL);
 minimatch_destroy();
 }
@@ -7944,7 +7951,13 @@ handle_bundle_add(struct ofconn *ofconn, const struct 
ofp_header *oh)
 error = ofputil_decode_packet_out(, badd.msg,
   ofproto_get_tun_tab(ofproto),
   );
-if (!error) {
+if (error) {
+   VLOG_WARN("Unable to parse OFPTYPE_PACKET_OUT message in "
+"OFPTYPE_BUNDLE_ADD_MESSAGE(bundle idx = %x)"
+"successfully",
+ badd.bundle_id);
+   cleanup=false;
+} else {
 po.ofpacts = ofpbuf_steal_data();   /* Move to heap. */
 error = ofproto_packet_out_init(ofproto, ofconn, >opo, );
 }
@@ -7960,7 +7973,7 @@ handle_bundle_add(struct ofconn *ofconn, const struct 
ofp_header *oh)
 }
 
 if (error) {
-ofp_bundle_entry_free(bmsg);
+ofp_bundle_entry_free(bmsg, cleanup);
 }
 
 return error;
-- 
1.9.1

___
dev