~mreed8855/ubuntu/+source/linux/+git/hirsute:mpt3sas_update_38_100_hirsute_next2

Last commit made on 2021-08-18
Get this branch:
git clone -b mpt3sas_update_38_100_hirsute_next2 https://git.launchpad.net/~mreed8855/ubuntu/+source/linux/+git/hirsute
Only Michael Reed can upload to this branch. If you are Michael Reed please log in for upload directions.

Branch merges

Branch information

Name:
mpt3sas_update_38_100_hirsute_next2
Repository:
lp:~mreed8855/ubuntu/+source/linux/+git/hirsute

Recent commits

f6e89ad... by Sreekanth Reddy

scsi: mpt3sas: Bump driver version to 38.100.00.00

Bump driver version to 38.100.00.00.

BugLink: https://launchpad.net/bugs/1935034
Link: https://<email address hidden>
Reviewed-by: Lee Duncan <email address hidden>
Signed-off-by: Sreekanth Reddy <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 44f88ef3c9f1edf4f8229508649965d85bc6f186)
Signed-off-by: Michael Reed <email address hidden>

1fd27a0... by Ming Lei <email address hidden>

scsi: core: Replace sdev->device_busy with sbitmap

SCSI currently uses an atomic variable to track queue depth for each
attached device. The queue depth depends on many factors such as transport
type and device implementation. In addition, the SCSI device queue depth is
not a static entity but changes over time as a result of congestion
management.

While blk-mq currently tracks queue depth for each hctx, it can't easily be
changed to accommodate the SCSI per-device requirement.

The current approach of using an atomic variable doesn't scale well when
there are lots of CPU cores and the disk is very fast. IOPS can be
substantially impacted by the atomic in the hot path.

Replace the atomic variable sdev->device_busy with an sbitmap for tracking
the SCSI device queue depth.

It has been observed that IOPS is improved ~30% by this patchset in the
following test:

1) test machine(32 logical CPU cores)
 Thread(s) per core: 2
 Core(s) per socket: 8
 Socket(s): 2
 NUMA node(s): 2
 Model name: Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz

2) setup scsi_debug:
modprobe scsi_debug virtual_gb=128 max_luns=1 submit_queues=32 delay=0 max_queue=256

3) fio script:
fio --rw=randread --size=128G --direct=1 --ioengine=libaio --iodepth=2048 \
 --numjobs=32 --bs=4k --group_reporting=1 --group_reporting=1 --runtime=60 \
 --loops=10000 --name=job1 --filename=/dev/sdN

[mkp: fix device_busy reference in mpt3sas]

BugLink: https://launchpad.net/bugs/1935034
Link: https://<email address hidden>
Link: https://<email address hidden>/
Cc: Omar Sandoval <email address hidden>
Cc: Kashyap Desai <email address hidden>
Cc: Sumanesh Samanta <email address hidden>
Cc: Ewan D. Milne <email address hidden>
Cc: Hannes Reinecke <email address hidden>
Tested-by: Sumanesh Samanta <email address hidden>
Reviewed-by: Hannes Reinecke <email address hidden>
Signed-off-by: Ming Lei <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 020b0f0a31920e5b7e7e120d4560453b67b70733)
Signed-off-by: Michael Reed <email address hidden>

9d08037... by Suganath Prabu

scsi: mpt3sas: Fix Coverity reported issue

Fix the structurally dead code (UNREACHABLE) type of error reported by
Coverity.

BugLink: https://launchpad.net/bugs/1935034
Link: https://lore<email address hidden>
Reported-by: Colin Ian King <email address hidden>
Signed-off-by: Suganath Prabu S <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit cf750be8e68e8c2755f0ee29784463a2da91e922)
Signed-off-by: Michael Reed <email address hidden>

037da65... by "Gustavo A. R. Silva" <email address hidden>

scsi: mpt3sas: Fix fall-through warnings for Clang

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding break statements instead of just letting
the code fall through to the next case.

