1. 30 5月, 2018 1 次提交
  2. 16 3月, 2018 2 次提交
  3. 17 2月, 2018 2 次提交
  4. 30 1月, 2018 2 次提交
  5. 11 1月, 2018 1 次提交
    • H
      IB/core: Increase number of char device minors · 8cf12d77
      Huy Nguyen 提交于
      There is a need to increase number of possible char devices to support
      large number of SR-IOV instances. The current limit is in the range of
      64-128 devices/ports. Increase it to support up to 1024.
      
      The patch performs the following steps to refactor the code:
      1. Removes the split bitmap for fixed and overflow dev numbers.
      2. Pre-allocates the non-legacy major number range during driver
         initialization, choosen for simplicity.
      3. Add new define (RDMA_MAX_PORTS) that is shared between all drivers.
         This is the maximum total number of ports on all struct ib_devices.
      4. Set RDMA_MAX_PORTS to 1024.
      Signed-off-by: NHuy Nguyen <huyn@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      8cf12d77
  6. 09 1月, 2018 2 次提交
    • D
      {net, IB}/mlx5: Manage port association for multiport RoCE · 32f69e4b
      Daniel Jurgens 提交于
      When mlx5_ib_add is called determine if the mlx5 core device being
      added is capable of dual port RoCE operation. If it is, determine
      whether it is a master device or a slave device using the
      num_vhca_ports and affiliate_nic_vport_criteria capabilities.
      
      If the device is a slave, attempt to find a master device to affiliate it
      with. Devices that can be affiliated will share a system image guid. If
      none are found place it on a list of unaffiliated ports. If a master is
      found bind the port to it by configuring the port affiliation in the NIC
      vport context.
      
      Similarly when mlx5_ib_remove is called determine the port type. If it's
      a slave port, unaffiliate it from the master device, otherwise just
      remove it from the unaffiliated port list.
      
      The IB device is registered as a multiport device, even if a 2nd port is
      not available for affiliation. When the 2nd port is affiliated later the
      GID cache must be refreshed in order to get the default GIDs for the 2nd
      port in the cache. Export roce_rescan_device to provide a mechanism to
      refresh the cache after a new port is bound.
      
      In a multiport configuration all IB object (QP, MR, PD, etc) related
      commands should flow through the master mlx5_core_dev, other commands
      must be sent to the slave port mlx5_core_mdev, an interface is provide
      to get the correct mdev for non IB object commands.
      Signed-off-by: NDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      32f69e4b
    • D
      IB/core: Change roce_rescan_device to return void · 908d6460
      Daniel Jurgens 提交于
      It always returns 0. Change return type to void.
      Signed-off-by: NDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      908d6460
  7. 03 1月, 2018 1 次提交
  8. 28 12月, 2017 1 次提交
  9. 19 12月, 2017 1 次提交
  10. 10 8月, 2017 4 次提交
  11. 09 8月, 2017 1 次提交
  12. 02 6月, 2017 1 次提交
  13. 24 5月, 2017 2 次提交
    • D
      IB/core: Enforce security on management datagrams · 47a2b338
      Daniel Jurgens 提交于
      Allocate and free a security context when creating and destroying a MAD
      agent.  This context is used for controlling access to PKeys and sending
      and receiving SMPs.
      
      When sending or receiving a MAD check that the agent has permission to
      access the PKey for the Subnet Prefix of the port.
      
      During MAD and snoop agent registration for SMI QPs check that the
      calling process has permission to access the manage the subnet  and
      register a callback with the LSM to be notified of policy changes. When
      notificaiton of a policy change occurs recheck permission and set a flag
      indicating sending and receiving SMPs is allowed.
      
      When sending and receiving MADs check that the agent has access to the
      SMI if it's on an SMI QP.  Because security policy can change it's
      possible permission was allowed when creating the agent, but no longer
      is.
      Signed-off-by: NDaniel Jurgens <danielj@mellanox.com>
      Acked-by: NDoug Ledford <dledford@redhat.com>
      [PM: remove the LSM hook init code]
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      47a2b338
    • D
      IB/core: Enforce PKey security on QPs · d291f1a6
      Daniel Jurgens 提交于
      Add new LSM hooks to allocate and free security contexts and check for
      permission to access a PKey.
      
      Allocate and free a security context when creating and destroying a QP.
      This context is used for controlling access to PKeys.
      
      When a request is made to modify a QP that changes the port, PKey index,
      or alternate path, check that the QP has permission for the PKey in the
      PKey table index on the subnet prefix of the port. If the QP is shared
      make sure all handles to the QP also have access.
      
      Store which port and PKey index a QP is using. After the reset to init
      transition the user can modify the port, PKey index and alternate path
      independently. So port and PKey settings changes can be a merge of the
      previous settings and the new ones.
      
      In order to maintain access control if there are PKey table or subnet
      prefix change keep a list of all QPs are using each PKey index on
      each port. If a change occurs all QPs using that device and port must
      have access enforced for the new cache settings.
      
      These changes add a transaction to the QP modify process. Association
      with the old port and PKey index must be maintained if the modify fails,
      and must be removed if it succeeds. Association with the new port and
      PKey index must be established prior to the modify and removed if the
      modify fails.
      
      1. When a QP is modified to a particular Port, PKey index or alternate
         path insert that QP into the appropriate lists.
      
      2. Check permission to access the new settings.
      
      3. If step 2 grants access attempt to modify the QP.
      
      4a. If steps 2 and 3 succeed remove any prior associations.
      
      4b. If ether fails remove the new setting associations.
      
      If a PKey table or subnet prefix changes walk the list of QPs and
      check that they have permission. If not send the QP to the error state
      and raise a fatal error event. If it's a shared QP make sure all the
      QPs that share the real_qp have permission as well. If the QP that
      owns a security structure is denied access the security structure is
      marked as such and the QP is added to an error_list. Once the moving
      the QP to error is complete the security structure mark is cleared.
      
      Maintaining the lists correctly turns QP destroy into a transaction.
      The hardware driver for the device frees the ib_qp structure, so while
      the destroy is in progress the ib_qp pointer in the ib_qp_security
      struct is undefined. When the destroy process begins the ib_qp_security
      structure is marked as destroying. This prevents any action from being
      taken on the QP pointer. After the QP is destroyed successfully it
      could still listed on an error_list wait for it to be processed by that
      flow before cleaning up the structure.
      
      If the destroy fails the QPs port and PKey settings are reinserted into
      the appropriate lists, the destroying flag is cleared, and access control
      is enforced, in case there were any cache changes during the destroy
      flow.
      
      To keep the security changes isolated a new file is used to hold security
      related functionality.
      Signed-off-by: NDaniel Jurgens <danielj@mellanox.com>
      Acked-by: NDoug Ledford <dledford@redhat.com>
      [PM: merge fixup in ib_verbs.h and uverbs_cmd.c]
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      d291f1a6
  14. 23 5月, 2017 1 次提交
  15. 15 2月, 2017 1 次提交
  16. 11 1月, 2017 1 次提交
    • P
      IB/core: added support to use rdma cgroup controller · 43579b5f
      Parav Pandit 提交于
      Added support APIs for IB core to register/unregister every IB/RDMA
      device with rdma cgroup for tracking rdma resources.
      IB core registers with rdma cgroup controller.
      Added support APIs for uverbs layer to make use of rdma controller.
      Added uverbs layer to perform resource charge/uncharge functionality.
      Added support during query_device uverb operation to ensure it
      returns resource limits by honoring rdma cgroup configured limits.
      Signed-off-by: NParav Pandit <pandit.parav@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      43579b5f
  17. 14 12月, 2016 1 次提交
  18. 18 10月, 2016 1 次提交
  19. 25 5月, 2016 5 次提交
  20. 23 12月, 2015 4 次提交
  21. 22 10月, 2015 2 次提交
  22. 31 8月, 2015 2 次提交
    • M
      IB/core: Add RoCE GID table management · 03db3a2d
      Matan Barak 提交于
      RoCE GIDs are based on IP addresses configured on Ethernet net-devices
      which relate to the RDMA (RoCE) device port.
      
      Currently, each of the low-level drivers that support RoCE (ocrdma,
      mlx4) manages its own RoCE port GID table. As there's nothing which is
      essentially vendor specific, we generalize that, and enhance the RDMA
      core GID cache to do this job.
      
      In order to populate the GID table, we listen for events:
      
      (a) netdev up/down/change_addr events - if a netdev is built onto
          our RoCE device, we need to add/delete its IPs. This involves
          adding all GIDs related to this ndev, add default GIDs, etc.
      
      (b) inet events - add new GIDs (according to the IP addresses)
          to the table.
      
      For programming the port RoCE GID table, providers must implement
      the add_gid and del_gid callbacks.
      
      RoCE GID management requires us to state the associated net_device
      alongside the GID. This information is necessary in order to manage
      the GID table. For example, when a net_device is removed, its
      associated GIDs need to be removed as well.
      
      RoCE mandates generating a default GID for each port, based on the
      related net-device's IPv6 link local. In contrast to the GID based on
      the regular IPv6 link-local (as we generate GID per IP address),
      the default GID is also available when the net device is down (in
      order to support loopback).
      
      Locking is done as follows:
      The patch modify the GID table code both for new RoCE drivers
      implementing the add_gid/del_gid callbacks and for current RoCE and
      IB drivers that do not. The flows for updating the table are
      different, so the locking requirements are too.
      
      While updating RoCE GID table, protection against multiple writers is
      achieved via mutex_lock(&table->lock). Since writing to a table
      requires us to find an entry (possible a free entry) in the table and
      then modify it, this mutex protects both the find_gid and write_gid
      ensuring the atomicity of the action.
      Each entry in the GID cache is protected by rwlock. In RoCE, writing
      (usually results from netdev notifier) involves invoking the vendor's
      add_gid and del_gid callbacks, which could sleep.
      Therefore, an invalid flag is added for each entry. Updates for RoCE are
      done via a workqueue, thus sleeping is permitted.
      
      In IB, updates are done in write_lock_irq(&device->cache.lock), thus
      write_gid isn't allowed to sleep and add_gid/del_gid are not called.
      
      When passing net-device into/out-of the GID cache, the device
      is always passed held (dev_hold).
      
      The code uses a single work item for updating all RDMA devices,
      following a netdev or inet notifier.
      
      The patch moves the cache from being a client (which was incorrect,
      as the cache is part of the IB infrastructure) to being explicitly
      initialized/freed when a device is registered/removed.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      03db3a2d
    • J
      IB/core: Make ib_alloc_device init the kobject · 55aeed06
      Jason Gunthorpe 提交于
      This gets rid of the weird in-between state where struct ib_device
      was allocated but the kobject didn't work.
      
      Consequently ib_device_release is now guaranteed to be called in
      all situations and we needn't duplicate its kfrees on error paths.
      Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      55aeed06
  23. 20 1月, 2014 1 次提交