- 09 Feb, 2021 2 commits
-
-
Yixing Liu authored
Direct wqe is a mechanism to fill wqe directly into the hardware. In the case of light load, the wqe will be filled into pcie bar space of the hardware, this will reduce one memory access operation and therefore reduce the latency. Link: https://lore.kernel.org/r/1611997513-27107-1-git-send-email-liweihang@huawei.comSigned-off-by:
Yixing Liu <liuyixing1@huawei.com> Signed-off-by:
Lang Cheng <chenglang@huawei.com> Signed-off-by:
Weihang Li <liweihang@huawei.com> Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com>
-
Kamal Heib authored
The size of tx_valid_cpus was calculated under the assumption that the numa nodes identifiers are continuous, which is not the case in all archs as this could lead to the following panic when trying to access an invalid tx_valid_cpus index, avoid the following panic by using nr_node_ids instead of num_online_nodes() to allocate the tx_valid_cpus size. Kernel attempted to read user page (8) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000008 Faulting instruction address: 0xc0080000081b4a90 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: siw(+) rfkill rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm sunrpc ib_umad rdma_cm ib_cm iw_cm i40iw ib_uverbs ib_core i40e ses enclosure scsi_transport_sas ipmi_powernv ibmpowernv at24 ofpart ipmi_devintf regmap_i2c ipmi_msghandler powernv_flash uio_pdrv_genirq uio mtd opal_prd zram ip_tables xfs libcrc32c sd_mod t10_pi ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm drm vmx_crypto aacraid drm_panel_orientation_quirks dm_mod CPU: 40 PID: 3279 Comm: modprobe Tainted: G W X --------- --- 5.11.0-0.rc4.129.eln108.ppc64le #2 NIP: c0080000081b4a90 LR: c0080000081b4a2c CTR: c0000000007ce1c0 REGS: c000000027fa77b0 TRAP: 0300 Tainted: G W X --------- --- (5.11.0-0.rc4.129.eln108.ppc64le) MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 44224882 XER: 00000000 CFAR: c0000000007ce200 DAR: 0000000000000008 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000081b4a2c c000000027fa7a50 c0080000081c3900 0000000000000040 GPR04: c000000002023080 c000000012e1c300 000020072ad70000 0000000000000001 GPR08: c000000001726068 0000000000000008 0000000000000008 c0080000081b5758 GPR12: c0000000007ce1c0 c0000007fffc3000 00000001590b1e40 0000000000000000 GPR16: 0000000000000000 0000000000000001 000000011ad68fc8 00007fffcc09c5c8 GPR20: 0000000000000008 0000000000000000 00000001590b2850 00000001590b1d30 GPR24: 0000000000043d68 000000011ad67a80 000000011ad67a80 0000000000100000 GPR28: c000000012e1c300 c0000000020271c8 0000000000000001 c0080000081bf608 NIP [c0080000081b4a90] siw_init_cpulist+0x194/0x214 [siw] LR [c0080000081b4a2c] siw_init_cpulist+0x130/0x214 [siw] Call Trace: [c000000027fa7a50] [c0080000081b4a2c] siw_init_cpulist+0x130/0x214 [siw] (unreliable) [c000000027fa7a90] [c0080000081b4e68] siw_init_module+0x40/0x2a0 [siw] [c000000027fa7b30] [c0000000000124f4] do_one_initcall+0x84/0x2e0 [c000000027fa7c00] [c000000000267ffc] do_init_module+0x7c/0x350 [c000000027fa7c90] [c00000000026a180] __do_sys_init_module+0x210/0x250 [c000000027fa7db0] [c0000000000387e4] system_call_exception+0x134/0x230 [c000000027fa7e10] [c00000000000d660] system_call_common+0xf0/0x27c Instruction dump: 40810044 3d420000 e8bf0000 e88a82d0 3d420000 e90a82c8 792a1f24 7cc4302a 7d2642aa 79291f24 7d25482a 7d295214 <7d4048a8> 7d4a3b78 7d4049ad 40c2fff4 Fixes: bdcf26bf ("rdma/siw: network and RDMA core interface") Link: https://lore.kernel.org/r/20210201112922.141085-1-kamalheib1@gmail.comSigned-off-by:
Kamal Heib <kamalheib1@gmail.com> Reviewed-by:
Bernard Metzler <bmt@zurich.ibm.com> Tested-by:
Yi Zhang <yi.zhang@redhat.com> Signed-off-by:
-
- 08 Feb, 2021 13 commits
-
-
Wenpeng Liang authored
The post_recv only supports QP types of RC, GSI and UD. Link: https://lore.kernel.org/r/1611997090-48820-13-git-send-email-liweihang@huawei.comSigned-off-by:
Wenpeng Liang <liangwenpeng@huawei.com> Signed-off-by:
-
Wenpeng Liang authored
The SRQ in the hns driver consists of the following four parts: * wqe buf: the buffer to store WQE. * wqe_idx buf: the cqe of SRQ may be not generated in the order of wqe, so the wqe_idx corresponding to the idle WQE needs to be pushed into the index queue which is a FIFO, then it instructs the hardware to obtain the corresponding WQE. * bitmap: bitmap is used to generate and release wqe_idx. When the user has a new WR, the driver finds the idx of the idle wqe in bitmap. When the CQE of wqe is generated, the driver will release the idx. * wr_id buf: wr_id buf is used to store the user's wr_id, then return it to the user when poll_cq verb is invoked. The process of post SRQ recv is refactored to make preceding code clearer. Link: https://lore.kernel.org/r/1611997090-48820-12-git-send-email-liweihang@huawei.comSigned-off-by:
-
Xi Wang authored
The HIP09 requires the driver to clear the unused data segments in wqe buffer to make the hns ROCEE stop reading the remaining invalid sges for RQ. Link: https://lore.kernel.org/r/1611997090-48820-11-git-send-email-liweihang@huawei.comSigned-off-by:
Xi Wang <wangxi11@huawei.com> Signed-off-by:
-
Xi Wang authored
Refactor post recv flow by removing unnecessary checking and removing duplicated code. Link: https://lore.kernel.org/r/1611997090-48820-10-git-send-email-liweihang@huawei.comSigned-off-by:
-
Lang Cheng authored
Use new register operation interfaces to simplify the process of write SRQ Context. Link: https://lore.kernel.org/r/1611997090-48820-9-git-send-email-liweihang@huawei.comSigned-off-by:
-
Wenpeng Liang authored
Reduce parameter numbers of write_srqc() and move some related code into it from alloc_srqc(). Link: https://lore.kernel.org/r/1611997090-48820-8-git-send-email-liweihang@huawei.comSigned-off-by:
-
Wenpeng Liang authored
Split the SRQ creation process into multiple steps and encapsulate them into functions. Link: https://lore.kernel.org/r/1611997090-48820-7-git-send-email-liweihang@huawei.comSigned-off-by:
-
Wenpeng Liang authored
Each SRQs contain an reserved WQE, it is inappropriate and should be removed. Fixes: c7bcb134 ("RDMA/hns: Add SRQ support for hip08 kernel mode") Link: https://lore.kernel.org/r/1611997090-48820-6-git-send-email-liweihang@huawei.comSigned-off-by:
-
Wenpeng Liang authored
When an error occurs, the qp_table must be cleared, regardless of whether the SRQ feature is enabled. Fixes: 5c1f167a ("RDMA/hns: Init SRQ table for hip08") Link: https://lore.kernel.org/r/1611997090-48820-5-git-send-email-liweihang@huawei.comSigned-off-by:
-
Wenpeng Liang authored
According to the IB Specification, srq_limit shouldn't be configured during SRQ creation. If a user set srq_limit at this time, the driver should forced it to zero, or the result of creating SRQ will conflict with the result of querying SRQ. Fixes: c7bcb134 ("RDMA/hns: Add SRQ support for hip08 kernel mode") Link: https://lore.kernel.org/r/1611997090-48820-4-git-send-email-liweihang@huawei.comSigned-off-by:
-
Wenpeng Liang authored
If a user posts WR by wr_list, the head pointer of idx_queue won't be updated until all wqes are filled, so the judgment of whether head equals to tail will get a wrong result. Fix above issue and move the head and tail pointer from the srq structure into the idx_queue structure. After idx_queue is filled with wqe idx, the head pointer of it will increase. Fixes: c7bcb134 ("RDMA/hns: Add SRQ support for hip08 kernel mode") Link: https://lore.kernel.org/r/1611997090-48820-3-git-send-email-liweihang@huawei.comSigned-off-by:
-
Lang Cheng authored
The RQ/SRQ of HIP08 needs one special sge to stop receive reliably. So the driver needs to allocate at least one SGE when creating RQ/SRQ and ensure that at least one SGE is filled with the special value during post_recv. Besides, the kernel driver should only do this for kernel ULP. For userspace ULP, the userspace driver will allocate the reserved SGE in buffer, and the kernel driver just needs to pin the corresponding size of memory based on the userspace driver's requirements. Link: https://lore.kernel.org/r/1611997090-48820-2-git-send-email-liweihang@huawei.comSigned-off-by:
-
Bob Pearson authored
rxe_udp_encap_recv() drops the reference to rxe->ib_dev taken by rxe_get_dev_from_net() which should be held until each received skb is freed. This patch moves the calls to ib_device_put() to each place a received skb is freed. It also takes references to the ib_device for each cloned skb created to process received multicast packets. Fixes: 4c173f59 ("RDMA/rxe: Use ib_device_get_by_netdev() instead of open coding") Link: https://lore.kernel.org/r/20210128233318.2591-1-rpearson@hpe.comSigned-off-by:
Bob Pearson <rpearson@hpe.com> Signed-off-by:
-
- 05 Feb, 2021 10 commits
-
-
Bob Pearson authored
rxe_net.c sends packets at the IP layer with skb->data pointing at the IP header but receives packets from a UDP tunnel with skb->data pointing at the UDP header. On the loopback path this was not correctly accounted for. This patch corrects for this by using sbk_pull() to strip the IP header from the skb on received packets. Fixes: 8700e3e7 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20210128182301.16859-1-rpearson@hpe.comSigned-off-by:
-
Bob Pearson authored
rxe_rcv_mcast_pkt() in rxe_recv.c can leak SKBs in error path code. The loop over the QPs attached to a multicast group creates new cloned SKBs for all but the last QP in the list and passes the SKB and its clones to rxe_rcv_pkt() for further processing. Any QPs that do not pass some checks are skipped. If the last QP in the list fails the tests the SKB is leaked. This patch checks if the SKB for the last QP was used and if not frees it. Also removes a redundant loop invariant assignment. Fixes: 8700e3e7 ("Soft RoCE driver") Fixes: 71abf20b ("RDMA/rxe: Handle skb_clone() failure in rxe_recv.c") Link: https://lore.kernel.org/r/20210128174752.16128-1-rpearson@hpe.comSigned-off-by:
-
Bob Pearson authored
In check_keys() in rxe_recv.c if ((...) && pkt->mask) { ... } always has pkt->mask non zero since in rxe_udp_encap_recv() pkt->mask is always set to RXE_GRH_MASK (!= 0). There is no obvious reason for this additional test and the original intent is lost. This patch simplifies the expression. Fixes: 8b7b59d0 ("IB/rxe: remove redudant qpn check") Link: https://lore.kernel.org/r/20210127224203.2812-1-rpearson@hpe.comSigned-off-by: -
Bob Pearson authored
check_type_state() in rxe_recv.c is written as if the type bits in the packet opcode were a bit mask which is not correct. This patch corrects this code to compare all 3 type bits to the required type. Fixes: 8700e3e7 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20210127214500.3707-1-rpearson@hpe.comSigned-off-by:
-
Parav Pandit authored
Instead of open coding the loop for port iteration, use rdma_for_each_port macro provided by core. To use such macro, early initialization of phys_port_cnt is needed. Hence, initialize such constant early enough in the init stage. Whichever functions are called with port using rdma_for_each_port(), convert their port type from u8 to unsigned int to match the core API. Link: https://lore.kernel.org/r/20210203130133.4057329-6-leon@kernel.orgSigned-off-by:
Parav Pandit <parav@nvidia.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Parav Pandit authored
Currently mlx5 driver caches port GID table length for 2 ports. It is also cached by IB core as port immutable data. When mlx5 representor ports are present, which are usually more than 2, invalid access to port_caps array can happen while validating the GID table length which is only for 2 ports. To avoid this, take help of the IB cores port immutable data by exposing an API to read the port immutable fields. Remove mlx5 driver's internal cache, thereby reduce code and data. Link: https://lore.kernel.org/r/20210203130133.4057329-5-leon@kernel.orgSigned-off-by:
-
Parav Pandit authored
Improve query port functionality for representor port as below. 1. RoCE Qkey violation counters are not applicable for representor port. 2. Avoid setting gid_tbl_len twice for representor port. 3. Avoid setting ip_gids and IB_PORT_CM_SUP property for representor port as GID table is empty and CM support is not present in representor mode. Link: https://lore.kernel.org/r/20210203130133.4057329-4-leon@kernel.orgSigned-off-by:
-
Parav Pandit authored
Pkey table length for all the ports of the device is the same. Currently get_ports_cap() reads and stores it for each port by querying the device which reads more than just pkey table length. For representor device ports which can be in range of hundreds, it queries is for each such port and end up returning same value for all the ports. When in representor mode, modify QP accesses pkey port caps for a port index that can be outside of the port_caps table. Hence, simplify the logic to query the max pkey table length only once during device initialization sequence. Link: https://lore.kernel.org/r/20210203130133.4057329-3-leon@kernel.orgSigned-off-by:
-
Parav Pandit authored
mlx5_port_caps are RDMA specific capabilities. These are not used by the mlx5_core_device at all. Move them to mlx5_ib_dev where it is used and reduce the scope of it to multiple drivers. Link: https://lore.kernel.org/r/20210203130133.4057329-2-leon@kernel.orgSigned-off-by:
-
Weihang Li authored
There is no need to do irqsave and irqrestore in context of hard IRQ. Link: https://lore.kernel.org/r/1612514278-49220-1-git-send-email-liweihang@huawei.comSigned-off-by:
-
- 02 Feb, 2021 5 commits
-
-
Parav Pandit authored
Representor port has only one default pkey. Hence have simpler query pkey callback or it. Link: https://lore.kernel.org/r/20210127150010.1876121-4-leon@kernel.orgSigned-off-by:
-
Parav Pandit authored
IB HCA port starts from 1. Use IB core provided port iterator API to avoid any assumption with start port number. Link: https://lore.kernel.org/r/20210127150010.1876121-11-leon@kernel.orgSigned-off-by:
-
Parav Pandit authored
Use IB core provided routine to check if the port is valid or not and to iterate over IB ports. Link: https://lore.kernel.org/r/20210127150010.1876121-10-leon@kernel.orgSigned-off-by:
-
Parav Pandit authored
When RDMA device has 255 ports, loop iterator i overflows. Due to which cm_add_one() port iterator loops infinitely. Use core provided port iterator to avoid the infinite loop. Fixes: a977049d ("[PATCH] IB: Add the kernel CM implementation") Link: https://lore.kernel.org/r/20210127150010.1876121-9-leon@kernel.orgSigned-off-by:
Mark Bloch <mbloch@nvidia.com> Signed-off-by:
-
Parav Pandit authored
When mlx5_ib_stage_init_init() fails, return the error code related to failure instead of -ENOMEM. Fixes: 16c1975f ("IB/mlx5: Create profile infrastructure to add and remove stages") Link: https://lore.kernel.org/r/20210127150010.1876121-8-leon@kernel.orgSigned-off-by:
-
- 28 Jan, 2021 10 commits
-
-
Gal Pressman authored
The notification syndrome enum values are unused, remove them. Link: https://lore.kernel.org/r/20210126120702.9807-6-galpress@amazon.comReviewed-by:
Firas JahJah <firasj@amazon.com> Signed-off-by:
Gal Pressman <galpress@amazon.com> Signed-off-by:
-
Gal Pressman authored
The 'select' field in the get/set feature admin command is unimplemented, unused and misleading, remove it. The command always refers to the current values. Link: https://lore.kernel.org/r/20210126120702.9807-5-galpress@amazon.comReviewed-by:
Yossi Leybovich <sleybo@amazon.com> Signed-off-by:
-
Gal Pressman authored
The indentation in the subsequent comment lines is unnecessary, remove it. Link: https://lore.kernel.org/r/20210126120702.9807-4-galpress@amazon.comReviewed-by:
-
Gal Pressman authored
The EFA_DMA_ADDR_TO_UINT32_HIGH/LOW macros are the same as the kernel's upper/lower_32_bits, remove them and use kernel macros instead. Link: https://lore.kernel.org/r/20210126120702.9807-3-galpress@amazon.comReviewed-by:
-
Gal Pressman authored
A pointer to store the command completion must be provided as it is always used in efa_com_put_comp_ctx() to return the completion context back to the pool. Remove the NULL pointer check and the redundant 'status' field stored on the context as it could be retrieved from the completion itself. Link: https://lore.kernel.org/r/20210126120702.9807-2-galpress@amazon.comReviewed-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/infiniband/hw/hfi1/rc.c:1388: warning: Function parameter or member 'packet' not described in 'hfi1_send_rc_ack' drivers/infiniband/hw/hfi1/rc.c:1388: warning: Function parameter or member 'is_fecn' not described in 'hfi1_send_rc_ack' drivers/infiniband/hw/hfi1/rc.c:1388: warning: Excess function parameter 'qp' description in 'hfi1_send_rc_ack' Link: https://lore.kernel.org/r/20210126124732.3320971-21-lee.jones@linaro.org Cc: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: linux-rdma@vger.kernel.org Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/infiniband/hw/hfi1/verbs.c:741: warning: Function parameter or member 'qp' not described in 'update_tx_opstats' drivers/infiniband/hw/hfi1/verbs.c:1160: warning: Function parameter or member 'pkey' not described in 'egress_pkey_check' drivers/infiniband/hw/hfi1/verbs.c:1160: warning: Excess function parameter 'bkey' description in 'egress_pkey_check' drivers/infiniband/hw/hfi1/verbs.c:1217: warning: Function parameter or member 'qp' not described in 'get_send_routine' drivers/infiniband/hw/hfi1/verbs.c:1217: warning: Function parameter or member 'ps' not described in 'get_send_routine' Link: https://lore.kernel.org/r/20210126124732.3320971-20-lee.jones@linaro.org Cc: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: linux-rdma@vger.kernel.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/infiniband/hw/hfi1/user_exp_rcv.c:174: warning: Function parameter or member 'fd' not described in 'unpin_rcv_pages' drivers/infiniband/hw/hfi1/user_exp_rcv.c:174: warning: Function parameter or member 'tidbuf' not described in 'unpin_rcv_pages' drivers/infiniband/hw/hfi1/user_exp_rcv.c:174: warning: Function parameter or member 'node' not described in 'unpin_rcv_pages' drivers/infiniband/hw/hfi1/user_exp_rcv.c:174: warning: Function parameter or member 'idx' not described in 'unpin_rcv_pages' drivers/infiniband/hw/hfi1/user_exp_rcv.c:174: warning: Function parameter or member 'npages' not described in 'unpin_rcv_pages' drivers/infiniband/hw/hfi1/user_exp_rcv.c:174: warning: Function parameter or member 'mapped' not described in 'unpin_rcv_pages' drivers/infiniband/hw/hfi1/user_exp_rcv.c:196: warning: Function parameter or member 'fd' not described in 'pin_rcv_pages' drivers/infiniband/hw/hfi1/user_exp_rcv.c:196: warning: Function parameter or member 'tidbuf' not described in 'pin_rcv_pages' Link: https://lore.kernel.org/r/20210126124732.3320971-19-lee.jones@linaro.org Cc: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: linux-rdma@vger.kernel.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/infiniband/hw/hfi1/ud.c:477: warning: Function parameter or member 'ps' not described in 'hfi1_make_ud_req' drivers/infiniband/hw/hfi1/ud.c:855: warning: Function parameter or member 'packet' not described in 'hfi1_ud_rcv' drivers/infiniband/hw/hfi1/ud.c:855: warning: Excess function parameter 'ibp' description in 'hfi1_ud_rcv' drivers/infiniband/hw/hfi1/ud.c:855: warning: Excess function parameter 'hdr' description in 'hfi1_ud_rcv' drivers/infiniband/hw/hfi1/ud.c:855: warning: Excess function parameter 'rcv_flags' description in 'hfi1_ud_rcv' drivers/infiniband/hw/hfi1/ud.c:855: warning: Excess function parameter 'data' description in 'hfi1_ud_rcv' drivers/infiniband/hw/hfi1/ud.c:855: warning: Excess function parameter 'tlen' description in 'hfi1_ud_rcv' drivers/infiniband/hw/hfi1/ud.c:855: warning: Excess function parameter 'qp' description in 'hfi1_ud_rcv' Link: https://lore.kernel.org/r/20210126124732.3320971-18-lee.jones@linaro.org Cc: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: linux-rdma@vger.kernel.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/infiniband/hw/hfi1/uc.c:64: warning: Function parameter or member 'ps' not described in 'hfi1_make_uc_req' drivers/infiniband/hw/hfi1/uc.c:306: warning: Function parameter or member 'packet' not described in 'hfi1_uc_rcv' drivers/infiniband/hw/hfi1/uc.c:306: warning: Excess function parameter 'ibp' description in 'hfi1_uc_rcv' drivers/infiniband/hw/hfi1/uc.c:306: warning: Excess function parameter 'hdr' description in 'hfi1_uc_rcv' drivers/infiniband/hw/hfi1/uc.c:306: warning: Excess function parameter 'rcv_flags' description in 'hfi1_uc_rcv' drivers/infiniband/hw/hfi1/uc.c:306: warning: Excess function parameter 'data' description in 'hfi1_uc_rcv' drivers/infiniband/hw/hfi1/uc.c:306: warning: Excess function parameter 'tlen' description in 'hfi1_uc_rcv' drivers/infiniband/hw/hfi1/uc.c:306: warning: Excess function parameter 'qp' description in 'hfi1_uc_rcv' Link: https://lore.kernel.org/r/20210126124732.3320971-17-lee.jones@linaro.org Cc: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: linux-rdma@vger.kernel.org Signed-off-by:
-
