- 02 Jun, 2021 9 commits
-
-
Mark Zhang authored
During cm_dev deregistration in cm_remove_one(), the cm_device and cm_ports will be freed, after that they should not be accessed. The mad_agent needs to be protected as well. This patch adds a cm_device kref to protect cm_dev and cm_ports, and a mad_agent_lock spinlock to protect mad_agent. Link: https://lore.kernel.org/r/501ba7a2ff203dccd0e6755d3f93329772adce52.1622629024.git.leonro@nvidia.comSigned-off-by:
Mark Zhang <markzhang@nvidia.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com>
-
Mark Zhang authored
The cm_init_av_for_lap() and cm_init_av_by_path() function calls have the following issues: 1. Both of them might sleep and should not be called under spinlock. 2. The access of cm_id_priv->av should be under cm_id_priv->lock, which means it can't be initialized directly. This patch splits the calling of 2 functions into two parts: first one initializes an AV outside of the spinlock, the second one copies AV to cm_id_priv->av under spinlock. Fixes: e1444b5a ("IB/cm: Fix automatic path migration support") Link: https://lore.kernel.org/r/038fb8ad932869b4548b0c7708cab7f76af06f18.1622629024.git.leonro@nvidia.comSigned-off-by:
-
Mark Zhang authored
The mad_agent parameter is redundant since the struct ib_mad_send_buf already has a pointer of it. Link: https://lore.kernel.org/r/0987c784b25f7bfa72f78691f50cff066de587e1.1622629024.git.leonro@nvidia.comSigned-off-by:
-
Mark Zhang authored
This reverts commit 9db0ff53, which wasn't a full fix and still causes to the following panic: panic @ time 1605623870.843, thread 0xfffffeb63b552000: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe811a94e000 time = 1605623870 cpuid = 9, TSC = 0xb7937acc1b6 Panic occurred in module kernel loaded at 0xffffffff80200000:Stack: -------------------------------------------------- kernel:vm_fault+0x19da kernel:vm_fault_trap+0x6e kernel:trap_pfault+0x1f1 kernel:trap+0x31e kernel:cm_destroy_id+0x38c kernel:rdma_destroy_id+0x127 kernel:sdp_shutdown_task+0x3ae kernel:taskqueue_run_locked+0x10b kernel:taskqueue_thread_loop+0x87 kernel:fork_exit+0x83 Link: https://lore.kernel.org/r/4346449a7cdacc7a4eedc89cb1b42d8434ec9814.1622629024.git.leonro@nvidia.comSigned-off-by:
-
Jason Gunthorpe authored
Now that all the free paths are explicit cm_free_msg() will only be called for msgs's allocated with cm_alloc_msg(), so we can assume the context is set. Place it after the allocation function it is paired with for clarity. Also remove a bogus NULL assignment in one place after a cancel. This does nothing other than disable completions to become events, but changing the state already did that. Link: https://lore.kernel.org/r/082fd3552be0d1a2c19b1c4cefb5f3f0e3e68e82.1622629024.git.leonro@nvidia.comSigned-off-by:
-
Jason Gunthorpe authored
There are now three destroy functions for the cm_msg, and all places except the general send completion handler use the correct function. Fix cm_send_handler() to detect which kind of message is being completed and destroy it using the correct function with the correct locking. Link: https://lore.kernel.org/r/62a507195b8db85bb11228d0c6e7fa944204bf12.1622629024.git.leonro@nvidia.comSigned-off-by:
-
Jason Gunthorpe authored
This is being used with two quite different flows, one attaches the message to the priv and the other does not. Ensure the message attach is consistently done under the spinlock and ensure that the free on error always detaches the message from the cm_id_priv, also always under lock. This makes read/write to the cm_id_priv->msg consistently locked and consistently NULL'd when the message is freed, even in all error paths. Link: https://lore.kernel.org/r/f692b8c89eecb34fd82244f317e478bea6c97688.1622629024.git.leonro@nvidia.comSigned-off-by:
-
Jason Gunthorpe authored
This is not a functional change, but it helps make the purpose of all the cm_free_msg() calls clearer. In this case a response msg has a NULL context[0], and is never placed in cm_id_priv->msg. Link: https://lore.kernel.org/r/5cd53163be7df0a94f0d4ef7294546bc674fb74a.1622629024.git.leonro@nvidia.comSigned-off-by:
-
Leon Romanovsky authored
The mlx4 and mlx5 implemented differently the WQ input checks. Instead of duplicating mlx4 logic in the mlx5, let's prepare the input in the central place. The mlx5 implementation didn't check for validity of state input. It is not real bug because our FW checked that, but still worth to fix. Fixes: f213c052 ("IB/uverbs: Add WQ support") Link: https://lore.kernel.org/r/ac41ad6a81b095b1a8ad453dcf62cf8d3c5da779.1621413310.git.leonro@nvidia.comReported-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
- 31 May, 2021 1 commit
-
-
Jack Wang authored
drivers/infiniband/ulp/rtrs/rtrs-clt.c:1786:19: warning: result of comparison of constant 'MAX_SESS_QUEUE_DEPTH' (65536) with expression of type 'u16' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare] To fix it, limit MAX_SESS_QUEUE_DEPTH to u16 max, which is 65535, and drop the check in rtrs-clt, as it's the type u16 max. Link: https://lore.kernel.org/r/20210531122835.58329-1-jinpu.wang@ionos.comSigned-off-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
-
- 28 May, 2021 30 commits
-
-
Gioh Kim authored
sess->stats and sess->stats->pcpu_stats objects are freed when sysfs entry is removed. If something wrong happens and session is closed before sysfs entry is created, sess->stats and sess->stats->pcpu_stats objects are not freed. This patch adds freeing of them at three places: 1. When client uses wrong address and session creation fails. 2. When client fails to create a sysfs entry. 3. When client adds wrong address via sysfs add_path. Fixes: 215378b8 ("RDMA/rtrs: client: sysfs interface functions") Link: https://lore.kernel.org/r/20210528113018.52290-21-jinpu.wang@ionos.comSigned-off-by:
Gioh Kim <gi-oh.kim@ionos.com> Signed-off-by:
-
Md Haris Iqbal authored
The queue_depth is a module parameter for rtrs_server. It is used on the client side to determing the queue_depth of the request queue for the RNBD virtual block device. During a reconnection event for an already mapped device, in case the rtrs_server module queue_depth has changed, fail the reconnect attempt. Also stop further auto reconnection attempts. A manual reconnect via sysfs has to be triggerred. Fixes: 6a98d71d ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20210528113018.52290-20-jinpu.wang@ionos.comSigned-off-by:
Md Haris Iqbal <haris.iqbal@ionos.com> Signed-off-by:
-
Jack Wang authored
Gioh notice memory leak below unreferenced object 0xffff8880acda2000 (size 2048): comm "kworker/4:1", pid 77, jiffies 4295062871 (age 1270.730s) hex dump (first 32 bytes): 00 20 da ac 80 88 ff ff 00 20 da ac 80 88 ff ff . ....... ...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000e85d85b5>] rtrs_srv_rdma_cm_handler+0x8e5/0xa90 [rtrs_server] [<00000000e31a988a>] cma_ib_req_handler+0xdc5/0x2b50 [rdma_cm] [<000000000eb02c5b>] cm_process_work+0x2d/0x100 [ib_cm] [<00000000e1650ca9>] cm_req_handler+0x11bc/0x1c40 [ib_cm] [<000000009c28818b>] cm_work_handler+0xe65/0x3cf2 [ib_cm] [<000000002b53eaa1>] process_one_work+0x4bc/0x980 [<00000000da3499fb>] worker_thread+0x78/0x5c0 [<00000000167127a4>] kthread+0x191/0x1e0 [<0000000060802104>] ret_from_fork+0x3a/0x50 unreferenced object 0xffff88806d595d90 (size 8): comm "kworker/4:1H", pid 131, jiffies 4295062972 (age 1269.720s) hex dump (first 8 bytes): 62 6c 61 00 6b 6b 6b a5 bla.kkk. backtrace: [<000000004447d253>] kstrdup+0x2e/0x60 [<0000000047259793>] kobject_set_name_vargs+0x2f/0xb0 [<00000000c2ee3bc8>] dev_set_name+0xab/0xe0 [<000000002b6bdfb1>] rtrs_srv_create_sess_files+0x260/0x290 [rtrs_server] [<0000000075d87bd7>] rtrs_srv_info_req_done+0x71b/0x960 [rtrs_server] [<00000000ccdf1bb5>] __ib_process_cq+0x94/0x100 [ib_core] [<00000000cbcb60cb>] ib_cq_poll_work+0x32/0xc0 [ib_core] [<000000002b53eaa1>] process_one_work+0x4bc/0x980 [<00000000da3499fb>] worker_thread+0x78/0x5c0 [<00000000167127a4>] kthread+0x191/0x1e0 [<0000000060802104>] ret_from_fork+0x3a/0x50 unreferenced object 0xffff88806d6bb100 (size 256): comm "kworker/4:1H", pid 131, jiffies 4295062972 (age 1269.720s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 59 4d 86 ff ff ff ff .........YM..... backtrace: [<00000000a18a11e4>] device_add+0x74d/0xa00 [<00000000a915b95f>] rtrs_srv_create_sess_files.cold+0x49/0x1fe [rtrs_server] [<0000000075d87bd7>] rtrs_srv_info_req_done+0x71b/0x960 [rtrs_server] [<00000000ccdf1bb5>] __ib_process_cq+0x94/0x100 [ib_core] [<00000000cbcb60cb>] ib_cq_poll_work+0x32/0xc0 [ib_core] [<000000002b53eaa1>] process_one_work+0x4bc/0x980 [<00000000da3499fb>] worker_thread+0x78/0x5c0 [<00000000167127a4>] kthread+0x191/0x1e0 [<0000000060802104>] ret_from_fork+0x3a/0x50 The problem is we increase device refcount by get_device in process_info_req for each path, but only does put_deice for last path, which lead to memory leak. To fix it, it also calls put_device when dev_ref is not 0. Fixes: e2853c49 ("RDMA/rtrs-srv-sysfs: fix missing put_device") Link: https://lore.kernel.org/r/20210528113018.52290-19-jinpu.wang@ionos.comSigned-off-by: -
Gioh Kim authored
When closing a session, currently the rtrs_srv_stats object in the closing session is freed by kobject release. But if it failed to create a session by various reasons, it must free the rtrs_srv_stats object directly because kobject is not created yet. This problem is found by kmemleak as below: 1. One client machine maps /dev/nullb0 with session name 'bla': root@test1:~# echo "sessname=bla path=ip:192.168.122.190 \ device_path=/dev/nullb0" > /sys/devices/virtual/rnbd-client/ctl/map_device 2. Another machine failed to create a session with the same name 'bla': root@test2:~# echo "sessname=bla path=ip:192.168.122.190 \ device_path=/dev/nullb1" > /sys/devices/virtual/rnbd-client/ctl/map_device -bash: echo: write error: Connection reset by peer 3. The kmemleak on server machine reported an error: unreferenced object 0xffff888033cdc800 (size 128): comm "kworker/2:1", pid 83, jiffies 4295086585 (age 2508.680s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000a72903b2>] __alloc_sess+0x1d4/0x1250 [rtrs_server] [<00000000d1e5321e>] rtrs_srv_rdma_cm_handler+0xc31/0xde0 [rtrs_server] [<00000000bb2f6e7e>] cma_ib_req_handler+0xdc5/0x2b50 [rdma_cm] [<00000000e896235d>] cm_process_work+0x2d/0x100 [ib_cm] [<00000000b6866c5f>] cm_req_handler+0x11bc/0x1c40 [ib_cm] [<000000005f5dd9aa>] cm_work_handler+0xe65/0x3cf2 [ib_cm] [<00000000610151e7>] process_one_work+0x4bc/0x980 [<00000000541e0f77>] worker_thread+0x78/0x5c0 [<00000000423898ca>] kthread+0x191/0x1e0 [<000000005a24b239>] ret_from_fork+0x3a/0x50 Fixes: 39c2d639 ("RDMA/rtrs-srv: Set .release function for rtrs srv device during device init") Link: https://lore.kernel.org/r/20210528113018.52290-18-jinpu.wang@ionos.comSigned-off-by: -
Gioh Kim authored
If two clients try to use the same session name, rtrs-server generates a kernel error that it failed to create the sysfs because the filename is duplicated. This patch adds code to check if there already exists the same session name with the different UUID. If a client tries to add more session, it sends the UUID and the session name. Therefore it is ok if there is already same session name with the same UUID. The rtrs-server must fail only-if there is the same session name with the different UUID. Link: https://lore.kernel.org/r/20210528113018.52290-17-jinpu.wang@ionos.comSigned-off-by:
Aleksei Marov <aleksei.marov@ionos.com> Signed-off-by:
-
Gioh Kim authored
When re-connecting, it resets hb_missed_max to 0. Before the first re-connecting, client will trigger re-connection when it gets hb-ack more than 5 times. But after the first re-connecting, clients will do re-connection whenever it does not get hb-ack because hb_missed_max is 0. There is no need to reset hb_missed_max when re-connecting. hb_missed_max should be kept until closing the session. Fixes: c0894b3e ("RDMA/rtrs: core: lib functions shared between client and server modules") Link: https://lore.kernel.org/r/20210528113018.52290-16-jinpu.wang@ionos.comSigned-off-by:
-
Jack Wang authored
Link: https://lore.kernel.org/r/20210528113018.52290-15-jinpu.wang@ionos.comSigned-off-by:
-
Md Haris Iqbal authored
ids_inflight is used to track the inflight IOs. But the use of atomic_t variable can cause performance drops and can also become a performance bottleneck. This commit replaces the use of atomic_t with a percpu_ref structure. The advantage it offers is, it doesn't check if the reference has fallen to 0, until the user explicitly signals it to; and that is done by the percpu_ref_kill() function call. After that, the percpu_ref structure behaves like an atomic_t and for every put call, checks whether the reference has fallen to 0 or not. rtrs_srv_stats_rdma_to_str shows the count of ids_inflight as 0 for user-mode tools not to be confused. Fixes: 9cb83748 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20210528113018.52290-14-jinpu.wang@ionos.comSigned-off-by:
-
Md Haris Iqbal authored
When get_next_path_min_inflight is called to select the next path, it iterates over the list of available rtrs_clt_sess (paths). It then reads the number of inflight IOs for that path to select one which has the least inflight IO. But it may so happen that rtrs_clt_sess (path) is no longer in the connected state because closing or error recovery paths can change the status of the rtrs_clt_Sess. For example, the client sent the heart-beat and did not get the response, it would change the session status and stop IO processing. The added checking of this patch can prevent accessing the broken path and generating duplicated error messages. It is ok if the status is changed after checking the status because the error recovery path does not free memory and only tries to reconnection. And also it is ok if the session is closed after checking the status because closing the session changes the session status and flush all IO beforing free memory. If the session is being accessed for IO processing, the closing session will wait. Fixes: 6a98d71d ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20210528113018.52290-13-jinpu.wang@ionos.comSigned-off-by:
-
Guoqing Jiang authored
It is duplicated with the very next line Link: https://lore.kernel.org/r/20210528113018.52290-12-jinpu.wang@ionos.comSigned-off-by:
Guoqing Jiang <guoqing.jiang@ionos.com> Reviewed-by:
-
Guoqing Jiang authored
No need since the only user is rtrs_srv_change_state. Link: https://lore.kernel.org/r/20210528113018.52290-11-jinpu.wang@ionos.comSigned-off-by:
-
Guoqing Jiang authored
The function is just a wrapper of rtrs_clt_close_conns, let's call rtrs_clt_close_conns directly. Link: https://lore.kernel.org/r/20210528113018.52290-10-jinpu.wang@ionos.comSigned-off-by:
-
Guoqing Jiang authored
The two wrappers are not needed since we can call rtrs_{start,stop}_hb directly. Link: https://lore.kernel.org/r/20210528113018.52290-9-jinpu.wang@ionos.comSigned-off-by: -
Dima Stepanov authored
During checkpatch analyzing the following warning message was found: WARNING:STRLCPY: Prefer strscpy over strlcpy - see: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Fix it by using strscpy calls instead of strlcpy. Link: https://lore.kernel.org/r/20210528113018.52290-8-jinpu.wang@ionos.comSigned-off-by:
Dima Stepanov <dmitrii.stepanov@ionos.com> Signed-off-by:
-
Gioh Kim authored
Define MIN_CHUNK_SIZE to replace the hard-coding number. We need 4k for metadata, so MIN_CHUNK_SIZE should be at least 8k. Link: https://lore.kernel.org/r/20210528113018.52290-7-jinpu.wang@ionos.comSigned-off-by:
-
Gioh Kim authored
Max IB immediate data size is 2^28 (MAX_IMM_PAYL_BITS) and the minimum chunk size is 4096 (2^12). Therefore the maximum sess_queue_depth is 65536 (2^16). Link: https://lore.kernel.org/r/20210528113018.52290-6-jinpu.wang@ionos.comSigned-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Guoqing Jiang authored
No need to use double switch to check the change of state everywhere, let's change them to "if" to reduce size. Link: https://lore.kernel.org/r/20210528113018.52290-5-jinpu.wang@ionos.comSigned-off-by:
-
Md Haris Iqbal authored
It was difficult to find out why it failed to establish RDMA connection. This patch adds some messages to show which function has failed why. Link: https://lore.kernel.org/r/20210528113018.52290-4-jinpu.wang@ionos.comSigned-off-by:
-
Gioh Kim authored
Client receives queue_depth value from server. There is no need to use MAX_SESS_QUEUE_DEPTH value. Link: https://lore.kernel.org/r/20210528113018.52290-3-jinpu.wang@ionos.comSigned-off-by:
-
Guoqing Jiang authored
We can goto reject_w_err label after initialize err with -ECONNRESET. Link: https://lore.kernel.org/r/20210528113018.52290-2-jinpu.wang@ionos.comReviewed-by:
-
YueHaibing authored
Use DEVICE_ATTR_*() helpers instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Link: https://lore.kernel.org/r/20210528125750.20788-1-yuehaibing@huawei.comSigned-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
Use the DEVICE_ATTR_RO() helper instead of plain DEVICE_ATTR(), which makes the code a bit shorter and easier to read. Link: https://lore.kernel.org/r/20210526132949.20184-1-yuehaibing@huawei.comSigned-off-by:
-
YueHaibing authored
Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Link: https://lore.kernel.org/r/20210526132753.3092-1-yuehaibing@huawei.comSigned-off-by:
-
Håkon Bugge authored
Both the PKEY and GID tables in an HCA can hold in the order of hundreds entries. Reading them is expensive. Partly because the API for retrieving them only returns a single entry at a time. Further, on certain implementations, e.g., CX-3, the VFs are paravirtualized in this respect and have to rely on the PF driver to perform the read. This again demands VF to PF communication. IB Core's cache is refreshed on all events. Hence, filter the refresh of the PKEY and GID caches based on the event received being IB_EVENT_PKEY_CHANGE and IB_EVENT_GID_CHANGE respectively. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/r/1621964949-28484-1-git-send-email-haakon.bugge@oracle.comSigned-off-by:
Håkon Bugge <haakon.bugge@oracle.com> Reviewed-by:
-
Xi Wang authored
The capbability configurations of PFs and VFs are coupled. Decoupling them by abstracting some functions and reorganizing the configuration process. Link: https://lore.kernel.org/r/1621860428-58009-1-git-send-email-liweihang@huawei.comSigned-off-by:
Xi Wang <wangxi11@huawei.com> Signed-off-by:
Yixing Liu <liuyixing1@huawei.com> Signed-off-by:
Weihang Li <liweihang@huawei.com> Signed-off-by:
-
Max Gurtovoy authored
This will allow both IPv4 and IPv6 sockets to bind a single port at the same time. Same behaviour is implemented in NVMe/RDMA target. Link: https://lore.kernel.org/r/20210524085225.29064-1-mgurtovoy@nvidia.comReviewed-by:
Alaa Hleihel <alaa@nvidia.com> Reviewed-by:
Israel Rukshin <israelr@nvidia.com> Signed-off-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Bart Van Assche authored
Define .init_cmd_priv and .exit_cmd_priv callback functions in struct scsi_host_template. Set .cmd_size such that the SCSI core allocates per-command private data. Use scsi_cmd_priv() to access that private data. Remove the req_ring pointer from struct srp_rdma_ch since it is no longer necessary. Convert srp_alloc_req_data() and srp_free_req_data() into functions that initialize one instance of the SRP-private command data. This is a micro-optimization since this patch removes several pointer dereferences from the hot path. Note: due to commit e73a5e8e ("scsi: core: Only return started requests from scsi_host_find_tag()"), it is no longer necessary to protect the completion path against duplicate responses. Link: https://lore.kernel.org/r/20210524041211.9480-6-bvanassche@acm.orgSigned-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Bart Van Assche authored
Only allocate a memory registration list if it will be used and if it will be freed. Link: https://lore.kernel.org/r/20210524041211.9480-5-bvanassche@acm.orgReviewed-by:
Max Gurtovoy <maxg@mellanox.com> Fixes: f273ad4f ("RDMA/srp: Remove support for FMR memory registration") Signed-off-by:
-
Bart Van Assche authored
Applying the __packed attribute to an entire data structure results in suboptimal code on architectures that do not support unaligned accesses. Hence apply the __packed attribute only to those data members that are not naturally aligned. Link: https://lore.kernel.org/r/20210524041211.9480-4-bvanassche@acm.org Cc: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.com> Signed-off-by:
-
Bart Van Assche authored
Before modifying how the __packed attribute is used, add compile time size checks for the structures that will be modified. Link: https://lore.kernel.org/r/20210524041211.9480-3-bvanassche@acm.orgReviewed-by:
-
