[ovs-git] [openvswitch/ovs] 1ffca5: datapath: meter: fix the incorrect calculation of ...

GitHub noreply at github.com
Mon Jul 30 18:37:36 UTC 2018


  Branch: refs/heads/branch-2.10
  Home:   https://github.com/openvswitch/ovs
  Commit: 1ffca53e548df1f9a8367fe5285a8e809e9aed68
      https://github.com/openvswitch/ovs/commit/1ffca53e548df1f9a8367fe5285a8e809e9aed68
  Author: zhangliping <zhangliping02 at baidu.com>
  Date:   2018-07-30 (Mon, 30 Jul 2018)

  Changed paths:
    M datapath/meter.c

  Log Message:
  -----------
  datapath: meter: fix the incorrect calculation of max delta_t

Upstream commit:
    commit ddc502dfed600bff0b61d899f70d95b76223fdfc
    Author: zhangliping <zhangliping02 at baidu.com>
    Date:   Fri Mar 9 10:08:50 2018 +0800

    openvswitch: meter: fix the incorrect calculation of max delta_t

    Max delat_t should be the full_bucket/rate instead of the full_bucket.
    Also report EINVAL if the rate is zero.

    Fixes: 96fbc13d7e77 ("openvswitch: Add meter infrastructure")
    Cc: Andy Zhou <azhou at ovn.org>
    Signed-off-by: zhangliping <zhangliping02 at baidu.com>
    Acked-by: Pravin B Shelar <pshelar at ovn.org>
    Signed-off-by: David S. Miller <davem at davemloft.net>

Signed-off-by: Yi-Hung Wei <yihung.wei at gmail.com>
Reviewed-by: Greg Rose <gvrose8192 at gmail.com>
Tested-by: Greg Rose <gvrose8192 at gmail.com>
Signed-off-by: Justin Pettit <jpettit at ovn.org>


  Commit: 90460928e6f945a30b8d7c02d414acfaec0ee0e6
      https://github.com/openvswitch/ovs/commit/90460928e6f945a30b8d7c02d414acfaec0ee0e6
  Author: Yi-Hung Wei <yihung.wei at gmail.com>
  Date:   2018-07-30 (Mon, 30 Jul 2018)

  Changed paths:
    M acinclude.m4
    M datapath/datapath.c

  Log Message:
  -----------
  datapath: Introduce net_rwsem and remove rtnl_lock()

This patch backports the following two upstream commits and
add a new symbol HAVE_NET_RWSEM in acinclude.m4 to determine
whether to use new introduced rw_semaphore, net_rwsem.

Upstream commit:
    commit f0b07bb151b098d291fd1fd71ef7a2df56fb124a
    Author: Kirill Tkhai <ktkhai at virtuozzo.com>
    Date:   Thu Mar 29 19:20:32 2018 +0300

    net: Introduce net_rwsem to protect net_namespace_list

    rtnl_lock() is used everywhere, and contention is very high.
    When someone wants to iterate over alive net namespaces,
    he/she has no a possibility to do that without exclusive lock.
    But the exclusive rtnl_lock() in such places is overkill,
    and it just increases the contention. Yes, there is already
    for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
    and this can't be sleepable. Also, sometimes it may be need
    really prevent net_namespace_list growth, so for_each_net_rcu()
    is not fit there.

    This patch introduces new rw_semaphore, which will be used
    instead of rtnl_mutex to protect net_namespace_list. It is
    sleepable and allows not-exclusive iterations over net
    namespaces list. It allows to stop using rtnl_lock()
    in several places (what is made in next patches) and makes
    less the time, we keep rtnl_mutex. Here we just add new lock,
    while the explanation of we can remove rtnl_lock() there are
    in next patches.

    Fine grained locks generally are better, then one big lock,
    so let's do that with net_namespace_list, while the situation
    allows that.

    Signed-off-by: Kirill Tkhai <ktkhai at virtuozzo.com>
    Signed-off-by: David S. Miller <davem at davemloft.net>

