- 20 Jul, 2017 35 commits
-
-
Kalderon, Michal authored
Once in_dev_get is called to receive in_device pointer, the in_device reference counter is increased, but if there are no ipv4 addresses configured on the net-device the ifa_list will be null, resulting in a flow that doesn't call in_dev_put to decrease the ref_cnt. This was exposed when running RoCE over ipv6 without any ipv4 addresses configured Fixes: commit 8e3867310c90 ("IB/cma: Fix a race condition in iboe_addr_get_sgid()") Signed-off-by:Michal Kalderon <Michal.Kalderon@cavium.com> Signed-off-by:
Ariel Elior <Ariel.Elior@cavium.com> Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Sagi Grimberg authored
We might get some bogus error completions in case the target will remotely invalidate the rkey and the HCA will need to retransmit from this buffer. Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Vijay Immanuel authored
If we modified the qp to ERROR state, and drained the recieve queue, post_recv must trigger the responder task to complete the drain work request. Cc: Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
Vijay Immanuel <vijayi@attalasystems.com> Signed-off-by:
-
Amrani, Ram authored
Wrap ib_copy_to_udata with a function that ensures that the data being copied over to user space isn't longer than the allowed. Fixes: cecbcddf ("qedr: Add support for QP verbs") Fixes: a7efd777 ("qedr: Add support for PD,PKEY and CQ verbs") Fixes: ac1b36e5 ("qedr: Add support for user context verbs") Signed-off-by:
Ram Amrani <Ram.Amrani@cavium.com> Signed-off-by:
-
Ganesh Goudar authored
Only use the read sge lkey/addr and the remote rkey/addr if the length of the read is not zero. Otherwise the read response might be treated as the RTR read response and not delivered to the application. Or worse Terminator hardware will fail a 0B read if the STAG is 0 even if the read length is 0. Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
Håkon Bugge authored
CM REQs cannot be successfully retried, because a new pv_cm_id is created for each request, without checking if one already exists. By checking if an id exists before creating one, the bug is fixed. This bug can be provoked by running an RDMA CM user-land application, but inserting a five seconds delay before the rdma_accept() call on the passive side. This delay is larger than the default CMA timeout, and triggers a retry from the active side. The retried REQ will use another pv_cm_id (the cm_id on the wire). This confuses the CM protocol and two REJs are sent from the passive side. Here is an excerpt from ibdump running without the patch: 3.285092 LID: 4 -> LID: 4 SDP 290 CM: ConnectRequest(SDP Hello) 7.382711 LID: 4 -> LID: 4 SDP 290 CM: ConnectRequest(SDP Hello) 7.382861 LID: 4 -> LID: 4 InfiniBand 290 CM: ConnectReject 7.387644 LID: 4 -> LID: 4 InfiniBand 290 CM: ConnectReject and here is the same with bug fix applied: 3.251010 LID: 4 -> LID: 4 SDP 290 CM: ConnectRequest(SDP Hello) 7.349387 LID: 4 -> LID: 4 SDP 290 CM: ConnectRequest(SDP Hello) 8.258443 LID: 4 -> LID: 4 SDP 290 CM: ConnectReply(SDP Hello) 8.259890 LID: 4 -> LID: 4 InfiniBand 290 CM: ReadyToUse Suggested-by:
Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com> Signed-off-by:
Håkon Bugge <haakon.bugge@oracle.com> Reported-by:
Wei Lin Guay <wei.lin.guay@oracle.com> Tested-by:
Yuval Shaia <yuval.shaia@oracle.com> Acked-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
-
Kaike Wan authored
Current computation of qp->timeout_jiffies in rvt_modify_qp() will cause overflow due to the fact that the input to the function usecs_to_jiffies is only 32-bit ( unsigned int). Overflow will occur when attr->timeout is equal to or greater than 30. The consequence is unnecessarily excessive retry and thus degradation of the system performance. This patch fixes the problem by limiting the input to 5-bit and calling usecs_to_jiffies() before multiplying the scaling factor. Reviewed-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Kaike Wan <kaike.wan@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
-
Matan Barak authored
Delete unused variables to prevent sparse warnings. Fixes: db1b5ddd ("IB/core: Rename uverbs event file structure") Fixes: fd3c7904 ("IB/core: Change idr objects to use the new schema") Signed-off-by:
-
Selvin Xavier authored
Local ack delay exposed by the driver is 0 which means infinite QP timeout. Reporting the default value to 16 (approx 260ms) Signed-off-by:
Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by:
-
Selvin Xavier authored
While invoking the req_notify_cq hook, ULPs can request whether the CQs have any CQEs pending. If CQEs are pending, drivers can indicate it by returning 1 for req_notify_cq. The stack will poll CQ again till CQ is empty. This patch peeks the CQ for any valid entries and return accordingly. Signed-off-by:
-
Devesh Sharma authored
Fix the incorrect reporting of number of polled entries by taking into account the max CQ depth in the driver. Signed-off-by:
Devesh Sharma <devesh.sharma@broadcom.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Devesh Sharma authored
Driver shall check if the host system bios has enabled Atomic operations capability in PCI Device Control 2 register of the pci-device. Expose the ATOMIC_HCA flag only if the Atomic operations capability is set. Signed-off-by:
-
Somnath Kotur authored
Starting FW version 20.6.47, firmware is keeping separate statistics for L2 and RDMA. However, driver needs to specify RDMA or not when allocating stat_ctx. Signed-off-by:
-
Eddie Wai authored
There's a couple of bugs in the support of max_rd_atomic and max_dest_rd_atomic. In the modify_qp, if the requested max_rd_atomic, which is the ORRQ size, is greater than what the chip can support, then we have to cap the request to chip max as we can't have the HW overflow the ORRQ. Capping the max_rd_atomic support internally is okay to do as the remaining read/atomic WRs will still be sitting in the SQ. However, for the max_dest_rd_atomic, the driver has to error out as this dictates the IRRQ size and we can't control what the remote side sends. Signed-off-by:
Eddie Wai <eddie.wai@broadcom.com> Signed-off-by:
-
Selvin Xavier authored
- Report supported value for max_mr_size to IB stack in query_device. Also, check and log if MR size requested by application in reg_user_mr() is greater than value currently supported by driver. - Report only 4K page size support for now - Fix Max_QP value returned by ibv_devinfo -vv. In case of PF, FW reserves 129 QPs for creating QP1s of VFs and PF. So the max_qp value reported by FW for PF doesn'tt include the QP1. Fixing this issue by adding 1 with the value reported by FW. Signed-off-by:
-
Selvin Xavier authored
This fix is added only to avoid system crash in some a specific scenario. When bnxt_re driver is loaded and if user tries to change interface mac address, delete GID fails because QP1 is still associated with existing MAC (default GID). If the above command fails GID tables are not modified in the h/w or driver, but the GID context memory is freed. Now, if the user changes the mac back to the original value, another add_gid comes to the driver where the driver reports that the GID is already present in its table and tries to access the context which was already freed. So, in this case, in order to avoid NULL pointer de-reference, this patch removes the context memory free if delete_gid fails and the same context memory is re-used in new add_gid. Memory cleanup will be taken care during driver unload, while deleting the GID table. Signed-off-by:
Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by:
-
Somnath Kotur authored
Posting WQE size of 2 results in a WQE_FORMAT_ERROR thrown by the HW as it requires host to supply WQE Size with room for atleast one SGE so that the resulting WQE size be atleast 3. Signed-off-by:
Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by:
-
Devesh Sharma authored
The driver must free the DPI during the dealloc_ucontext instead of freeing it during dealloc_pd. However, the DPI allocation scheme remains unchanged. Signed-off-by:
-
Dan Carpenter authored
"umem" is a valid pointer. We intended to print "*umem" or even just "err" instead. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
Dan Carpenter authored
If either of these allocations fail then we return ERR_PTR(0). That's equivalent to NULL and results in a NULL pointer dereference in the caller. Fixes: fe2caefc ("RDMA/ocrdma: Add driver for Emulex OneConnect IBoE RDMA adapter") Signed-off-by:
-
Dan Carpenter authored
We should preserve the original "status" error code instead of resetting it to zero. Returning ERR_PTR(0) is the same as NULL and results in a NULL dereference in the callers. I added a printk() on error instead. Fixes: 45e86b33 ("RDMA/ocrdma: Cache recv DB until QP moved to RTR") Signed-off-by:
-
Dan Carpenter authored
We accidentally don't set the error code on some error paths. It means return ERR_PTR(0) which is NULL and results in a NULL dereference in the caller. Fixes: 13a23933 ("RDMA/cxgb3: Don't ignore insert_handle() failures") Signed-off-by:
-
Dan Carpenter authored
If one of these kmalloc() calls fails then we return ERR_PTR(0) which is NULL. It results in a NULL dereference in the callers. Fixes: cfdda9d7 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC") Signed-off-by:
-
Dan Carpenter authored
We accidentally forgot to set the error code if ib_copy_from_udata() fails. It means we return ERR_PTR(0) which is NULL and results in a NULL dereference in the callers. Fixes: d3749841 ("i40iw: add files for iwarp interface") Signed-off-by:
Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by:
-
Dan Carpenter authored
We accidentally don't see the error code on some of these error paths. It means we return ERR_PTR(0) which is NULL and it results in a NULL dereference in the caller. This bug dates to pre-git days. Signed-off-by:
-
Dan Carpenter authored
bnxt_re_alloc_mw() doesn't return NULL, it returns error pointers. Fixes: 9152e0b7 ("RDMA/bnxt_re: HW workarounds for handling specific conditions") Signed-off-by:
-
Tatyana Nikolova authored
If the physical buffer list entries (PBLEs) of a QP are freed up at i40iw_dereg_mr, they can be assigned to a newly created QP before the previous QP is destroyed. Fix this by freeing PBLEs only when the QP is destroyed. Signed-off-by:
Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by:
Faisal Latif <faisal.latif@intel.com> Signed-off-by:
-
Shiraz Saleem authored
Control Queue Pair (CQP) request objects, which have not received a completion upon interface close, remain in memory. To fix this, identify and free all pending CQP request objects during destroy CQP OP. Signed-off-by:
Henry Orosco <henry.orosco@intel.com> Signed-off-by:
-
Henry Orosco authored
To avoid infinite loop, in i40iw_ieq_handle_exception, update plist inside while loop. Signed-off-by:
-
Henry Orosco authored
Add missing write memory barrier before writing the header containing valid bit to the WQE in i40iw_puda_send. Signed-off-by:
-
Shiraz Saleem authored
Current flow leaves software QP structures in memory if Control Queue Pair (CQP) destroy QP OP fails. To fix this, free QP resources on fail of CQP destroy QP OP. Signed-off-by:
-
Shiraz Saleem authored
On PCI function reset, cm_id reference is not released which causes an application hang, as it waits on the cm_id to be released on rdma_destroy. To fix this, call i40iw_cm_disconn during a PCI function reset to clean-up resources and release cm_id reference. Signed-off-by:
-
Shiraz Saleem authored
Utilize iwdev->reset on a PCI function reset notification instead of passing in reset flag for resource clean-up. Signed-off-by:
-
Mustafa Ismail authored
Control Queue Pair (CQP) OPs, in this case - Update SDs, cannot poll the Control Completion Queue (CCQ) after CCQ is destroyed. Instead, poll via registers. Signed-off-by:
Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by:
-
Mustafa Ismail authored
The order for calling i40iw_destroy_pble_pool is incorrect. Also, add PBLE_CHUNK_MEM init state to track pble pool creation and destruction. Signed-off-by:
-
- 18 Jul, 2017 5 commits
-
-
Tadeusz Struk authored
Playing with IP-O-IB interface can trigger a warning message: "ib0: Failed to modify QP to ERROR state" to be logged. This happens when the QP is in IB_QPS_RESET state and the stack is trying to transition it to IB_QPS_ERR state in ipoib_ib_dev_stop(). According to the IB spec, Table 91 - "QP State Transition Properties" it looks like the transition from reset to error is valid: Transition: Any State to Error Required Attributes: None Optional Attributes: None allowed Actions: Queue processing is stopped. Work Requests pending or in process are completed in error, when possible. This patch allows the transition and quiets the message. Reviewed-by:
Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by:
-
oulijun authored
This patch correct the comment style warnings caught by checkpatch.pl script. Signed-off-by:
Lijun Ou <oulijun@huawei.com> Signed-off-by:
-
oulijun authored
When modified the MAC address used hns_roce_mac function, we release and create reserved qp again, It is not necessary to use spin_lock_bh and spin_unlock_bh in handle_en_event, Otherwise, it will occur a error. This patch mainly fixes it. Signed-off-by:
-
oulijun authored
When opcode of work request is RDMA read and write, it should use rdma_wr to get remote_addr and rkey. This patch fixes it. Signed-off-by:
-
oulijun authored
When destroyed rc qp, the hr_qp will be used after freed. This patch will fix it. Signed-off-by:
-
