Re: [ovs-dev] datapath: kmalloc() -> kmalloc_array()

I think this is a false positive due to the upstream commit format we use. - Greg On 12/5/2018 11:18 AM, 0-day Robot wrote: Bleep bloop. Greetings Greg Rose, 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

Re: [ovs-dev] [PATCH 2/2] dpctl: Expand the flow dump type filter

On 21/11/2018 10:22, Simon Horman wrote: > > On Tue, 20 Nov 2018 at 14:09, Roi Dayan > wrote: > > > > On 13/09/2018 17:58, Simon Horman wrote: > > Thanks for the clarification below, I have applied this series to > master. > > > > > Hi Simon, >

Re: [ovs-dev] [PATCH net-next 0/8] Pass extack to NETDEV_PRE_UP

Your CC list is so huge that vger.kernel.org dropped all of your postings. That CC list is not reasonable at all, trim it down to the most minimum set. Probably 2 or 3 mailing lists, primarily netdev, and maybe a small handful of specific developers. Nothing more.

Re: [ovs-dev] OVN multicast enhancements

On 11/16/18 6:11 AM, Ankur Sharma wrote: Hi Mark, Thanks for the write up. Initial proposal looks to be a good starting point. Please find my feedback inline. Regards, Ankur Sorry for the late response Ankur, but for some reason your response got completely lost and I did not see it until

Re: [ovs-dev] datapath: kmalloc() -> kmalloc_array()

Bleep bloop. Greetings Greg Rose, 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: Author Kees Cook needs to sign off. WARNING: Unexpected sign-offs from developers who are

[ovs-dev] [PATCH v5] pinctrl: Check requested IP in DHCPREQUEST messages

See RFC 2131, section 4.3.2. When handling a DHCPREQUEST message, the server should validate that the client's requested IP matches the offered IP. If not, the server should reply with a DHCPNAK. The client's requested IP is either specified as the Requested IP Address (option 50), or as the

[ovs-dev] [PATCH 8/8] datapath: fix spelling mistake "execeeds" -> "exceeds"

From: Colin Ian King Upstream commit: commit 43d0e96022ae3c66743c01bba6c18a3afec7b578 Author: Colin Ian King Date: Tue Nov 27 14:37:17 2018 + openvswitch: fix spelling mistake "execeeds" -> "exceeds" There is a spelling mistake in a net_warn_ratelimited message, fix

[ovs-dev] [PATCH 7/8] datapath: load NAT helper

From: Flavio Leitner Upstream commit: commit 17c357efe5eceebdc3971a48b3d4d61a03c1178b Author: Flavio Leitner Date: Fri Sep 28 14:51:28 2018 -0300 openvswitch: load NAT helper Load the respective NAT helper module if the flow uses it. Signed-off-by: Flavio Leitner

[ovs-dev] [PATCH 6/8] datapath: fix return type of ndo_start_xmit function

From: YueHaibing Upstream commit: commit eddf11e18dff0e8671e06ce54e64cfc843303ab9 Author: YueHaibing Date: Wed Sep 26 17:15:38 2018 +0800 net: ovs: fix return type of ndo_start_xmit function The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which

[ovs-dev] [PATCH 5/8] datapath: Derive IP protocol number for IPv6 later frags

From: Yi-Hung Wei Upstream commit: commit fa642f08839bf2ff35b2f6c6a6c062aee8121ba8 Author: Yi-Hung Wei Date: Tue Sep 4 15:33:41 2018 -0700 openvswitch: Derive IP protocol number for IPv6 later frags Currently, OVS only parses the IP protocol number for the first IPv6

[ovs-dev] [PATCH 4/8] datapath: check tunnel option type in tunnel flags

From: Pieter Jansen van Vuuren Upstream commit: commit 256c87c17c53e60882a43dcf3e98f3bf859eaf6f Author: Pieter Jansen van Vuuren Date: Tue Jun 26 21:39:36 2018 -0700 net: check tunnel option type in tunnel flags Check the tunnel option type stored in tunnel flags when

[ovs-dev] [PATCH 3/8] compat: Fixup ip_tunnel_info_opts_set

A new flags parameter has been added in 4.19 so add compat fixup. Signed-off-by: Greg Rose --- acinclude.m4 | 3 +++ datapath/linux/compat/include/net/ip_tunnels.h | 16 +++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git

[ovs-dev] [PATCH 2/8] datapath: kzalloc() -> kcalloc()

From: Kees Cook Upstream commit: commit 6396bb221514d2876fd6dc0aa2a1f240d99b37bb Author: Kees Cook Date: Tue Jun 12 14:03:40 2018 -0700 treewide: kzalloc() -> kcalloc() The kzalloc() function has a 2-factor argument form, kcalloc(). This patch replaces cases of:

[ovs-dev] [PATCH 1/8] datapath: kmalloc() -> kmalloc_array()