BugLink: https://launchpad.net/bugs/1935034
Link: https://github.com/KSPP/linux/issues/115
Link: https://lore.kernel.org/r/20210528200828.GA39349@embeddedor
Reviewed-by: Kees Cook <email address hidden>
Signed-off-by: Gustavo A. R. Silva <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 84a84cc6aff4243c9f28c879b94d0dd55a310b54)
Signed-off-by: Michael Reed <email address hidden>

2218af6... by Hannes Reinecke <email address hidden>

scsi: core: Introduce scsi_build_sense()

Introduce scsi_build_sense() as a wrapper around scsi_build_sense_buffer()
to format the buffer and set the correct SCSI status.

BugLink: https://launchpad.net/bugs/1935034
Link: https://<email address hidden>
Reviewed-by: Bart Van Assche <email address hidden>
Reviewed-by: Christoph Hellwig <email address hidden>
Signed-off-by: Hannes Reinecke <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit f2b1e9c6f867ec8f929e96ba4e4010e267587448)
Signed-off-by: Michael Reed <email address hidden>

4243e36... by Suganath Prabu

scsi: mpt3sas: Handle firmware faults during second half of IOC init

If a firmware fault occurs while scanning the devices during IOC
initialization then the driver issues the hard reset operation to recover
the IOC. However, the driver is not issuing a Port enable request
messageĀ as part of hard reset operation during IOC initialization. Due to
this, the driver will not receive get any device discovery-related events
and hence devices will not be accessible.

Teach the driver to gracefully handle firmware faults while scanning for
target devices during IOC initialization. Make the driver issue a port
enable request message as part of hard reset operation. This permits
receiving device discovery-related events from the firmware after the hard
reset operation completes.

BugLink: https://launchpad.net/bugs/1935034
Link: https://lore<email address hidden>
Signed-off-by: Suganath Prabu S <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit a0815c45c89f544861eae55d85ccee6b1b1451e8)
Signed-off-by: Michael Reed <email address hidden>

44aa90b... by Suganath Prabu

scsi: mpt3sas: Handle firmware faults during first half of IOC init

During first half of IOC initialization (i.e. before going for device
scanning), if any firmware fault occurs then driver is aborting the IOC
initialization operation.

Modify the driver to issue a diag reset operation to recover IOC from fault
state and reinitialize the IOC.

BugLink: https://launchpad.net/bugs/1935034
Link: https://lore<email address hidden>
Signed-off-by: Suganath Prabu S <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 19a622c39a9d497d3c06ffe9068ee4c7bbd2bdcc)
Signed-off-by: Michael Reed <email address hidden>

4bd5c37... by Randy Dunlap <email address hidden>

scsi: mpt3sas: Documentation cleanup

Fix kernel-doc warnings, spellos, and typos.

drivers/scsi/mpt3sas/mpt3sas_base.c:5430: warning: Excess function parameter 'ct' description in '_base_allocate_pcie_sgl_pool'
drivers/scsi/mpt3sas/mpt3sas_base.c:5493: warning: Excess function parameter 'ctr' description in '_base_allocate_chain_dma_pool'
mpt3sas_base.c:1362: warning: missing initial short description on line:
 * _base_display_reply_info -
mpt3sas_base.c:2151: warning: contents before sections
mpt3sas_base.c:2314: warning: missing initial short description on line:
 * base_make_prp_nvme -

BugLink: https://launchpad.net/bugs/1935034
Link: https://<email address hidden>
Cc: <email address hidden>
Cc: "James E.J. Bottomley" <email address hidden>
Cc: "Martin K. Petersen" <email address hidden>
Cc: Sathya Prakash <email address hidden>
Cc: Sreekanth Reddy <email address hidden>
Cc: Suganath Prabu Subramani <email address hidden>
Cc: <email address hidden>
Signed-off-by: Randy Dunlap <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 2910a4a9e90a5853f38766b2e8d025e3bb26d12b)
Signed-off-by: Michael Reed <email address hidden>

734fefe... by Bart Van Assche

scsi: mpt3sas: Fix two kernel-doc headers

Fix the following warnings:

drivers/scsi/mpt3sas/mpt3sas_base.c:5430: warning: Excess function parameter 'ct' description in '_base_allocate_pcie_sgl_pool'
drivers/scsi/mpt3sas/mpt3sas_base.c:5493: warning: Excess function parameter 'ctr' description in '_base_allocate_chain_dma_pool'

