Re: [ovs-dev] [PATCH] net: openswitch: flow_netlink.c: Fix indentation errors

[David Miller]

From: Shubhankar Kuranagatti 
Date: Mon, 3 May 2021 23:47:06 +0530

> Every subsequent line starts with a * of block comment
> The closing */ is shifted to a new line
> New line added after declaration
> The repeasted word 'is' is omitted from comment block
> This is done to maintain code uniformity
> 
> Signed-off-by: Shubhankar Kuranagatti 
Please resubmit this when net-next opens back up.

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

Re: [ovs-dev] [PATCH net-next] net: openvswitch: conntrack: simplify the return expression of ovs_ct_limit_get_default_limit()

[David Miller]

From: Zheng Yongjun 
Date: Tue, 8 Dec 2020 20:13:53 +0800

> Simplify the return expression.
> 
> Signed-off-by: Zheng Yongjun 

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

Re: [ovs-dev] [PATCH 0/9 net-next] drivers/net: add sw_netstats_rx_add helper

[David Miller]

From: Fabian Frederick 
Date: Mon,  5 Oct 2020 22:33:57 +0200

> This small patchset creates netstats addition dev_sw_netstats_rx_add()
> based on dev_lstats_add() and replaces some open coding
> in both drivers/net and net branches.

Series applied, thank you.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v2 0/2] net: Constify struct genl_small_ops

[David Miller]

From: Rikard Falkeborn 
Date: Mon,  5 Oct 2020 01:44:15 +0200

> Make a couple of static struct genl_small_ops const to allow the compiler
> to put them in read-only memory. Patches are independent.
> 
> v2: Rebase on net-next, genl_ops -> genl_small_ops

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

Re: [ovs-dev] [PATCH net-next 0/2] net: Constify struct genl_ops

[David Miller]

From: Rikard Falkeborn 
Date: Sun,  4 Oct 2020 23:58:08 +0200

> Make a couple of static struct genl_ops const to allow the compiler to put
> them in read-only memory. Patches are independent.

These do not apply cleanly to net-next, please respin.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] net: openswitch: reuse the helper variable to improve the code readablity

[David Miller]

From: Zeng Tao 
Date: Fri, 18 Sep 2020 15:14:30 +0800

> In the function ovs_ct_limit_exit, there is already a helper vaibale
> which could be reused to improve the readability, so i fix it in this
> patch.
> 
> Signed-off-by: Zeng Tao 

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

Re: [ovs-dev] [PATCH net-next] net: openvswitch: fixes crash if nf_conncount_init() fails

[David Miller]

From: Eelco Chaudron 
Date: Mon, 31 Aug 2020 11:57:57 +0200

> If nf_conncount_init fails currently the dispatched work is not canceled,
> causing problems when the timer fires. This change fixes this by not
> scheduling the work until all initialization is successful.
> 
> Fixes: a65878d6f00b ("net: openvswitch: fixes potential deadlock in dp 
> cleanup code")
> Reported-by: kernel test robot 
> Signed-off-by: Eelco Chaudron 

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

Re: [ovs-dev] [PATCH v2] net: openvswitch: pass NULL for unused parameters

[David Miller]

From: t...@redhat.com
Date: Sun, 30 Aug 2020 14:26:30 -0700

> Passing unused parameters is a waste.

Poorly predicted branches are an even bigger waste.

I'm not a big fan of this change and others have asked for performance
analysis to be performed.

So I'm not applying this as-is, sorry.

It's also not great to see that CLANG can't make use of the caller's
__always_unused directive to guide these warnings.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v4 0/3] net: openvswitch: improve the codes

[David Miller]

From: xiangxia.m@gmail.com
Date: Tue,  1 Sep 2020 20:26:11 +0800

> From: Tonghao Zhang 
> 
> This series patches are not bug fix, just improve codes.

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

Re: [ovs-dev] [PATCH net-next v2 1/3] net: openvswitch: improve coding style

[David Miller]

From: Tonghao Zhang 
Date: Mon, 31 Aug 2020 21:00:28 +0800

> On Thu, Aug 27, 2020 at 3:23 AM Pravin Shelar  wrote:
>>
>> On Mon, Aug 24, 2020 at 12:37 AM  wrote:
>> >
>> > From: Tonghao Zhang 
>> >
>> > Not change the logic, just improve coding style.
>> >
>> > Cc: Pravin B Shelar 
>> > Signed-off-by: Tonghao Zhang 
>>
>> Acked-by: Pravin B Shelar 
> Hi David
> This series patches were ACKed by Pravin. Will you have a plan to
> apply them to the net-next ? or I sent v4 with ACK tag.

In v3 of this series Stefano Brivio asked you to add some more curly brace
changes as feedback.  So you must address this feedback and post a new
version of the series.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v3 0/3] net: openvswitch: improve codes

[David Miller]

From: xiangxia.m@gmail.com
Date: Tue, 25 Aug 2020 13:06:33 +0800

> From: Tonghao Zhang 
> 
> This series patches are not bug fix, just improve codes.

Pravin, please review this patch series.

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

Re: [ovs-dev] [PATCH net-next v2 2/3] net: openvswitch: refactor flow free function

[David Miller]

From: xiangxia.m@gmail.com
Date: Mon, 24 Aug 2020 15:36:01 +0800

> To avoid a bug when deleting flows in the future, add
> BUG_ON in flush flows function.

BUG_ON() is too severe, I think WARN_ON() or similar are sufficient
because the kernel can try to continue operating if this condition is
detected.

And you can force the values to zero in such a situation.

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

Re: [ovs-dev] [PATCH net-next v1 2/3] net: openvswitch: refactor flow free function

[David Miller]

From: Tonghao Zhang 
Date: Thu, 20 Aug 2020 07:21:33 +0800

> On Thu, Aug 20, 2020 at 6:52 AM David Miller  wrote:
> 
>> From: xiangxia.m@gmail.com
>>
>> Date: Tue, 18 Aug 2020 18:09:22 +0800
>>
>>
>>
>> > Decrease table->count and ufid_count unconditionally,
>>
>>
>>
>> You don't explain why this is a valid transformation.
>>
>>
>>
>> Is it a bug fix?
> 
> No
> 
>>
>>
>>
>> Can it never happen?
>>
>>
>>
>> What are the details and how did you determine this?
> 
> I want to simplify the codes, when flushing the flow, previous codes don't
> count the flow, because we have set them(flow counter/ufid counter)to 0.
> Now don't set counter and count flow and ufid flow when deleting them, and
> I add BUG_ON to make sure other patch no bug when flushing flow.

Add these details to your commit message, please.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v1 2/3] net: openvswitch: refactor flow free function

[David Miller]

From: xiangxia.m@gmail.com
Date: Tue, 18 Aug 2020 18:09:22 +0800

> Decrease table->count and ufid_count unconditionally,

You don't explain why this is a valid transformation.

Is it a bug fix?

Can it never happen?

What are the details and how did you determine this?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] net: openvswitch: introduce common code for flushing flows

[David Miller]

From: xiangxia.m@gmail.com
Date: Wed, 12 Aug 2020 17:56:39 +0800

