1. 17 5月, 2019 1 次提交
    • I
      mlxsw: spectrum_switchdev: Add MDB entries in prepare phase · a80f62f7
      Ido Schimmel 提交于
      [ Upstream commit d4d0e40977ac450f32f2db5e4d8e23c9d2578899 ]
      
      The driver cannot guarantee in the prepare phase that it will be able to
      write an MDB entry to the device. In case the driver returned success
      during the prepare phase, but then failed to add the entry in the commit
      phase, a WARNING [1] will be generated by the switchdev core.
      
      Fix this by doing the work in the prepare phase instead.
      
      [1]
      [  358.544486] swp12s0: Commit of object (id=2) failed.
      [  358.550061] WARNING: CPU: 0 PID: 30 at net/switchdev/switchdev.c:281 switchdev_port_obj_add_now+0x9b/0xe0
      [  358.560754] CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 5.0.0-custom-13382-gf2449babf221 #1350
      [  358.570472] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
      [  358.580582] Workqueue: events switchdev_deferred_process_work
      [  358.587001] RIP: 0010:switchdev_port_obj_add_now+0x9b/0xe0
      ...
      [  358.614109] RSP: 0018:ffffa6b900d6fe18 EFLAGS: 00010286
      [  358.619943] RAX: 0000000000000000 RBX: ffff8b00797ff000 RCX: 0000000000000000
      [  358.627912] RDX: ffff8b00b7a1d4c0 RSI: ffff8b00b7a152e8 RDI: ffff8b00b7a152e8
      [  358.635881] RBP: ffff8b005c3f5bc0 R08: 000000000000022b R09: 0000000000000000
      [  358.643850] R10: 0000000000000000 R11: ffffa6b900d6fcc8 R12: 0000000000000000
      [  358.651819] R13: dead000000000100 R14: ffff8b00b65a23c0 R15: 0ffff8b00b7a2200
      [  358.659790] FS:  0000000000000000(0000) GS:ffff8b00b7a00000(0000) knlGS:0000000000000000
      [  358.668820] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  358.675228] CR2: 00007f00aad90de0 CR3: 00000001ca80d000 CR4: 00000000001006f0
      [  358.683188] Call Trace:
      [  358.685918]  switchdev_port_obj_add_deferred+0x13/0x60
      [  358.691655]  switchdev_deferred_process+0x6b/0xf0
      [  358.696907]  switchdev_deferred_process_work+0xa/0x10
      [  358.702548]  process_one_work+0x1f5/0x3f0
      [  358.707022]  worker_thread+0x28/0x3c0
      [  358.711099]  ? process_one_work+0x3f0/0x3f0
      [  358.715768]  kthread+0x10d/0x130
      [  358.719369]  ? __kthread_create_on_node+0x180/0x180
      [  358.724815]  ret_from_fork+0x35/0x40
      
      Fixes: 3a49b4fd ("mlxsw: Adding layer 2 multicast support")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Tested-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <alexander.levin@microsoft.com>
      a80f62f7
  2. 02 5月, 2019 3 次提交
  3. 06 4月, 2019 1 次提交
    • F
      mlxsw: spectrum: Avoid -Wformat-truncation warnings · a64ffbaf
      Florian Fainelli 提交于
      [ Upstream commit ab2c4e2581ad32c28627235ff0ae8c5a5ea6899f ]
      
      Give precision identifiers to the two snprintf() formatting the priority
      and TC strings to avoid producing these two warnings:
      
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
      'mlxsw_sp_port_get_prio_strings':
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:37: warning: '%d'
      directive output may be truncated writing between 1 and 3 bytes into a
      region of size between 0 and 31 [-Wformat-truncation=]
         snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
                                           ^~
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:3: note: 'snprintf'
      output between 3 and 36 bytes into a destination of size 32
         snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           mlxsw_sp_port_hw_prio_stats[i].str, prio);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
      'mlxsw_sp_port_get_tc_strings':
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:37: warning: '%d'
      directive output may be truncated writing between 1 and 11 bytes into a
      region of size between 0 and 31 [-Wformat-truncation=]
         snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
                                           ^~
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:3: note: 'snprintf'
      output between 3 and 44 bytes into a destination of size 32
         snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           mlxsw_sp_port_hw_tc_stats[i].str, tc);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a64ffbaf
  4. 27 2月, 2019 3 次提交
  5. 23 2月, 2019 1 次提交
  6. 13 2月, 2019 2 次提交
    • I
      mlxsw: spectrum: Properly cleanup LAG uppers when removing port from LAG · b124f086
      Ido Schimmel 提交于
      [ Upstream commit be2d6f421f680e01d58f7cd452646e0d8586d49b ]
      
      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: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b124f086
    • N
      mlxsw: spectrum_acl: Limit priority value · 702286d3
      Nir Dotan 提交于
      [ Upstream commit d7263ab35be25505ab57ebecd93cbc5dba8be717 ]
      
      In Spectrum-2, higher priority value wins and priority valid values are in
      the range of {1,cap_kvd_size-1}. mlxsw_sp_acl_tcam_priority_get converts
      from lower-bound priorities alike tc flower to Spectrum-2 HW range. Up
      until now tc flower did not provide priority 0 or reached the maximal
      value, however multicast routing does provide priority 0.
      
      Therefore, Change mlxsw_sp_acl_tcam_priority_get to verify priority is in
      the correct range. Make sure priority is never set to zero and never
      exceeds the maximal allowed value.
      Signed-off-by: NNir Dotan <nird@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      702286d3
  7. 31 1月, 2019 3 次提交
    • I
      mlxsw: pci: Ring CQ's doorbell before RDQ's · bdafc159
      Ido Schimmel 提交于
      When a packet should be trapped to the CPU the device consumes a WQE
      (work queue element) from an RDQ (receive descriptor queue) and copies
      the packet to the address specified in the WQE. The device then tries to
      post a CQE (completion queue element) that contains various metadata
      (e.g., ingress port) about the packet to a CQ (completion queue).
      
      In case the device managed to consume a WQE, but did not manage to post
      the corresponding CQE, it will get stuck. This unlikely situation can be
      triggered due to the scheme the driver is currently using to process
      CQEs.
      
      The driver will consume up to 512 CQEs at a time and after processing
      each corresponding WQE it will ring the RDQ's doorbell, letting the
      device know that a new WQE was posted for it to consume. Only after
      processing all the CQEs (up to 512), the driver will ring the CQ's
      doorbell, letting the device know that new ones can be posted.
      
      Fix this by having the driver ring the CQ's doorbell for every processed
      CQE, but before ringing the RDQ's doorbell. This guarantees that
      whenever we post a new WQE, there is a corresponding CQE available. Copy
      the currently processed CQE to prevent the device from overwriting it
      with a new CQE after ringing the doorbell.
      
      Note that the driver still arms the CQ only after processing all the
      pending CQEs, so that interrupts for this CQ will only be delivered
      after the driver finished its processing.
      
      Before commit 8404f6f2 ("mlxsw: pci: Allow to use CQEs of version 1
      and version 2") the issue was virtually impossible to trigger since the
      number of CQEs was twice the number of WQEs and the number of CQEs
      processed at a time was equal to the number of available WQEs.
      
      Fixes: 8404f6f2 ("mlxsw: pci: Allow to use CQEs of version 1 and version 2")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NSemion Lisyansky <semionl@mellanox.com>
      Tested-by: NSemion Lisyansky <semionl@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdafc159
    • N
      mlxsw: spectrum_fid: Update dummy FID index · c82f4684
      Nir Dotan 提交于
      [ Upstream commit a11dcd6497915ba79d95ef4fe2541aaac27f6201 ]
      
      When using a tc flower action of egress mirred redirect, the driver adds
      an implicit FID setting action. This implicit action sets a dummy FID to
      the packet and is used as part of a design for trapping unmatched flows
      in OVS.  While this implicit FID setting action is supposed to be a NOP
      when a redirect action is added, in Spectrum-2 the FID record is
      consulted as the dummy FID index is an 802.1D FID index and the packet
      is dropped instead of being redirected.
      
      Set the dummy FID index value to be within 802.1Q range. This satisfies
      both Spectrum-1 which ignores the FID and Spectrum-2 which identifies it
      as an 802.1Q FID and will then follow the redirect action.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Signed-off-by: NNir Dotan <nird@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c82f4684
    • N
      mlxsw: pci: Increase PCI SW reset timeout · bc4e2300
      Nir Dotan 提交于
      [ Upstream commit d2f372ba0914e5722ac28e15f2ed2db61bcf0e44 ]
      
      Spectrum-2 PHY layer introduces a calibration period which is a part of the
      Spectrum-2 firmware boot process. Hence increase the SW timeout waiting for
      the firmware to come out of boot. This does not increase system boot time
      in cases where the firmware PHY calibration process is done quickly.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Signed-off-by: NNir Dotan <nird@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc4e2300
  8. 26 1月, 2019 2 次提交
  9. 10 1月, 2019 1 次提交
    • S
      mlxsw: core: Increase timeout during firmware flash process · af93ac09
      Shalom Toledo 提交于
      [ Upstream commit cf0b70e71b32137ccf9c1f3dd9fb30cbf89b4322 ]
      
      During the firmware flash process, some of the EMADs get timed out, which
      causes the driver to send them again with a limit of 5 retries. There are
      some situations in which 5 retries is not enough and the EMAD access fails.
      If the failed EMAD was related to the flashing process, the driver fails
      the flashing.
      
      The reason for these timeouts during firmware flashing is cache misses in
      the CPU running the firmware. In case the CPU needs to fetch instructions
      from the flash when a firmware is flashed, it needs to wait for the
      flashing to complete. Since flashing takes time, it is possible for pending
      EMADs to timeout.
      
      Fix by increasing EMADs' timeout while flashing firmware.
      
      Fixes: ce6ef68f ("mlxsw: spectrum: Implement the ethtool flash_device callback")
      Signed-off-by: NShalom Toledo <shalomt@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af93ac09
  10. 21 12月, 2018 1 次提交
    • I
      mlxsw: spectrum_switchdev: Fix VLAN device deletion via ioctl · 8175f9d3
      Ido Schimmel 提交于
      [ Upstream commit 993107fea5eefdfdfde1ca38d3f01f0bebf76e77 ]
      
      When deleting a VLAN device using an ioctl the netdev is unregistered
      before the VLAN filter is updated via ndo_vlan_rx_kill_vid(). It can
      lead to a use-after-free in mlxsw in case the VLAN device is deleted
      while being enslaved to a bridge.
      
      The reason for the above is that when mlxsw receives the CHANGEUPPER
      event, it wrongly assumes that the VLAN device is no longer its upper
      and thus destroys the internal representation of the bridge port despite
      the reference count being non-zero.
      
      Fix this by checking if the VLAN device is our upper using its real
      device. In net-next I'm going to remove this trick and instead make
      mlxsw completely agnostic to the order of the events.
      
      Fixes: c57529e1 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8175f9d3
  11. 23 11月, 2018 1 次提交
  12. 04 11月, 2018 2 次提交
  13. 18 10月, 2018 1 次提交
  14. 05 10月, 2018 2 次提交
  15. 20 9月, 2018 1 次提交
  16. 05 9月, 2018 1 次提交
    • P
      mlxsw: spectrum_buffers: Set up a dedicated pool for BUM traffic · 3a3539cd
      Petr Machata 提交于
      MC-aware mode was recently enabled by mlxsw on Spectrum switches in
      commit 7b819530 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw
      ports"). Unfortunately, testing has shown that the fix is incomplete and
      in the presented form actually makes the problem even worse, because any
      amount of MC traffic causes UC disruption.
      
      The reason for this is that currently, mlxsw configures the MC-specific
      TCs (8..15) to map to pool 0. It also configures a maximum buffer size
      of 0, but for MC traffic that maximum is disregarded and not part of the
      quota. Therefore MC traffic is always admitted to the egress buffer.
      
      Fix the configuration by directing the MC TCs into pool 15, which is
      dedicated to MC traffic and recognized as such by the silicon.
      
      Fixes: 7b819530 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw ports")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a3539cd
  17. 26 8月, 2018 1 次提交
    • I
      mlxsw: spectrum_switchdev: Do not leak RIFs when removing bridge · 602b74ed
      Ido Schimmel 提交于
      When a bridge device is removed, the VLANs are flushed from each
      configured port. This causes the ports to decrement the reference count
      on the associated FIDs (filtering identifier). If the reference count of
      a FID is 1 and it has a RIF (router interface), then this RIF is
      destroyed.
      
      However, if no port is member in the VLAN for which a RIF exists, then
      the RIF will continue to exist after the removal of the bridge. To
      reproduce:
      
      # ip link add name br0 type bridge vlan_filtering 1
      # ip link set dev swp1 master br0
      # ip link add link br0 name br0.10 type vlan id 10
      # ip address add 192.0.2.0/24 dev br0.10
      # ip link del dev br0
      
      The RIF associated with br0.10 continues to exist.
      
      Fix this by iterating over all the bridge device uppers when it is
      destroyed and take care of destroying their RIFs.
      
      Fixes: 99f44bb3 ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      602b74ed
  18. 22 8月, 2018 1 次提交
  19. 11 8月, 2018 2 次提交
  20. 10 8月, 2018 7 次提交
  21. 06 8月, 2018 3 次提交