1. 09 12月, 2020 4 次提交
  2. 02 12月, 2020 4 次提交
  3. 29 9月, 2020 1 次提交
  4. 24 8月, 2020 1 次提交
  5. 27 2月, 2020 1 次提交
  6. 21 2月, 2020 2 次提交
  7. 18 2月, 2020 4 次提交
  8. 05 10月, 2019 1 次提交
  9. 18 7月, 2019 1 次提交
    • I
      mlxsw: spectrum: Do not process learned records with a dummy FID · 577fa14d
      Ido Schimmel 提交于
      The switch periodically sends notifications about learned FDB entries.
      Among other things, the notification includes the FID (Filtering
      Identifier) and the port on which the MAC was learned.
      
      In case the driver does not have the FID defined on the relevant port,
      the following error will be periodically generated:
      
      mlxsw_spectrum2 0000:06:00.0 swp32: Failed to find a matching {Port, VID} following FDB notification
      
      This is not supposed to happen under normal conditions, but can happen
      if an ingress tc filter with a redirect action is installed on a bridged
      port. The redirect action will cause the packet's FID to be changed to
      the dummy FID and a learning notification will be emitted with this FID
      - which is not defined on the bridged port.
      
      Fix this by having the driver ignore learning notifications generated
      with the dummy FID and delete them from the device.
      
      Another option is to chain an ignore action after the redirect action
      which will cause the device to disable learning, but this means that we
      need to consume another action whenever a redirect action is used. In
      addition, the scenario described above is merely a corner case.
      
      Fixes: cedbb8b2 ("mlxsw: spectrum_flower: Set dummy FID before forward action")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Tested-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      577fa14d
  10. 11 4月, 2019 1 次提交
    • I
      mlxsw: spectrum_switchdev: Add MDB entries in prepare phase · d4d0e409
      Ido Schimmel 提交于
      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>
      d4d0e409
  11. 28 2月, 2019 2 次提交
  12. 22 2月, 2019 3 次提交
  13. 13 2月, 2019 2 次提交
  14. 07 2月, 2019 1 次提交
  15. 29 1月, 2019 1 次提交
  16. 19 1月, 2019 1 次提交
  17. 18 1月, 2019 2 次提交
  18. 09 1月, 2019 2 次提交
  19. 21 12月, 2018 3 次提交
  20. 20 12月, 2018 2 次提交
    • I
      mlxsw: spectrum: Properly cleanup LAG uppers when removing port from LAG · be2d6f42
      Ido Schimmel 提交于
      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>
      be2d6f42
    • I
      mlxsw: spectrum: Remove reference count from VLAN entries · 635c8c8b
      Ido Schimmel 提交于
      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: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      635c8c8b
  21. 13 12月, 2018 1 次提交
    • P
      mlxsw: spectrum_switchdev: Propagate extack on port VLAN events · 7357eb3d
      Petr Machata 提交于
      After switchdev_handle_port_obj_add() was extended in a preceding patch,
      mlxsw_sp_port_obj_add() now takes an extack argument. Propagate it
      further by extending a callee chain from mlxsw_sp_port_vlans_add(), via
      mlxsw_sp_bridge_port_vlan_add() via mlxsw_sp_port_vlan_bridge_join() via
      mlxsw_sp_port_vlan_fid_join() to mlxsw_sp_bridge_ops.fid_get, adding an
      extack argument for each of them.
      
      This code path is used when a VLAN is added to a port netdevice if there
      already is an unoffloadable VXLAN device with that VLAN mapped.
      
      mlxsw_sp_bridge_8021d_port_join() is updated to obey the new interfaces
      changed by the abovementioned code, propagating extack ultimately from
      NETDEV_CHANGEUPPER events.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7357eb3d