From: Kees Cook Upstream commit: commit 6da2ec56059c3c7a7e5f729e6349e74ace1e5c57 Author: Kees Cook Date: Tue Jun 12 13:55:00 2018 -0700 treewide: kmalloc() -> kmalloc_array() The kmalloc() function has a 2-factor argument form, kmalloc_array(). This patch replaces

[ovs-dev] [PATCH 0/8] datapath: Pull in upstream fixes and updates

Pull in recent Linux upstream kernel updates for openvswitch core. Travis build is here: https://travis-ci.org/gvrose8192/ovs-experimental/builds/463951223 'make check-kmod' results: ## - ## ## Test results. ## ## - ## 116 tests were successful. 16 tests were skipped.

Re: [ovs-dev] [PATCH net-next 7/8] net: core: dev: Attach extack to NETDEV_PRE_UP

On 12/5/18 3:52 AM, Petr Machata wrote: > Drivers may need to validate configuration of a device that's about to > be upped. Should the validation fail, there's currently no way to > communicate details of the failure to the user, beyond an error number. > > To mend that, change __dev_open() to

Re: [ovs-dev] [PATCH net-next 6/8] net: core: dev: Add call_netdevice_notifiers_extack()

On 12/5/18 3:51 AM, Petr Machata wrote: > In order to propagate extack through NETDEV_PRE_UP, add a new function > call_netdevice_notifiers_extack() that primes the extack field of the > notifier info. Convert call_netdevice_notifiers() to a simple wrapper > around the new function that passes

Re: [ovs-dev] [PATCH net-next 4/8] net: core: dev: Add extack argument to dev_change_flags()

On 12/5/18 3:51 AM, Petr Machata wrote: > In order to pass extack together with NETDEV_PRE_UP notifications, it's > necessary to route the extack to __dev_open() from diverse (possibly > indirect) callers. One prominent API through which the notification is > invoked is dev_change_flags(). > >

Re: [ovs-dev] [PATCH net-next 5/8] net: core: dev: Add extack argument to __dev_change_flags()

On 12/5/18 3:51 AM, Petr Machata wrote: > In order to pass extack together with NETDEV_PRE_UP notifications, it's > necessary to route the extack to __dev_open() from diverse (possibly > indirect) callers. The last missing API is __dev_change_flags(). > > Therefore extend __dev_change_flags()

Re: [ovs-dev] [PATCH net-next 2/8] net: vrf: cycle_netdev(): Add an extack argument

On 12/5/18 3:51 AM, Petr Machata wrote: > A follow-up patch will extend dev_change_flags() with an extack > argument. Extend cycle_netdev() to have that argument available for the > conversion. > > Signed-off-by: Petr Machata > Acked-by: Jiri Pirko > Reviewed-by: Ido Schimmel > --- >

Re: [ovs-dev] [PATCH net-next 1/8] net: core: dev: Add extack argument to dev_open()

On 12/5/18 3:51 AM, Petr Machata wrote: > In order to pass extack together with NETDEV_PRE_UP notifications, it's > necessary to route the extack to __dev_open() from diverse (possibly > indirect) callers. One prominent API through which the notification is > invoked is dev_open(). > > Therefore

Re: [ovs-dev] [patch v3 2/4] conntrack: Add rcu support.