Upstream commit:
    commit ec9c780925c57588637e1dbd8650d294107311c0
    Author: Kirill Tkhai <ktkhai at virtuozzo.com>
    Date:   Thu Mar 29 19:21:09 2018 +0300

    ovs: Remove rtnl_lock() from ovs_exit_net()

    Here we iterate for_each_net() and removes
    vport from alive net to the exiting net.

    ovs_net::dps are protected by ovs_mutex(),
    and the others, who change it (ovs_dp_cmd_new(),
    __dp_destroy()) also take it.
    The same with datapath::ports list.

    So, we remove rtnl_lock() here.

    Signed-off-by: Kirill Tkhai <ktkhai at virtuozzo.com>
    Signed-off-by: David S. Miller <davem at davemloft.net>

Signed-off-by: Yi-Hung Wei <yihung.wei at gmail.com>
Reviewed-by: Greg Rose <gvrose8192 at gmail.com>
Signed-off-by: Justin Pettit <jpettit at ovn.org>


  Commit: bb9518d910c8fa9234631cd41257b73e50155aba
      https://github.com/openvswitch/ovs/commit/bb9518d910c8fa9234631cd41257b73e50155aba
  Author: Yi-Hung Wei <yihung.wei at gmail.com>
  Date:   2018-07-30 (Mon, 30 Jul 2018)

  Changed paths:
    M acinclude.m4
    M datapath/conntrack.c

  Log Message:
  -----------
  datapath: NAT support for shifted portmap ranges

This patch backports the following upstream commit from net-next, and
defines HAVE_NF_NAT_RANGE2 to determine whether to use
'struct nf_nat_range2'.

Upstream commit:
    commit 2eb0f624b709e78ec8e2f4c3412947703db99301
    Author: Thierry Du Tre <thierry at dtsystems.be>
    Date:   Wed Apr 4 15:38:22 2018 +0200

    netfilter: add NAT support for shifted portmap ranges

    This is a patch proposal to support shifted ranges in portmaps.  (i.e. tcp/udp
    incoming port 5000-5100 on WAN redirected to LAN 192.168.1.5:2000-2100)

    Currently DNAT only works for single port or identical port ranges.  (i.e.
    ports 5000-5100 on WAN interface redirected to a LAN host while original
    destination port is not altered) When different port ranges are configured,
    either 'random' mode should be used, or else all incoming connections are
    mapped onto the first port in the redirect range. (in described example
    WAN:5000-5100 will all be mapped to 192.168.1.5:2000)

    This patch introduces a new mode indicated by flag NF_NAT_RANGE_PROTO_OFFSET
    which uses a base port value to calculate an offset with the destination port
    present in the incoming stream. That offset is then applied as index within the
    redirect port range (index modulo rangewidth to handle range overflow).

    In described example the base port would be 5000. An incoming stream with
    destination port 5004 would result in an offset value 4 which means that the
    NAT'ed stream will be using destination port 2004.

    Other possibilities include deterministic mapping of larger or multiple ranges
    to a smaller range : WAN:5000-5999 -> LAN:5000-5099 (maps WAN port 5*xx to port
    51xx)

    This patch does not change any current behavior. It just adds new NAT proto
    range functionality which must be selected via the specific flag when intended
    to use.

    A patch for iptables (libipt_DNAT.c + libip6t_DNAT.c) will also be proposed
    which makes this functionality immediately available.

    Signed-off-by: Thierry Du Tre <thierry at dtsystems.be>
    Signed-off-by: Pablo Neira Ayuso <pablo at netfilter.org>

Signed-off-by: Yi-Hung Wei <yihung.wei at gmail.com>
Reviewed-by: Greg Rose <gvrose8192 at gmail.com>
Signed-off-by: Justin Pettit <jpettit at ovn.org>


  Commit: a1cd409aa3de56b83d79211373615f551c89e789
      https://github.com/openvswitch/ovs/commit/a1cd409aa3de56b83d79211373615f551c89e789
  Author: Stefano Brivio <sbrivio at redhat.com>
  Date:   2018-07-30 (Mon, 30 Jul 2018)

  Changed paths:
    M datapath/flow_netlink.c

  Log Message:
  -----------
  datapath: Don't swap table in nlattr_set() after OVS_ATTR_NESTED is found

