- 07 Sep, 2022 14 commits
-
-
Kees Cook authored
In preparation for FORTIFY_SOURCE performing run-time destination buffer bounds checking for memcpy(), specify the destination output buffer explicitly, instead of asking memcpy() to write past the end of what looked like a fixed-size object. Silences future run-time warning: memcpy: detected field-spanning write (size 80) of single field "trc + 1" (size 64) There is no binary code output differences from this change. Link: https://lore.kernel.org/r/20220901205729.2260982-1-keescook@chromium.org Cc: Bradley Grove <linuxdrivers@attotech.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Letu Ren authored
The original code will "goto out_disable_device" and call pci_disable_device() if pci_enable_device() fails. The kernel will generate a warning message like "3w-9xxx 0000:00:05.0: disabling already-disabled device". We shouldn't disable a device that failed to be enabled. A simple return is fine. Link: https://lore.kernel.org/r/20220829110115.38789-1-fantasquex@gmail.comReported-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
Letu Ren <fantasquex@gmail.com> Signed-off-by:
-
Daniil Lunev authored
Userspace may want to manually control when the data should go into WriteBooster buffer. The control happens via "wb_on" node, but presently, there is no simple way to check if WriteBooster is supported and enabled. Expose the Write Booster and Clock Scaling capabilities to be able to determine if the Write Booster is available and if its manual control is blocked by Clock Scaling mechanism. Link: https://lore.kernel.org/r/20220829081845.v8.1.Ibf9efc9be50783eeee55befa2270b7d38552354c@changeidReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Daniil Lunev <dlunev@chromium.org> Signed-off-by:
-
Jack Wang authored
Add missing error check for dma_map_sg(). Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20220826101435.79170-1-jinpu.wang@ionos.comSigned-off-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
-
Mike Christie authored
The host codes that were supposed to only be used for internal use are now not used, so remove them. Link: https://lore.kernel.org/r/20220812010027.8251-11-michael.christie@oracle.comReviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Mike Christie authored
Don't use: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR Instead use the SCSI midlayer internal values. Link: https://lore.kernel.org/r/20220812010027.8251-10-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If a driver returns: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR we hit a couple bugs: 1. The SCSI error handler runs because scsi_decide_disposition() has no case statements for them and we return FAILED. 2. For SG IO the userspace app gets a success status instead of failed, because scsi_result_to_blk_status() clears those errors. This patch adds a new internal error code byte for use by the SCSI midlayer. This will be used instead of the above error codes, so we don't have to play that clearing the host code game in scsi_result_to_blk_status() and drivers cannot accidentally use them. A subsequent commit will then remove the internal users of the above codes and convert us to use the new ones. Link: https://lore.kernel.org/r/20220812010027.8251-9-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
DID_ALLOC_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. By the code comment, it looks like the driver wanted a retryable error code, so this has it use DID_ERROR. Link: https://lore.kernel.org/r/20220812010027.8251-8-michael.christie@oracle.comSigned-off-by: -
Mike Christie authored
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. This has qla2xxx use DID_NO_CONNECT because it looks like we hit this error when we can't find a port. It will give us the same hard error behavior and it seems to match the error where we can't find the endpoint. Link: https://lore.kernel.org/r/20220812010027.8251-7-michael.christie@oracle.comReviewed-by:Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
-
Mike Christie authored
DID_NEXUS_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. virtio_scsi gets this when something like qemu returns VIRTIO_SCSI_S_NEXUS_FAILURE. It looks like qemu returns that error code if host OS returns DID_NEXUS_FAILURE (qemu's internal SCSI_HOST_RESERVATION_ERROR maps to DID_NEXUS_FAILURE). This shouldn't happen for Linux since we don't propagate that error code to userspace. This has us convert VIRTIO_SCSI_S_NEXUS_FAILURE to a SAM_STAT_RESERVATION_CONFLICT in case some other virt layer is returning it. In that case we will still get the reservation confict failure we expect. Link: https://lore.kernel.org/r/20220812010027.8251-6-michael.christie@oracle.comAcked-by:Paolo Bonzini <pbonzini@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Mike Christie authored
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. virtio_scsi gets this when something like qemu returns VIRTIO_SCSI_S_TARGET_FAILURE. It looks like qemu returns that error code if a host OS returns it, but this shouldn't happen for Linux since we never propagate that error to userspace. This has us use DID_BAD_TARGET in case some other virt layer is returning it. In that case we will still get a hard error like before and it conveys something unexpected happened. Link: https://lore.kernel.org/r/20220812010027.8251-5-michael.christie@oracle.comAcked-by: -
Mike Christie authored
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. It looks like the driver wanted a hard failure so this swaps it with DID_BAD_TARGET which gives us that behavior. The error looks like it's for a case where the target did not support a TMF we wanted to use (maybe not a bad target but disappointing so close enough). Link: https://lore.kernel.org/r/20220812010027.8251-4-michael.christie@oracle.comSigned-off-by: -
Mike Christie authored
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in the SCSI error handling running. It looks like the driver wanted a hard failure so swap it with DID_BAD_TARGET. Link: https://lore.kernel.org/r/20220812010027.8251-3-michael.christie@oracle.comSigned-off-by: -
Mike Christie authored
The error codes: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR are internal to the SCSI layer. Drivers must not use them because: 1. They are not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. xen-scsiback will never see this error and should not try to send it. 2. There is no handling for them in scsi_decide_disposition() so if xen-scsifront were to return the error to the SCSI midlayer then it kicks off the error handler which is definitely not what we want. Remove the use from xen-scsifront/back. Link: https://lore.kernel.org/r/20220812010027.8251-2-michael.christie@oracle.comReviewed-by:Juergen Gross <jgross@suse.com> Signed-off-by:
-
- 01 Sep, 2022 26 commits
-
-
Shaomin Deng authored
There is repeated word, remove it. Link: https://lore.kernel.org/r/20220811153923.17278-1-dengshaomin@cdjrlc.comReviewed-by:
Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by:
Shaomin Deng <dengshaomin@cdjrlc.com> Signed-off-by:
-
Christophe JAILLET authored
{clear|set}_bit() can take an almost arbitrarily large bit number, so there is no need to manually compute addresses. This is just redundant. Link: https://lore.kernel.org/r/c3429a22023f58e5e5cc65d6cd7e83fb2bd9b870.1658340442.git.christophe.jaillet@wanadoo.frTested-by:Don Brace <don.brace@microchip.com> Acked-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
Use bitmap_zalloc()/bitmap_free() instead of hand-writing them. It is less verbose and it improves the semantic. Link: https://lore.kernel.org/r/5f975ef43f8b7306e4ac4e2e8ce4bcd53f6092bb.1658340441.git.christophe.jaillet@wanadoo.frTested-by:
-
ye xingchen authored
Return the value from lpfc_issue_reg_vfi() directly instead of storing it in another redundant variable. Link: https://lore.kernel.org/r/20220824075123.221316-1-ye.xingchen@zte.com.cnReported-by:
Zeal Robot <zealci@zte.com.cn> Reviewed-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Signed-off-by:
-
ye xingchen authored
Return the value from lpfc_sli4_issue_wqe() directly instead of storing it in another redundant variable. Link: https://lore.kernel.org/r/20220824075017.221244-1-ye.xingchen@zte.com.cnReported-by:
-
Randy Dunlap authored
Correct a typo in SCSI documentation. Link: https://lore.kernel.org/r/20220827221719.11006-1-rdunlap@infradead.org Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Nilesh Javali authored
Link: https://lore.kernel.org/r/20220826102559.17474-8-njavali@marvell.comReviewed-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Nilesh Javali authored
drivers/scsi/qla2xxx/qla_os.c:40:20: warning: symbol 'qla_trc_array' was not declared. Should it be static? drivers/scsi/qla2xxx/qla_os.c:345:5: warning: symbol 'ql2xdelay_before_pci_error_handling' was not declared. Should it be static? Define qla_trc_array and ql2xdelay_before_pci_error_handling as static to fix sparse warnings. Link: https://lore.kernel.org/r/20220826102559.17474-7-njavali@marvell.com Cc: stable@vger.kernel.org Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Arun Easi authored
Older tracing of driver messages was to: - log only debug messages to kernel main trace buffer; and - log only if extended logging bits corresponding to this message is off This has been modified and extended as follows: - Tracing is now controlled via ql2xextended_error_logging_ktrace module parameter. Bit usages same as ql2xextended_error_logging. - Tracing uses "qla2xxx" trace instance, unless instance creation have issues. - Tracing is enabled (compile time tunable). - All driver messages, include debug and log messages are now traced in kernel trace buffer. Trace messages can be viewed by looking at the qla2xxx instance at: /sys/kernel/tracing/instances/qla2xxx/trace Trace tunable that takes the same bit mask as ql2xextended_error_logging is: ql2xextended_error_logging_ktrace (default=1) Link: https://lore.kernel.org/r/20220826102559.17474-6-njavali@marvell.comSuggested-by:Daniel Wagner <dwagner@suse.de> Suggested-by:
Steven Rostedt <rostedt@goodmis.org> Tested-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
Anil Gurumurthy authored
Add new API to obtain the NVMe Parameters region status from the Auxiliary Image Status bitmap. Link: https://lore.kernel.org/r/20220826102559.17474-5-njavali@marvell.comReviewed-by:
Anil Gurumurthy <agurumurthy@marvell.com> Signed-off-by:
-
Arun Easi authored
Define a few helpful macros for creating debugfs files. Link: https://lore.kernel.org/r/20220826102559.17474-4-njavali@marvell.comReviewed-by:
-
Arun Easi authored
On some platforms, the current logic of relying on finding new packet solely based on signature pattern can lead to driver reading stale packets. Though this is a bug in those platforms, reduce such exposures by limiting reading packets until the IN pointer. Link: https://lore.kernel.org/r/20220826102559.17474-3-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by:
-
Arun Easi authored
Reverting this commit so that a fixed up patch, without adding new module parameters, can be submitted. Link: https://lore.kernel.org/stable/166039743723771@kroah.com/ This reverts commit b1f70714. Link: https://lore.kernel.org/r/20220826102559.17474-2-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by: -
Mauricio Faria de Oliveira authored
This message is helpful to troubleshoot missing LUNs/SAN boot errors. It'd be nice to log it by default instead of only being enabled with debug. This user had an accidental/forgotten file modprobe.d/qla2xxx.conf w/ option qlini_mode=disabled from experiments with FC target mode, and their boot LUN didn't come up, as it skips SCSI scan, of course. However, their boot log didn't provide any clues to help understand that. The issue/message could be figured out w/ ql2xextended_error_logging, but it would have been simpler (or even deflected/addressed by user) if it had been there by default. And it also would help support/triage/deflection tooling. Expected change: scsi host15: qla2xxx +qla2xxx [0000:3b:00.0]-00fb:15: skipping scsi_scan_host() for non-initiator port qla2xxx [0000:3b:00.0]-00fb:15: QLogic QLE2692 - QLE2692 Dual Port 16Gb FC to PCIe Gen3 x8 Adapter. According to: qla2x00_probe_one() ... ret = scsi_add_host(...); ... ql_log(ql_log_info, ... "skipping scsi_scan_host() for non-initiator port\n"); ... ql_log(ql_log_info, ... "QLogic %s - %s.\n", ha->model_number, ha->model_desc); Link: https://lore.kernel.org/r/20220825120159.275051-1-mfo@canonical.comTested-by:Mauricio Faria de Oliveira <mfo@canonical.com> Signed-off-by:
-
Sreekanth Reddy authored
Update driver version to 43.100.00.00. Link: https://lore.kernel.org/r/20220825075457.16422-5-sreekanth.reddy@broadcom.comSigned-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
With cmd_per_lun value 7, a higher number of cache lines (map_nr) are needed while allocating sdev->budget_map which is not reasonable and hence increase the cmd_per_lun value to 128. Link: https://lore.kernel.org/r/20220825075457.16422-4-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
The ExtendedType field was set to 1 in the diag buffer register command and hence MPT Endpoint firmware is failing the request with Invalid Field IOCStatus. memset the request frame to zero before framing the diag buffer register command. Link: https://lore.kernel.org/r/20220825075457.16422-3-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
When a pool crosses the 4GB boundary region then before reallocating pools change the coherent DMA mask to 32 bits and keep the normal DMA mask set to 63/64 bits. Link: https://lore.kernel.org/r/20220825075457.16422-2-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
If SCSI error handling is taking place for timed out I/Os on a drive and the corresponding drive is removed, then stop escalating to higher level of reset by returning the TUR with "I_T NEXUS LOSS OCCURRED" sense key. Link: https://lore.kernel.org/r/20220816080801.13929-1-sreekanth.reddy@broadcom.comSigned-off-by:
-
Gustavo A. R. Silva authored
Prefer struct_size() over open-coded versions of idiom: sizeof(struct-with-flex-array) + sizeof(type-of-flex-array) * count where count is the max number of items the flexible array is supposed to have. Link: https://github.com/KSPP/linux/issues/160 Link: https://lore.kernel.org/r/b215f4760f0e8fbe5fc35be20f2487e89924424d.1660592640.git.gustavoars@kernel.orgReviewed-by: -
Gustavo A. R. Silva authored
Prefer struct_size() over open-coded versions of idiom: sizeof(struct-with-flex-array) + sizeof(type-of-flex-array) * count where count is the max number of items the flexible array is supposed to have. Link: https://github.com/KSPP/linux/issues/160 Link: https://lore.kernel.org/r/1211398fb8f7ab332a93f4f8f1a63e8168dbd002.1660592640.git.gustavoars@kernel.orgReviewed-by:
-
Gustavo A. R. Silva authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct MR_PD_CFG_SEQ_NUM_SYNC and refactor the rest of the code accordingly. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays [0]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109 Link: Link: https://reviews.llvm.org/D126864 [0] Link: https://lore.kernel.org/r/78e9261591db072b67fcf49f0216d7046a67ca6d.1660592640.git.gustavoars@kernel.orgReviewed-by:
-
Gustavo A. R. Silva authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct MR_DRV_RAID_MAP and refactor the code accordingly. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/r/1448f387821833726b99f0ce13069ada89164eb5.1660592640.git.gustavoars@kernel.orgReviewed-by:
-
Gustavo A. R. Silva authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct MR_FW_RAID_MAP_DYNAMIC. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/r/896476f8fe43cf83b491c6c13f59c9ace780d82c.1660592640.git.gustavoars@kernel.orgReviewed-by:
-
Gustavo A. R. Silva authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct MR_DRV_RAID_MAP and refactor the the rest of the code accordingly. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/r/4495ce170c8ef088a10f1abe0e7c227368f43242.1660592640.git.gustavoars@kernel.orgReviewed-by:
-
Tetsuo Handa authored
Although qla2xxx driver is calling schedule_{,delayed}_work() from 10 locations, I assume that flush_scheduled_work() from qlt_stop_phase1() needs to flush only works scheduled by qlt_sched_sess_work(), for this loop continues while "struct qla_tgt"->sess_works_list is not empty. Link: https://lore.kernel.org/r/133c6723-90b6-5c8b-72b4-cc01eeb3a8c0@I-love.SAKURA.ne.jpTested-by:Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
