- 04 Jun, 2018 9 commits
-
-
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:Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com>
-
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:
Leon Romanovsky <leonro@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:
-
- 31 May, 2018 6 commits
-
-
Colin Ian King authored
Trivial fix to spelling mistake in DP_ERR error message Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Sergey Gorenko authored
The iSER driver reduces max_sectors. For example, if you load the ib_iser module with max_sectors=1024, you will see that /sys/class/block/<bdev>/queue/max_hw_sectors_kb is 508. It is an incorrect value. The expected value is (max_sectors * sector_size) / 1024 = 512. Reducing of max_sectors can cause performance degradation due to unnecessary splitting of IO requests. The number of pages per MR has been fixed here, so there is no longer any need to reduce max_sectors. Fixes: 9c674815 ("IB/iser: Fix max_sectors calculation") Signed-off-by:
Sergey Gorenko <sergeygo@mellanox.com> Reviewed-by:
Israel Rukshin <israelr@mellanox.com> Reviewed-by:
-
Doug Ledford authored
Signed-off-by: -
Wei Hu(Xavier) authored
This patch implemented the IB core disassociate_ucontext API. Signed-off-by:
Wei Hu (Xavier) <xavier.huwei@huawei.com> Signed-off-by:
-
Wei Hu(Xavier) authored
This patch hoisted the common process of disassociate_ucontext callback function into ib core code, and these code are common to ervery ib_device driver. Signed-off-by:
-
Wei Hu(Xavier) authored
This patch fixed the potential illegal operation when using the extend sge buffer cross page in post send operation. The bug will cause the calltrace as below. [ 3302.922107] Unable to handle kernel paging request at virtual address ffff00003b3a0004 [ 3302.930009] Mem abort info: [ 3302.932790] Exception class = DABT (current EL), IL = 32 bits [ 3302.938695] SET = 0, FnV = 0 [ 3302.941735] EA = 0, S1PTW = 0 [ 3302.944863] Data abort info: [ 3302.947729] ISV = 0, ISS = 0x00000047 [ 3302.951551] CM = 0, WnR = 1 [ 3302.954506] swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff000009ea5000 [ 3302.961279] [ffff00003b3a0004] *pgd=00000023dfffe003, *pud=00000023dfffd003, *pmd=00000022dc84c003, *pte=0000000000000000 [ 3302.972224] Internal error: Oops: 96000047 [#1] SMP [ 3302.999509] CPU: 9 PID: 19628 Comm: roce_test_main Tainted: G OE 4.14.10 #1 [ 3303.007498] task: ffff80234df78000 task.stack: ffff00000f640000 [ 3303.013412] PC is at hns_roce_v2_post_send+0x690/0xe20 [hns_roce_pci] [ 3303.019843] LR is at hns_roce_v2_post_send+0x658/0xe20 [hns_roce_pci] [ 3303.026269] pc : [<ffff0000020694f8>] lr : [<ffff0000020694c0>] pstate: 804001c9 [ 3303.033649] sp : ffff00000f643870 [ 3303.036951] x29: ffff00000f643870 x28: ffff80232bfa9c00 [ 3303.042250] x27: ffff80234d909380 x26: ffff00003b37f0c0 [ 3303.047549] x25: 0000000000000000 x24: 0000000000000003 [ 3303.052848] x23: 0000000000000000 x22: 0000000000000000 [ 3303.058148] x21: 0000000000000101 x20: 0000000000000001 [ 3303.063447] x19: ffff80236163f800 x18: 0000000000000000 [ 3303.068746] x17: 0000ffff86b76fc8 x16: ffff000008301600 [ 3303.074045] x15: 000020a51c000000 x14: 3128726464615f65 [ 3303.079344] x13: 746f6d6572202c29 x12: 303035312879656b [ 3303.084643] x11: 723a6f666e692072 x10: 573a6f666e693a5d [ 3303.089943] x9 : 0000000000000004 x8 : ffff8023ce38b000 [ 3303.095242] x7 : ffff8023ce38b320 x6 : 0000000000000418 [ 3303.100541] x5 : ffff80232bfa9cc8 x4 : 0000000000000030 [ 3303.105839] x3 : 0000000000000100 x2 : 0000000000000200 [ 3303.111138] x1 : 0000000000000320 x0 : ffff00003b3a0000 [ 3303.116438] Process roce_test_main (pid: 19628, stack limit = 0xffff00000f640000) [ 3303.123906] Call trace: [ 3303.126339] Exception stack(0xffff00000f643730 to 0xffff00000f643870) [ 3303.215790] [<ffff0000020694f8>] hns_roce_v2_post_send+0x690/0xe20 [hns_roce_pci] [ 3303.223293] [<ffff0000021c3750>] rt_ktest_post_send+0x5d0/0x8b8 [rdma_test] [ 3303.230261] [<ffff0000021b3234>] exec_send_cmd+0x664/0x1350 [rdma_test] [ 3303.236881] [<ffff0000021b8b30>] rt_ktest_dispatch_cmd_3+0x1510/0x3790 [rdma_test] [ 3303.244455] [<ffff0000021bae54>] rt_ktest_dispatch_cmd_2+0xa4/0x118 [rdma_test] [ 3303.251770] [<ffff0000021bafec>] rt_ktest_dispatch_cmd+0x124/0xaa8 [rdma_test] [ 3303.258997] [<ffff0000021bbc3c>] rt_ktest_dev_write+0x2cc/0x568 [rdma_test] [ 3303.265947] [<ffff0000082ad688>] __vfs_write+0x60/0x18c [ 3303.271158] [<ffff0000082ad998>] vfs_write+0xa8/0x198 [ 3303.276196] [<ffff0000082adc7c>] SyS_write+0x6c/0xd4 [ 3303.281147] Exception stack(0xffff00000f643ec0 to 0xffff00000f644000) [ 3303.287573] 3ec0: 0000000000000003 0000fffffc85faa8 0000000000004e60 0000000000000000 [ 3303.295388] 3ee0: 0000000021fb2000 000000000000ffff eff0e3efe4e58080 0000fffffcc724fe [ 3303.303204] 3f00: 0000000000000040 1999999999999999 0101010101010101 0000000000000038 [ 3303.311019] 3f20: 0000000000000005 ffffffffffffffff 0d73757461747320 ffffffffffffffff [ 3303.318835] 3f40: 0000000000000000 0000000000459b00 0000fffffc85e360 000000000043d788 [ 3303.326650] 3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 3303.334465] 3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 3303.342281] 3fa0: 0000000000000000 0000fffffc85e570 0000000000438804 0000fffffc85e570 [ 3303.350096] 3fc0: 0000ffff8553f618 0000000080000000 0000000000000003 0000000000000040 [ 3303.357911] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 3303.365729] [<ffff000008083808>] __sys_trace_return+0x0/0x4 [ 3303.371288] Code: b94008e9 34000129 b9400ce2 110006b5 (b9000402) [ 3303.377377] ---[ end trace fd5ab98b3325cf9a ]--- Reported-by:
Jie Chen <chenjie103@huawei.com> Reported-by:
Xiping Zhang (Francis) <zhangxiping3@huawei.com> Fixes: b1c15835("RDMA/hns: Get rid of virt_to_page and vmap calls after dma_alloc_coherent") Signed-off-by:
-