Upstream commit:

    commit 72f17baf2352ded6a1d3f4bb2d15da8c678cd2cb
    Author: Stefano Brivio <sbrivio at redhat.com>
    Date:   Thu May 3 18:13:25 2018 +0200

    openvswitch: Don't swap table in nlattr_set() after OVS_ATTR_NESTED is found

    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:

    [ 7654.586496] ==================================================================
    [ 7654.594573] BUG: KASAN: global-out-of-bounds in nlattr_set+0x164/0xde9 [openvswitch]
    [ 7654.603214] Read of size 4 at addr ffffffffc169ecf0 by task handler29/87430
    [ 7654.610983]
    [ 7654.612644] CPU: 21 PID: 87430 Comm: handler29 Kdump: loaded Not tainted 3.10.0-866.el7.test.x86_64 #1
    [ 7654.623030] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.1.7 06/16/2016
    [ 7654.631379] Call Trace:
    [ 7654.634108]  [<ffffffffb65a7c50>] dump_stack+0x19/0x1b
    [ 7654.639843]  [<ffffffffb53ff373>] print_address_description+0x33/0x290
    [ 7654.647129]  [<ffffffffc169b37b>] ? nlattr_set+0x164/0xde9 [openvswitch]
    [ 7654.654607]  [<ffffffffb53ff812>] kasan_report.part.3+0x242/0x330
    [ 7654.661406]  [<ffffffffb53ff9b4>] __asan_report_load4_noabort+0x34/0x40
    [ 7654.668789]  [<ffffffffc169b37b>] nlattr_set+0x164/0xde9 [openvswitch]
    [ 7654.676076]  [<ffffffffc167ef68>] ovs_nla_get_match+0x10c8/0x1900 [openvswitch]
    [ 7654.684234]  [<ffffffffb61e9cc8>] ? genl_rcv+0x28/0x40
    [ 7654.689968]  [<ffffffffb61e7733>] ? netlink_unicast+0x3f3/0x590
    [ 7654.696574]  [<ffffffffc167dea0>] ? ovs_nla_put_tunnel_info+0xb0/0xb0 [openvswitch]
    [ 7654.705122]  [<ffffffffb4f41b50>] ? unwind_get_return_address+0xb0/0xb0
    [ 7654.712503]  [<ffffffffb65d9355>] ? system_call_fastpath+0x1c/0x21
    [ 7654.719401]  [<ffffffffb4f41d79>] ? update_stack_state+0x229/0x370
    [ 7654.726298]  [<ffffffffb4f41d79>] ? update_stack_state+0x229/0x370
    [ 7654.733195]  [<ffffffffb53fe4b5>] ? kasan_unpoison_shadow+0x35/0x50
    [ 7654.740187]  [<ffffffffb53fe62a>] ? kasan_kmalloc+0xaa/0xe0
    [ 7654.746406]  [<ffffffffb53fec32>] ? kasan_slab_alloc+0x12/0x20
    [ 7654.752914]  [<ffffffffb53fe711>] ? memset+0x31/0x40
    [ 7654.758456]  [<ffffffffc165bf92>] ovs_flow_cmd_new+0x2b2/0xf00 [openvswitch]

    [snip]

    [ 7655.132484] The buggy address belongs to the variable:
    [ 7655.138226]  ovs_tunnel_key_lens+0xf0/0xffffffffffffd400 [openvswitch]
    [ 7655.145507]
    [ 7655.147166] Memory state around the buggy address:
    [ 7655.152514]  ffffffffc169eb80: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
    [ 7655.160585]  ffffffffc169ec00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [ 7655.168644] >ffffffffc169ec80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa
    [ 7655.176701]                                                              ^
    [ 7655.184372]  ffffffffc169ed00: fa fa fa fa 00 00 00 00 fa fa fa fa 00 00 00 05
    [ 7655.192431]  ffffffffc169ed80: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
    [ 7655.200490] ==================================================================

    Reported-by: Hangbin Liu <liuhangbin at gmail.com>
    Fixes: 982b52700482 ("openvswitch: Fix mask generation for nested attributes.")
    Signed-off-by: Stefano Brivio <sbrivio at redhat.com>
    Reviewed-by: Sabrina Dubroca <sd at queasysnail.net>
    Signed-off-by: David S. Miller <davem at davemloft.net>

Signed-off-by: Yi-Hung Wei <yihung.wei at gmail.com>
Reviewed-by: Greg Rose <gvrose8192 at gmail.com>
Tested-by: Greg Rose <gvrose8192 at gmail.com>
Signed-off-by: Justin Pettit <jpettit at ovn.org>


Compare: https://github.com/openvswitch/ovs/compare/3a6e8c8395e8...a1cd409aa3de
      **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.


More information about the git mailing list