BugLink: https://launchpad.net/bugs/1935034
Link: https://<email address hidden>
Fixes: d6adc251dd2f ("scsi: mpt3sas: Force PCIe scatterlist allocations to be within same 4 GB region")
Fixes: 7dd847dae1c4 ("scsi: mpt3sas: Force chain buffer allocations to be within same 4 GB region")
Cc: Sathya Prakash <email address hidden>
Cc: Sreekanth Reddy <email address hidden>
Cc: Suganath Prabu Subramani <email address hidden>
Signed-off-by: Bart Van Assche <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 3ad0b1da0da2e073b1c9d2e317a5ebf7704f98e6)
Signed-off-by: Michael Reed <email address hidden>

cd9d2a1... by "Gustavo A. R. Silva" <email address hidden>

scsi: mpt3sas: Fix out-of-bounds warnings in _ctl_addnl_diag_query

Fix the following out-of-bounds warnings by embedding existing struct
htb_rel_query into struct mpt3_addnl_diag_query, instead of duplicating its
members:

include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [19, 32] from the object at 'karg' is out of the bounds of referenced subobject 'buffer_rel_condition' with type 'short unsigned int' at offset 16 [-Warray-bounds]
include/linux/fortify-string.h:22:29: warning: '__builtin_memset' offset [19, 32] from the object at 'karg' is out of the bounds of referenced subobject 'buffer_rel_condition' with type 'short unsigned int' at offset 16 [-Warray-bounds]

The problem is that the original code is trying to copy data into a bunch
of struct members adjacent to each other in a single call to memcpy(). All
those members are exactly the same contained in struct htb_rel_query, so
instead of duplicating them into struct mpt3_addnl_diag_query, replace them
with new member rel_query of type struct htb_rel_query. So, now that this
new object is introduced, memcpy() doesn't overrun the length of
&karg.buffer_rel_condition, because the address of the new struct object
_rel_query_ is used as destination, instead. The same issue is present when
calling memset(), and it is fixed with this same approach.

Below is a comparison of struct mpt3_addnl_diag_query, before and after
this change (the size and cachelines remain the same):

$ pahole -C mpt3_addnl_diag_query drivers/scsi/mpt3sas/mpt3sas_ctl.o
struct mpt3_addnl_diag_query {
 struct mpt3_ioctl_header hdr; /* 0 12 */
 uint32_t unique_id; /* 12 4 */
 uint16_t buffer_rel_condition; /* 16 2 */
 uint16_t reserved1; /* 18 2 */
 uint32_t trigger_type; /* 20 4 */
 uint32_t trigger_info_dwords[2]; /* 24 8 */
 uint32_t reserved2[2]; /* 32 8 */

 /* size: 40, cachelines: 1, members: 7 */
 /* last cacheline: 40 bytes */
};

$ pahole -C mpt3_addnl_diag_query drivers/scsi/mpt3sas/mpt3sas_ctl.o
struct mpt3_addnl_diag_query {
 struct mpt3_ioctl_header hdr; /* 0 12 */
 uint32_t unique_id; /* 12 4 */
 struct htb_rel_query rel_query; /* 16 16 */
 uint32_t reserved2[2]; /* 32 8 */

 /* size: 40, cachelines: 1, members: 4 */
 /* last cacheline: 40 bytes */
};

Also, this helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines on
memcpy().

BugLink: https://launchpad.net/bugs/1935034
Link: https://github.com/KSPP/linux/issues/109
Link: https://lore.kernel.org/lkml/60659889.bJJILx2THu3hlpxW%<email address hidden>/
Link: https://lore.kernel.org/r/20210401162054.GA397186@embeddedor
Build-tested-by: kernel test robot <email address hidden>
Reported-by: kernel test robot <email address hidden>
Signed-off-by: Gustavo A. R. Silva <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 16660db3fc2af8664af5e0a3cac69c4a54bfb794)
Signed-off-by: Michael Reed <email address hidden>