- 16 Feb, 2021 10 commits
-
-
Avihai Horon authored
ucma_process_join() allocates struct ucma_multicast mc and frees it if an error occurs during its run. Specifically, if an error occurs in copy_to_user(), a use-after-free might happen in the following scenario: 1. mc struct is allocated. 2. rdma_join_multicast() is called and succeeds. During its run, cma_iboe_join_multicast() enqueues a work that will later use the aforementioned mc struct. 3. copy_to_user() is called and fails. 4. mc struct is deallocated. 5. The work that was enqueued by cma_iboe_join_multicast() is run and calls ucma_create_uevent() which tries to access mc struct (which is freed by now). Fix this bug by cancelling the work enqueued by cma_iboe_join_multicast(). Since cma_work_handler() frees struct cma_work, we don't use it in cma_iboe_join_multicast() so we can safely cancel the work later. The following syzkaller report revealed it: BUG: KASAN: use-after-free in ucma_create_uevent+0x2dd/0x;3f0 drivers/infiniband/core/ucma.c:272 Read of size 8 at addr ffff88810b3ad110 by task kworker/u8:1/108 CPU: 1 PID: 108 Comm: kworker/u8:1 Not tainted 5.10.0-rc6+ #257 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: rdma_cm cma_work_handler Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xbe/0xf9 lib/dump_stack.c:118 print_address_description.constprop.0+0x3e/0×60 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report.cold+0x1f/0×37 mm/kasan/report.c:562 ucma_create_uevent+0x2dd/0×3f0 drivers/infiniband/core/ucma.c:272 ucma_event_handler+0xb7/0×3c0 drivers/infiniband/core/ucma.c:349 cma_cm_event_handler+0x5d/0×1c0 drivers/infiniband/core/cma.c:1977 cma_work_handler+0xfa/0×190 drivers/infiniband/core/cma.c:2718 process_one_work+0x54c/0×930 kernel/workqueue.c:2272 worker_thread+0x82/0×830 kernel/workqueue.c:2418 kthread+0x1ca/0×220 kernel/kthread.c:292 ret_from_fork+0x1f/0×30 arch/x86/entry/entry_64.S:296 Allocated by task 359: kasan_save_stack+0x1b/0×40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:461 [inline] __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:434 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:664 [inline] ucma_process_join+0x16e/0×3f0 drivers/infiniband/core/ucma.c:1453 ucma_join_multicast+0xda/0×140 drivers/infiniband/core/ucma.c:1538 ucma_write+0x1f7/0×280 drivers/infiniband/core/ucma.c:1724 vfs_write fs/read_write.c:603 [inline] vfs_write+0x191/0×4c0 fs/read_write.c:585 ksys_write+0x1a1/0×1e0 fs/read_write.c:658 do_syscall_64+0x2d/0×40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 359: kasan_save_stack+0x1b/0×40 mm/kasan/common.c:48 kasan_set_track+0x1c/0×30 mm/kasan/common.c:56 kasan_set_free_info+0x1b/0×30 mm/kasan/generic.c:355 __kasan_slab_free+0x112/0×160 mm/kasan/common.c:422 slab_free_hook mm/slub.c:1544 [inline] slab_free_freelist_hook mm/slub.c:1577 [inline] slab_free mm/slub.c:3142 [inline] kfree+0xb3/0×3e0 mm/slub.c:4124 ucma_process_join+0x22d/0×3f0 drivers/infiniband/core/ucma.c:1497 ucma_join_multicast+0xda/0×140 drivers/infiniband/core/ucma.c:1538 ucma_write+0x1f7/0×280 drivers/infiniband/core/ucma.c:1724 vfs_write fs/read_write.c:603 [inline] vfs_write+0x191/0×4c0 fs/read_write.c:585 ksys_write+0x1a1/0×1e0 fs/read_write.c:658 do_syscall_64+0x2d/0×40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff88810b3ad100 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 16 bytes inside of 192-byte region [ffff88810b3ad100, ffff88810b3ad1c0) Fixes: b5de0c60 ("RDMA/cma: Fix use after free race in roce multicast join") Link: https://lore.kernel.org/r/20210211090517.1278415-1-leon@kernel.orgReported-by:Amit Matityahu <mitm@nvidia.com> Signed-off-by:
Avihai Horon <avihaih@nvidia.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com>
-
Leon Romanovsky authored
drivers/infiniband/core/device.c:859: warning: Function parameter or member 'dev' not described in 'ib_port_immutable_read' drivers/infiniband/core/device.c:859: warning: Function parameter or member 'port' not described in 'ib_port_immutable_read' Fixes: 7416790e ("RDMA/core: Introduce and use API to read port immutable data") Link: https://lore.kernel.org/r/20210210151421.1108809-1-leon@kernel.orgReported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Jiapeng Chong authored
Fix the following coccicheck warning: ./drivers/infiniband/hw/qedr/qedr.h:629:9-10: WARNING: return of 0/1 in function 'qedr_qp_has_rq' with return type bool. ./drivers/infiniband/hw/qedr/qedr.h:620:9-10: WARNING: return of 0/1 in function 'qedr_qp_has_sq' with return type bool. Link: https://lore.kernel.org/r/1612949901-109873-1-git-send-email-jiapeng.chong@linux.alibaba.com Reported-by: Abaci Robot<abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Acked-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by:
-
Yixing Liu authored
FRMR is not well-supported on HIP08, it is re-designed for HIP09 and the position of related fields is changed. Then the ULPs should be forbidden to use FRMR on older hardwares. Link: https://lore.kernel.org/r/1612924424-28217-1-git-send-email-liweihang@huawei.comSigned-off-by:
Yixing Liu <liuyixing1@huawei.com> Signed-off-by:
Weihang Li <liweihang@huawei.com> Signed-off-by:
-
Lang Cheng authored
Simplify __hns_roce_cmq_send() then remove the redundant variables. Link: https://lore.kernel.org/r/1612688143-28226-6-git-send-email-liweihang@huawei.comSigned-off-by:
Lang Cheng <chenglang@huawei.com> Signed-off-by:
-
Lang Cheng authored
The register 0x07014 is actually the head pointer of CMDQ, and 0x07010 means tail pointer. Current definitions are confusing, so rename them and related variables. The next_to_use of structure hns_roce_v2_cmq_ring has the same semantics as head, merge them into one member. The next_to_clean of structure hns_roce_v2_cmq_ring has the same semantics as tail. After deleting next_to_clean, tail should also be deleted. Link: https://lore.kernel.org/r/1612688143-28226-5-git-send-email-liweihang@huawei.comSigned-off-by:
-
Lang Cheng authored
CMDQ works serially, after each successful transmission, the head and tail pointers will be equal, so there is no need to check whether the queue is full. At the same time, since the descriptor of each transmission is new, there is no need to perform a cleanup operation. Then, the field named next_to_clean in structure hns_roce_v2_cmq_ring is redundant. Fixes: a04ff739 ("RDMA/hns: Add command queue support for hip08 RoCE driver") Link: https://lore.kernel.org/r/1612688143-28226-4-git-send-email-liweihang@huawei.comSigned-off-by:
-
Lang Cheng authored
When posting a multi-descriptors command, the error code of previous failed descriptors may be rewrote to 0 by a later successful descriptor. Fixes: a04ff739 ("RDMA/hns: Add command queue support for hip08 RoCE driver") Link: https://lore.kernel.org/r/1612688143-28226-3-git-send-email-liweihang@huawei.comSigned-off-by:
-
Lang Cheng authored
last_status of structure hns_roce_v2_cmq has never been used, and the variable named 'complete' in __hns_roce_cmq_send() is meaningless. Fixes: a04ff739 ("RDMA/hns: Add command queue support for hip08 RoCE driver") Link: https://lore.kernel.org/r/1612688143-28226-2-git-send-email-liweihang@huawei.comSigned-off-by:
-
Christoph Lameter authored
When a system receives a REREG event from the SM, then the SM information in the kernel is marked as invalid and a request is sent to the SM to update the information. The SM information is invalid in that time period. However, receiving a REREG also occurs simultaneously in user space applications that are now trying to rejoin the multicast groups. Some of those may be sendonly multicast groups which are then failing. If the SM information is invalid then ib_sa_sendonly_fullmem_support() returns false. That is wrong because it just means that we do not know yet if the potentially new SM supports sendonly joins. Sendonly join was introduced in 2015 and all the Subnet managers have supported it ever since. So there is no point in checking if a subnet manager supports it. Should an old opensm get a request for a sendonly join then the request will fail. The code that is removed here accomodated that situation and fell back to a full join. Falling back to a full join is problematic in itself. The reason to use the sendonly join was to reduce the traffic on the Infiniband fabric otherwise one could have just stayed with the regular join. So this patch may cause users of very old opensms to discover that lots of traffic needlessly crosses their IB fabrics. Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2101281845160.13303@www.lameter.comSigned-off-by:
Christoph Lameter <cl@linux.com> Signed-off-by:
-
- 09 Feb, 2021 18 commits
-
-
Patrisious Haddad authored
Support 400Gbps IB rate in mlx5 driver. Link: https://lore.kernel.org/r/20210209130429.698237-1-leon@kernel.orgSigned-off-by:
Patrisious Haddad <phaddad@nvidia.com> Signed-off-by:
Mark Zhang <markzhang@nvidia.com> Reviewed-by:
Maor Gottlieb <maorg@nvidia.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
qedr_gsi_post_send() has a debug output which prints the return value of in_irq() and irqs_disabled(). The result of the in_irq(), even if invoked from an interrupt handler, is subject to change depending on the `threadirqs' command line switch. The result of irqs_disabled() is always be 1 because the function acquires spinlock_t with spin_lock_irqsave(). Remove in_irq() and irqs_disabled() from the debug output because it provides little value. Link: https://lore.kernel.org/r/20210208193347.383254-1-bigeasy@linutronix.deSigned-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Bob Pearson authored
This patch changes the type of init_send_wqe in rxe_verbs.c to void since it always returns 0. It also separates out the code that copies inline data into the send wqe as copy_inline_data_to_wqe(). Link: https://lore.kernel.org/r/20210206002437.2756-1-rpearson@hpe.comSigned-off-by:
Bob Pearson <rpearson@hpe.com> Signed-off-by:
-
Bob Pearson authored
checkpatch -f found 3 warnings in RDMA/rxe 1. a missing space following switch 2. return followed by else 3. use of strlcpy() instead of strscpy(). This patch fixes each of these. In ... } elseif (...) { ... return 0; } else ... The middle block can be safely moved since it is completely independent of the other code. Link: https://lore.kernel.org/r/20210205230525.49068-1-rpearson@hpe.comSigned-off-by: -
Yishai Hadas authored
Cleanup the synchronize_srcu() from the ODP flow as it was found to be a very heavy time consumer as part of dereg_mr. For example de-registration of 10000 ODP MRs each with size of 2M hugepage took 19.6 sec comparing de-registration of same number of non ODP MRs that took 172 ms. The new locking scheme uses the wait_event() mechanism which follows the use count of the MR instead of using synchronize_srcu(). By that change, the time required for the above test took 95 ms which is even better than the non ODP flow. Once fully dropped the srcu usage, had to come with a lock to protect the XA access. As part of using the above mechanism we could also clean the num_deferred_work stuff and follow the use count instead. Link: https://lore.kernel.org/r/20210202071309.2057998-1-leon@kernel.orgSigned-off-by:
Yishai Hadas <yishaih@nvidia.com> Signed-off-by:
-
Xinhao Liu authored
There is no need to use a for loop to assign values for an array of cmd descriptors which has only two elements. Link: https://lore.kernel.org/r/1612517974-31867-13-git-send-email-liweihang@huawei.comSigned-off-by:
Xinhao Liu <liuxinhao5@hisilicon.com> Signed-off-by:
-
Yixian Liu authored
The hns driver wrap around the consumer index of AEQ and CEQ when they reach to two times of queue entries number for owner mechanism, actually, it is unnecessary to wrap around since the hardware itself will mask it before use. Link: https://lore.kernel.org/r/1612517974-31867-12-git-send-email-liweihang@huawei.comSigned-off-by:
Yixian Liu <liuyixian@huawei.com> Signed-off-by:
-
Lang Cheng authored
All fields of WQE will be rewrote, so the memset is unnecessary. And when SQ is working in OWNER mode, the pipeline may prefetch the WQEs beyond PI, the memset operation may flip the owner bit too early, then the pipeline may get a wrong WQ. Link: https://lore.kernel.org/r/1612517974-31867-11-git-send-email-liweihang@huawei.comSigned-off-by:
-
Xinhao Liu authored
Use macros instead of magic numbers to represent shift of dma_handle_wqe, dma_handle_idx and UDP destination port number of RoCEv2. Link: https://lore.kernel.org/r/1612517974-31867-10-git-send-email-liweihang@huawei.comSigned-off-by:
-
Lang Cheng authored
hns_roce_device.h is not specific to hardware, some definitions are only used for HIP06, they should be moved into hns_roce_hw_v1.h. Link: https://lore.kernel.org/r/1612517974-31867-9-git-send-email-liweihang@huawei.comSigned-off-by:
-
Lang Cheng authored
Currently, the driver updates doorbell looks like this: post() { wqe.field = 0x111; wmb(); update_wq_db(); } update_wq_db() { db.field = 0x222; __raw_writeq(db, db_reg); } writeq() is a better choice than __raw_writeq() because it calls dma_wmb() to barrier in ARM64, and dma_wmb() is better than wmb() for ROCEE device. This patch removes all wmb() before updating doorbell of SQ/RQ/CQ/SRQ by replacing __raw_writeq() with writeq() to improve performence. The new process looks like this: post() { wqe.field = 0x111; update_wq_db(); } update_wq_db() { db.field = 0x222; writeq(db, db_reg); } Link: https://lore.kernel.org/r/1612517974-31867-8-git-send-email-liweihang@huawei.comSigned-off-by: -
Yixing Liu authored
Since HIP09 does not require this function, it should be masked. Link: https://lore.kernel.org/r/1612517974-31867-7-git-send-email-liweihang@huawei.comSigned-off-by:
-
Lijun Ou authored
This feature should only be enabled by querying capability from firmware. Fixes: ba6bb7e9 ("RDMA/hns: Add interfaces to get pf capabilities from firmware") Link: https://lore.kernel.org/r/1612517974-31867-5-git-send-email-liweihang@huawei.comSigned-off-by:
Lijun Ou <oulijun@huawei.com> Signed-off-by:
-
Xi Wang authored
Add the mapped page count checking flow to avoid invalid page size when creating MTR. Fixes: 38389eaa ("RDMA/hns: Add mtr support for mixed multihop addressing") Link: https://lore.kernel.org/r/1612517974-31867-4-git-send-email-liweihang@huawei.comSigned-off-by:
Xi Wang <wangxi11@huawei.com> Signed-off-by:
-
Weihang Li authored
This bit should be in type of enum ib_sig_type, or there will be a sparse warning. Fixes: bfe86035 ("RDMA/hns: Fix cast from or to restricted __le32 for driver") Link: https://lore.kernel.org/r/1612517974-31867-3-git-send-email-liweihang@huawei.comReported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Weihang Li authored
ULP usually set IB(V)_QP_AV when trying to modify QP to RTR if they want to record sgid index into QPC. For UD QPs, it is useless because it will be included in WQE. For RC QPs, it will be filled in hns_roce_set_path(). So sgid index shouldn't be filled by default. Then hns_get_gid_index() is moved to hns_roce_hw_v1.c because it is only called in it. Fixes: 926a01dc ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1612517974-31867-2-git-send-email-liweihang@huawei.comSigned-off-by:
-
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:
-
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 12 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 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:
-
