- 05 Jun, 2018 1 commit
-
-
Leon Romanovsky authored
Resource tracking is supposed to be dual licensed: GPL-2.0 and OpenIB, but the SPDX tag was not compliant to it. Update the tag to properly reflect license. Fixes: 02d8883f ("RDMA/restrack: Add general infrastructure to track RDMA resources") Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com>
-
- 04 Jun, 2018 14 commits
-
-
Mike Marciniszyn authored
The comment for the default header queue entry size is incorrect. Correct the comment and fix the resulting S_IRUGO warning that shows up in the widened patch context. Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
-
Kaike Wan authored
The mutex exp_lock in struct hfi1_ctxtdata is used to protect all Expected TID data of a user context. This patch renames it to exp_mutex to better reflect its identity and prepare for upcoming patches. Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Harish Chegondi <harish.chegondi@intel.com> Signed-off-by:
Kaike Wan <kaike.wan@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
-
Mike Marciniszyn authored
These registers were not added in the 16B work. Add them and replace blind constants with the correct defines. Fixes: 72c07e2b ("IB/hfi1: Add support to receive 16B bypass packets") Reviewed-by:
Don Hiatt <don.hiatt@intel.com> Signed-off-by:
-
Kaike Wan authored
The variable extended_psn was not used any more. Signed-off-by:
-
Kaike Wan authored
Improve the safety of the code and ensure the array cannot be indexed out of bounds when picking the CPU for a given SDMA engine. Reviewed-by:
-
Mike Marciniszyn authored
The following code fails to allocate a buffer for the tail address that the hardware DMAs into when the user context DMA_RTAIL is set. if (HFI1_CAP_KGET_MASK(rcd->flags, DMA_RTAIL)) { rcd->rcvhdrtail_kvaddr = dma_zalloc_coherent( &dd->pcidev->dev, PAGE_SIZE, &dma_hdrqtail, gfp_flags); if (!rcd->rcvhdrtail_kvaddr) goto bail_free; rcd->rcvhdrqtailaddr_dma = dma_hdrqtail; } So the rcvhdrtail_kvaddr would then be NULL. The mmap logic fails to check for a NULL rcvhdrtail_kvaddr. The fix is to test for both user and kernel DMA_TAIL options during the allocation as well as testing for a NULL rcvhdrtail_kvaddr during the mmap processing. Additionally, all downstream testing of the capmask for DMA_RTAIL have been eliminated in favor of testing rcvhdrtail_kvaddr. Cc: <stable@vger.kernel.org> # 4.9.x Reviewed-by: -
YueHaibing authored
Use dma_zalloc_coherent for allocating zeroed memory and remove unnecessary memset function. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Cong Wang authored
ucma_process_join() will free the new allocated "mc" struct, if there is any error after that, especially the copy_to_user(). But in parallel, ucma_leave_multicast() could find this "mc" through idr_find() before ucma_process_join() frees it, since it is already published. So "mc" could be used in ucma_leave_multicast() after it is been allocated and freed in ucma_process_join(), since we don't refcnt it. Fix this by separating "publish" from ID allocation, so that we can get an ID first and publish it later after copy_to_user(). Fixes: c8f6a362 ("RDMA/cma: Add multicast communication support") Reported-by:
Noam Rathaus <noamr@beyondsecurity.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
The newly added fill_res_ep_entry function fails to link if CONFIG_INFINIBAND_ADDR_TRANS is not set: drivers/infiniband/hw/cxgb4/restrack.o: In function `fill_res_ep_entry': restrack.c:(.text+0x3cc): undefined reference to `rdma_res_to_id' restrack.c:(.text+0x3d0): undefined reference to `rdma_iw_cm_id' This adds a Kconfig dependency for the driver. Fixes: 116aeb88 ("iw_cxgb4: provide detailed provider-specific CM_ID information") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Greg Thelen <gthelen@google.com> Signed-off-by:
-
Max Gurtovoy authored
No reason to use hard-coded protection information checks in ib_isert driver. Use check masks from RDMA core driver. Also, while we here, reduce the number of instructions made for setting the check mask (no need to do bitwise or with 0 since we zero the mask in the beginning of the function). Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Signed-off-by:
-
Max Gurtovoy authored
No reason to re-define protection information check in ib_iser driver. Use check masks from RDMA core driver. Reviewed-by:
-
Max Gurtovoy authored
T10-PI offload capability is currently supported in iSER protocol only, and the definition of the HCA protection information checks are missing from the core layer. Add those definition to avoid code duplication in other drivers (such iSER target and NVMeoF). Reviewed-by:
-
Max Gurtovoy authored
A copy/paste bug (probably) caused setting of an app_tag check mask in case where a ref_tag check was needed. Fixes: 38a2d0d4 ("IB/isert: convert to the generic RDMA READ/WRITE API") Fixes: 9e961ae7 ("IB/isert: Support T10-PI protected transactions") Cc: stable@vger.kernel.org Reviewed-by:
-
Jason Gunthorpe authored
Merge tag 'verbs_flow_counters' of git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git into for-next Pull verbs counters series from Leon Romanovsky: ==================== Verbs flow counters support This series comes to allow user space applications to monitor real time traffic activity and events of the verbs objects it manages, e.g.: ibv_qp, ibv_wq, ibv_flow. The API enables generic counters creation and define mapping to association with a verbs object, the current mlx5 driver is using this API for flow counters. With this API, an application can monitor the entire life cycle of object activity, defined here as a static counters attachment. This API also allows dynamic counters monitoring of measurement points for a partial period in the verbs object life cycle. In addition it presents the implementation of the generic counters interface. This will be achieved by extending flow creation by adding a new flow count specification type which allows the user to associate a previously created flow counters using the generic verbs counters interface to the created flow, once associated the user could read statistics by using the read function of the generic counters interface. The API includes: 1. create and destroyed API of a new counters objects 2. read the counters values from HW Note: Attaching API to allow application to define the measurement points per objects is a user space only API and this data is passed to kernel when the counted object (e.g. flow) is created with the counters object. =================== * tag 'verbs_flow_counters': IB/mlx5: Add counters read support IB/mlx5: Add flow counters read support IB/mlx5: Add flow counters binding support IB/mlx5: Add counters create and destroy support IB/uverbs: Add support for flow counters IB/core: Add support for flow counters IB/core: Support passing uhw for create_flow IB/uverbs: Add read counters support IB/core: Introduce counters read verb IB/uverbs: Add create/destroy counters support IB/core: Introduce counters object and its create/destroy IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure net/mlx5: Export flow counter related API net/mlx5: Use flow counter pointer as input to the query function
-
- 02 Jun, 2018 14 commits
-
-
Raed Salem authored
This patch implements the uverbs counters read API, it will use the specific read counters function to the given type to accomplish its task. Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Raed Salem <raeds@mellanox.com> Signed-off-by:
-
Raed Salem authored
Implements the flow counters read wrapper. Reviewed-by:
-
Raed Salem authored
Associates a counters with a flow when IB_FLOW_SPEC_ACTION_COUNT is part of the flow specifications. The counters user space placements of location and description (index, description) pairs are passed as private data of the counters flow specification. Reviewed-by:
-
Raed Salem authored
This patch implements the device counters create and destroy APIs and introducing some internal management structures. Downstream patches in this series will add the functionality to support flow counters binding and reading. Reviewed-by:
-
Raed Salem authored
The struct ib_uverbs_flow_spec_action_count associates a counters object with the flow. Post this association the flow counters can be read via the counters object. Reviewed-by:
-
Raed Salem authored
A counters object could be attached to flow on creation by providing the counter specification action. General counters description which count packets and bytes are introduced, downstream patches from this series will use them as part of flow counters binding. In addition, increase number of flow specifications supported layers to 10 upon adding count specification and for the previously added drop specification. Reviewed-by:
-
Matan Barak authored
This is required when user-space drivers need to pass extra information regarding how to handle this flow steering specification. Reviewed-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
Boris Pismenny <borisp@mellanox.com> Signed-off-by:
-
Raed Salem authored
This patch exposes the read counters verb to user space applications. By that verb the user can read the hardware counters which are associated with the counters object. The application needs to provide a sufficient memory to hold the statistics. Reviewed-by:
-
Raed Salem authored
The user supplies counters instance and a reference to an output array of uint64_t. The driver reads the hardware counters values and writes them to the output index location in the user supplied array. All counters values are represented as uint64_t types. To be able to successfully read the data the counters must be first bound to an IB object. Downstream patches will present binding method for flow counters. Reviewed-by:
-
Raed Salem authored
User space application which uses counters functionality, is expected to allocate/release the counters resources by calling create/destroy verbs and in turn get a unique handle that can be used to attach the counters to its counted type. Reviewed-by:
-
Raed Salem authored
A verbs application may need to get statistics and info on various aspects of a verb object (e.g. Flow, QP, ...), in general case the application will state which object's counters its interested in (we refer to this action as attach), bind this new counters object to the appropriate verb object and on later stage read their values using the counters object. This series introduces a general API for counters object that may accumulate any ib object counters type, bound and read on demand. Counters instance is allocated on an IB context and belongs to that context. Upon successful creation the counters can be bound to a verbs object so that hardware counter instances can be created and read. Downstream patches in this series will introduce the attach, bind and the read functionality. Counters instance can be de-allocated, upon successful destruction the related hardware resources are released. Prior to destroy call the user must first make sure that the counters is not being used by any IB object, e.g. not attached to any of its counted type otherwise an EBUSY error is invoked. Reviewed-by:
-
Matan Barak authored
Previously, the user had to dig inside the attribute to get the uobject. Add a helper function that correctly extract it (and do the required checks) for him/her. Signed-off-by:
-
Raed Salem authored
Exports counters API to be used in both IB and EN. Reviewed-by:
-
Or Gerlitz authored
This allows to un-expose the details of struct mlx5_fc and keep it internal to the core driver. Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
- 01 Jun, 2018 11 commits
-
-
Leon Romanovsky authored
All callers of zap_vma_ptes() are not interested in the return value of that function, so let's simplify its interface and drop the return value. Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Doug Ledford authored
There is no need to check return value of zap_vma_ptes() because there is nothing to do with this knowledge. Signed-off-by: -
Leon Romanovsky authored
The failure reported by zap_vma_ptes() means that wrong VMA pages were supplied, however it is impossible for this type of address. Signed-off-by:
-
Leon Romanovsky authored
There is no need to check return value of zap_vma_ptes() because there is nothing to do with this knowledge. Signed-off-by:
-
Leon Romanovsky authored
Let's perform checks in-place instead of BUG_ONs. Signed-off-by:
-
Leon Romanovsky authored
There is no need to check existence of mad_queue, because we already did pointer dereference before call to dequeue_mad(). Signed-off-by:
-
Leon Romanovsky authored
There is no need to bring down the whole machine, just because unknown event was received. It is better to ignore it silently. Signed-off-by:
-
Leon Romanovsky authored
In case CM work list is empty, the work pointer will be NULL, so instead of kernel crash it is better to abort processing of works. Signed-off-by:
-
Leon Romanovsky authored
cxgb3 driver properly handles errors returned by IDR, so there is no need to have special case (kernel crash) just because IDR is full. Signed-off-by:
-
Leon Romanovsky authored
There is no need to crash the machine if unknown work request was received in SQP MAD. Cc: <stable@vger.kernel.org> # 3.6 Fixes: 37bfc7c1 ("IB/mlx4: SR-IOV multiplex and demultiplex MADs") Signed-off-by:
-
Leon Romanovsky authored
Any steering QP is supposed be above steering_qp_base, see function mlx4_ib_steer_qp_alloc() for it, however in case of misalignment between SW and FW, this qp_base can be wrong. Use WARN() to catch such situation without killing the machine. Signed-off-by:
-