> From: Tonghao Zhang 
> 
> To avoid some issues, for example RCU usage warning and double free,
> we should flush the flows under ovs_lock. This patch refactors
> table_instance_destroy and introduces table_instance_flow_flush
> which can be invoked by __dp_destroy or ovs_flow_tbl_flush.
> 
> Fixes: 50b0e61b32ee ("net: openvswitch: fix possible memleak on destroy 
> flow-table")
> Reported-by: Johan Knöös 
> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-August/050489.html
> Signed-off-by: Tonghao Zhang 

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

Re: [ovs-dev] [PATCH] net: openvswitch: introduce common code for flushing flows

[David Miller]

From: xiangxia.m@gmail.com
Date: Tue, 11 Aug 2020 09:10:01 +0800

> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 42f8cc70bb2c..5fec47e62615 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -1756,6 +1756,9 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct 
> genl_info *info)
>  /* Called with ovs_mutex. */
>  static void __dp_destroy(struct datapath *dp)
>  {
> + struct flow_table *table = >table;
> + struct table_instance *ufid_ti = ovsl_dereference(table->ufid_ti);
> + struct table_instance *ti = ovsl_dereference(table->ti);
>   int i;
>  
>   for (i = 0; i < DP_VPORT_HASH_BUCKETS; i++) {

Please use reverse christmas tree ordering for local variables.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] net: openvswitch: silence suspicious RCU usage warning

[David Miller]

From: xiangxia.m@gmail.com
Date: Wed,  5 Aug 2020 15:19:11 +0800

> From: Tonghao Zhang 
> 
> ovs_flow_tbl_destroy always is called from RCU callback
> or error path. It is no need to check if rcu_read_lock
> or lockdep_ovsl_is_held was held.
> 
> ovs_dp_cmd_fill_info always is called with ovs_mutex,
> So use the rcu_dereference_ovsl instead of rcu_dereference
> in ovs_flow_tbl_masks_cache_size.
> 
> Fixes: 9bf24f594c6a ("net: openvswitch: make masks cache size configurable")
> Cc: Eelco Chaudron 
> Reported-by: syzbot+c0eb9e7cdde04e4eb...@syzkaller.appspotmail.com
> Reported-by: syzbot+f612c02823acb02ff...@syzkaller.appspotmail.com
> Signed-off-by: Tonghao Zhang 

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

Re: [ovs-dev] [Linux-kernel-mentees] [PATCH net] openvswitch: Prevent kernel-infoleak in ovs_ct_put_key()

[David Miller]

From: Peilin Ye 
Date: Fri, 31 Jul 2020 00:48:38 -0400

> ovs_ct_put_key() is potentially copying uninitialized kernel stack memory
> into socket buffers, since the compiler may leave a 3-byte hole at the end
> of `struct ovs_key_ct_tuple_ipv4` and `struct ovs_key_ct_tuple_ipv6`. Fix
> it by initializing `orig` with memset().
> 
> Cc: sta...@vger.kernel.org

Please don't CC: stable for networking fixes.

> Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to 
> sw_flow_key.")
> Suggested-by: Dan Carpenter 
> Signed-off-by: Peilin Ye 

Applied and queued up for -stable, thank you.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next] net: openvswitch: fixes potential deadlock in dp cleanup code

[David Miller]

From: Eelco Chaudron 
Date: Fri, 24 Jul 2020 10:20:59 +0200

> The previous patch introduced a deadlock, this patch fixes it by making
> sure the work is canceled without holding the global ovs lock. This is
> done by moving the reorder processing one layer up to the netns level.
> 
> Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage")
> Reported-by: syzbot+2c4ff3614695f75ce...@syzkaller.appspotmail.com
> Reported-by: syzbot+bad6507e5db05017b...@syzkaller.appspotmail.com
> Reviewed-by: Paolo 
> Signed-off-by: Eelco Chaudron 

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

Re: [ovs-dev] [PATCH net-next] net: openvswitch: reorder masks array based on usage

[David Miller]

From: Eelco Chaudron 
Date: Wed, 15 Jul 2020 14:09:28 +0200

> This patch reorders the masks array every 4 seconds based on their
> usage count. This greatly reduces the masks per packet hit, and
> hence the overall performance. Especially in the OVS/OVN case for
> OpenShift.
> 
> Here are some results from the OVS/OVN OpenShift test, which use
> 8 pods, each pod having 512 uperf connections, each connection
> sends a 64-byte request and gets a 1024-byte response (TCP).
> All uperf clients are on 1 worker node while all uperf servers are
> on the other worker node.
> 
> Kernel without this patch :  7.71 Gbps
> Kernel with this patch applied: 14.52 Gbps
> 
> We also run some tests to verify the rebalance activity does not
> lower the flow insertion rate, which does not.
> 
> Signed-off-by: Eelco Chaudron 
> Tested-by: Andrew Theurer 

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

Re: [ovs-dev] [PATCH v2 net] openvswitch: take into account de-fragmentation/gso_size in execute_check_pkt_len

[David Miller]

From: Lorenzo Bianconi 
Date: Tue, 23 Jun 2020 18:33:15 +0200

> ovs connection tracking module performs de-fragmentation on incoming
> fragmented traffic. Take info account if traffic has been de-fragmented
> in execute_check_pkt_len action otherwise we will perform the wrong
> nested action considering the original packet size. This issue typically
> occurs if ovs-vswitchd adds a rule in the pipeline that requires connection
> tracking (e.g. OVN stateful ACLs) before execute_check_pkt_len action.
> Moreover take into account GSO fragment size for GSO packet in
> execute_check_pkt_len routine
> 
> Fixes: 4d5ec89fc8d14 ("net: openvswitch: Add a new action check_pkt_len")
> Signed-off-by: Lorenzo Bianconi 

Applied and queued up for -stable, thank you.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v4 0/5] expand meter tables and fix bug

[David Miller]

From: xiangxia.m@gmail.com
Date: Fri, 24 Apr 2020 08:08:01 +0800

> From: Tonghao Zhang 
> 
> The patch set expand or shrink the meter table when necessary.
> and other patches fix bug or improve codes.

This looks better, series applied, thank you.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v3 0/5] expand meter tables and fix bug

[David Miller]

From: David Miller 
Date: Thu, 23 Apr 2020 12:45:29 -0700 (PDT)

> From: xiangxia.m@gmail.com
> Date: Thu, 23 Apr 2020 01:08:55 +0800
> 
>> From: Tonghao Zhang 
>> 
>> The patch set expand or shrink the meter table when necessary.
>> and other patches fix bug or improve codes.
> 
> Series applied, thanks.

Actually I had to revert, this adds build warnings:

In file included from ./include/linux/uio.h:8,
 from ./include/linux/socket.h:8,
 from ./include/uapi/linux/if.h:25,
 from net/openvswitch/meter.c:8:
