wireguard-linux/drivers/infiniband/ulp/srp, branch jd/unified-crypt-queue

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

RDMA/srp: Honor the max_send_sge device attribute

2019-10-04T18:35:06Z

Instead of assuming that max_send_sge >= 3, restrict the number of scatter gather elements to what is supported by the RDMA adapter. Link: https://lore.kernel.org/r/20190930231707.48259-8-bvanassche@acm.org Cc: Honggang LI Cc: Laurence Oberman Signed-off-by: Bart Van Assche Signed-off-by: Jason Gunthorpe

RDMA/srp: Remove two casts

2019-10-04T18:35:05Z

This patch does not change any functionality. Link: https://lore.kernel.org/r/20190930231707.48259-7-bvanassche@acm.org Cc: Honggang LI Cc: Laurence Oberman Signed-off-by: Bart Van Assche Signed-off-by: Jason Gunthorpe

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2019-07-20T17:04:58Z

Pull SCSI fixes from James Bottomley: "This is the final round of mostly small fixes in our initial submit. It's mostly minor fixes and driver updates. The only change of note is adding a virt_boundary_mask to the SCSI host and host template to parametrise this for NVMe devices instead of having them do a call in slave_alloc. It's a fairly straightforward conversion except in the two NVMe handling drivers that didn't set it who now have a virtual infinity parameter added" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (24 commits) scsi: megaraid_sas: set an unlimited max_segment_size scsi: mpt3sas: set an unlimited max_segment_size for SAS 3.0 HBAs scsi: IB/srp: set virt_boundary_mask in the scsi host scsi: IB/iser: set virt_boundary_mask in the scsi host scsi: storvsc: set virt_boundary_mask in the scsi host template scsi: ufshcd: set max_segment_size in the scsi host template scsi: core: take the DMA max mapping size into account scsi: core: add a host / host template field for the virt boundary scsi: core: Fix race on creating sense cache scsi: sd_zbc: Fix compilation warning scsi: libfc: fix null pointer dereference on a null lport scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized scsi: zfcp: fix request object use-after-free in send path causing wrong traces scsi: zfcp: fix request object use-after-free in send path causing seqno errors scsi: megaraid_sas: Update driver version to 07.710.50.00 scsi: megaraid_sas: Add module parameter for FW Async event logging scsi: megaraid_sas: Enable msix_load_balance for Invader and later controllers scsi: megaraid_sas: Fix calculation of target ID scsi: lpfc: reduce stack size with CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE scsi: devinfo: BLIST_TRY_VPD_PAGES for SanDisk Cruzer Blade ...

scsi: IB/srp: set virt_boundary_mask in the scsi host

2019-07-17T03:02:11Z

This ensures all proper DMA layer handling is taken care of by the SCSI midlayer. Signed-off-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Acked-by: Bart Van Assche Reviewed-by: Max Gurtovoy Signed-off-by: Martin K. Petersen