1. 25 8月, 2017 2 次提交
  2. 24 7月, 2017 4 次提交
  3. 23 7月, 2017 1 次提交
  4. 18 7月, 2017 2 次提交
  5. 17 7月, 2017 2 次提交
    • M
      IB/core: Don't resolve IP address to the loopback device · cbd09aeb
      Moni Shoua 提交于
      When resolving an IP address that is on the host of the caller the
      result from querying the routing table is the loopback device. This is
      not a valid response, because it doesn't represent the RDMA device and
      the port.
      
      Therefore, callers need to check the resolved device and if it is a
      loopback device find an alternative way to resolve it. To avoid this we
      make sure that the response from rdma_resolve_ip() will not be the
      loopback device.
      
      While that, we fix an static checker warning about dereferencing an
      unintitialized pointer using the same solution as in commit abeffce9
      ("net/mlx5e: Fix a -Wmaybe-uninitialized warning") as a reference.
      Signed-off-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      cbd09aeb
    • G
      RDMA/core: Document confusing code · 28b5b3a2
      Gustavo A. R. Silva 提交于
      While looking into Coverity ID 1351047 I ran into the following
      piece of code at
      drivers/infiniband/core/verbs.c:496:
      
      ret = rdma_addr_find_l2_eth_by_grh(&dgid, &sgid,
                                         ah_attr->dmac,
                                         wc->wc_flags & IB_WC_WITH_VLAN ?
                                         NULL : &vlan_id,
                                         &if_index, &hoplimit);
      
      The issue here is that the position of arguments in the call to
      rdma_addr_find_l2_eth_by_grh() function do not match the order of
      the parameters:
      
      &dgid is passed to sgid
      &sgid is passed to dgid
      
      This is the function prototype:
      
      int rdma_addr_find_l2_eth_by_grh(const union ib_gid *sgid,
       				 const union ib_gid *dgid,
       				 u8 *dmac, u16 *vlan_id, int *if_index,
       				 int *hoplimit)
      
      My question here is if this is intentional?
      
      Answer:
      Yes. ib_init_ah_from_wc() creates ah from the incoming packet.
      Incoming packet has dgid of the receiver node on which this code is
      getting executed and sgid contains the GID of the sender.
      
      When resolving mac address of destination, you use arrived dgid as
      sgid and use sgid as dgid because sgid contains destinations GID whom to
      respond to.
      Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      28b5b3a2
  6. 28 6月, 2017 1 次提交
  7. 24 5月, 2017 1 次提交
    • 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
  8. 02 5月, 2017 7 次提交
  9. 29 4月, 2017 1 次提交
  10. 19 2月, 2017 1 次提交
  11. 28 1月, 2017 1 次提交
  12. 14 12月, 2016 3 次提交
  13. 17 11月, 2016 2 次提交
  14. 08 10月, 2016 2 次提交
    • S
      IB/core: correctly handle rdma_rw_init_mrs() failure · b6bc1c73
      Steve Wise 提交于
      Function ib_create_qp() was failing to return an error when
      rdma_rw_init_mrs() fails, causing a crash further down in ib_create_qp()
      when trying to dereferece the qp pointer which was actually a negative
      errno.
      
      The crash:
      
      crash> log|grep BUG
      [  136.458121] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
      crash> bt
      PID: 3736   TASK: ffff8808543215c0  CPU: 2   COMMAND: "kworker/u64:2"
       #0 [ffff88084d323340] machine_kexec at ffffffff8105fbb0
       #1 [ffff88084d3233b0] __crash_kexec at ffffffff81116758
       #2 [ffff88084d323480] crash_kexec at ffffffff8111682d
       #3 [ffff88084d3234b0] oops_end at ffffffff81032bd6
       #4 [ffff88084d3234e0] no_context at ffffffff8106e431
       #5 [ffff88084d323530] __bad_area_nosemaphore at ffffffff8106e610
       #6 [ffff88084d323590] bad_area_nosemaphore at ffffffff8106e6f4
       #7 [ffff88084d3235a0] __do_page_fault at ffffffff8106ebdc
       #8 [ffff88084d323620] do_page_fault at ffffffff8106f057
       #9 [ffff88084d323660] page_fault at ffffffff816e3148
          [exception RIP: ib_create_qp+427]
          RIP: ffffffffa02554fb  RSP: ffff88084d323718  RFLAGS: 00010246
          RAX: 0000000000000004  RBX: fffffffffffffff4  RCX: 000000018020001f
          RDX: ffff880830997fc0  RSI: 0000000000000001  RDI: ffff88085f407200
          RBP: ffff88084d323778   R8: 0000000000000001   R9: ffffea0020bae210
          R10: ffffea0020bae218  R11: 0000000000000001  R12: ffff88084d3237c8
          R13: 00000000fffffff4  R14: ffff880859fa5000  R15: ffff88082eb89800
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
      #10 [ffff88084d323780] rdma_create_qp at ffffffffa0782681 [rdma_cm]
      #11 [ffff88084d3237b0] nvmet_rdma_create_queue_ib at ffffffffa07c43f3 [nvmet_rdma]
      #12 [ffff88084d323860] nvmet_rdma_alloc_queue at ffffffffa07c5ba9 [nvmet_rdma]
      #13 [ffff88084d323900] nvmet_rdma_queue_connect at ffffffffa07c5c96 [nvmet_rdma]
      #14 [ffff88084d323980] nvmet_rdma_cm_handler at ffffffffa07c6450 [nvmet_rdma]
      #15 [ffff88084d3239b0] iw_conn_req_handler at ffffffffa0787480 [rdma_cm]
      #16 [ffff88084d323a60] cm_conn_req_handler at ffffffffa0775f06 [iw_cm]
      #17 [ffff88084d323ab0] process_event at ffffffffa0776019 [iw_cm]
      #18 [ffff88084d323af0] cm_work_handler at ffffffffa0776170 [iw_cm]
      #19 [ffff88084d323cb0] process_one_work at ffffffff810a1483
      #20 [ffff88084d323d90] worker_thread at ffffffff810a211d
      #21 [ffff88084d323ec0] kthread at ffffffff810a6c5c
      #22 [ffff88084d323f50] ret_from_fork at ffffffff816e1ebf
      
      Fixes: 632bc3f6 ("IB/core, RDMA RW API: Do not exceed QP SGE send limit")
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      b6bc1c73
    • B
      IB/core: Improve ib_map_mr_sg() documentation · 52746129
      Bart Van Assche 提交于
      Document that ib_map_mr_sg() is able to map physically discontiguous
      sg-lists as a single MR. Change IB_MR_TYPE_SG_GAPS_REG into
      IB_MR_TYPE_SG_GAPS.
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Cc: Christoph Hellwig <hch@lst.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NSagi Grimberg <sagi@rimberg.me>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      52746129
  15. 24 9月, 2016 3 次提交
  16. 03 8月, 2016 1 次提交
  17. 23 6月, 2016 4 次提交
  18. 14 5月, 2016 2 次提交