net/openvswitch/meter.c: In function ‘ovs_meters_init’:
./include/linux/kernel.h:842:29: warning: comparison of distinct pointer types 
lacks a cast
   (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
 ^~
./include/linux/kernel.h:856:4: note: in expansion of macro ‘__typecheck’
   (__typecheck(x, y) && __no_side_effects(x, y))
^~~
./include/linux/kernel.h:866:24: note: in expansion of macro ‘__safe_cmp’
  __builtin_choose_expr(__safe_cmp(x, y), \
^~
./include/linux/kernel.h:875:19: note: in expansion of macro ‘__careful_cmp’
 #define min(x, y) __careful_cmp(x, y, <)
   ^
net/openvswitch/meter.c:733:28: note: in expansion of macro ‘min’
  tbl->max_meters_allowed = min(free_mem_bytes / sizeof(struct dp_meter),
^~~
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v3 0/5] expand meter tables and fix bug

[David Miller]

From: xiangxia.m@gmail.com
Date: Thu, 23 Apr 2020 01:08:55 +0800

> From: Tonghao Zhang 
> 
> The patch set expand or shrink the meter table when necessary.
> and other patches fix bug or improve codes.

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

Re: [ovs-dev] [PATCH] net: openvswitch: ovs_ct_exit to be done under ovs_lock

[David Miller]

From: xiangxia.m@gmail.com
Date: Fri, 17 Apr 2020 02:57:31 +0800

> From: Tonghao Zhang 
> 
> syzbot wrote:
 ...
> To avoid that warning, invoke the ovs_ct_exit under ovs_lock and add
> lockdep_ovsl_is_held as optional lockdep expression.
> 
> Link: https://lore.kernel.org/lkml/e642a905a0cbe...@google.com
> Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
> Cc: Pravin B Shelar  
> Cc: Yi-Hung Wei 
> Reported-by: syzbot+7ef50afd3a211f879...@syzkaller.appspotmail.com
> Signed-off-by: Tonghao Zhang 

Applied and queued up for -stable, thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v2 0/5] expand meter tables and fix bug

[David Miller]

From: xiangxia.m@gmail.com
Date: Thu, 16 Apr 2020 18:16:58 +0800

> From: Tonghao Zhang 
> 
> The patch set expands or shrink the meter table when necessary.
> and other patch fixes bug or improve codes.

Pravin et al. please review this series.

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

Re: [ovs-dev] [PATCH] net: openvswitch: use hlist_for_each_entry_rcu instead of hlist_for_each_entry

[David Miller]

From: xiangxia.m@gmail.com
Date: Thu, 26 Mar 2020 04:27:24 +0800

> From: Tonghao Zhang 
> 
> The struct sw_flow is protected by RCU, when traversing them,
> use hlist_for_each_entry_rcu.
> 
> Signed-off-by: Tonghao Zhang 

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

Re: [ovs-dev] [PATCH net-next] net: Fix typo of SKB_SGO_CB_OFFSET

[David Miller]

From: Cambda Zhu 
Date: Thu, 26 Mar 2020 15:33:14 +0800

> The SKB_SGO_CB_OFFSET should be SKB_GSO_CB_OFFSET which means the
> offset of the GSO in skb cb. This patch fixes the typo.
> 
> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
> Signed-off-by: Cambda Zhu 

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

Re: [ovs-dev] [PATCH] openvswitch: Distribute switch variables for initialization

[David Miller]

From: Kees Cook 
Date: Wed, 19 Feb 2020 22:23:09 -0800

> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initialization feature, this triggers a warning (and they
> don't get initialized). Clang's automatic stack variable initialization
> (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
> doesn't initialize such variables[1]. Note that these warnings (or silent
> skipping) happen before the dead-store elimination optimization phase,
> so even when the automatic initializations are later elided in favor of
> direct initializations, the warnings remain.
> 
> To avoid these problems, move such variables into the "case" where
> they're used or lift them up into the main function body.
> 
> net/openvswitch/flow_netlink.c: In function ‘validate_set’:
> net/openvswitch/flow_netlink.c:2711:29: warning: statement will never be 
> executed [-Wswitch-unreachable]
>  2711 |  const struct ovs_key_ipv4 *ipv4_key;
>   | ^~~~
> 
> [1] https://bugs.llvm.org/show_bug.cgi?id=44916
> 
> Signed-off-by: Kees Cook 

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

Re: [ovs-dev] [PATCH 3/4] datapath.c: Use built-in RCU list checking

[David Miller]

From: madhuparnabhowmi...@gmail.com
Date: Wed, 19 Feb 2020 01:28:02 +0530

> From: Madhuparna Bhowmik 
> 
> hlist_for_each_entry_rcu() has built-in RCU and lock checking.
> 
> Pass cond argument to list_for_each_entry_rcu() to silence
> false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
> by default.
> 
> Signed-off-by: Madhuparna Bhowmik 

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

Re: [ovs-dev] [PATCH 1/4] meter.c: Use built-in RCU list checking

[David Miller]

From: madhuparnabhowmi...@gmail.com
Date: Wed, 19 Feb 2020 01:24:25 +0530

> From: Madhuparna Bhowmik 
> 
> hlist_for_each_entry_rcu() has built-in RCU and lock checking.
> 
> Pass cond argument to list_for_each_entry_rcu() to silence
> false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
> by default.
> 
> Signed-off-by: Madhuparna Bhowmik 

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

Re: [ovs-dev] [PATCH 4/4] flow_table.c: Use built-in RCU list checking

[David Miller]

From: madhuparnabhowmi...@gmail.com
Date: Wed, 19 Feb 2020 01:28:20 +0530

> From: Madhuparna Bhowmik 
> 
> hlist_for_each_entry_rcu() has built-in RCU and lock checking.
> 
> Pass cond argument to list_for_each_entry_rcu() to silence
> false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
> by default.
> 
> Signed-off-by: Madhuparna Bhowmik 

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

Re: [ovs-dev] [PATCH 2/4] vport.c: Use built-in RCU list checking

[David Miller]

From: madhuparnabhowmi...@gmail.com
Date: Wed, 19 Feb 2020 01:27:42 +0530

> From: Madhuparna Bhowmik 
> 
> hlist_for_each_entry_rcu() has built-in RCU and lock checking.
> 
> Pass cond argument to list_for_each_entry_rcu() to silence
> false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
> by default.
> 
> Signed-off-by: Madhuparna Bhowmik 

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

Re: [ovs-dev] [PATCH net-next v5] openvswitch: add TTL decrement action

[David Miller]

From: Matteo Croce 
Date: Sat, 15 Feb 2020 14:20:56 +0100

> New action to decrement TTL instead of setting it to a fixed value.
> This action will decrement the TTL and, in case of expired TTL, drop it
> or execute an action passed via a nested attribute.
> The default TTL expired action is to drop the packet.
> 
> Supports both IPv4 and IPv6 via the ttl and hop_limit fields, respectively.
> 
> Tested with a corresponding change in the userspace:
> 
> # ovs-dpctl dump-flows
> in_port(2),eth(),eth_type(0x0800), packets:0, bytes:0, used:never, 
> actions:dec_ttl{ttl<=1 action:(drop)},1
> in_port(1),eth(),eth_type(0x0800), packets:0, bytes:0, used:never, 
> actions:dec_ttl{ttl<=1 action:(drop)},2
> in_port(1),eth(),eth_type(0x0806), packets:0, bytes:0, used:never, 
> actions:2
> in_port(2),eth(),eth_type(0x0806), packets:0, bytes:0, used:never, 
> actions:1
> 
> # ping -c1 192.168.0.2 -t 42
> IP (tos 0x0, ttl 41, id 61647, offset 0, flags [DF], proto ICMP (1), 
> length 84)
> 192.168.0.1 > 192.168.0.2: ICMP echo request, id 386, seq 1, length 64
> # ping -c1 192.168.0.2 -t 120
> IP (tos 0x0, ttl 119, id 62070, offset 0, flags [DF], proto ICMP (1), 
> length 84)
> 192.168.0.1 > 192.168.0.2: ICMP echo request, id 388, seq 1, length 64
> # ping -c1 192.168.0.2 -t 1
> #
> 
> Co-developed-by: Bindiya Kurle 
> Signed-off-by: Bindiya Kurle 
> Signed-off-by: Matteo Croce 

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

Re: [ovs-dev] [PATCH net-next v4] openvswitch: add TTL decrement action

[David Miller]

From: Matteo Croce 
Date: Thu,  6 Feb 2020 21:29:49 +0100

> New action to decrement TTL instead of setting it to a fixed value.
> This action will decrement the TTL and, in case of expired TTL, drop it
> or execute an action passed via a nested attribute.
> The default TTL expired action is to drop the packet.
> 
> Supports both IPv4 and IPv6 via the ttl and hop_limit fields, respectively.
> 
> Tested with a corresponding change in the userspace:
> 
> # ovs-dpctl dump-flows
> in_port(2),eth(),eth_type(0x0800), packets:0, bytes:0, used:never, 
> actions:dec_ttl{ttl<=1 action:(drop)},1
> in_port(1),eth(),eth_type(0x0800), packets:0, bytes:0, used:never, 
> actions:dec_ttl{ttl<=1 action:(drop)},2
> in_port(1),eth(),eth_type(0x0806), packets:0, bytes:0, used:never, 
> actions:2
> in_port(2),eth(),eth_type(0x0806), packets:0, bytes:0, used:never, 
> actions:1
> 
> # ping -c1 192.168.0.2 -t 42
> IP (tos 0x0, ttl 41, id 61647, offset 0, flags [DF], proto ICMP (1), 
> length 84)
> 192.168.0.1 > 192.168.0.2: ICMP echo request, id 386, seq 1, length 64
> # ping -c1 192.168.0.2 -t 120
> IP (tos 0x0, ttl 119, id 62070, offset 0, flags [DF], proto ICMP (1), 
> length 84)
> 192.168.0.1 > 192.168.0.2: ICMP echo request, id 388, seq 1, length 64
> # ping -c1 192.168.0.2 -t 1
> #
> 
> Co-developed-by: Bindiya Kurle 
> Signed-off-by: Bindiya Kurle 
> Signed-off-by: Matteo Croce 

net-next is closed, please resubmit this when it opens back up.

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

Re: [ovs-dev] [PATCH 2/2] act_ct: support asymmetric conntrack

[David Miller]

From: Aaron Conole 
Date: Tue,  3 Dec 2019 16:34:14 -0500

> The act_ct TC module shares a common conntrack and NAT infrastructure
> exposed via netfilter.  It's possible that a packet needs both SNAT and
> DNAT manipulation, due to e.g. tuple collision.  Netfilter can support
> this because it runs through the NAT table twice - once on ingress and
> again after egress.  The act_ct action doesn't have such capability.
> 
> Like netfilter hook infrastructure, we should run through NAT twice to
> keep the symmetry.
> 
> Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct")
> 
> Signed-off-by: Aaron Conole 
> Acked-by: Marcelo Ricardo Leitner 
> ---
> NOTE: this is a repost to see if the email client issues go away.

Applied and queued up for -stable.

Next time, please:

1) Provide an introductory posting ala "[PATCH net 0/N] ..." describing
   what the patch series does on a high level, how it is doing it, and
   why it is doing it that way.

   This allows people to understand what they are about to read, and it
   gives me a single mail to respon to when I apply your entire series.

2) Always clearly indicate the target GIT tree in your Subject line,
   in these cases it should have been "[PATCH net N/M]"

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

Re: [ovs-dev] [PATCH 1/2] openvswitch: support asymmetric conntrack

[David Miller]

From: Aaron Conole 
Date: Tue,  3 Dec 2019 16:34:13 -0500

