1. 30 7月, 2020 1 次提交
  2. 02 6月, 2020 6 次提交
  3. 15 5月, 2020 1 次提交
  4. 05 5月, 2020 3 次提交
  5. 02 5月, 2020 1 次提交
    • J
      devlink: fix return value after hitting end in region read · 610a9346
      Jakub Kicinski 提交于
      Commit d5b90e99 ("devlink: report 0 after hitting end in region read")
      fixed region dump, but region read still returns a spurious error:
      
      $ devlink region read netdevsim/netdevsim1/dummy snapshot 0 addr 0 len 128
      0000000000000000 a6 f4 c4 1c 21 35 95 a6 9d 34 c3 5b 87 5b 35 79
      0000000000000010 f3 a0 d7 ee 4f 2f 82 7f c6 dd c4 f6 a5 c3 1b ae
      0000000000000020 a4 fd c8 62 07 59 48 03 70 3b c7 09 86 88 7f 68
      0000000000000030 6f 45 5d 6d 7d 0e 16 38 a9 d0 7a 4b 1e 1e 2e a6
      0000000000000040 e6 1d ae 06 d6 18 00 85 ca 62 e8 7e 11 7e f6 0f
      0000000000000050 79 7e f7 0f f3 94 68 bd e6 40 22 85 b6 be 6f b1
      0000000000000060 af db ef 5e 34 f0 98 4b 62 9a e3 1b 8b 93 fc 17
      devlink answers: Invalid argument
      0000000000000070 61 e8 11 11 66 10 a5 f7 b1 ea 8d 40 60 53 ed 12
      
      This is a minimal fix, I'll follow up with a restructuring
      so we don't have two checks for the same condition.
      
      Fixes: fdd41ec2 ("devlink: Return right error code in case of errors for region read")
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      610a9346
  6. 31 3月, 2020 6 次提交
  7. 27 3月, 2020 9 次提交
  8. 26 3月, 2020 1 次提交
    • P
      devlink: Rely on driver eswitch thread safety instead of devlink · 98fed6eb
      Parav Pandit 提交于
      devlink_nl_cmd_eswitch_set_doit() doesn't hold devlink->lock mutex while
      invoking driver callback. This is likely due to eswitch mode setting
      involves adding/remove devlink ports, health reporters or
      other devlink objects for a devlink device.
      
      So it is driver responsiblity to ensure thread safe eswitch state
      transition happening via either sriov legacy enablement or via devlink
      eswitch set callback.
      
      Therefore, get() callback should also be invoked without holding
      devlink->lock mutex.
      Vendor driver can use same internal lock which it uses during eswitch
      mode set() callback.
      This makes get() and set() implimentation symmetric in devlink core and
      in vendor drivers.
      
      Hence, remove holding devlink->lock mutex during eswitch get() callback.
      
      Failing to do so results into below deadlock scenario when mlx5_core
      driver is improved to handle eswitch mode set critical section invoked
      by devlink and sriov sysfs interface in subsequent patch.
      
      devlink_nl_cmd_eswitch_set_doit()
         mlx5_eswitch_mode_set()
           mutex_lock(esw->mode_lock) <- Lock A
           [...]
           register_devlink_port()
             mutex_lock(&devlink->lock); <- lock B
      
      mutex_lock(&devlink->lock); <- lock B
      devlink_nl_cmd_eswitch_get_doit()
         mlx5_eswitch_mode_get()
         mutex_lock(esw->mode_lock) <- Lock A
      
      In subsequent patch, mlx5_core driver uses its internal lock during
      get() and set() eswitch callbacks.
      
      Other drivers have been inspected which returns either constant during
      get operations or reads the value from already allocated structure.
      Hence it is safe to remove the lock in get( ) callback and let vendor
      driver handle it.
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Reviewed-by: NMark Bloch <markb@mellanox.com>
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      98fed6eb
  9. 24 3月, 2020 3 次提交
  10. 04 3月, 2020 3 次提交
  11. 29 2月, 2020 1 次提交
  12. 27 2月, 2020 1 次提交
  13. 26 2月, 2020 2 次提交
  14. 25 2月, 2020 1 次提交
  15. 24 2月, 2020 1 次提交