wireguard-linux/drivers/infiniband/ulp/srp, branch jd/orphan-parallel

treewide: replace '---help---' in Kconfig files with 'help'

2020-06-13T16:57:21Z

Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada

RDMA/srp: Remove support for FMR memory registration

2020-06-02T23:32:53Z

FMR is not supported on most recent RDMA devices (that use fast memory registration mechanism). Also, FMR was recently removed from NFS/RDMA ULP. Link: https://lore.kernel.org/r/2-v3-f58e6669d5d3+2cf-fmr_removal_jgg@mellanox.com Signed-off-by: Max Gurtovoy Reviewed-by: Israel Rukshin Reviewed-by: Bart Van Assche Signed-off-by: Jason Gunthorpe

RDMA/srp: Make the channel count configurable per target

2020-05-29T17:49:55Z

Increase the flexibility of the SRP initiator driver by making the channel count configurable per target instead of only providing a kernel module parameter for configuring the channel count. Link: https://lore.kernel.org/r/20200525172212.14413-2-bvanassche@acm.org Signed-off-by: Bart Van Assche Signed-off-by: Jason Gunthorpe

RDMA: Allow ib_client's to fail when add() is called

2020-05-06T14:57:33Z

When a client is added it isn't allowed to fail, but all the client's have various failure paths within their add routines. This creates the very fringe condition where the client was added, failed during add and didn't set the client_data. The core code will then still call other client_data centric ops like remove(), rename(), get_nl_info(), and get_net_dev_by_params() with NULL client_data - which is confusing and unexpected. If the add() callback fails, then do not call any more client ops for the device, even remove. Remove all the now redundant checks for NULL client_data in ops callbacks. Update all the add() callbacks to return error codes appropriately. EOPNOTSUPP is used for cases where the ULP does not support the ib_device - eg because it only works with IB. Link: https://lore.kernel.org/r/20200421172440.387069-1-leon@kernel.org Signed-off-by: Leon Romanovsky Acked-by: Ursula Braun Signed-off-by: Jason Gunthorpe

RDMA: Replace zero-length array with flexible-array member

2020-02-20T17:33:51Z

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200213010425.GA13068@embeddedor.com Signed-off-by: Gustavo A. R. Silva Signed-off-by: Jason Gunthorpe # added a few more

IB/srp: Never use immediate data if it is disabled by a user

2020-01-15T20:37:37Z

Some SRP targets that do not support specification SRP-2, put the garbage to the reserved bits of the SRP login response. The problem was not detected for a long time because the SRP initiator ignored those bits. But now one of them is used as SRP_LOGIN_RSP_IMMED_SUPP. And it causes a critical error on the target when the initiator sends immediate data. The ib_srp module has a use_imm_date parameter to enable or disable immediate data manually. But it does not help in the above case, because use_imm_date is ignored at handling the SRP login response. The problem is definitely caused by a bug on the target side, but the initiator's behavior also does not look correct. The initiator should not use immediate data if use_imm_date is disabled by a user. This commit adds an additional checking of use_imm_date at the handling of SRP login response to avoid unexpected use of immediate data. Fixes: 882981f4a411 ("RDMA/srp: Add support for immediate data") Link: https://lore.kernel.org/r/20200115133055.30232-1-sergeygo@mellanox.com Signed-off-by: Sergey Gorenko Reviewed-by: Bart Van Assche Signed-off-by: Jason Gunthorpe

ib/srp: Add missing new line after displaying fast_io_fail_tmo param

2019-10-21T20:55:16Z

Long-time missing new-line in sysfs output. Simply add it. Signed-off-by: Donald Dutile Reviewed-by: Bart Van Assche Link: https://lore.kernel.org/r/20191009164937.21989-1-ddutile@redhat.com Signed-off-by: Doug Ledford

RDMA/srp: Calculate max_it_iu_size if remote max_it_iu length available

2019-10-08T18:17:32Z

The default maximum immediate size is too big for old srp clients, which do not support immediate data. According to the SRP and SRP-2 specifications, the IOControllerProfile attributes for SRP target ports contains the maximum initiator to target iu length. The maximum initiator to target iu length can be obtained by sending MAD packets to query subnet manager port and SRP target ports. We should calculate the max_it_iu_size instead of the default value, when remote maximum initiator to target iu length available. Link: https://lore.kernel.org/r/20190927174352.7800-2-honli@redhat.com Reviewed-by: Bart Van Assche Signed-off-by: Honggang Li Signed-off-by: Jason Gunthorpe

RDMA/srp: Add parse function for maximum initiator to target IU size

2019-10-08T18:17:32Z

According to SRP specifications 'srp-r16a' and 'srp2r06', IOControllerProfile attributes for SRP target port include the maximum initiator to target IU size. SRP connection daemons, such as srp_daemon, can get the value from the subnet manager. The SRP connection daemon can pass this value to kernel. This patch adds a parse function for it. Upstream commit [1] enables the kernel parameter, 'use_imm_data', by default. [1] also use (8 * 1024) as the default value for kernel parameter 'max_imm_data'. With those default values, the maximum initiator to target IU size will be 8260. In case the SRPT modules, which include the in-tree 'ib_srpt.ko' module, do not support SRP-2 'immediate data' feature, the default maximum initiator to target IU size is significantly smaller than 8260. For 'ib_srpt.ko' module, which built from source before [2], the default maximum initiator to target IU is 2116. [1] introduces a regression issue for old srp targets with default kernel parameters, as the connection will be rejected because of a too large maximum initiator to target IU size. [1] commit 882981f4a411 ("RDMA/srp: Add support for immediate data") [2] commit 5dabcd0456d7 ("RDMA/srpt: Add support for immediate data") Link: https://lore.kernel.org/r/20190927174352.7800-1-honli@redhat.com Reviewed-by: Bart Van Assche Signed-off-by: Honggang Li Signed-off-by: Jason Gunthorpe

RDMA/srp: Make route resolving error messages more informative

2019-10-04T18:35:06Z

The IPv6 scope ID is essential when setting up an iWARP connection between IPv6 link-local addresses. Report the scope ID in error messages. Link: https://lore.kernel.org/r/20190930231707.48259-9-bvanassche@acm.org Cc: Honggang LI Cc: Laurence Oberman Signed-off-by: Bart Van Assche Signed-off-by: Jason Gunthorpe