1. 19 6月, 2019 2 次提交
  2. 18 6月, 2019 1 次提交
  3. 12 6月, 2019 2 次提交
  4. 11 6月, 2019 3 次提交
  5. 22 5月, 2019 1 次提交
  6. 07 5月, 2019 3 次提交
  7. 03 5月, 2019 2 次提交
  8. 02 5月, 2019 1 次提交
  9. 25 4月, 2019 1 次提交
  10. 09 4月, 2019 3 次提交
  11. 02 4月, 2019 2 次提交
  12. 30 3月, 2019 1 次提交
  13. 29 3月, 2019 3 次提交
  14. 23 2月, 2019 1 次提交
  15. 20 2月, 2019 8 次提交
    • S
      RDMA/core: Add RDMA_NLDEV_CMD_NEWLINK/DELLINK support · 3856ec4b
      Steve Wise 提交于
      Add support for new LINK messages to allow adding and deleting rdma
      interfaces.  This will be used initially for soft rdma drivers which
      instantiate device instances dynamically by the admin specifying a netdev
      device to use.  The rdma_rxe module will be the first user of these
      messages.
      
      The design is modeled after RTNL_NEWLINK/DELLINK: rdma drivers register
      with the rdma core if they provide link add/delete functions.  Each driver
      registers with a unique "type" string, that is used to dispatch messages
      coming from user space.  A new RDMA_NLDEV_ATTR is defined for the "type"
      string.  User mode will pass 3 attributes in a NEWLINK message:
      RDMA_NLDEV_ATTR_DEV_NAME for the desired rdma device name to be created,
      RDMA_NLDEV_ATTR_LINK_TYPE for the "type" of link being added, and
      RDMA_NLDEV_ATTR_NDEV_NAME for the net_device interface to use for this
      link.  The DELLINK message will contain the RDMA_NLDEV_ATTR_DEV_INDEX of
      the device to delete.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: NMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      3856ec4b
    • J
      RDMA/rxe: Close a race after ib_register_device · ca22354b
      Jason Gunthorpe 提交于
      Since rxe allows unregistration from other threads the rxe pointer can
      become invalid any moment after ib_register_driver returns. This could
      cause a user triggered use after free.
      
      Add another driver callback to be called right after the device becomes
      registered to complete any device setup required post-registration.  This
      callback has enough core locking to prevent the device from becoming
      unregistered.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      ca22354b
    • J
      RDMA/device: Provide APIs from the core code to help unregistration · d0899892
      Jason Gunthorpe 提交于
      These APIs are intended to support drivers that exist outside the usual
      driver core probe()/remove() callbacks. Normally the driver core will
      prevent remove() from running concurrently with probe(), once this safety
      is lost drivers need more support to get the locking and lifetimes right.
      
      ib_unregister_driver() is intended to be used during module_exit of a
      driver using these APIs. It unregisters all the associated ib_devices.
      
      ib_unregister_device_and_put() is to be used by a driver-specific removal
      function (ie removal by name, removal from a netdev notifier, removal from
      netlink)
      
      ib_unregister_queued() is to be used from netdev notifier chains where
      RTNL is held.
      
      The locking is tricky here since once things become async it is possible
      to race unregister with registration. This is largely solved by relying on
      the registration refcount, unregistration will only ever work on something
      that has a positive registration refcount - and then an unregistration
      mutex serializes all competing unregistrations of the same device.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      d0899892
    • J
      RDMA/device: Add ib_device_get_by_netdev() · 324e227e
      Jason Gunthorpe 提交于
      Several drivers need to find the ib_device from a given netdev. rxe needs
      this at speed in an unsleepable context, so choose to implement the
      translation using a RCU safe hash table.
      
      The hash table can have a many to one mapping. This is intended to support
      some future case where multiple IB drivers (ie iWarp and RoCE) connect to
      the same netdevs. driver_ids will need to be different to support this.
      
      In the process this makes the struct ib_device and ib_port_data RCU safe
      by deferring their kfrees.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      324e227e
    • J
      RDMA/device: Add ib_device_set_netdev() as an alternative to get_netdev · c2261dd7
      Jason Gunthorpe 提交于
      The associated netdev should not actually be very dynamic, so for most
      drivers there is no reason for a callback like this. Provide an API to
      inform the core code about the net dev affiliation and use a core
      maintained data structure instead.
      
      This allows the core code to be more aware of the ndev relationship which
      will allow some new APIs based around this.
      
      This also uses locking that makes some kind of sense, many drivers had a
      confusing RCU lock, or missing locking which isn't right.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      c2261dd7
    • J
      RDMA/cache: Move the cache per-port data into the main ib_port_data · 8faea9fd
      Jason Gunthorpe 提交于
      Like the other cases there no real reason to have another array just for
      the cache. This larger conversion gets its own patch.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      8faea9fd
    • J
      RDMA/device: Consolidate ib_device per_port data into one place · 8ceb1357
      Jason Gunthorpe 提交于
      There is no reason to have three allocations of per-port data. Combine
      them together and make the lifetime for all the per-port data match the
      struct ib_device.
      
      Following patches will require more port-specific data, now there is a
      good place to put it.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      8ceb1357
    • J
      RDMA: Add and use rdma_for_each_port · ea1075ed
      Jason Gunthorpe 提交于
      We have many loops iterating over all of the end port numbers on a struct
      ib_device, simplify them with a for_each helper.
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      ea1075ed
  16. 19 2月, 2019 1 次提交
  17. 16 2月, 2019 1 次提交
  18. 09 2月, 2019 4 次提交
    • J
      RDMA/devices: Re-organize device.c locking · 921eab11
      Jason Gunthorpe 提交于
      The locking here started out with a single lock that covered everything
      and then has lately veered into crazy town.
      
      The fundamental problem is that several places need to iterate over a
      linked list, but also need to drop their locks to avoid deadlock during
      client callbacks.
      
      xarray's restartable iteration offers a simple solution to the
      problem. Once all the lists are xarrays we can drop locks in the places
      that need that and rely on xarray to provide consistency and locking for
      the data structure.
      
      The resulting simplification is that each of the three lists has a
      dedicated rwsem that must be held when working with the list it
      covers. One data structure is no longer covered by multiple locks.
      
      The sleeping semaphore is selected because the read side generally needs
      to be held over something sleeping, and using RCU reader locking in those
      cases is overkill.
      
      In the process this simplifies the entire registration/unregistration flow
      to be the expected list of setups and the reversed list of matching
      teardowns, and the registration lock 'refcount' can now be revised to be
      released after the ULPs are removed, providing a very sane semantic for
      this feature.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      921eab11
    • J
      RDMA/devices: Use xarray to store the client_data · 0df91bb6
      Jason Gunthorpe 提交于
      Now that we have a small ID for each client we can use xarray instead of
      linearly searching linked lists for client data. This will give much
      faster and scalable client data lookup, and will lets us revise the
      locking scheme.
      
      Since xarray can store 'going_down' using a mark just entirely eliminate
      the struct ib_client_data and directly store the client_data value in the
      xarray. However this does require a special iterator as we must still
      iterate over any NULL client_data values.
      
      Also eliminate the client_data_lock in favour of internal xarray locking.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      0df91bb6
    • J
      RDMA/devices: Use xarray to store the clients · e59178d8
      Jason Gunthorpe 提交于
      This gives each client a unique ID and will let us move client_data to use
      xarray, and revise the locking scheme.
      
      clients have to be add/removed in strict FIFO/LIFO order as they
      interdepend. To support this the client_ids are assigned to increase in
      FIFO order. The existing linked list is kept to support reverse iteration
      until xarray can get a reverse iteration API.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      e59178d8
    • J
      RDMA/device: Get rid of reg_state · 652432f3
      Jason Gunthorpe 提交于
      This really has no purpose anymore, refcount can be used to tell if the
      device is still registered. Keeping it around just invites mis-use.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      652432f3