1. 05 Apr, 2021 5 commits
  2. 02 Apr, 2021 3 commits
  3. 01 Apr, 2021 17 commits
  4. 31 Mar, 2021 15 commits
    • Ong Boon Leong's avatar
      xdp: fix xdp_return_frame() kernel BUG throw for page_pool memory model · 622d1369
      Ong Boon Leong authored
      xdp_return_frame() may be called outside of NAPI context to return
      xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
      napi_direct = false. For page_pool memory model, __xdp_return() calls
      xdp_return_frame_no_direct() unconditionally and below false negative
      kernel BUG throw happened under preempt-rt build:
      
      [  430.450355] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/3884
      [  430.451678] caller is __xdp_return+0x1ff/0x2e0
      [  430.452111] CPU: 0 PID: 3884 Comm: modprobe Tainted: G     U      E     5.12.0-rc2+ #45
      
      Changes in v2:
       - This patch fixes the issue by making xdp_return_frame_no_direct() is
         only called if napi_direct = true, as recommended for better by
         Jesper Dangaard Brouer. Thanks!
      
      Fixes: 2539650f ("xdp: Helpers for disabling napi_direct of xdp_return_frame")
      Signed-off-by: default avatarOng Boon Leong <boon.leong.ong@intel.com>
      Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      622d1369
    • Eric Dumazet's avatar
      Revert "net: correct sk_acceptq_is_full()" · c609e6aa
      Eric Dumazet authored
      This reverts commit f211ac15.
      
      We had similar attempt in the past, and we reverted it.
      
      History:
      
      64a14651 [NET]: Revert incorrect accept queue backlog changes.
      8488df89 [NET]: Fix bugs in "Whether sock accept queue is full" checking
      
      I am adding a fat comment so that future attempts will
      be much harder.
      
      Fixes: f211ac15 ("net: correct sk_acceptq_is_full()")
      Cc: iuyacan <yacanliu@163.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c609e6aa
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2021-03-31' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 9dc22c0d
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5 fixes 2021-03-31
      
      This series introduces some fixes to mlx5 driver.
      Please pull and let me know if there is any problem.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9dc22c0d
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · c9170f13
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2021-03-31
      
      1) Fix ipv4 pmtu checks for xfrm anf vti interfaces.
         From Eyal Birger.
      
      2) There are situations where the socket passed to
         xfrm_output_resume() is not the same as the one
         attached to the skb. Use the socket passed to
         xfrm_output_resume() to avoid lookup failures
         when xfrm is used with VRFs.
         From Evan Nimmo.
      
      3) Make the xfrm_state_hash_generation sequence counter per
         network namespace because but its write serialization
         lock is also per network namespace. Write protection
         is insufficient otherwise.
         From Ahmed S. Darwish.
      
      4) Fixup sctp featue flags when used with esp offload.
         From Xin Long.
      
      5) xfrm BEET mode doesn't support fragments for inner packets.
         This is a limitation of the protocol, so no fix possible.
         Warn at least to notify the user about that situation.
         From Xin Long.
      
      6) Fix NULL pointer dereference on policy lookup when
         namespaces are uses in combination with esp offload.
      
      7) Fix incorrect transformation on esp offload when
         packets get segmented at layer 3.
      
      8) Fix some user triggered usages of WARN_ONCE in
         the xfrm compat layer.
         From Dmitry Safonov.
      
      Please pull or let me know if there are problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9170f13
    • Lv Yunlong's avatar
      net/rds: Fix a use after free in rds_message_map_pages · bdc2ab5c
      Lv Yunlong authored
      In rds_message_map_pages, the rm is freed by rds_message_put(rm).
      But rm is still used by rm->data.op_sg in return value.
      
      My patch assigns ERR_CAST(rm->data.op_sg) to err before the rm is
      freed to avoid the uaf.
      
      Fixes: 7dba9203 ("net/rds: Use ERR_PTR for rds_message_alloc_sgs()")
      Signed-off-by: default avatarLv Yunlong <lyl2019@mail.ustc.edu.cn>
      Reviewed-by: default avatarHåkon Bugge <haakon.bugge@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bdc2ab5c
    • Tong Zhu's avatar
      neighbour: Disregard DEAD dst in neigh_update · d47ec7a0
      Tong Zhu authored
      After a short network outage, the dst_entry is timed out and put
      in DST_OBSOLETE_DEAD. We are in this code because arp reply comes
      from this neighbour after network recovers. There is a potential
      race condition that dst_entry is still in DST_OBSOLETE_DEAD.
      With that, another neighbour lookup causes more harm than good.
      
      In best case all packets in arp_queue are lost. This is
      counterproductive to the original goal of finding a better path
      for those packets.
      
      I observed a worst case with 4.x kernel where a dst_entry in
      DST_OBSOLETE_DEAD state is associated with loopback net_device.
      It leads to an ethernet header with all zero addresses.
      A packet with all zero source MAC address is quite deadly with
      mac80211, ath9k and 802.11 block ack.  It fails
      ieee80211_find_sta_by_ifaddr in ath9k (xmit.c). Ath9k flushes tx
      queue (ath_tx_complete_aggr). BAW (block ack window) is not
      updated. BAW logic is damaged and ath9k transmission is disabled.
      Signed-off-by: default avatarTong Zhu <zhutong@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d47ec7a0
    • Tariq Toukan's avatar
      net/mlx5e: Guarantee room for XSK wakeup NOP on async ICOSQ · 3ff3874f
      Tariq Toukan authored
      XSK wakeup flow triggers an IRQ by posting a NOP WQE and hitting
      the doorbell on the async ICOSQ.
      It maintains its state so that it doesn't issue another NOP WQE
      if it has an outstanding one already.
      
      For this flow to work properly, the NOP post must not fail.
      Make sure to reserve room for the NOP WQE in all WQE posts to the
      async ICOSQ.
      
      Fixes: 8d94b590 ("net/mlx5e: Turn XSK ICOSQ into a general asynchronous one")
      Fixes: 1182f365 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
      Fixes: 0419d8c9 ("net/mlx5e: kTLS, Add kTLS RX resync support")
      Signed-off-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Reviewed-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      3ff3874f
    • Dima Chumak's avatar
      net/mlx5e: Consider geneve_opts for encap contexts · 929a2fad
      Dima Chumak authored
      Current algorithm for encap keys is legacy from initial vxlan
      implementation and doesn't take into account all possible fields of a
      tunnel. For example, for a Geneve tunnel, which may have additional TLV
      options, they are ignored when comparing encap keys and a rule can be
      attached to an incorrect encap entry.
      
      Fix that by introducing encap_info_equal() operation in
      struct mlx5e_tc_tunnel. Geneve tunnel type uses custom implementation,
      which extends generic algorithm and considers options if they are set.
      
      Fixes: 7f1a546e ("net/mlx5e: Consider tunnel type for encap contexts")
      Signed-off-by: default avatarDima Chumak <dchumak@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      929a2fad
    • Daniel Jurgens's avatar
      net/mlx5: Don't request more than supported EQs · a7b76002
      Daniel Jurgens authored
      Calculating the number of compeltion EQs based on the number of
      available IRQ vectors doesn't work now that all async EQs share one IRQ.
      Thus the max number of EQs can be exceeded on systems with more than
      approximately 256 CPUs. Take this into account when calculating the
      number of available completion EQs.
      
      Fixes: 81bfa206 ("net/mlx5: Use a single IRQ for all async EQs")
      Signed-off-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: default avatarParav Pandit <parav@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      a7b76002
    • Tariq Toukan's avatar
      net/mlx5e: kTLS, Fix RX counters atomicity · 6f4fdd53
      Tariq Toukan authored
      Some TLS RX counters increment per socket/connection, and are not
      protected against parallel modifications from several cores.
      Switch them to atomic counters by taking them out of the RQ stats into
      the global atomic TLS stats.
      
      In this patch, we touch 'rx_tls_ctx/del' that count the number of
      device-offloaded RX TLS connections added/deleted.
      These counters are updated in the add/del callbacks, out of the fast
      data-path.
      
      This change is not needed for counters that increment only in NAPI
      context, as they are protected by the NAPI mechanism.
      Keep them as tls_* counters under 'struct mlx5e_rq_stats'.
      
      Fixes: 76c1e1ac ("net/mlx5e: kTLS, Add kTLS RX stats")
      Signed-off-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Reviewed-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      6f4fdd53
    • Tariq Toukan's avatar
      net/mlx5e: kTLS, Fix TX counters atomicity · a51bce96
      Tariq Toukan authored
      Some TLS TX counters increment per socket/connection, and are not
      protected against parallel modifications from several cores.
      Switch them to atomic counters by taking them out of the SQ stats into
      the global atomic TLS stats.
      
      In this patch, we touch a single counter 'tx_tls_ctx' that counts the
      number of device-offloaded TX TLS connections added.
      Now that this counter can be increased without the for having the SQ
      context in hand, move it to the mlx5e_ktls_add_tx() callback where it
      really belongs, out of the fast data-path.
      
      This change is not needed for counters that increment only in NAPI
      context or under the TX lock, as they are already protected.
      Keep them as tls_* counters under 'struct mlx5e_sq_stats'.
      
      Fixes: d2ead1f3 ("net/mlx5e: Add kTLS TX HW offload support")
      Signed-off-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Reviewed-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      a51bce96
    • Maor Dickman's avatar
      net/mlx5: E-switch, Create vport miss group only if src rewrite is supported · e929e3da
      Maor Dickman authored
      Create send to vport miss group was added in order to support traffic
      recirculation to root table with metadata source rewrite.
      This group is created also in case source rewrite isn't supported.
      
      Fixed by creating send to vport miss group only if source rewrite is
      supported by FW.
      
      Fixes: 8e404fef ("net/mlx5e: Match recirculated packet miss in slow table using reg_c1")
      Signed-off-by: default avatarMaor Dickman <maord@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      e929e3da
    • Aya Levin's avatar
      net/mlx5e: Fix ethtool indication of connector type · 3211434d
      Aya Levin authored
      Use connector_type read from PTYS register when it's valid, based on
      corresponding capability bit.
      
      Fixes: 5b4793f8 ("net/mlx5e: Add support for reading connector type from PTYS")
      Signed-off-by: default avatarAya Levin <ayal@nvidia.com>
      Reviewed-by: default avatarEran Ben Elisha <eranbe@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      3211434d
    • Maor Dickman's avatar
      net/mlx5: Delete auxiliary bus driver eth-rep first · 1f90aedf
      Maor Dickman authored
      Delete auxiliary bus drivers flow deletes the eth driver
      first and then the eth-reps driver but eth-reps devices resources
      are depend on eth device.
      
      Fixed by changing the delete order of auxiliary bus drivers to delete
      the eth-rep driver first and after it the eth driver.
      
      Fixes: 601c10c8 ("net/mlx5: Delete custom device management logic")
      Signed-off-by: default avatarMaor Dickman <maord@nvidia.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      1f90aedf
    • Ariel Levkovich's avatar
      net/mlx5e: Fix mapping of ct_label zero · d24f847e
      Ariel Levkovich authored
      ct_label 0 is a default label each flow has and therefore
      there can be rules that match on ct_label=0 without a prior
      rule that set the ct_label to this value.
      
      The ct_label value is not used directly in the HW rules and
      instead it is mapped to some id within a defined range and this
      id is used to set and match the metadata register which carries
      the ct_label.
      
      If we have a rule that matches on ct_label=0, the hw rule will
      perform matching on a value that is != 0 because of the mapping
      from label to id. Since the metadata register default value is
      0 and it was never set before to anything else by an action that
      sets the ct_label, there will always be a mismatch between that
      register and the value in the rule.
      
      To support such rule, a forced mapping of ct_label 0 to id=0
      is done so that it will match the metadata register default
      value of 0.
      
      Fixes: 54b154ec ("net/mlx5e: CT: Map 128 bits labels to 32 bit map ID")
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      d24f847e