> The openvswitch module shares a common conntrack and NAT infrastructure
> exposed via netfilter.  It's possible that a packet needs both SNAT and
> DNAT manipulation, due to e.g. tuple collision.  Netfilter can support
> this because it runs through the NAT table twice - once on ingress and
> again after egress.  The openvswitch module doesn't have such capability.
> 
> Like netfilter hook infrastructure, we should run through NAT twice to
> keep the symmetry.
> 
> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
> Signed-off-by: Aaron Conole 
> ---
> NOTE: this is a repost to see if the email client issues go away.

Applied and queued up for -stable.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next] net: openvswitch: don't call pad_packet if not necessary

[David Miller]

From: xiangxia.m@gmail.com
Date: Thu, 14 Nov 2019 23:51:08 +0800

> From: Tonghao Zhang 
> 
> The nla_put_u16/nla_put_u32 makes sure that
> *attrlen is align. The call tree is that:
> 
> nla_put_u16/nla_put_u32
>   -> nla_put  attrlen = sizeof(u16) or sizeof(u32)
>   -> __nla_putattrlen
>   -> __nla_reserveattrlen
>   -> skb_put(skb, nla_total_size(attrlen))
> 
> nla_total_size returns the total length of attribute
> including padding.
> 
> Cc: Joe Stringer 
> Cc: William Tu 
> Signed-off-by: Tonghao Zhang 

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

Re: [ovs-dev] [PATCH net-next v2] net: openvswitch: add hash info to upcall

[David Miller]

From: xiangxia.m@gmail.com
Date: Sun, 10 Nov 2019 19:54:04 +0800

> From: Tonghao Zhang 
> 
> When using the kernel datapath, the upcall don't
> add skb hash info relatived. That will introduce
> some problem, because the hash of skb is very
> important (e.g. vxlan module uses it for udp src port,
> tx queue selection on tx path.).
> 
> For example, there will be one upcall, without information
> skb hash, to ovs-vswitchd, for the first packet of one tcp
> session. When kernel sents the tcp packets, the hash is
> random for a tcp socket:
 ...
> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
> Signed-off-by: Tonghao Zhang 
> ---
> v2: add define before #endif

OVS folks, please review.

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

Re: [ovs-dev] [PATCH net-next v2] net: openvswitch: select vport upcall portid directly

[David Miller]

From: xiangxia.m@gmail.com
Date: Thu,  7 Nov 2019 00:34:28 +0800

> From: Tonghao Zhang 
> 
> The commit 69c51582ff786 ("dpif-netlink: don't allocate per
> thread netlink sockets"), in Open vSwitch ovs-vswitchd, has
> changed the number of allocated sockets to just one per port
> by moving the socket array from a per handler structure to
> a per datapath one. In the kernel datapath, a vport will have
> only one socket in most case, if so select it directly in
> fast-path.
> 
> Signed-off-by: Tonghao Zhang 
> ---
> v2: drectly -> directly in the commit title

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

Re: [ovs-dev] [PATCH net-next v6 05/10] net: openvswitch: optimize flow-mask looking up

[David Miller]

From: William Tu 
Date: Mon, 4 Nov 2019 05:59:27 -0800

> Nack to this patch.

These changes are already in net-next.

If you already pointed out these problems in previous discussions, I'm
sorry about that.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v6 00/10] optimize openvswitch flow looking up

[David Miller]

From: xiangxia.m@gmail.com
Date: Fri,  1 Nov 2019 22:23:44 +0800

> This series patch optimize openvswitch for performance or simplify
> codes.

Series applied, thank you.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v5 04/10] net: openvswitch: optimize flow mask cache hash collision

[David Miller]

From: xiangxia.m@gmail.com
Date: Sat, 19 Oct 2019 16:08:38 +0800

