- 05 May, 2020 10 commits
-
-
Douglas Gilbert authored
Add support for the 5 ZBC commands and enough functionality to emulate a host-managed device with one conventional zone and a set of sequential write-required zones up to the disk capacity. Link: https://lore.kernel.org/r/20200422104221.378203-3-damien.lemoal@wdc.comSigned-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Douglas Gilbert authored
The ZBC standard "piggy-backs" on many, but not all, of the facilities in SBC. Add those ZBC mode pages (plus mode parameter block descriptors (e.g. "WP")) and VPD pages in common with SBC. Add ZBC specific VPD page for the host-managed ZBC device type (ptype=0x14). Link: https://lore.kernel.org/r/20200422104221.378203-2-damien.lemoal@wdc.comSigned-off-by:
-
Douglas Gilbert authored
The scsi_debug driver version is visible in: /sys/modules/scsi_debug/version and can thus be used by user space programs to alter the features they try to use. Since the per_host_store and zbc/zone options are significant additions, bump the version number to 1.89 . Link: https://lore.kernel.org/r/20200421151424.32668-9-dgilbert@interlog.comSigned-off-by:
-
Douglas Gilbert authored
This module has a lot of parameters and when searching for one, the author prefers them in alphabetical order. This can lead to somewhat illogical ordering (e.g. inq_product before inq_vendor). However it is not clear what another sensible total logical ordering would be. Link: https://lore.kernel.org/r/20200421151424.32668-8-dgilbert@interlog.comSigned-off-by:
-
Douglas Gilbert authored
Many disks implement the SCSI PRE-FETCH commands. One use case might be a disk-to-disk compare, say between disks A and B. Then this sequence of commands might be used: PRE-FETCH(from B, IMMED), READ(from A), VERIFY (BYTCHK=1 on B with data returned from READ). The PRE-FETCH (which returns quickly due to the IMMED) fetches the data from the media into B's cache which should speed the trailing VERIFY command. The next chunk of the compare might be done in parallel, with A and B reversed. The implementation tries to bring the specified range in main memory into the cache(s) associated with this machine's CPU(s) using the prefetch_range() function. Link: https://lore.kernel.org/r/20200421151424.32668-7-dgilbert@interlog.comSigned-off-by:
-
Douglas Gilbert authored
Previously the code did the work implied by the given SCSI command and after that it waited for a timer based on the user specified command duration to be exhausted before informing the mid-level that the command was complete. For short command durations, the time to complete the work implied by the SCSI command could be significant compared to the user specified command duration. For example a WRITE of 128 blocks (say 512 bytes each) on a machine that can copy from main memory to main memory at a rate of 10 GB/sec will take around 6.4 microseconds to do that copy. If the user specified a command duration of 5 microseconds (ndelay=5000), should the driver do a further delay of 5 microseconds after the copy or return immediately because 6.4 > 5 ? The action prior to this patch was to always do the timer based delay. After this patch, for ndelay values less than 1 millisecond, this driver will complete the command immediately. And in the case where the user specified delay was 7 microseconds, a timer delay of 600 nanoseconds will be set ((7 - 6.4) * 1000). Link: https://lore.kernel.org/r/20200421151424.32668-6-dgilbert@interlog.comSigned-off-by:
-
Douglas Gilbert authored
The design of this driver is to do any ramdisk access on the same thread that invoked the queuecommand() call. That is assumed to be user space context. The command duration is implemented by setting the delay with a high resolution timer. The hr timer's callback may well be in interrupt context, but it doesn't touch the ramdisk. So try removing the _irqsave()/_irqrestore() portion on the read-write lock that protects ramdisk access. Link: https://lore.kernel.org/r/20200421151424.32668-5-dgilbert@interlog.comSigned-off-by:
-
Douglas Gilbert authored
With the addition of the per_host_store option, the ability to check whether two different ramdisk images are the same or not becomes practical. Prior to this patch VERIFY(10) always returned true (i.e. the SCSI GOOD status) without checking. This option adds support for BYTCHK equal to 0, 1 and 3. If the comparison fails, then a sense key of MISCOMPARE is returned as per the T10 standards. Also add support for the VERIFY(16) command. Link: https://lore.kernel.org/r/20200421151424.32668-4-dgilbert@interlog.comReviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Douglas Gilbert authored
The scsi_debug driver has always been restricted to using one ramdisk image (or none) for its storage. This means that thousands of scsi_debug devices can be created without exhausting the host machine's RAM. The downside is that all scsi_debug devices share the same ramdisk image. This option changes the way a following write to the add_host parameter (or an add_host in the module/driver invocation) operates. For each new host that is created while per_host_store is true, a new store (of dev-size_mb MiB) is created and associated with all the LUs that belong to that new host. The user (who will need root permissions) needs to take care not to exhaust all the machine's available RAM. One reason for doing this is to check that (partial) disk to disk copies based on scsi_debug devices have actually copied accurately. To test this the add_host=<n> parameter where <n> is 2 or greater can be used when the scsi_debug module is loaded. Let us assume that /dev/sdb and /dev/sg1 are the same scsi_debug device, while /dev/sdc and /dev/sg2 are the same scsi_debug device. With per_host_store=1 add_host=2 they will have different ramdisk images. Then the following pseudocode could be executed to check if the sgh_dd copy worked: dd if=/dev/urandom of=/dev/sdb sgh_dd if=/dev/sg1 of=/dev/sg2 [plus option(s) to test] cmp /dev/sdb /dev/sdc If the cmp fails then the copy has failed (or some other mechanism wrote to /dev/sdb or /dev/sdc in the interim). [mkp: use kstrtobool()] Link: https://lore.kernel.org/r/20200421151424.32668-3-dgilbert@interlog.comSigned-off-by: -
Douglas Gilbert authored
Add a new command line option (e.g. random=1) and sysfs attribute that causes subsequent command completion times to be between the current command delay setting and 0. A uniformly distributed 32 bit, kernel provided integer is used for this purpose. Since the existing 'delay' whose units are jiffies (typically milliseconds) and 'ndelay' (units: nanoseconds) options (and sysfs attributes) span a range greater than 32 bits, some scaling is required. The purpose of this patch is to widen the range of testing cases that are visited in long running tests. Put simply: rarely struct race conditions are more likely to be found when this facility is used. The default is the previous case in which all command completions were roughly equal to (if not, slightly longer) than the value given by the 'delay' or 'ndelay' settings (or their defaults). This option's default is equivalent to setting 'random=0' . [mkp: use kstrtobool()] Link: https://lore.kernel.org/r/20200421151424.32668-2-dgilbert@interlog.comReviewed-by:
-
- 30 Apr, 2020 4 commits
-
-
Xiongfeng Wang authored
The channel index is represented by an unsigned variable 'u32 chan'. We don't need to check whether it is less than zero, the 'chan < 0' statement is always false. Remove it. Link: https://lore.kernel.org/r/1588162218-61757-1-git-send-email-wangxiongfeng2@huawei.comReported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by:
-
Dan Carpenter authored
Smatch complains that the "path_data->handle" variable is user controlled. It comes from iscsi_set_path() so that seems possible. It's harmless to add a limit check. The qedi->ep_tbl[] array has qedi->max_active_conns elements (which is always ISCSI_MAX_SESS_PER_HBA (4096) elements). The array is allocated in the qedi_cm_alloc_mem() function. Link: https://lore.kernel.org/r/20200428131939.GA696531@mwanda Fixes: ace7f46b ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Acked-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Colin Ian King authored
The bitfields mpi_fw_dump_reading and mpi_fw_dumped are currently signed which is not recommended as the representation is an implementation defined behaviour. Fix this by making the bit-fields unsigned ints. Link: https://lore.kernel.org/r/20200428102013.1040598-1-colin.king@canonical.com Fixes: cbb01c2f ("scsi: qla2xxx: Fix MPI failure AEN (8200) handling") Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Johannes Thumshirn authored
In case scsi_setup_fs_cmnd() fails we're not freeing the sgtables allocated by scsi_init_io(), thus we leak the allocated memory. Free the sgtables allocated by scsi_init_io() in case scsi_setup_fs_cmnd() fails. Technically scsi_setup_scsi_cmnd() does not suffer from this problem as it can only fail if scsi_init_io() fails, so it does not have sgtables allocated. But to maintain symmetry and as a measure of defensive programming, free the sgtables on scsi_setup_scsi_cmnd() failure as well. scsi_mq_free_sgtables() has safeguards against double-freeing of memory so this is safe to do. While we're at it, rename scsi_mq_free_sgtables() to scsi_free_sgtables(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=205595 Link: https://lore.kernel.org/r/20200428104605.8143-2-johannes.thumshirn@wdc.comReviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Daniel Wagner <dwagner@suse.de> Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
-
- 27 Apr, 2020 7 commits
-
-
André Almeida authored
Despite of functions being documented, they are not in the kernel-doc specification, and could not be included in kernel documentation. Change the style of functions comments to be compliant to the kernel-doc style. When the function comments are outdated, update then. [mkp: a few edits] Link: https://lore.kernel.org/r/20200419050148.33371-1-andrealmeid@collabora.comSigned-off-by:
André Almeida <andrealmeid@collabora.com> Signed-off-by:
-
Asutosh Das authored
Enable WriteBooster for Qualcomm platform. Link: https://lore.kernel.org/r/cd4cf745ea0b3a59c2075036e17316b97494fe65.1587591527.git.asutoshd@codeaurora.orgReviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Asutosh Das <asutoshd@codeaurora.org> Signed-off-by:
-
Asutosh Das authored
Adds unit, device, geometry descriptor sysfs entries. Adds flags sysfs entries for write booster. Link: https://lore.kernel.org/r/98987ef17844292bd42c57613990a3a26c6de2b8.1587591527.git.asutoshd@codeaurora.orgReviewed-by:
-
Asutosh Das authored
The write performance of TLC NAND is considerably lower than SLC NAND. Using SLC NAND as a WriteBooster Buffer enables the write request to be processed with lower latency and improves the overall write performance. Adds support for shared-buffer mode WriteBooster. WriteBooster enable: SW enables it when clocks are scaled up, thus it's enabled only in high load conditions. WriteBooster disable: SW will disable the feature, when clocks are scaled down. Thus writes would go as normal writes. To keep the endurance of the WriteBooster Buffer at a maximum, this load-based toggling is adopted. Link: https://lore.kernel.org/r/2871444d9083b0e9323ef6d8ff1b544b7784adc9.1587591527.git.asutoshd@codeaurora.orgReviewed-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/ufs/ufshcd.c:4140:6-14: WARNING: Assignment of 0/1 to bool variable. Link: https://lore.kernel.org/r/20200426094305.24083-1-yanaijie@huawei.comSigned-off-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Bart Van Assche authored
This patch makes the sr code slightly easier to read. Link: https://lore.kernel.org/r/20200427014844.12109-1-bvanassche@acm.org Cc: Merlijn Wajer <merlijn@archive.org> Signed-off-by:
-
Christophe JAILLET authored
If 'scsi_host_alloc()' or 'kcalloc()' fail, 'error' is known to be 0. Set it explicitly to -ENOMEM before branching to the error handling path. While at it, remove 2 useless assignments to 'error'. These values are overwridden a few lines later. Link: https://lore.kernel.org/r/20200412094039.8822-1-christophe.jaillet@wanadoo.frSigned-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
- 24 Apr, 2020 19 commits
-
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/sgiwd93.c:190:2-3: Unneeded semicolon Link: https://lore.kernel.org/r/20200421034029.28030-1-yanaijie@huawei.comSigned-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/qla4xxx/ql4_os.c:969:3-4: Unneeded semicolon Link: https://lore.kernel.org/r/20200421034038.28113-1-yanaijie@huawei.comSigned-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/isci/isci.h:515:1-12: WARNING: Assignment of 0/1 to bool variable drivers/scsi/isci/isci.h:503:1-12: WARNING: Assignment of 0/1 to bool variable drivers/scsi/isci/isci.h:509:1-12: WARNING: Assignment of 0/1 to bool variable Link: https://lore.kernel.org/r/20200421034050.28193-1-yanaijie@huawei.comSigned-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:948:4-5: Unneeded semicolon drivers/scsi/bnx2fc/bnx2fc_fcoe.c:968:4-5: Unneeded semicolon Link: https://lore.kernel.org/r/20200421034019.27949-1-yanaijie@huawei.comSigned-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/bfa/bfa_fcs_rport.c:2452:2-3: Unneeded semicolon drivers/scsi/bfa/bfa_fcs_rport.c:1578:3-4: Unneeded semicolon Link: https://lore.kernel.org/r/20200421033957.27783-1-yanaijie@huawei.comSigned-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/bfa/bfa_svc.c: In function 'uf_recv': drivers/scsi/bfa/bfa_svc.c:5520:17: warning: variable 'fchs' set but not used [-Wunused-but-set-variable] struct fchs_s *fchs; ^ Link: https://lore.kernel.org/r/20200418071057.96699-1-yuehaibing@huawei.comSigned-off-by:YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Jason Yan authored
This function does not need a return value since no callers depend on it. Make it return void. This also fixes the coccicheck warning: drivers/scsi/snic/snic_ctl.c:163:5-8: Unneeded variable: "ret". Return "0" on line 228 Link: https://lore.kernel.org/r/20200418070615.11603-1-yanaijie@huawei.comReported-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/mpt3sas/mpt3sas_base.c:4906:3-19: WARNING: NULL check before some freeing functions is not needed. Link: https://lore.kernel.org/r/20200418095850.34883-1-yanaijie@huawei.comReported-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/ipr.c:9533:2-18: WARNING: NULL check before some freeing functions is not needed. Link: https://lore.kernel.org/r/20200418095903.35118-1-yanaijie@huawei.comReported-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/bfa/bfa_fcs_lport.c:4361:3-4: Unneeded semicolon Link: https://lore.kernel.org/r/20200418070553.11262-1-yanaijie@huawei.comReported-by:
-
Wu Bo authored
Replace dma_pool_malloc with dma_pool_zalloc to make the code more concise in pmcraid_allocate_control_blocks() function. Link: https://lore.kernel.org/r/1587197241-274646-1-git-send-email-wubo40@huawei.comSigned-off-by:
Wu Bo <wubo40@huawei.com> Signed-off-by:
-
Maurizio Lombardi authored
This patch removes the iscsi_data_count structure and the iscsit_do_rx_data() function because they are used only by rx_data() Link: https://lore.kernel.org/r/20200424113913.17237-1-mlombard@redhat.comReviewed-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Signed-off-by:
-
Ming Lei authored
scsi_host_block() calls scsi_internal_device_block() for each scsi_device and scsi_internal_device_block() calls blk_mq_quiesce_queue() for each LUN. Since synchronize_rcu() is called from blk_mq_quiesce_queue(), this can cause substantial slowdowns on systems with many LUNs. Use scsi_internal_device_block_nowait() to implement scsi_host_block() so it is sufficient to run synchronize_rcu() once. This is safe since SCSI does not set the BLK_MQ_F_BLOCKING flag. [mkp: commit desc and comment tweaks] Link: https://lore.kernel.org/r/20200423020713.332743-1-ming.lei@redhat.com Cc: Steffen Maier <maier@linux.ibm.com> Cc: Bart Van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Dexuan Cui <decui@microsoft.com> Cc: Hannes Reinecke <hare@suse.de> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
-
Jason Yan authored
The '!=' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/scsi/BusLogic.c:2240:46-51: WARNING: conversion to bool not needed here Link: https://lore.kernel.org/r/20200421034120.28433-1-yanaijie@huawei.comAcked-by:
Khalid Aziz <khalid@gonehiking.org> Signed-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/scsi/megaraid/megaraid_sas_fusion.c:4242:6-16: WARNING: Assignment of 0/1 to bool variable drivers/scsi/megaraid/megaraid_sas_fusion.c:4786:1-29: WARNING: Assignment of 0/1 to bool variable drivers/scsi/megaraid/megaraid_sas_fusion.c:4791:1-29: WARNING: Assignment of 0/1 to bool variable drivers/scsi/megaraid/megaraid_sas_fusion.c:4716:1-29: WARNING: Assignment of 0/1 to bool variable drivers/scsi/megaraid/megaraid_sas_fusion.c:4721:1-29: WARNING: Assignment of 0/1 to bool variable Link: https://lore.kernel.org/r/20200421034111.28353-1-yanaijie@huawei.comAcked-by:
Chandrakanth Patil <chandrakanth.patil@broadcom.com> Signed-off-by:
-
Suganath Prabu authored
Update mpt3sas driver version from 33.100.00.00 to 33.101.00.00. Link: https://lore.kernel.org/r/1587626596-1044-6-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by:
Suganath Prabu <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Suganath Prabu authored
For INVADER_SERIES, each set of 8 reply queues (0 - 7, 8 - 15,..), and for VENTURA_SERIES, each set of 16 reply queues (0 - 15, 16 - 31,..) need to be within the same 4 GB boundary. Driver uses limitation of VENTURA_SERIES to manage INVADER_SERIES as well. The driver is allocating the DMA able memory for RDPQs accordingly. 1) At driver load, set DMA mask to 64 and allocate memory for RDPQs 2) Check if allocated resources for RDPQ are in the same 4GB range 3) If #2 is true, continue with 64 bit DMA and go to #6 4) If #2 is false, then free all the resources from #1 5) Set DMA mask to 32 and allocate RDPQs 6) Proceed with driver loading and other allocations Link: https://lore.kernel.org/r/1587626596-1044-5-git-send-email-suganath-prabu.subramani@broadcom.comReviewed-by:
-
Suganath Prabu authored
For readability separate out RDPQ allocations to new function base_alloc_rdpq_dma_pool(). Link: https://lore.kernel.org/r/1587626596-1044-4-git-send-email-suganath-prabu.subramani@broadcom.comReviewed-by:
-
Suganath Prabu authored
Rename is_MSB_are_same() to mpt3sas_check_same_4gb_region() for better readability. Link: https://lore.kernel.org/r/1587626596-1044-3-git-send-email-suganath-prabu.subramani@broadcom.comReviewed-by:
-
