Resolve a couple of conflicts between the 5.12 fixes branch and the
5.13 staging tree (iSCSI target and UFS).
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Fix the following out-of-bounds warnings by enclosing some structure
members into new structure objects upiu_req and upiu_rsp:
include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [29, 48] from the object at 'treq' is out of the bounds of referenced subobject 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds]
include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [61, 80] from the object at 'treq' is out of the bounds of referenced subobject 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds]
arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset [29, 48] from the object at 'treq' is out of the bounds of referenced subobject 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds]
arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset [61, 80] from the object at 'treq' is out of the bounds of referenced subobject 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds]
Refactor the code by making it more structured.
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(). Now
that a new struct _upiu_req_ enclosing all those adjacent members is
introduced, memcpy() doesn't overrun the length of &treq.req_header,
because the address of the new struct object _upiu_req_ is used as the
destination, instead. The same problem is present when memcpy() overruns
the length of the source &treq.rsp_header; in this case the address of the
new struct object _upiu_rsp_ is used, instead.
Also, this helps with the ongoing efforts to enable -Warray-bounds and
avoid confusing the compiler.
Link: https://github.com/KSPP/linux/issues/109
Link: https://lore.kernel.org/lkml/60640558.lsAxiK6otPwTo9rv%25lkp@intel.com/
Link: https://lore.kernel.org/r/20210331224338.GA347171@embeddedor
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Build-tested-by: kernel test robot <lkp@intel.com>
While diag reset is in progress there is short duration where all access to
controller's PCI config space from the host needs to be blocked. This is
due to a hardware limitation of the IOC controllers.
Block all access to controller's config space from userland applications by
calling pci_cfg_access_lock() while diag reset is in progress and unlocking
it again after the controller comes back to ready state.
Link: https://lore.kernel.org/r/20210330105137.20728-1-sreekanth.reddy@broadcom.com
Cc: stable@vger.kernel.org #v5.4.108+
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Due to the frequency that alua_rtpg() is called, the path group info print
within can print the same info multiple times in the logs, subsequent
prints adding no new information or value.
To reproduce:
# modprobe scsi_debug vpd_use_hostno=0
# systemctl start multipathd.service
To fix, check stored values, only printing at alua attach/activate and if
any of the values change.
Link: https://lore.kernel.org/r/20210331181656.5046-1-jpittman@redhat.com
Reviewed-by: David Jeffery <djeffery@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: John Pittman <jpittman@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
rport_dev_loss_timedout() sets the rport state to SRP_PORT_LOST and the
SCSI target state to SDEV_TRANSPORT_OFFLINE. If this races with
srp_reconnect_work(), a warning is printed:
Mar 27 18:48:07 ictm1604s01h4 kernel: dev_loss_tmo expired for SRP port-18:1 / host18.
Mar 27 18:48:07 ictm1604s01h4 kernel: ------------[ cut here ]------------
Mar 27 18:48:07 ictm1604s01h4 kernel: scsi_internal_device_block(18:0:0:100) failed: ret = -22
Mar 27 18:48:07 ictm1604s01h4 kernel: Call Trace:
Mar 27 18:48:07 ictm1604s01h4 kernel: ? scsi_target_unblock+0x50/0x50 [scsi_mod]
Mar 27 18:48:07 ictm1604s01h4 kernel: starget_for_each_device+0x80/0xb0 [scsi_mod]
Mar 27 18:48:07 ictm1604s01h4 kernel: target_block+0x24/0x30 [scsi_mod]
Mar 27 18:48:07 ictm1604s01h4 kernel: device_for_each_child+0x57/0x90
Mar 27 18:48:07 ictm1604s01h4 kernel: srp_reconnect_rport+0xe4/0x230 [scsi_transport_srp]
Mar 27 18:48:07 ictm1604s01h4 kernel: srp_reconnect_work+0x40/0xc0 [scsi_transport_srp]
Avoid this by not trying to block targets for rports in SRP_PORT_LOST
state.
Link: https://lore.kernel.org/r/20210401091105.8046-1-mwilck@suse.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
OFA, Online Firmware Activation, allows users to update firmware without a
reboot.
- Change OFA setup to a worker thread
- Delay soft resets
- Add OFA event handler to allow FW to initiate OFA
- Add in-memory allocation to OFA events
- Update OFA buffer size calculations
- Add ability to cancel OFA events
- Update OFA quiesce/un-quiesce
- Prevent Kernel crashes while issuing ioctl during OFA
- Returned EBUSY for pass-through IOCTLs throughout all stages of OFA
- Add mutex to prevent parallel OFA updates.
Link: https://lore.kernel.org/r/161549381563.25025.2647205502550052197.stgit@brunhilda
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Signed-off-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cleanup soft reset code for Online Firmware Activation (OFA). OFA allows
controller firmware updates without a reboot.
OFA updates require an on-line controller reset to activate the updated
firmware. There were some missing actions for some of the reset cases. The
controller is first set back to sis mode before returning to pqi mode.
Check to ensure the controller is in sis mode.
Release QRM memory (OFA buffer) on OFA error conditions. Clean up
controller state which can cause a kernel panic upon reboot after an
unsuccessful OFA.
Link: https://lore.kernel.org/r/161549379215.25025.10654441314249183621.stgit@brunhilda
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Signed-off-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Allow R5/R6 stream detection to be disabled/enabled using sysfs entry
enable_stream_detection.
Example usage:
lsscsi
[2:2:0:0] storage Adaptec 3258P-32i /e 0010
^
|
+---- NOTE: here host is host2
find /sys -name \*enable_stream\*
/sys/devices/pci0000:36/0000:36:00.0/0000:37:00.0/0000:38:00.0/0000:39:00.0/host2/scsi_host/host2/enable_stream_detection
/sys/devices/pci0000:5b/0000:5b:00.0/0000:5c:00.0/host3/scsi_host/host3/enable_stream_detection
Current stream detection:
cat /sys/devices/pci0000:36/0000:36:00.0/0000:37:00.0/0000:38:00.0/0000:39:00.0/host2/scsi_host/host2/enable_stream_detection
1
Turn off stream detection:
echo 0 > /sys/devices/pci0000:36/0000:36:00.0/0000:37:00.0/0000:38:00.0/0000:39:00.0/host2/scsi_host/host2/enable_stream_detection
Turn on stream detection:
echo 1 > /sys/devices/pci0000:36/0000:36:00.0/0000:37:00.0/0000:38:00.0/0000:39:00.0/host2/scsi_host/host2/enable_stream_detection
Link: https://lore.kernel.org/r/161549376281.25025.1132304698441513738.stgit@brunhilda
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Enhance performance by adding sequential stream detection for RAID5/RAID6
sequential write requests. Reduce stripe lock contention with full-stripe
write operations.
There is one common stripe lock for each RAID volume that can be set by
either the RAID engine or the AIO engine. The AIO path has I/O request
sizes well below the stripe size resulting in many Read-Modify-Write
operations.
Sending the request to the RAID engine allows for coalescing requests into
full stripe operations resulting in reduced Read-Modify-Write operations.
Link: https://lore.kernel.org/r/161549375693.25025.2962141451773219796.stgit@brunhilda
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Pull 5.12/scsi-fixes into the 5.13 SCSI tree to provide a baseline for
some UFS changes that would otherwise cause conflicts during the
merge.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