> @@ -516,18 +519,31 @@ static struct sw_flow *flow_lookup(struct flow_table 
> *tbl,
>  u32 *index)
>  {
>   struct sw_flow *flow;
> + struct sw_flow_mask *mask;
>   int i;

Please preserve the reverse christmas tree ordering of local variables here.

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

Re: [ovs-dev] [PATCH net-next v5 06/10] net: openvswitch: simplify the flow_hash

[David Miller]

From: xiangxia.m@gmail.com
Date: Sat, 19 Oct 2019 16:08:40 +0800

> @@ -432,13 +432,9 @@ int ovs_flow_tbl_flush(struct flow_table *flow_table)
>  static u32 flow_hash(const struct sw_flow_key *key,
>const struct sw_flow_key_range *range)
>  {
> - int key_start = range->start;
> - int key_end = range->end;
> - const u32 *hash_key = (const u32 *)((const u8 *)key + key_start);
> - int hash_u32s = (key_end - key_start) >> 2;
> -
> + const u32 *hash_key = (const u32 *)((const u8 *)key + range->start);
>   /* Make sure number of hash bytes are multiple of u32. */
> - BUILD_BUG_ON(sizeof(long) % sizeof(u32));
> + int hash_u32s = range_n_bytes(range) >> 2;

Please place an empty line between the last local variable declaration and
the start of comments and code in the body of the function.

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

Re: [ovs-dev] [PATCH net-next v5 02/10] net: openvswitch: convert mask list in mask array

[David Miller]

From: xiangxia.m@gmail.com
Date: Sat, 19 Oct 2019 16:08:36 +0800

> @@ -611,13 +683,8 @@ struct sw_flow *ovs_flow_tbl_lookup_ufid(struct 
> flow_table *tbl,
>  
>  int ovs_flow_tbl_num_masks(const struct flow_table *table)
>  {
> - struct sw_flow_mask *mask;
> - int num = 0;
> -
> - list_for_each_entry(mask, >mask_list, list)
> - num++;
> -
> - return num;
> + struct mask_array *ma = rcu_dereference_ovsl(table->mask_array);
> + return ma->count;
>  }

Please put an empty line between the variable declarations and the start of the
code in this function.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v5 00/10] optimize openvswitch flow looking up

[David Miller]

Date: Sat, 19 Oct 2019 16:08:34 +0800

The date on your postings is in the past.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v4 00/10] optimize openvswitch flow looking up

[David Miller]

From: xiangxia.m@gmail.com
Date: Tue, 15 Oct 2019 18:30:30 +0800

> This series patch optimize openvswitch for performance or simplify
> codes.
 ...

Pravin and company, please review!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovs: datapath: hide clang frame-overflow warnings

[David Miller]

From: Arnd Bergmann 
Date: Mon, 22 Jul 2019 17:00:01 +0200

> Some functions in the datapath code are factored out so that each
> one has a stack frame smaller than 1024 bytes with gcc. However,
> when compiling with clang, the functions are inlined more aggressively
> and combined again so we get
> 
> net/openvswitch/datapath.c:1124:12: error: stack frame size of 1528 bytes in 
> function 'ovs_flow_cmd_set' [-Werror,-Wframe-larger-than=]
> 
> Marking both get_flow_actions() and ovs_nla_init_match_and_action()
> as 'noinline_for_stack' gives us the same behavior that we see with
> gcc, and no warning. Note that this does not mean we actually use
> less stack, as the functions call each other, and we still get
> three copies of the large 'struct sw_flow_key' type on the stack.
> 
> The comment tells us that this was previously considered safe,
> presumably since the netlink parsing functions are called with
> a known backchain that does not also use a lot of stack space.
> 
> Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.")
> Signed-off-by: Arnd Bergmann 

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

Re: [ovs-dev] [PATCH net-next] net: openvswitch: do not update max_headroom if new headroom is equal to old headroom

[David Miller]

From: Taehee Yoo 
Date: Sat,  6 Jul 2019 01:08:09 +0900

> When a vport is deleted, the maximum headroom size would be changed.
> If the vport which has the largest headroom is deleted,
> the new max_headroom would be set.
> But, if the new headroom size is equal to the old headroom size,
> updating routine is unnecessary.
> 
> Signed-off-by: Taehee Yoo 

I don't think Taehee should be punished because it took several days
to get someone to look at and review and/or test this patch and
meanwhile the net-next tree closed down.

I ask for maintainer review as both a courtesy and a way to lessen
my workload.  But if that means patches rot for days in patchwork
I'm just going to apply them after my own review.

So I'm applying this now.

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

Re: [ovs-dev] [PATCH net-next] net: openvswitch: do not update max_headroom if new headroom is equal to old headroom

[David Miller]

From: Taehee Yoo 
Date: Sat,  6 Jul 2019 01:08:09 +0900

> When a vport is deleted, the maximum headroom size would be changed.
> If the vport which has the largest headroom is deleted,
> the new max_headroom would be set.
> But, if the new headroom size is equal to the old headroom size,
> updating routine is unnecessary.
> 
> Signed-off-by: Taehee Yoo 

I'm not so sure about the logic here and I'd therefore like an OVS expert
to review this.

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

Re: [ovs-dev] [PATCH net-next] net: openvswitch: use netif_ovs_is_port() instead of opencode

[David Miller]

From: Taehee Yoo 
Date: Sat,  6 Jul 2019 01:05:46 +0900

> Use netif_ovs_is_port() function instead of open code.
> This patch doesn't change logic.
> 
> Signed-off-by: Taehee Yoo 

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

Re: [ovs-dev] [PATCH net-next] net: openvswitch: remove unnecessary ASSERT_OVSL in ovs_vport_del()

[David Miller]

From: Taehee Yoo 
Date: Mon, 10 Jun 2019 02:19:06 +0900

> ASSERT_OVSL() in ovs_vport_del() is unnecessary because
> ovs_vport_del() is only called by ovs_dp_detach_port() and
> ovs_dp_detach_port() calls ASSERT_OVSL() too.
> 
> Signed-off-by: Taehee Yoo 

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

Re: [ovs-dev] [PATCH net] net: openvswitch: do not free vport if register_netdevice() is failed.

[David Miller]

From: Taehee Yoo 
Date: Sun,  9 Jun 2019 23:26:21 +0900

> In order to create an internal vport, internal_dev_create() is used and
> that calls register_netdevice() internally.
> If register_netdevice() fails, it calls dev->priv_destructor() to free
> private data of netdev. actually, a private data of this is a vport.
> 
> Hence internal_dev_create() should not free and use a vport after failure
> of register_netdevice().
> 
> Test command
> ovs-dpctl add-dp bonding_masters
 ...
> Fixes: cf124db566e6 ("net: Fix inconsistent teardown and release of private 
> netdev state.")
> Signed-off-by: Taehee Yoo 

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

Re: [ovs-dev] [PATCH] net: openvswitch: drop unneeded likely() call around IS_ERR()

[David Miller]

From: "Enrico Weigelt, metux IT consult" 
Date: Wed,  5 Jun 2019 23:06:40 +0200

> From: Enrico Weigelt 
> 
> IS_ERR() already calls unlikely(), so this extra likely() call
> around the !IS_ERR() is not needed.
> 
> Signed-off-by: Enrico Weigelt 

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

Re: [ovs-dev] [PATCH] openvswitch: Replace removed NF_NAT_NEEDED with IS_ENABLED(CONFIG_NF_NAT)

[David Miller]

From: Geert Uytterhoeven 
Date: Wed,  8 May 2019 08:52:32 +0200

> Commit 4806e975729f99c7 ("netfilter: replace NF_NAT_NEEDED with
> IS_ENABLED(CONFIG_NF_NAT)") removed CONFIG_NF_NAT_NEEDED, but a new user
> popped up afterwards.
> 
> Fixes: fec9c271b8f1bde1 ("openvswitch: load and reference the NAT helper.")
> Signed-off-by: Geert Uytterhoeven 

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

Re: [ovs-dev] [PATCH][next] openvswitch: check for null pointer return from nla_nest_start_noflag

[David Miller]

From: Colin King 
Date: Wed,  1 May 2019 14:41:58 +0100

> From: Colin Ian King 
> 
> The call to nla_nest_start_noflag can return null in the unlikely
> event that nla_put returns -EMSGSIZE.  Check for this condition to
> avoid a null pointer dereference on pointer nla_reply.
> 
> Addresses-Coverity: ("Dereference null return value")
> Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
> Signed-off-by: Colin Ian King 

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

Re: [ovs-dev] [PATCH net-next] net: openvswitch: return an error instead of doing BUG_ON()

[David Miller]

From: Eelco Chaudron 
Date: Thu,  2 May 2019 16:12:38 -0400

> For all other error cases in queue_userspace_packet() the error is
> returned, so it makes sense to do the same for these two error cases.
> 
> Reported-by: Davide Caratti 
> Signed-off-by: Eelco Chaudron 

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

Re: [ovs-dev] [PATCH net-next v3 0/4] openvswitch: load and reference the NAT helper

[David Miller]

From: Flavio Leitner 
Date: Wed, 17 Apr 2019 11:46:13 -0300

> The request_module() is quite expensive and triggers the
> usermode helper in userspace. Instead, load only if the
> module is not present and keep module references to avoid
> problems.
> 
> The first patch standardize the module alias which is already
> there, but not in a formal way.
> 
> The second patch adds an API to point to the NAT helper.
> 
> The third patch will register each NAT helper using the
> new API.
> 
> The last patch fixes openvswitch to use the new API to
> load and reference the NAT helper and also report an error
> if the operation fails.

Netfilter folks, besides a review, I was wondering if you'd like
to take this series the netfilter tree since it's mostly changes
in that area?

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

Re: [ovs-dev] [PATCH net-next] openvswitch: use after free in __ovs_ct_free_action()

[David Miller]

From: Dan Carpenter 
Date: Tue, 2 Apr 2019 09:53:14 +0300

> We free "ct_info->ct" and then use it on the next line when we pass it
> to nf_ct_destroy_timeout().  This patch swaps the order to avoid the use
> after free.
> 
> Fixes: 06bd2bdf19d2 ("openvswitch: Add timeout support to ct action")
> Signed-off-by: Dan Carpenter 

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

Re: [ovs-dev] [PATCH net-next v5] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

[David Miller]

From: we...@ucloud.cn
Date: Thu, 28 Mar 2019 12:43:23 +0800

> From: wenxu 
> 
> There is currently no support for the multicast/broadcast aspects
> of VXLAN in ovs. In the datapath flow the tun_dst must specific.
> But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
> And the packet can forward through the fdb table of vxlan devcice. In
> this mode the broadcast/multicast packet can be sent through the
> following ways in ovs.
> 
> ovs-vsctl add-port br0 vxlan -- set in vxlan type=vxlan \
> options:key=1000 options:remote_ip=flow
> ovs-ofctl add-flow br0 in_port=LOCAL,dl_dst=ff:ff:ff:ff:ff:ff, \
> action=output:vxlan
> 
> bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.1 \
> src_vni 1000 vni 1000 self
> bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.2 \
> src_vni 1000 vni 1000 self
> 
> Signed-off-by: wenxu 

Applied to net-next, thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next 0/8] openvswitch: load and reference the NAT helper.

[David Miller]

From: Flavio Leitner 
Date: Tue, 26 Mar 2019 17:57:07 -0300

> The request_module() is quite expensive and triggers the
> usermode helper in userspace. Instead, load only if the
> module is not present and keep module references to avoid
> problems.
> 
> The first patch standardize the module alias which is already
> there, but not in a formal way.
> 
> The second patch adds an API to point to the NAT helper.
> 
> The following patches will register each NAT helper using
> the new API.
> 
> The last patch fixes openvswitch to use the new API to
> load and reference the NAT helper and also report an error
> if the operation fails.

I haven't seen any netfilter reviews of this series, so I'm dropping
it.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] openvswitch: fix flow actions reallocation

[David Miller]

From: Andrea Righi 
Date: Thu, 28 Mar 2019 07:36:00 +0100

> The flow action buffer can be resized if it's not big enough to contain
> all the requested flow actions. However, this resize doesn't take into
> account the new requested size, the buffer is only increased by a factor
> of 2x. This might be not enough to contain the new data, causing a
> buffer overflow, for example:
> 
> [   42.044472] 
> =
> [   42.045608] BUG kmalloc-96 (Not tainted): Redzone overwritten
> [   42.046415] 
> -
> 
> [   42.047715] Disabling lock debugging due to kernel taint
> [   42.047716] INFO: 0x8bf2c4a5-0x720c0928. First byte 0x0 instead of 0xcc
> [   42.048677] INFO: Slab 0xbc6d2040 objects=29 used=18 fp=0xdc07dec4 
> flags=0x2808101
> [   42.049743] INFO: Object 0xd53a3464 @offset=2528 fp=0xccdcdebb
> 
> [   42.050747] Redzone 76f1b237: cc cc cc cc cc cc cc cc  
> 
> [   42.051839] Object d53a3464: 6b 6b 6b 6b 6b 6b 6b 6b 0c 00 00 00 6c 00 00 
> 00  l...
> [   42.053015] Object f49a30cc: 6c 00 0c 00 00 00 00 00 00 00 00 03 78 a3 15 
> f6  l...x...
> [   42.054203] Object acfe4220: 20 00 02 00 ff ff ff ff 00 00 00 00 00 00 00 
> 00   ...
> [   42.055370] Object 21024e91: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00  
> [   42.056541] Object 070e04c3: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00  
> [   42.057797] Object 948a777a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00  
> [   42.059061] Redzone 8bf2c4a5: 00 00 00 00  
> 
> [   42.060189] Padding a681b46e: 5a 5a 5a 5a 5a 5a 5a 5a  
> 
> 
> Fix by making sure the new buffer is properly resized to contain all the
> requested data.
> 
> BugLink: https://bugs.launchpad.net/bugs/1813244
> Signed-off-by: Andrea Righi 

Applied and queued up for -stable.

Althought next time I want to see a proper Fixes: tag.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next 0/8] openvswitch: load and reference the NAT helper.

