1. 05 Jan, 2018 16 commits
    • Jon Maloy's avatar
      tipc: simplify small window members' sorting algorithm · d84d1b3b
      Jon Maloy authored
      We simplify the sorting algorithm in tipc_update_member(). We also make
      the remaining conditional call to this function unconditional, since the
      same condition now is tested for inside the said function.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d84d1b3b
    • Jon Maloy's avatar
      tipc: some clarifying name changes · 38266ca1
      Jon Maloy authored
      We rename some functions and variables, to make their purpose clearer.
      
      - tipc_group::congested -> tipc_group::small_win. Members in this list
        are not necessarily (and typically) congested. Instead, they may
        *potentially* be subject to congestion because their send window is
        less than ADV_IDLE, and therefore need to be checked during message
        transmission.
      
      - tipc_group_is_receiver() -> tipc_group_is_sender(). This socket will
        accept messages coming from members fulfilling this condition, i.e.,
        they are senders from this member's viewpoint.
      
      - tipc_group_is_enabled() -> tipc_group_is_receiver(). Members
        fulfilling this condition will accept messages sent from the current
        socket, i.e., they are receivers from its viewpoint.
      
      There are no functional changes in this commit.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38266ca1
    • Wei Yongjun's avatar
      net: dsa: lan9303: Fix error return code in lan9303_check_device() · a31e795a
      Wei Yongjun authored
      Fix to return error code -ENODEV from the chip not found error handling
      case instead of 0(ret have been overwritten to 0 by lan9303_read()), as
      done elsewhere in this function.
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarEgil Hjelmeland <privat@egil-hjelmeland.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a31e795a
    • David S. Miller's avatar
      Merge branch 'dsa-Move-padding-into-Broadcom-tagger' · 7892ea23
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: dsa: Move padding into Broadcom tagger
      
      This patch series moves the padding of short packets to where it belongs
      within the DSA Broadcom tagger code, I just found myself doing this for
      a third driver, which was a clear indication this was wrong and did not
      scale.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7892ea23
    • Florian Fainelli's avatar
      net: bgmac: Remove short packet padding for DSA · c979da77
      Florian Fainelli authored
      DSA now correctly pads short packets within net/dsa/tag_brcm.c such that
      this it is no longer necessary to do this within bgmac.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c979da77
    • Florian Fainelli's avatar
      net: systemport: Remove short packet padding · 398aff64
      Florian Fainelli authored
      Short packet padding added to the driver is only necessary when using
      Broadcom tags, but since this is now taken care of net/dsa/tag_brcm.c,
      we are guaranteed being given correctly padded packets.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      398aff64
    • Florian Fainelli's avatar
      net: dsa: Move padding into Broadcom tagger · bf08c340
      Florian Fainelli authored
      Instead of having the different master network device drivers
      potentially used by DSA/Broadcom tags, move the padding necessary for
      the switches to accept short packets where it makes most sense: within
      tag_brcm.c. This avoids multiplying the number of similar commits to
      e.g: bgmac, bcmsysport, etc.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf08c340
    • Quentin Monnet's avatar
      net: sched: fix tcf_block_get_ext() in case CONFIG_NET_CLS is not set · 33c30a8b
      Quentin Monnet authored
      The definition of functions tcf_block_get() and tcf_block_get_ext()
      depends of CONFIG_NET_CLS being set. When those functions gained extack
      support, only one version of the declaration of those functions was
      updated. Function tcf_block_get() was later fixed with commit
      3c149091 ("net: sch: api: fix tcf_block_get").
      
      Change arguments of tcf_block_get_ext() for the case when CONFIG_NET_CLS
      is not set.
      
      Fixes: 8d1a77f9 ("net: sch: api: add extack support in tcf_block_get")
      Signed-off-by: default avatarQuentin Monnet <quentin.monnet@netronome.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33c30a8b
    • Soheil Hassas Yeganeh's avatar
      net: revert "Update RFS target at poll for tcp/udp" · 0a38806f
      Soheil Hassas Yeganeh authored
      On multi-threaded processes, one common architecture is to have
      one (or a small number of) threads polling sockets, and a
      considerably larger pool of threads reading form and writing to the
      sockets. When we set RPS core on tcp_poll() or udp_poll() we essentially
      steer all packets of all the polled FDs to one (or small number of)
      cores, creaing a bottleneck and/or RPS misprediction.
      
      Another common architecture is to shard FDs among threads pinned
      to cores. In such a setting, setting RPS core in tcp_poll() and
      udp_poll() is redundant because the RFS core is correctly
      set in recvmsg and sendmsg.
      
      Thus, revert the following commit:
      c3f1dbaf ("net: Update RFS target at poll for tcp/udp").
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a38806f
    • Soheil Hassas Yeganeh's avatar
      ip: do not set RFS core on error queue reads · e3f2c4a3
      Soheil Hassas Yeganeh authored
      We should only record RPS on normal reads and writes.
      In single threaded processes, all calls record the same state. In
      multi-threaded processes where a separate thread processes
      errors, the RFS table mispredicts.
      
      Note that, when CONFIG_RPS is disabled, sock_rps_record_flow
      is a noop and no branch is added as a result of this patch.
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3f2c4a3
    • David S. Miller's avatar
      Merge branch 'l2tp-remove-configurable-offset-parameters' · 2e40b823
      David S. Miller authored
      James Chapman says:
      
      ====================
      l2tp: remove configurable offset parameters
      
      This patch series removes all code to support a configurable offset in
      transmitted l2tp packets. Code to handle this is incomplete and buggy
      and has been this way for years. If anyone tried to configure an
      offset, it would be ignored for L2TPv2 tunnels, or for L2TPv3 tunnels,
      could result in L2TPv3 packets being transmitted which are not
      compliant with L2TPv3 RFC3931. This patch series removes the support
      for configurable offsets.
      
      No known userspace l2tp daemon configures an offset. However,
      iproute2's "ip l2tp" command has an offset parameter and if set, the
      value is passed to the kernel. This is the most likely use case where
      offsets might be configured, e.g.
      
         ip l2tp add tunnel local 1.1.1.1 remote 1.1.1.2 tunnel_id 1 \
             peer_tunnel_id 2 encap ip
         ip l2tp add session name l2tp0 tunnel_id 1 session_id 1 \
             peer_session_id 2 offset 8
      
      The above would result in packets being transmitted to 1.1.1.2 with 8
      bytes padding between the L2TPv3 header and the payload. The peer
      would need to be configured with the same offset value. However, the
      packets are not compliant with the L2TPv3 RFC, hence I think it's
      unlikely that offset is being used. With this patch series applied,
      the offset would not be configured. The peer would need to be modified to
      remove its offset setting too.
      
      iproute2 should be modified to remove or ignore the ip l2tp offset
      parameter.
      
      This issue was discovered when reviewing a patch series from
      lorenzo.bianconi@redhat.com which adds another netlink attribute to
      configure the expected offset in received L2TPv3 packets. This change
      is reverted by this series because offsets do not exist in L2TPv3
      packets. These commits are:
      
        commit f15bc54e ("l2tp: add peer_offset parameter")
        commit 820da535 ("l2tp: fix missing print session offset info")
      
      In more detail:
      
      The L2TPv2 protocol supports a variable offset from the L2TPv2 header
      to the payload to give the sender implementation some flexibility for
      data alignment when adding L2TP headers on to payloads. The offset
      value is indicated by an optional field in the L2TP header.  Our L2TP
      implementation already detects the presence of the optional offset in
      received packets and skips those bytes when parsing packets. All
      transmitted L2TPv2 packets are always transmitted with no offset.
      
      L2TPv3 has no optional offset field in the L2TPv3 packet
      header. Instead, L2TPv3 defines optional fields in a "Layer-2 Specific
      Sublayer". At the time when the original L2TP code was written, there
      was talk at IETF of offset being implemented in a new Layer-2 Specific
      Sublayer. A L2TP_ATTR_OFFSET netlink attribute was added so that this
      offset could be configured and the intention was to allow it to be
      also used to set the tx offset for L2TPv2. However, no L2TPv3 offset
      was ever specified and the L2TP_ATTR_OFFSET parameter was forgotten
      about.
      
      Setting L2TP_ATTR_OFFSET results in L2TPv3 packets being transmitted
      with the specified number of bytes padding between L2TPv3 header and
      payload. This is not compliant with L2TPv3 RFC3931. So this change
      removes the configurable offset altogether while retaining
      L2TP_ATTR_OFFSET in the API for backwards compatibility. If
      L2TP_ATTR_OFFSET is given, its value is now silently ignored.
      ====================
      Reviewed-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Tested-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e40b823
    • James Chapman's avatar
    • James Chapman's avatar
      l2tp: remove configurable payload offset · 900631ee
      James Chapman authored
      If L2TP_ATTR_OFFSET is set to a non-zero value in L2TPv3 tunnels, it
      results in L2TPv3 packets being transmitted which might not be
      compliant with the L2TPv3 RFC. This patch has l2tp ignore the offset
      setting and send all packets with no offset.
      
      In more detail:
      
      L2TPv2 supports a variable offset from the L2TPv2 header to the
      payload. The offset value is indicated by an optional field in the
      L2TP header.  Our L2TP implementation already detects the presence of
      the optional offset and skips that many bytes when handling data
      received packets. All transmitted packets are always transmitted with
      no offset.
      
      L2TPv3 has no optional offset field in the L2TPv3 packet
      header. Instead, L2TPv3 defines optional fields in a "Layer-2 Specific
      Sublayer". At the time when the original L2TP code was written, there
      was talk at IETF of offset being implemented in a new Layer-2 Specific
      Sublayer. A L2TP_ATTR_OFFSET netlink attribute was added so that this
      offset could be configured and the intention was to allow it to be
      also used to set the tx offset for L2TPv2. However, no L2TPv3 offset
      was ever specified and the L2TP_ATTR_OFFSET parameter was forgotten
      about.
      
      Setting L2TP_ATTR_OFFSET results in L2TPv3 packets being transmitted
      with the specified number of bytes padding between L2TPv3 header and
      payload. This is not compliant with L2TPv3 RFC3931. This change
      removes the configurable offset altogether while retaining
      L2TP_ATTR_OFFSET for backwards compatibility. Any L2TP_ATTR_OFFSET
      value is ignored.
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      900631ee
    • James Chapman's avatar
      l2tp: revert "l2tp: fix missing print session offset info" · de3b58bc
      James Chapman authored
      Revert commit 820da535 ("l2tp: fix missing print session offset
      info").  The peer_offset parameter is removed.
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de3b58bc
    • James Chapman's avatar
      l2tp: revert "l2tp: add peer_offset parameter" · 863def15
      James Chapman authored
      Revert commit f15bc54e ("l2tp: add peer_offset parameter"). This
      is removed because it is adding another configurable offset and
      configurable offsets are being removed.
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      863def15
    • Arnd Bergmann's avatar
      net/mlx5e: hide an unused variable · 74bd5d56
      Arnd Bergmann authored
      The uplink_rpriv variable was added at the start of the function but
      only used inside of an #ifdef:
      
      drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 'mlx5e_route_lookup_ipv6':
      drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:1549:25: error: unused variable 'uplink_rpriv' [-Werror=unused-variable]
      
      This moves the declaration into that #ifdef as well.
      
      Fixes: 5ed99fb4 ("net/mlx5e: Move ethernet representors data into separate struct")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74bd5d56
  2. 04 Jan, 2018 6 commits
  3. 03 Jan, 2018 18 commits