I folded in the following incremental for this patch diff --git a/lib/conntrack.c b/lib/conntrack.c index d54575b..4ce5737 100644 --- a/lib/conntrack.c +++ b/lib/conntrack.c @@ -974,7 +974,9 @@ conn_update_state(struct dp_packet *pkt, struct conn_lookup_ctx *ctx, break; case

Re: [ovs-dev] [PATCH v4] pinctrl: Check requested IP in DHCPREQUEST messages

Hi Gregory, Gregory Smith writes: > See RFC 2131, section 4.3.2. When handling a DHCPREQUEST message, the > server should validate that the client's requested IP matches the > offered IP. If not, the server should reply with a DHCPNAK. The client's > requested IP is either specified as the

Re: [ovs-dev] [PATCH] ofproto-dpif: Let the dpif report when a port is a duplicate.

Hi Ben, This patch introduced a regression in OSP environments using internal ports in other netns. Their networking configuration is lost when the service is restarted because the ports are recreated now. Before the patch it checked using netlink if the port with a specific "name" was already

[ovs-dev] [PATCH v4] pinctrl: Check requested IP in DHCPREQUEST messages

See RFC 2131, section 4.3.2. When handling a DHCPREQUEST message, the server should validate that the client's requested IP matches the offered IP. If not, the server should reply with a DHCPNAK. The client's requested IP is either specified as the Requested IP Address (option 50), or as the

[ovs-dev] Crear vínculos cercanos con el cliente

¡PDF - Estamos a tiempo - Innova learn! La Programación Neurolingüística es el estudio de la estructura de la experiencia subjetiva de las personas. Es decir, entender por qué nos comportamos de ciertas formas y aprender a optar por mejores opciones y seleccionar la mejor alternativa

Re: [ovs-dev] [PATCH] OVN: add static IP support to IPAM

> On Wed, Dec 5, 2018 at 4:05 PM Lorenzo Bianconi > wrote: > > > Add the capability to IPAM/MACAM framework to specify a static ip address > > and get the L2 one allocated dynamically using the following syntax: > > > > $ovn-nbctl lsp-set-addresses " dynamic" > > > > Until now, the usage of

Re: [ovs-dev] [PATCH] OVN: add static IP support to IPAM

On Wed, Dec 5, 2018 at 4:05 PM Lorenzo Bianconi wrote: > Add the capability to IPAM/MACAM framework to specify a static ip address > and get the L2 one allocated dynamically using the following syntax: > > $ovn-nbctl lsp-set-addresses " dynamic" > Until now, the usage of dynamic is -

Re: [ovs-dev] [PATCH v2] ovn-controller: Inject GARPs to logical switch pipeline to update neighbors

On Wed, Dec 5, 2018 at 5:03 AM Han Zhou wrote: > On Tue, Dec 4, 2018 at 10:14 AM Daniel Alvarez > wrote: > > > > Prior to this patch, GARPs announcing NAT addresses or new VIFs > > were sent out to localnet ofport through an output action. > > This can lead to problems since local datapaths

Re: [ovs-dev] [PATCH v3] pinctrl: Check requested IP in DHCPREQUEST messages

Oops. Sorry. I accidently removed the ovs-dev ML. Added it back. Thanks Numan On Wed, Dec 5, 2018 at 6:23 PM Numan Siddique wrote: > > > On Mon, Dec 3, 2018 at 11:52 PM Gregory Smith wrote: > >> Hi Numan, >> >> Just a gentle reminder about this patch, in case it got buried in your >>

[ovs-dev] [PATCH net-next 8/8] selftests: mlxsw: Add a new test extack.sh

Add a testsuite dedicated to testing extack propagation and related functionality. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- .../testing/selftests/drivers/net/mlxsw/extack.sh | 84 ++ 1 file changed, 84 insertions(+) create mode

[ovs-dev] [PATCH net-next 7/8] net: core: dev: Attach extack to NETDEV_PRE_UP

Drivers may need to validate configuration of a device that's about to be upped. Should the validation fail, there's currently no way to communicate details of the failure to the user, beyond an error number. To mend that, change __dev_open() to take an extack argument and pass it from

[ovs-dev] [PATCH net-next 5/8] net: core: dev: Add extack argument to __dev_change_flags()

In order to pass extack together with NETDEV_PRE_UP notifications, it's necessary to route the extack to __dev_open() from diverse (possibly indirect) callers. The last missing API is __dev_change_flags(). Therefore extend __dev_change_flags() with and extra extack argument and update the two

[ovs-dev] [PATCH net-next 6/8] net: core: dev: Add call_netdevice_notifiers_extack()

In order to propagate extack through NETDEV_PRE_UP, add a new function call_netdevice_notifiers_extack() that primes the extack field of the notifier info. Convert call_netdevice_notifiers() to a simple wrapper around the new function that passes NULL for extack. Signed-off-by: Petr Machata

[ovs-dev] [PATCH net-next 4/8] net: core: dev: Add extack argument to dev_change_flags()

In order to pass extack together with NETDEV_PRE_UP notifications, it's necessary to route the extack to __dev_open() from diverse (possibly indirect) callers. One prominent API through which the notification is invoked is dev_change_flags(). Therefore extend dev_change_flags() with and extra

[ovs-dev] [PATCH net-next 3/8] net: ipvlan: ipvlan_set_port_mode(): Add an extack argument

A follow-up patch will extend dev_change_flags() with an extack argument. Extend ipvlan_set_port_mode() to have that argument available for the conversion. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- drivers/net/ipvlan/ipvlan_main.c | 7 --- 1 file

[ovs-dev] [PATCH net-next 2/8] net: vrf: cycle_netdev(): Add an extack argument

A follow-up patch will extend dev_change_flags() with an extack argument. Extend cycle_netdev() to have that argument available for the conversion. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- drivers/net/vrf.c | 7 --- 1 file changed, 4 insertions(+), 3

[ovs-dev] [PATCH net-next 1/8] net: core: dev: Add extack argument to dev_open()

In order to pass extack together with NETDEV_PRE_UP notifications, it's necessary to route the extack to __dev_open() from diverse (possibly indirect) callers. One prominent API through which the notification is invoked is dev_open(). Therefore extend dev_open() with and extra extack argument and

[ovs-dev] [PATCH net-next 0/8] Pass extack to NETDEV_PRE_UP

Drivers may need to validate configuration of a device that's about to be upped. An example is mlxsw, which needs to check the configuration of a VXLAN device attached to an offloaded bridge. Should the validation fail, there's currently no way to communicate details of the failure to the user,

[ovs-dev] [PATCH] OVN: add static IP support to IPAM

Add the capability to IPAM/MACAM framework to specify a static ip address and get the L2 one allocated dynamically using the following syntax: $ovn-nbctl lsp-set-addresses " dynamic" The static ip address needs to belong to the subnet configured for the logical switch Signed-off-by: Lorenzo