[David Miller]

From: Flavio Leitner 
Date: Tue, 26 Mar 2019 17:57:07 -0300

> The request_module() is quite expensive and triggers the
> usermode helper in userspace. Instead, load only if the
> module is not present and keep module references to avoid
> problems.
> 
> The first patch standardize the module alias which is already
> there, but not in a formal way.
> 
> The second patch adds an API to point to the NAT helper.
> 
> The following patches will register each NAT helper using
> the new API.
> 
> The last patch fixes openvswitch to use the new API to
> load and reference the NAT helper and also report an error
> if the operation fails.

These are mostly netfilter changes so I would like to see some
reviews/ACKs from netfilter folks.

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

Re: [ovs-dev] [PATCH v2 net-next] net: openvswitch: Add a new action check_pkt_len

[David Miller]

From: nusid...@redhat.com
Date: Tue, 26 Mar 2019 06:13:46 +0530

> From: Numan Siddique 
> 
> This patch adds a new action - 'check_pkt_len' which checks the
> packet length and executes a set of actions if the packet
> length is greater than the specified length or executes
> another set of actions if the packet length is lesser or equal to.
> 
> This action takes below nlattrs
>   * OVS_CHECK_PKT_LEN_ATTR_PKT_LEN - 'pkt_len' to check for
> 
>   * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_GREATER - Nested actions
> to apply if the packet length is greater than the specified 'pkt_len'
> 
>   * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_LESS_EQUAL - Nested
> actions to apply if the packet length is lesser or equal to the
> specified 'pkt_len'.
> 
> The main use case for adding this action is to solve the packet
> drops because of MTU mismatch in OVN virtual networking solution.
> When a VM (which belongs to a logical switch of OVN) sends a packet
> destined to go via the gateway router and if the nic which provides
> external connectivity, has a lesser MTU, OVS drops the packet
> if the packet length is greater than this MTU.
> 
> With the help of this action, OVN will check the packet length
> and if it is greater than the MTU size, it will generate an
> ICMP packet (type 3, code 4) and includes the next hop mtu in it
> so that the sender can fragment the packets.
> 
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html
> Suggested-by: Ben Pfaff 
> Signed-off-by: Numan Siddique 

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

Re: [ovs-dev] [PATCH net-next v2] openvswitch: add seqadj extension when NAT is used.

[David Miller]

From: Flavio Leitner 
Date: Mon, 25 Mar 2019 15:58:31 -0300

> When the conntrack is initialized, there is no helper attached
> yet so the nat info initialization (nf_nat_setup_info) skips
> adding the seqadj ext.
> 
> A helper is attached later when the conntrack is not confirmed
> but is going to be committed. In this case, if NAT is needed then
> adds the seqadj ext as well.
> 
> Fixes: 16ec3d4fbb96 ("openvswitch: Fix cached ct with helper.")
> Signed-off-by: Flavio Leitner 

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

Re: [ovs-dev] [PATCH] net: openvswitch: fix missing checks for nla_nest_start

[David Miller]

From: Kangjie Lu 
Date: Fri, 15 Mar 2019 01:11:22 -0500

> nla_nest_start may fail and thus deserves a check.
> The fix returns -EMSGSIZE when it fails.
> 
> Signed-off-by: Kangjie Lu 

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

Re: [ovs-dev] [PATCH] net: openvswitch: fix a NULL pointer dereference

[David Miller]

From: Kangjie Lu 
Date: Thu, 14 Mar 2019 23:20:16 -0500

> upcall is dereferenced even when genlmsg_put fails. The fix
> goto out to avoid the NULL pointer dereference in this case.
> 
> Signed-off-by: Kangjie Lu 

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

Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros

[David Miller]

From: Gregory Rose 
Date: Mon, 4 Feb 2019 11:41:29 -0800

> 
> On 2/3/2019 1:12 AM, Eli Britstein wrote:
>> Declare ovs key structures using macros as a pre-step towards to
>> enable retrieving fields information, as a work done in proposed
>> commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/
>> ("odp-util: Do not rewrite fields with the same values as matched"),
>> with no functional change.
>>
>> Signed-off-by: Eli Britstein 
>> Reviewed-by: Roi Dayan 
> 
> Obscuring the structures with these macros is awful.  I'm opposed but
> I see it has already been
> accepted upstream so I guess that's that.

I am personally in no way obligated to apply this patch to my tree
just because "upstream" did, and I absolutely have no plans to do so
at this point.

This patch is absolutely awful.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros

[David Miller]

From: Yi-Hung Wei 
Date: Mon, 4 Feb 2019 10:47:18 -0800

> For example, to see how 'struct ovs_key_ipv6' is defined, now we need
> to trace how OVS_KEY_IPV6_FIELDS is defined, and how OVS_KEY_FIELD_ARR
> and OVS_KEY_FIELD defined.  I think it makes the header file to be
> more complicated.

I completely agree.

Unless this is totally unavoidable, I do not want to apply a patch
which makes reading and auditing the networking code more difficult.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next 1/1] openvswitch: Declare ovs key structures using macros

[David Miller]

From: Eli Britstein 
Date: Thu, 24 Jan 2019 11:46:47 +0200

> Declare ovs key structures using macros to enable retrieving fields
> information, with no functional change.
> 
> Signed-off-by: Eli Britstein 
> Reviewed-by: Roi Dayan 

I agree with Pravin, this need a much better commit message.

Maybe even better to submit this alongside whatever is supposed
to use these new macros.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next] openvswitch: meter: Use struct_size() in kzalloc()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 15 Jan 2019 15:19:17 -0600

> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
> 
> struct foo {
> int stuff;
> struct boo entry[];
> };
> 
> instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), 
> GFP_KERNEL);
> 
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
> 
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

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

Re: [ovs-dev] [PATCH] openvswitch: Avoid OOB read when parsing flow nlattrs

[David Miller]

From: Ross Lagerwall 
Date: Mon, 14 Jan 2019 09:16:56 +

> For nested and variable attributes, the expected length of an attribute
> is not known and marked by a negative number.  This results in an OOB
> read when the expected length is later used to check if the attribute is
> all zeros. Fix this by using the actual length of the attribute rather
> than the expected length.
> 
> Signed-off-by: Ross Lagerwall 

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

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

[David Miller]

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.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] openvswitch: fix spelling mistake "execeeds" -> "exceeds"

[David Miller]

From: Colin King 
Date: Tue, 27 Nov 2018 14:37:17 +

> From: Colin Ian King 
> 
> There is a spelling mistake in a net_warn_ratelimited message, fix this.
> 
> Signed-off-by: Colin Ian King 

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

Re: [ovs-dev] [PATCH net-next] OVS: remove VLAN_TAG_PRESENT - fixup

[David Miller]

From: Michał Mirosław 
Date: Sat, 10 Nov 2018 19:55:34 +0100

> It turns out I missed one VLAN_TAG_PRESENT in OVS code while rebasing.
> This fixes it.
> 
> Fixes: 9df46aefafa6 ("OVS: remove use of VLAN_TAG_PRESENT")
> Signed-off-by: Michał Mirosław 

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

Re: [ovs-dev] [PATCH net-next 0/4] Remove VLAN_TAG_PRESENT from drivers

[David Miller]

From: Michał Mirosław 
Date: Thu, 08 Nov 2018 18:44:46 +0100

> This series removes VLAN_TAG_PRESENT use from network drivers in
> preparation to removing its special meaning.

Series applied, thank you.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH][net-next] openvswitch: remove BUG_ON from get_dpdev

[David Miller]

From: Li RongQing 
Date: Thu,  8 Nov 2018 20:40:20 +0800

