1. 20 Dec, 2018 7 commits
  2. 19 Dec, 2018 33 commits
    • David S. Miller's avatar
      Merge branch 'neigh-get-support' · 24894bc6
      David S. Miller authored
      Roopa Prabhu says:
      
      ====================
      neigh get support
      
      This series adds support for neigh get similar
      to route and recently added fdb get.
      
      v2: fix key len check. and some other fixes
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24894bc6
    • Roopa Prabhu's avatar
    • Roopa Prabhu's avatar
      neighbour: register rtnl doit handler · 82cbb5c6
      Roopa Prabhu authored
      this patch registers neigh doit handler. The doit handler
      returns a neigh entry given dst and dev. This is similar
      to route and fdb doit (get) handlers. Also moves nda_policy
      declaration from rtnetlink.c to neighbour.c
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Reviewed-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82cbb5c6
    • David S. Miller's avatar
      Merge branch 'mlxsw-Make-driver-more-robust' · 4ab0edec
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Make driver more robust
      
      In recent months we fixed several bugs in the driver that could have
      been avoided by re-evaluating some of the involved code paths and by
      introducing relevant and comprehensive test cases.
      
      This patchset tries to do that by introducing a set of small and mostly
      non-functional changes in addition to a new test. I have further
      improvements in mind, but they can be done in a different set.
      
      Patch #1 makes sure we correctly sanitize upper devices of a VLAN
      interface.
      
      Patch #2 removes an unexpected behavior from the driver, in which routes
      configured on a VLAN interface will cease being offloaded after certain
      operations.
      
      Patch #3 is a small cleanup.
      
      Patch #4 simplifies the driver by removing reference counting from VLAN
      entries configured on a port.
      
      Patches #5-#6 simplify linking/unlinking from a bridge, especially when
      LAG and VLAN devices are involved. They make both operations symmetric
      even when ports are unlinked from a bridged LAG device.
      
      Patch #7-#9 make router interface (RIF) deletion more robust by removing
      reliance on device chain to indicate whether a NETDEV_DOWN event in the
      inet{,6}addr notification chains should be processed. This is due to the
      fact that IP addresses can be flushed from a netdev after it was
      unlinked from its lower device.
      
      Patch #10 adds a new test to for valid and invalid configurations over
      mlxsw ports. Some of the test cases are derived from recent fixes. I
      expect that more test cases will be added over time.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ab0edec
    • Ido Schimmel's avatar
      selftests: mlxsw: Add rtnetlink tests · 489c25f9
      Ido Schimmel authored
      Add a new test that is focused on rtnetlink configuration. Its purpose
      is to test valid and invalid (as deemed by mlxsw) configurations and
      make sure that they succeed / fail without producing a trace.
      
      Some of the test cases are derived from recent fixes in order to make
      sure that the fixed bugs are not introduced again.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      489c25f9
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Hold a reference on RIF's netdev · b61cd7c6
      Ido Schimmel authored
      Previous patches tried to make RIF deletion more robust and avoid
      use-after-free situations.
      
      As another precaution, hold a reference on a RIF's netdev and release it
      when the RIF is deleted.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b61cd7c6
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Make RIF deletion more robust · 965fa8e6
      Ido Schimmel authored
      In the past we had multiple instances where RIFs were not properly
      deleted.
      
      One of the reasons for leaking a RIF was that at the time when IP
      addresses were flushed from the respective netdev (prompting the
      destruction of the RIF), the netdev was no longer a mlxsw upper. This
      caused the inet{,6}addr notification blocks to ignore the NETDEV_DOWN
      event and leak the RIF.
      
      Instead of checking whether the netdev is our upper when an IP address
      is removed, we can instead check if the netdev has a RIF configured.
      
      To look up a RIF we need to access mlxsw private data, so the patch
      stores the notification blocks inside a mlxsw struct. This then allows
      us to use container_of() and extract the required private data.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      965fa8e6
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Propagate 'struct mlxsw_sp' further · 21ffedb6
      Ido Schimmel authored
      Next patch is going to make RIF deletion more robust by removing
      reliance on fragile mlxsw_sp_lower_get(). This is because a netdev is
      not necessarily our upper anymore when its IP addresses are flushed.
      
      The inet{,6}addr notification blocks are going to resolve 'struct
      mlxsw_sp' using container_of(), but the functions they call still use
      mlxsw_sp_lower_get().
      
      As a preparation for the next patch, propagate 'struct mlxsw_sp' down to
      the functions called from the notification blocks and remove reliance on
      mlxsw_sp_lower_get().
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21ffedb6
    • Ido Schimmel's avatar
      mlxsw: spectrum: Properly cleanup LAG uppers when removing port from LAG · be2d6f42
      Ido Schimmel authored
      When a LAG device or a VLAN device on top of it is enslaved to a bridge,
      the driver propagates the CHANGEUPPER event to the LAG's slaves.
      
      This causes each physical port to increase the reference count of the
      internal representation of the bridge port by calling
      mlxsw_sp_port_bridge_join().
      
      However, when a port is removed from a LAG, the corresponding leave()
      function is not called and the reference count is not decremented. This
      leads to ugly hacks such as mlxsw_sp_bridge_port_should_destroy() that
      try to understand if the bridge port should be destroyed even when its
      reference count is not 0.
      
      Instead, make sure that when a port is unlinked from a LAG it would see
      the same events as if the LAG (or its uppers) were unlinked from a
      bridge.
      
      The above is achieved by walking the LAG's uppers when a port is
      unlinked and calling mlxsw_sp_port_bridge_leave() for each upper that is
      enslaved to a bridge.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be2d6f42
    • Ido Schimmel's avatar
      mlxsw: spectrum: Remove reference count from VLAN entries · 635c8c8b
      Ido Schimmel authored
      Commit b3529af6 ("spectrum: Reference count VLAN entries") started
      reference counting port-VLAN entries in a similar fashion to the 8021q
      driver.
      
      However, this is not actually needed and only complicates things.
      Instead, the driver should forbid the creation of a VLAN on a port if
      this VLAN already exists. This would also solve the issue fixed by the
      mentioned commit.
      
      Therefore, remove the get()/put() API and use create()/destroy()
      instead.
      
      One place that needs special attention is VLAN addition in a VLAN-aware
      bridge via switchdev operations. In case the VLAN flags (e.g., 'pvid')
      are toggled, then the VLAN entry already exists. To prevent the driver
      from wrongly returning EEXIST, the driver is changed to check in the
      prepare phase whether the entry already exists and only returns an error
      in case it is not associated with the correct bridge port.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      635c8c8b
    • Ido Schimmel's avatar
      mlxsw: spectrum: Handle VLAN device unlinking · e149113a
      Ido Schimmel authored
      In commit 993107fe ("mlxsw: spectrum_switchdev: Fix VLAN device
      deletion via ioctl") I fixed a bug caused by the fact that the driver
      views differently the deletion of a VLAN device when it is deleted via
      an ioctl and netlink.
      
      Instead of relying on a specific order of events (device being
      unregistered vs. VLAN filter being updated), simply make sure that the
      driver performs the necessary cleanup when the VLAN device is unlinked,
      which always happens before the other two events.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e149113a
    • Ido Schimmel's avatar
      mlxsw: spectrum_fid: Remove unused function · f1d7c33d
      Ido Schimmel authored
      This function is no longer used. Remove it.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1d7c33d
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Do not destroy RIFs based on FID's reference count · 32fd4b49
      Ido Schimmel authored
      Currently, when a RIF is constructed on top of a FID, the RIF increments
      the FID's reference count and the RIF is destroyed when the FID's
      reference count drops to 1. This effectively means that when no local
      ports are member in the FID, the FID is destroyed regardless if the
      router port is a member in the FID or not.
      
      The above can lead to the unexpected behavior in which routes using a
      VLAN interface as their nexthop device are no longer offloaded after the
      last local port leaves the corresponding VLAN (FID).
      
      Example:
      # ip -4 route show dev br0.10
      192.0.2.0/24 proto kernel scope link src 192.0.2.1 offload
      # bridge vlan del vid 10 dev swp3
      # ip -4 route show dev br0.10
      192.0.2.0/24 proto kernel scope link src 192.0.2.1
      
      After the patch, the route is offloaded before and after the VLAN is
      removed from local port 'swp3', as the RIF corresponding to 'br0.10'
      continues to exists.
      
      In order to remove RIFs' reliance on the underlying FID's reference
      count, we need to add a reference count to sub-port RIFs, which are RIFs
      that correspond to physical ports and their uppers (e.g., LAG devices).
      
      In this case, each {Port, VID} ('struct mlxsw_sp_port_vlan') needs to
      hold a reference on the RIF. For example:
      
                             bond0.10
                                |
                              bond0
                                |
                            +-------+
                            |       |
                          swp1    swp2
      
      Both {Port 1, VID 10} and {Port 2, VID 10} will hold a reference on the
      RIF corresponding to 'bond0.10'. When the last reference is dropped, the
      RIF will be destroyed.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32fd4b49
    • Ido Schimmel's avatar
      mlxsw: spectrum: Sanitize VLAN interface's uppers · 927d0ef1
      Ido Schimmel authored
      Currently, only VRF and macvlan uppers are supported on top of VLAN
      device configured over a bridge, so make sure the driver forbids other
      uppers.
      
      Note that enslavement to a VRF is handled earlier in the notification
      block, so there is no need to check for a VRF upper here.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      927d0ef1
    • Hoang Le's avatar
      tipc: fix uninitialized value for broadcast retransmission · 05572271
      Hoang Le authored
      When sending broadcast message on high load system, there are a lot of
      unnecessary packets restranmission. That issue was caused by missing in
      initial criteria for retransmission.
      
      To prevent this happen, just initialize this criteria for retransmission
      in next 10 milliseconds.
      
      Fixes: 31c4f4cc ("tipc: improve broadcast retransmission algorithm")
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarHoang Le <hoang.h.le@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05572271
    • David S. Miller's avatar
      Merge branch 'tipc-tracepoints' · 013dc9d5
      David S. Miller authored
      Tuong Lien says:
      
      ====================
      tipc: tracepoints and trace_events in TIPC
      
      The patch series is the first step of introducing a tracing framework in
      TIPC, which will assist in collecting complete & plentiful data for post
      analysis, even in the case of a single failure occurrence e.g. when the
      failure is unreproducible.
      
      The tracing code in TIPC utilizes the powerful kernel tracepoints, trace
      events features along with particular dump functions to trace the TIPC
      object data and events (incl. bearer, link, socket, node, etc.).
      
      The tracing code should generate zero-load to TIPC when the trace events
      are not enabled.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      013dc9d5
    • Tuong Lien's avatar
      tipc: add trace_events for tipc bearer · cf5f55f7
      Tuong Lien authored
      The commit adds the new trace_event for TIPC bearer, L2 device event:
      
      trace_tipc_l2_device_event()
      
      Also, it puts the trace at the tipc_l2_device_event() function, then
      the device/bearer events and related info can be traced out during
      runtime when needed.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Tested-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf5f55f7
    • Tuong Lien's avatar
      tipc: add trace_events for tipc node · eb18a510
      Tuong Lien authored
      The commit adds the new trace_events for TIPC node object:
      
      trace_tipc_node_create()
      trace_tipc_node_delete()
      trace_tipc_node_lost_contact()
      trace_tipc_node_timeout()
      trace_tipc_node_link_up()
      trace_tipc_node_link_down()
      trace_tipc_node_reset_links()
      trace_tipc_node_fsm_evt()
      trace_tipc_node_check_state()
      
      Also, enables the traces for the following cases:
      - When a node is created/deleted;
      - When a node contact is lost;
      - When a node timer is timed out;
      - When a node link is up/down;
      - When all node links are reset;
      - When node state is changed;
      - When a skb comes and node state needs to be checked/updated.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Tested-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb18a510
    • Tuong Lien's avatar
      tipc: add trace_events for tipc socket · 01e661eb
      Tuong Lien authored
      The commit adds the new trace_events for TIPC socket object:
      
      trace_tipc_sk_create()
      trace_tipc_sk_poll()
      trace_tipc_sk_sendmsg()
      trace_tipc_sk_sendmcast()
      trace_tipc_sk_sendstream()
      trace_tipc_sk_filter_rcv()
      trace_tipc_sk_advance_rx()
      trace_tipc_sk_rej_msg()
      trace_tipc_sk_drop_msg()
      trace_tipc_sk_release()
      trace_tipc_sk_shutdown()
      trace_tipc_sk_overlimit1()
      trace_tipc_sk_overlimit2()
      
      Also, enables the traces for the following cases:
      - When user creates a TIPC socket;
      - When user calls poll() on TIPC socket;
      - When user sends a dgram/mcast/stream message.
      - When a message is put into the socket 'sk_receive_queue';
      - When a message is released from the socket 'sk_receive_queue';
      - When a message is rejected (e.g. due to no port, invalid, etc.);
      - When a message is dropped (e.g. due to wrong message type);
      - When socket is released;
      - When socket is shutdown;
      - When socket rcvq's allocation is overlimit (> 90%);
      - When socket rcvq + bklq's allocation is overlimit (> 90%);
      - When the 'TIPC_ERR_OVERLOAD/2' issue happens;
      
      Note:
      a) All the socket traces are designed to be able to trace on a specific
      socket by either using the 'event filtering' feature on a known socket
      'portid' value or the sysctl file:
      
      /proc/sys/net/tipc/sk_filter
      
      The file determines a 'tuple' for what socket should be traced:
      
      (portid, sock type, name type, name lower, name upper)
      
      where:
      + 'portid' is the socket portid generated at socket creating, can be
      found in the trace outputs or the 'tipc socket list' command printouts;
      + 'sock type' is the socket type (1 = SOCK_TREAM, ...);
      + 'name type', 'name lower' and 'name upper' are the service name being
      connected to or published by the socket.
      
      Value '0' means 'ANY', the default tuple value is (0, 0, 0, 0, 0) i.e.
      the traces happen for every sockets with no filter.
      
      b) The 'tipc_sk_overlimit1/2' event is also a conditional trace_event
      which happens when the socket receive queue (and backlog queue) is
      about to be overloaded, when the queue allocation is > 90%. Then, when
      the trace is enabled, the last skbs leading to the TIPC_ERR_OVERLOAD/2
      issue can be traced.
      
      The trace event is designed as an 'upper watermark' notification that
      the other traces (e.g. 'tipc_sk_advance_rx' vs 'tipc_sk_filter_rcv') or
      actions can be triggerred in the meanwhile to see what is going on with
      the socket queue.
      
      In addition, the 'trace_tipc_sk_dump()' is also placed at the
      'TIPC_ERR_OVERLOAD/2' case, so the socket and last skb can be dumped
      for post-analysis.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Tested-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      01e661eb
    • Tuong Lien's avatar
      tipc: add trace_events for tipc link · 26574db0
      Tuong Lien authored
      The commit adds the new trace_events for TIPC link object:
      
      trace_tipc_link_timeout()
      trace_tipc_link_fsm()
      trace_tipc_link_reset()
      trace_tipc_link_too_silent()
      trace_tipc_link_retrans()
      trace_tipc_link_bc_ack()
      trace_tipc_link_conges()
      
      And the traces for PROTOCOL messages at building and receiving:
      
      trace_tipc_proto_build()
      trace_tipc_proto_rcv()
      
      Note:
      a) The 'tipc_link_too_silent' event will only happen when the
      'silent_intv_cnt' is about to reach the 'abort_limit' value (and the
      event is enabled). The benefit for this kind of event is that we can
      get an early indication about TIPC link loss issue due to timeout, then
      can do some necessary actions for troubleshooting.
      
      For example: To trigger the 'tipc_proto_rcv' when the 'too_silent'
      event occurs:
      
      echo 'enable_event:tipc:tipc_proto_rcv' > \
            events/tipc/tipc_link_too_silent/trigger
      
      And disable it when TIPC link is reset:
      
      echo 'disable_event:tipc:tipc_proto_rcv' > \
            events/tipc/tipc_link_reset/trigger
      
      b) The 'tipc_link_retrans' or 'tipc_link_bc_ack' event is useful to
      trace TIPC retransmission issues.
      
      In addition, the commit adds the 'trace_tipc_list/link_dump()' at the
      'retransmission failure' case. Then, if the issue occurs, the link
      'transmq' along with the link data can be dumped for post-analysis.
      These dump events should be enabled by default since it will only take
      effect when the failure happens.
      
      The same approach is also applied for the faulty case that the
      validation of protocol message is failed.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Tested-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26574db0
    • Tuong Lien's avatar
      tipc: enable tracepoints in tipc · b4b9771b
      Tuong Lien authored
      As for the sake of debugging/tracing, the commit enables tracepoints in
      TIPC along with some general trace_events as shown below. It also
      defines some 'tipc_*_dump()' functions that allow to dump TIPC object
      data whenever needed, that is, for general debug purposes, ie. not just
      for the trace_events.
      
      The following trace_events are now available:
      
      - trace_tipc_skb_dump(): allows to trace and dump TIPC msg & skb data,
        e.g. message type, user, droppable, skb truesize, cloned skb, etc.
      
      - trace_tipc_list_dump(): allows to trace and dump any TIPC buffers or
        queues, e.g. TIPC link transmq, socket receive queue, etc.
      
      - trace_tipc_sk_dump(): allows to trace and dump TIPC socket data, e.g.
        sk state, sk type, connection type, rmem_alloc, socket queues, etc.
      
      - trace_tipc_link_dump(): allows to trace and dump TIPC link data, e.g.
        link state, silent_intv_cnt, gap, bc_gap, link queues, etc.
      
      - trace_tipc_node_dump(): allows to trace and dump TIPC node data, e.g.
        node state, active links, capabilities, link entries, etc.
      
      How to use:
      Put the trace functions at any places where we want to dump TIPC data
      or events.
      
      Note:
      a) The dump functions will generate raw data only, that is, to offload
      the trace event's processing, it can require a tool or script to parse
      the data but this should be simple.
      
      b) The trace_tipc_*_dump() should be reserved for a failure cases only
      (e.g. the retransmission failure case) or where we do not expect to
      happen too often, then we can consider enabling these events by default
      since they will almost not take any effects under normal conditions,
      but once the rare condition or failure occurs, we get the dumped data
      fully for post-analysis.
      
      For other trace purposes, we can reuse these trace classes as template
      but different events.
      
      c) A trace_event is only effective when we enable it. To enable the
      TIPC trace_events, echo 1 to 'enable' files in the events/tipc/
      directory in the 'debugfs' file system. Normally, they are located at:
      
      /sys/kernel/debug/tracing/events/tipc/
      
      For example:
      
      To enable the tipc_link_dump event:
      
      echo 1 > /sys/kernel/debug/tracing/events/tipc/tipc_link_dump/enable
      
      To enable all the TIPC trace_events:
      
      echo 1 > /sys/kernel/debug/tracing/events/tipc/enable
      
      To collect the trace data:
      
      cat trace
      
      or
      
      cat trace_pipe > /trace.out &
      
      To disable all the TIPC trace_events:
      
      echo 0 > /sys/kernel/debug/tracing/events/tipc/enable
      
      To clear the trace buffer:
      
      echo > trace
      
      d) Like the other trace_events, the feature like 'filter' or 'trigger'
      is also usable for the tipc trace_events.
      For more details, have a look at:
      
      Documentation/trace/ftrace.txt
      
      MAINTAINERS | add two new files 'trace.h' & 'trace.c' in tipc
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Tested-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4b9771b
    • David S. Miller's avatar
      Merge branch 'sk_buff-add-extension-infrastructure' · 4a54877e
      David S. Miller authored
      Florian Westphal says:
      
      ====================
      sk_buff: add extension infrastructure
      
      TL;DR:
       - objdiff shows no change if CONFIG_XFRM=n && BR_NETFILTER=n
       - small size reduction when one or both options are set
       - no changes in ipsec performance
      
       Changes since v1:
       - Allocate entire extension space from a kmem_cache.
       - Avoid atomic_dec_and_test operation on skb_ext_put() for refcnt == 1 case.
         (similar to kfree_skbmem() fclone_ref use).
      
      This adds an optional extension infrastructure, with ispec (xfrm) and
      bridge netfilter as first users.
      
      The third (future) user is Multipath TCP which is still out-of-tree.
      MPTCP needs to map logical mptcp sequence numbers to the tcp sequence
      numbers used by individual subflows.
      
      This DSS mapping is read/written from tcp option space on receive and
      written to tcp option space on transmitted tcp packets that are part of
      and MPTCP connection.
      
      Extending skb_shared_info or adding a private data field to skb fclones
      doesn't work for incoming skb, so a different DSS propagation method would
      be required for the receive side.
      
      mptcp has same requirements as secpath/bridge netfilter:
      
      1. extension memory is released when the sk_buff is free'd.
      2. data is shared after cloning an skb (clone inherits extension)
      3. adding extension to an skb will COW the extension buffer if needed.
      
      Two new members are added to sk_buff:
      1. 'active_extensions' byte (filling a hole), telling which extensions
         are available for this skb.
         This has two purposes.
         a) avoids the need to initialize the pointer.
         b) allows to "delete" an extension by clearing its bit
         value in ->active_extensions.
      
         While it would be possible to store the active_extensions byte
         in the extension struct instead of sk_buff, there is one problem
         with this:
          When an extension has to be disabled, we can always clear the
          bit in skb->active_extensions.  But in case it would be stored in the
          extension buffer itself, we might have to COW it first, if
          we are dealing with a cloned skb.  On kmalloc failure we would
          be unable to turn an extension off.
      2. extension pointer, located at the end of the sk_buff.
         If the active_extensions byte is 0, the pointer is undefined,
         it is not initialized on skb allocation.
      
      This adds extra code to skb clone and free paths (to deal with
      refcount/free of extension area) but this replaces similar code that
      manages skb->nf_bridge and skb->sp structs in the followup patches of
      the series.
      
      It is possible to add support for extensions that are not preseved on
      clones/copies:
      
      1. define a bitmask of all extensions that need copy/cow on clone
      2. change __skb_ext_copy() to check
         ->active_extensions & SKB_EXT_PRESERVE_ON_CLONE
      3. set clone->active_extensions to 0 if test is false.
      
      This isn't done here because all extensions that get added here
      need the copy/cow semantics.
      
      Last patch converts skb->sp, secpath information gets stored as
      new SKB_EXT_SEC_PATH, so the 'sp' pointer is removed from skbuff.
      
      Extra code added to skb clone and free paths (to deal with refcount/free
      of extension area) replaces the existing code that does the same for
      skb->nf_bridge and skb->secpath.
      
      I don't see any other in-tree users that could benefit from this
      infrastructure, it doesn't make sense to add an extension just for the sake
      of a single flag bit (like skb->nf_trace).
      
      Adding a new extension is a good fit if all of the following are true:
      
      1. Data is related to the skb/packet aggregate
      2. Data should be freed when the skb is free'd
      3. Data is not going to be relevant/needed in normal case (udp, tcp,
         forwarding workloads, ...)
      4. There are no fancy action(s) needed on clone/free, such as callbacks
         into kernel modules.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a54877e
    • Florian Westphal's avatar
      net: switch secpath to use skb extension infrastructure · 4165079b
      Florian Westphal authored
      Remove skb->sp and allocate secpath storage via extension
      infrastructure.  This also reduces sk_buff by 8 bytes on x86_64.
      
      Total size of allyesconfig kernel is reduced slightly, as there is
      less inlined code (one conditional atomic op instead of two on
      skb_clone).
      
      No differences in throughput in following ipsec performance tests:
      - transport mode with aes on 10GB link
      - tunnel mode between two network namespaces with aes and null cipher
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4165079b
    • Florian Westphal's avatar
      xfrm: prefer secpath_set over secpath_dup · a84e3f53
      Florian Westphal authored
      secpath_set is a wrapper for secpath_dup that will not perform
      an allocation if the secpath attached to the skb has a reference count
      of one, i.e., it doesn't need to be COW'ed.
      
      Also, secpath_dup doesn't attach the secpath to the skb, it leaves
      this to the caller.
      
      Use secpath_set in places that immediately assign the return value to
      skb.
      
      This allows to remove skb->sp without touching these spots again.
      
      secpath_dup can eventually be removed in followup patch.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a84e3f53
    • Florian Westphal's avatar
      drivers: chelsio: use skb_sec_path helper · a053c866
      Florian Westphal authored
      reduce noise when skb->sp is removed later in the series.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a053c866
    • Florian Westphal's avatar
      xfrm: use secpath_exist where applicable · 26912e37
      Florian Westphal authored
      Will reduce noise when skb->sp is removed later in this series.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26912e37
    • Florian Westphal's avatar
      drivers: net: netdevsim: use skb_sec_path helper · 56d1ac32
      Florian Westphal authored
      ... so this won't have to be changed when skb->sp goes away.
      
      v2: no changes, preserve ack.
      Acked-by: default avatarShannon Nelson <shannon.lee.nelson@gmail.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56d1ac32
    • Florian Westphal's avatar
      drivers: net: ethernet: mellanox: use skb_sec_path helper · 6362a6a0
      Florian Westphal authored
      Will avoid touching this when sp pointer is removed from sk_buff struct.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6362a6a0
    • Florian Westphal's avatar
      drivers: net: intel: use secpath helpers in more places · 2fdb435b
      Florian Westphal authored
      Use skb_sec_path and secpath_exists helpers where possible.
      This reduces noise in followup patch that removes skb->sp pointer.
      
      v2: no changes, preseve acks from v1.
      Acked-by: default avatarShannon Nelson <shannon.lee.nelson@gmail.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fdb435b
    • Florian Westphal's avatar
      net: use skb_sec_path helper in more places · 2294be0f
      Florian Westphal authored
      skb_sec_path gains 'const' qualifier to avoid
      xt_policy.c: 'skb_sec_path' discards 'const' qualifier from pointer target type
      
      same reasoning as previous conversions: Won't need to touch these
      spots anymore when skb->sp is removed.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2294be0f
    • Florian Westphal's avatar
      net: move secpath_exist helper to sk_buff.h · 7af8f4ca
      Florian Westphal authored
      Future patch will remove skb->sp pointer.
      To reduce noise in those patches, move existing helper to
      sk_buff and use it in more places to ease skb->sp replacement later.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7af8f4ca
    • Florian Westphal's avatar
      xfrm: change secpath_set to return secpath struct, not error value · 0ca64da1
      Florian Westphal authored
      It can only return 0 (success) or -ENOMEM.
      Change return value to a pointer to secpath struct.
      
      This avoids direct access to skb->sp:
      
      err = secpath_set(skb);
      if (!err) ..
      skb->sp-> ...
      
      Becomes:
      sp = secpath_set(skb)
      if (!sp) ..
      sp-> ..
      
      This reduces noise in followup patch which is going to remove skb->sp.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ca64da1
    • Florian Westphal's avatar
      net: convert bridge_nf to use skb extension infrastructure · de8bda1d
      Florian Westphal authored
      This converts the bridge netfilter (calling iptables hooks from bridge)
      facility to use the extension infrastructure.
      
      The bridge_nf specific hooks in skb clone and free paths are removed, they
      have been replaced by the skb_ext hooks that do the same as the bridge nf
      allocations hooks did.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de8bda1d