> if local is NULL pointer, and the following access of local's
> dev will trigger panic, which is same as BUG_ON
> 
> Signed-off-by: Li RongQing 

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

Re: [ovs-dev] [PATCH] openvswitch: fix linking without CONFIG_NF_CONNTRACK_LABELS

[David Miller]

From: Arnd Bergmann 
Date: Fri,  2 Nov 2018 16:36:55 +0100

> When CONFIG_CC_OPTIMIZE_FOR_DEBUGGING is enabled, the compiler
> fails to optimize out a dead code path, which leads to a link failure:
> 
> net/openvswitch/conntrack.o: In function `ovs_ct_set_labels':
> conntrack.c:(.text+0x2e60): undefined reference to `nf_connlabels_replace'
> 
> In this configuration, we can take a shortcut, and completely
> remove the contrack label code. This may also help the regular
> optimization.
> 
> Signed-off-by: Arnd Bergmann 

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

Re: [ovs-dev] [PATCH] openvswitch: load NAT helper

[David Miller]

From: Flavio Leitner 
Date: Fri, 28 Sep 2018 14:51:28 -0300

> Load the respective NAT helper module if the flow uses it.
> 
> Signed-off-by: Flavio Leitner 

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

Re: [ovs-dev] [PATCH] Revert "openvswitch: Fix template leak in error cases."

[David Miller]

From: Flavio Leitner 
Date: Fri, 28 Sep 2018 14:55:34 -0300

> This reverts commit 90c7afc96cbbd77f44094b5b651261968e97de67.
> 
> When the commit was merged, the code used nf_ct_put() to free
> the entry, but later on commit 76644232e612 ("openvswitch: Free
> tmpl with tmpl_free.") replaced that with nf_ct_tmpl_free which
> is a more appropriate. Now the original problem is removed.
> 
> Then 44d6e2f27328 ("net: Replace NF_CT_ASSERT() with WARN_ON().")
> replaced a debug assert with a WARN_ON() which is trigged now.
> 
> Signed-off-by: Flavio Leitner 

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

Re: [ovs-dev] [PATCH net-next] net: ovs: fix return type of ndo_start_xmit function

[David Miller]

From: YueHaibing 
Date: Wed, 26 Sep 2018 17:15:38 +0800

> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, so make sure the implementation in
> this driver has returns 'netdev_tx_t' value, and change the function
> return type to netdev_tx_t.
> 
> Found by coccinelle.
> 
> Signed-off-by: YueHaibing 

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

Re: [ovs-dev] [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function

[David Miller]

From: YueHaibing 
Date: Thu, 20 Sep 2018 20:32:44 +0800

> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, so make sure the implementation in
> this driver has returns 'netdev_tx_t' value, and change the function
> return type to netdev_tx_t.

I would advise you not to send so many of these changes as a group.

If one of the patches needs feedback addressed, which is already the
case, you will have to resubmit the entire series all over again with
the fixes.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next] net: fix return type of ndo_start_xmit function

[David Miller]

Please don't do this.

The hard part of fixing this is not what you are doing, changing the
return type.

The hard part is fixing each and every function to actually return
values which are members of the netdev_tx_t enumeration.

Please fix each and every function properly.

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

Re: [ovs-dev] [PATCH net 0/2] openvswitch tests for nla_nest_start

[David Miller]

From: David Miller 
Date: Fri, 20 Jul 2018 12:15:36 -0700 (PDT)

> From: Stephen Hemminger 
> Date: Wed, 18 Jul 2018 09:12:14 -0700
> 
>> Coverity is looking for bugs here, and a couple of new bugzilla
>> reports showed up where nla_nest_start return is not checked
>> for NULL.
> 
> Series applied and patch #2 queued up for -stable, thanks Stephen.

Actually, this wasn't compile tested and fails to build. :-/

Please fix this and resubmit.

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

Re: [ovs-dev] [PATCH net 0/2] openvswitch tests for nla_nest_start

[David Miller]

From: Stephen Hemminger 
Date: Wed, 18 Jul 2018 09:12:14 -0700

> Coverity is looking for bugs here, and a couple of new bugzilla
> reports showed up where nla_nest_start return is not checked
> for NULL.

Series applied and patch #2 queued up for -stable, thanks Stephen.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net] openvswitch: Don't swap table in nlattr_set() after OVS_ATTR_NESTED is found

[David Miller]

From: Stefano Brivio 
Date: Thu,  3 May 2018 18:13:25 +0200

> If an OVS_ATTR_NESTED attribute type is found while walking
> through netlink attributes, we call nlattr_set() recursively
> passing the length table for the following nested attributes, if
> different from the current one.
> 
> However, once we're done with those sub-nested attributes, we
> should continue walking through attributes using the current
> table, instead of using the one related to the sub-nested
> attributes.
> 
> For example, given this sequence:
> 
> 1  OVS_KEY_ATTR_PRIORITY
> 2  OVS_KEY_ATTR_TUNNEL
> 3 OVS_TUNNEL_KEY_ATTR_ID
> 4 OVS_TUNNEL_KEY_ATTR_IPV4_SRC
> 5 OVS_TUNNEL_KEY_ATTR_IPV4_DST
> 6 OVS_TUNNEL_KEY_ATTR_TTL
> 7 OVS_TUNNEL_KEY_ATTR_TP_SRC
> 8 OVS_TUNNEL_KEY_ATTR_TP_DST
> 9  OVS_KEY_ATTR_IN_PORT
> 10 OVS_KEY_ATTR_SKB_MARK
> 11 OVS_KEY_ATTR_MPLS
> 
> we switch to the 'ovs_tunnel_key_lens' table on attribute #3,
> and we don't switch back to 'ovs_key_lens' while setting
> attributes #9 to #11 in the sequence. As OVS_KEY_ATTR_MPLS
> evaluates to 21, and the array size of 'ovs_tunnel_key_lens' is
> 15, we also get this kind of KASan splat while accessing the
> wrong table:
 ...
> Reported-by: Hangbin Liu 
> Fixes: 982b52700482 ("openvswitch: Fix mask generation for nested 
> attributes.")
> Signed-off-by: Stefano Brivio 
> Reviewed-by: Sabrina Dubroca 

Looks good, applied and queued up for -stable.

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

Re: [ovs-dev] [PATCH net-next 0/5] Introduce net_rwsem to protect net_namespace_list

[David Miller]

From: Kirill Tkhai 
Date: Thu, 29 Mar 2018 19:20:23 +0300

> The series introduces fine grained rw_semaphore, which will be used
> instead of rtnl_lock() to protect net_namespace_list.
> 
> This improves scalability and allows to do non-exclusive sleepable
> iteration for_each_net(), which is enough for most cases.
> 
> scripts/get_maintainer.pl gives enormous list of people, and I add
> all to CC.
> 
> Note, that this patch is independent of "Close race between
> {un, }register_netdevice_notifier and pernet_operations":
> https://patchwork.ozlabs.org/project/netdev/list/?series=36495
> 
> Signed-off-by: Kirill Tkhai 

Great stuff!

Series applied, thanks!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next 0/6] Converting pernet_operations (part #8)

[David Miller]

From: Kirill Tkhai 
Date: Thu, 15 Mar 2018 12:10:47 +0300

> this series continues to review and to convert pernet_operations
> to make them possible to be executed in parallel for several
> net namespaces at the same time. There are different operations
> over the tree, mostly are ipvs.

Series applied, thanks Kirill.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4] openvswitch: Remove padding from packet before L3+ conntrack processing

[David Miller]

From: Ed Swierk 
Date: Wed, 31 Jan 2018 18:48:02 -0800

> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
> included in the L3 length. For example, a short IPv4 packet may have
> up to 6 bytes of padding following the IP payload when received on an
> Ethernet device with a minimum packet length of 64 bytes.
> 
> Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(),
> and help() in nf_conntrack_ftp) assume skb->len reflects the length of
> the L3 header and payload, rather than referring back to
> ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by
> lower-layer padding.
> 
> In the normal IPv4 receive path, ip_rcv() trims the packet to
> ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive
> path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly
> in the br_netfilter receive path, br_validate_ipv4() and
> br_validate_ipv6() trim the packet to the L3 length before invoking
> netfilter hooks.
> 
> Currently in the OVS conntrack receive path, ovs_ct_execute() pulls
> the skb to the L3 header but does not trim it to the L3 length before
> calling nf_conntrack_in(NF_INET_PRE_ROUTING). When
> nf_conntrack_proto_tcp encounters a packet with lower-layer padding,
> nf_ip_checksum() fails causing a "nf_ct_tcp: bad TCP checksum" log
> message. While extra zero bytes don't affect the checksum, the length
> in the IP pseudoheader does. That length is based on skb->len, and
> without trimming, it doesn't match the length the sender used when
> computing the checksum.
> 
> In ovs_ct_execute(), trim the skb to the L3 length before higher-layer
> processing.
> 
> Signed-off-by: Ed Swierk 

Applied, thank you Ed.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] openvswitch: meter: Use 64-bit arithmetic instead of 32-bit

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 30 Jan 2018 22:55:33 -0600

> Add suffix LL to constant 1000 in order to give the compiler
> complete information about the proper arithmetic to use. Notice
> that this constant is used in a context that expects an expression
> of type long long int (64 bits, signed).
> 
> The expression (band->burst_size + band->rate) * 1000 is currently
> being evaluated using 32-bit arithmetic.
> 
> Addresses-Coverity-ID: 1461563 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva 

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

Re: [ovs-dev] [PATCH v2 0/4] Check size of packets before sending

[David Miller]

From: Daniel Axtens 
Date: Mon, 29 Jan 2018 14:20:58 +1100

> OK, so how about:
> 
>  - first, a series that introduces skb_gso_validate_mac_len and uses it
>in bnx2x. This should be backportable without difficulty.
> 
>  - then, a series that wires skb_gso_validate_mac_len into the core -
>validate_xmit_skb for instance, and reverts the bnx2x fix. This would
>not need to be backported.
> 
> If that's an approach we can agree on, I am ready to send it when
> net-next opens again.

Please send the bnx2x specific fix now, thank you.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 1/2] skbuff: Add skb_network_trim

[David Miller]

From: Ed Swierk 
Date: Mon, 22 Jan 2018 18:42:18 -0800

> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
> included in the L3 length. For example, a short IPv4 packet may have
> up to 6 bytes of padding following the IP payload when received on an
> Ethernet device with a minimum packet length of 64 bytes.
> 
> Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(),
> and help() in nf_conntrack_ftp) assume skb->len reflects the length of
> the L3 header and payload, rather than referring back to
> ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by
> lower-layer padding.
> 
> In the normal IPv4 receive path, ip_rcv() trims the packet to
> ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive
> path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly
> in the br_netfilter receive path, br_validate_ipv4() and
> br_validate_ipv6() trim the packet to the L3 length before invoking
> netfilter hooks.
> 
> Currently the openvswitch receive path does not perform such trimming,
> which will be fixed by the next patch. In preparation, this patch adds
> a generic skb_network_trim() function.
> 
> Signed-off-by: Ed Swierk 

Unfortunately this helper needs some more work.

It really doesn't belong in generic skbuff.c code, as it adds a whole
bunch of protocol specific header accesses and interpretation.

Also, there is only a very specific context in which it can be used
(receive) and this is not clear at all from the name.

To be quite honest, since there will be no other users of this helper
right now, just put it into the OVS conntrack.c code.

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

Re: [ovs-dev] [PATCH 0/3] Check gso_size of packets when forwarding

[David Miller]

From: Pravin Shelar 
Date: Fri, 19 Jan 2018 13:54:15 -0800

> I agree it is not perfect. But the other proposed patch does not fix
> the connectivity issue. It only adds log msg in such cases at cost
> of extra checks/code. Therefore I prefer the easier fix for the
> issue which also fixes for all cases of packet forwarding rather
> than just OVS and Bridge.

I really think that something needs to guarantee that device drivers
will never be given either over-MTU or over-max-GSO-seg-size SKBs.

Otherwise drivers need to add completely stupid checks like making
sure that SKB lengths do not exceed the maxmimu value that can be
encoded into descriptors.

What's probably happening often now in such situations is that the
driver ends up masking the length blindly and ends up sending out a
truncated packet.

Which frankly is quite bad too.

It doesn't scale to add these checks into every driver, or trying to
"figure out" which drivers will behave adversely and only add checks
to those.

The kernel shouldn't pass objects with out-of-range attributes
to the driver, period.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 0/3] Check gso_size of packets when forwarding

[David Miller]

From: Daniel Axtens 
Date: Tue, 16 Jan 2018 13:09:17 +1100

> When regular packets are forwarded, we validate their size against the
> MTU of the destination device. However, when GSO packets are
> forwarded, we do not validate their size against the MTU. We
> implicitly assume that when they are segmented, the resultant packets
> will be correctly sized.
> 
> This is not always the case.
> 
> We observed a case where a packet received on an ibmveth device had a
> GSO size of around 10kB. This was forwarded by Open vSwitch to a bnx2x
> device, where it caused a firmware assert. This is described in detail
> at [0] and was the genesis of this series. Rather than fixing it in
> the driver, this series fixes the forwarding path.
> 
> To fix this:
> 
>  - Move a helper in patch 1.
> 
>  - Validate GSO segment lengths in is_skb_forwardable() in the GSO
>case, rather than assuming all will be well. This fixes bridges.
>This is patch 2.
> 
>  - Open vSwitch uses its own slightly specialised algorithm for
>checking lengths. Wire up checking for that in patch 3.
> 
> [0]: https://patchwork.ozlabs.org/patch/859410/

This looks good to me, could the OVS folks please review this patch
series?

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

Re: [ovs-dev] [RESEND PATCH 2/3] net: ovs: remove unused hardirq.h

[David Miller]

From: "Yang Shi" 
Date: Tue, 09 Jan 2018 03:52:53 +0800

> Preempt counter APIs have been split out, currently, hardirq.h just
> includes irq_enter/exit APIs which are not used by openvswitch at all.
> 
> So, remove the unused hardirq.h.
> 
> Signed-off-by: Yang Shi 
> Acked-by: Pravin B Shelar 

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

Re: [ovs-dev] Pravin Shelar

[David Miller]

From: Pravin Shelar 
Date: Thu, 28 Dec 2017 15:47:39 -0800

> Thanks Joe for the patch. But it is corrupted. I will send updated patch soon.

I'm still waiting for this, just FYI :)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 05/12] openvswitch: drop unneeded newline

[David Miller]

From: Julia Lawall 
Date: Wed, 27 Dec 2017 15:51:38 +0100

> OVS_NLERR prints a newline at the end of the message string, so the
> message string does not need to include a newline explicitly.  Done
> using Coccinelle.
> 
> Signed-off-by: Julia Lawall 

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

Re: [ovs-dev] [PATCH net v3] openvswitch: Fix pop_vlan action for double tagged frames

[David Miller]

From: Eric Garver 
Date: Wed, 20 Dec 2017 15:09:22 -0500

> skb_vlan_pop() expects skb->protocol to be a valid TPID for double
> tagged frames. So set skb->protocol to the TPID and let skb_vlan_pop()
> shift the true ethertype into position for us.
> 
> Fixes: 5108bbaddc37 ("openvswitch: add processing of L3 packets")
> Signed-off-by: Eric Garver 

Applied and queued up for -stable, thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] openvswitch: use ktime_get_ts64() instead of ktime_get_ts()

[David Miller]

From: Arnd Bergmann 
Date: Mon, 27 Nov 2017 12:41:38 +0100

> timespec is deprecated because of the y2038 overflow, so let's convert
> this one to ktime_get_ts64(). The code is already safe even on 32-bit
> architectures, since it uses monotonic times. On 64-bit architectures,
> nothing changes, while on 32-bit architectures this avoids one
> type conversion.
> 
> Signed-off-by: Arnd Bergmann 

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

Re: [ovs-dev] [PATCH] net: openvswitch: datapath: fix data type in queue_gso_packets

[David Miller]

From: Willem de Bruijn 
Date: Sat, 25 Nov 2017 16:15:01 -0500

> On Sat, Nov 25, 2017 at 2:14 PM, Gustavo A. R. Silva
>  wrote:
>> gso_type is being used in binary AND operations together with SKB_GSO_UDP.
>> The issue is that variable gso_type is of type unsigned short and
>> SKB_GSO_UDP expands to more than 16 bits:
>>
>> SKB_GSO_UDP = 1 << 16
>>
>> this makes any binary AND operation between gso_type and SKB_GSO_UDP to
>> be always zero, hence making some code unreachable and likely causing
>> undesired behavior.
>>
>> Fix this by changing the data type of variable gso_type to unsigned int.
>>
>> Addresses-Coverity-ID: 1462223
>> Fixes: 0c19f846d582 ("net: accept UFO datagrams from tuntap and packet")
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Acked-by: Willem de Bruijn 

Applied and I'll queued this up with Willem's changes for -stable.

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