- 08 Jul, 2020 39 commits
-
-
Andres Beltran authored
For additional robustness in the face of Hyper-V errors or malicious behavior, validate all values that originate from packets that Hyper-V has sent to the guest. Ensure that invalid values cannot cause data being copied out of the bounds of the source buffer when calling memcpy. Ensure that outgoing packets do not have any leftover guest memory that has not been zeroed out. Link: https://lore.kernel.org/r/20200706160928.53049-1-lkmlabelt@gmail.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:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
Andres Beltran <lkmlabelt@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Randy Dunlap authored
Drop the doubled word "be". Link: https://lore.kernel.org/r/20200707180414.10467-18-rdunlap@infradead.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: Matthew Wilcox <willy@infradead.org> Cc: Hannes Reinecke <hare@suse.com> Cc: linux-scsi@vger.kernel.org Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Dick Kennedy authored
The expression start_idx - dbg_cnt is evaluated using unsigned int arthithmetic (since these variables are unsigned ints) and hence can never be less than zero, so the less than comparison is never true. Rewrite the expression to check for start_idx being less than dbg_cnt. After the logic was corrected, temp_idx wasn't working correctly. So fix it as well. Link: https://lore.kernel.org/r/20200706204246.130416-1-jsmart2021@gmail.com Fixes: 372c187b ("scsi: lpfc: Add an internal trace log buffer") CC: Colin Ian King <colin.king@canonical.com> Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
Dick Kennedy authored
With certain platforms its possible pci_alloc_irq_vectors() may affinitize irq vectors to multiple (all?) CPUs. The driver is currently assuming exclusivity and vectors being doled out to different CPUs and is assigning primary ownership of each vector to the first CPU in the mask. The code doesn't bother to check if the CPU already owns a vector and will unconditionally overwrite the CPU to vector mapping. This causes the relationships between eq's and cq's to get confused and gets worse when CPUs start to offline. The net results are interrupts are skipped resulting in mailbox timeouts and there are oopses in CPU offling flows. Fix this changing up the primary vector assignment. Now assign the eq to a CPU only if it is the CPU in the mask that does not have a prior assignment. And once the primary ownership is assigned, break from the loop. For CPUs that may have been set before but not the primary owner, the lpfc_cpu_affinity_check() routine will balance the CPU to eq assignment. Link: https://lore.kernel.org/r/20200706204230.130363-1-jsmart2021@gmail.comSigned-off-by:
-
Satya Tangirala authored
Wire up ufshcd.c with the UFS Crypto API, the block layer inline encryption additions and the keyslot manager. Many existing inline crypto devices require some additional behaviour not specified in the UFSHCI v2.1 specification - as such the vendor specific drivers will need to be updated where necessary to make it possible to use those devices. Some of these changes have already been proposed upstream, such as for the Qualcomm 845 SoC at https://lkml.kernel.org/linux-scsi/20200501045111.665881-1-ebiggers@kernel.org/ and for ufs-mediatek at https://lkml.kernel.org/linux-scsi/20200304022101.14165-1-stanley.chu@mediatek.com/ This patch has been tested on the db845c, sm8150-mtp and sm8250-mtp (which have Qualcomm chipsets) and on some mediatek chipsets using these aforementioned vendor specific driver updates. Link: https://lore.kernel.org/r/20200706200414.2027450-4-satyat@google.comReviewed-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Satya Tangirala <satyat@google.com> Signed-off-by:
-
Satya Tangirala authored
Introduce functions to manipulate UFS inline encryption hardware in line with the JEDEC UFSHCI v2.1 specification and to work with the block keyslot manager. The UFS crypto API will assume by default that a vendor driver doesn't support UFS crypto, even if the hardware advertises the capability, because a lot of hardware requires some special handling that's not specified in the aforementioned JEDEC spec. Each vendor driver must explicitly set hba->caps |= UFSHCD_CAP_CRYPTO before ufshcd_hba_init_crypto_capabilities() is called to opt-in to UFS crypto support. Link: https://lore.kernel.org/r/20200706200414.2027450-3-satyat@google.comReviewed-by:
-
Satya Tangirala authored
Add the crypto registers and structs defined in v2.1 of the JEDEC UFSHCI specification in preparation to add support for inline encryption to UFS. Link: https://lore.kernel.org/r/20200706200414.2027450-2-satyat@google.comReviewed-by:
-
Colin Ian King authored
Fix smatch warning: drivers/scsi/lpfc/lpfc_sli.c:15156 lpfc_cq_poll_hdler() warn: inconsistent indenting Link: https://lore.kernel.org/r/20200707150018.823350-1-colin.king@canonical.comReviewed-by:James Smart <james.smart@broadcom.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/libfc/fc_disc.c:343: warning: Function parameter or member 'disc' not described in 'fc_disc_gpn_ft_req' drivers/scsi/libfc/fc_disc.c:343: warning: Excess function parameter 'lport' description in 'fc_disc_gpn_ft_req' drivers/scsi/libfc/fc_disc.c:380: warning: Function parameter or member 'disc' not described in 'fc_disc_gpn_ft_parse' drivers/scsi/libfc/fc_disc.c:380: warning: Excess function parameter 'lport' description in 'fc_disc_gpn_ft_parse' drivers/scsi/libfc/fc_disc.c:498: warning: Function parameter or member 'disc_arg' not described in 'fc_disc_gpn_ft_resp' drivers/scsi/libfc/fc_disc.c:498: warning: Excess function parameter 'lp_arg' description in 'fc_disc_gpn_ft_resp' Link: https://lore.kernel.org/r/20200707140055.2956235-10-lee.jones@linaro.org Cc: Hannes Reinecke <hare@suse.de> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Lee Jones authored
There is no need to populate an unused variable, even if the read is required. Fixes the following W=1 kernel build warning(s): drivers/scsi/pcmcia/nsp_cs.c: In function ‘nsp_cs_message’: drivers/scsi/pcmcia/nsp_cs.c:143:2: warning: function ‘nsp_cs_message’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] drivers/scsi/pcmcia/nsp_cs.c: In function ‘nsp_fifo_count’: drivers/scsi/pcmcia/nsp_cs.c:692:24: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] Link: https://lore.kernel.org/r/20200707140055.2956235-9-lee.jones@linaro.org Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/pcmcia/nsp_cs.c: In function ‘nsp_cs_message’: drivers/scsi/pcmcia/nsp_cs.c:143:2: warning: function ‘nsp_cs_message’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] drivers/scsi/pcmcia/nsp_cs.c: In function ‘nsp_fifo_count’: drivers/scsi/pcmcia/nsp_cs.c:692:24: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] Link: https://lore.kernel.org/r/20200707140055.2956235-8-lee.jones@linaro.org Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp> Signed-off-by:
-
Lee Jones authored
Looks to be unused since 2014. Fixes the following W=1 kernel build warning(s): drivers/scsi/aha152x.c: In function ‘datai_run’: drivers/scsi/aha152x.c:2033:9: warning: variable ‘data’ set but not used [-Wunused-but-set-variable] 2033 | int data; | ^~~~ Link: https://lore.kernel.org/r/20200707140055.2956235-7-lee.jones@linaro.org Cc: "Juergen E. Fischer" <fischer@norbit.de> Signed-off-by:
-
Lee Jones authored
Not all source files which include 'fdomain.h' make use of 'fdomain_pm_ops' leaving them defined but unused. Mark it as __maybe_unused to tell the compiler this is not only acceptable, but expected. Fixes the following W=1 kernel build warning(s): In file included from drivers/scsi/pcmcia/fdomain_cs.c:16: drivers/scsi/fdomain.h:106:32: warning: ‘fdomain_pm_ops’ defined but not used [-Wunused-const-variable=] 106 | static const struct dev_pm_ops fdomain_pm_ops; | ^~~~~~~~~~~~~~ Link: https://lore.kernel.org/r/20200707140055.2956235-4-lee.jones@linaro.orgSigned-off-by:
-
Bean Huo authored
According to the UFS Spec, the Flags field in the UPIU is one byte in size, not 4. Change it to be u8. Link: https://lore.kernel.org/r/20200706123936.24799-1-huobean@gmail.comTested-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
Damien Le Moal authored
Fix kdoc comments format to avoid compiler warnings when compiling with W=1. No functional changes. Link: https://lore.kernel.org/r/20200706123358.452180-1-damien.lemoal@wdc.comSigned-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
-
Damien Le Moal authored
In _config_request(), the variable issue_reset is set using the macro mpt3sas_check_cmd_timeout() but otherwise unused, causing a compiler warning when compiling with W=1. Avoid this warning by removing this variable, using the function mpt3sas_base_check_cmd_timeout() directly instead of the mpt3sas_check_cmd_timeout() macro. Link: https://lore.kernel.org/r/20200706123356.452135-1-damien.lemoal@wdc.comSigned-off-by:
-
Damien Le Moal authored
Fix the kdoc comment of the function sd_zbc_check_capacity() to avoid a compiler warning when compiling with W=1. No functional changes. Link: https://lore.kernel.org/r/20200706123355.452091-1-damien.lemoal@wdc.comSigned-off-by:
-
Damien Le Moal authored
Fix the kdoc comment of the function sd_ioctl_common() to avoid a compiler warning when compiling with W=1. No functional changes. Link: https://lore.kernel.org/r/20200706123354.452047-1-damien.lemoal@wdc.comSigned-off-by:
-
Damien Le Moal authored
In mega_is_bios_enabled(), the variable ret is set but unused. Remove it to avoid a compiler warning. Link: https://lore.kernel.org/r/20200706123352.452003-1-damien.lemoal@wdc.comSigned-off-by:
-
Damien Le Moal authored
In megadev_ioctl(), if MEGA_HAVE_STATS is not defined, the variables num_ldrv and ustats are unused. Conditionally define them to avoid compiler warnings. Link: https://lore.kernel.org/r/20200706123351.451959-1-damien.lemoal@wdc.comSigned-off-by:
-
Damien Le Moal authored
In mega_build_cmd(), the variable epthru is set but not used. Remove it to avoid a compiler warning. Link: https://lore.kernel.org/r/20200706123349.451915-1-damien.lemoal@wdc.comSigned-off-by:
-
Damien Le Moal authored
The variable remainder is unused in mega_div64_32(). Remove it to avoid a compiler warning. While at it, also fix the function documentation comments. Link: https://lore.kernel.org/r/20200706123348.451871-1-damien.lemoal@wdc.comSigned-off-by:
-
Damien Le Moal authored
Move function declarations to megaraid_sas.h to avoid warnings such as: warning: no previous prototype for ‘xxx' No functional changes. Link: https://lore.kernel.org/r/20200706123346.451827-1-damien.lemoal@wdc.comSigned-off-by:
-
Damien Le Moal authored
Fix kernel documentation comments to avoid various warnings when compiling with W=1. No functional changes. Link: https://lore.kernel.org/r/20200706123345.451783-1-damien.lemoal@wdc.comSigned-off-by:
-
Julian Wiedmann authored
zfcp_qdio_send() and zfcp_qdio_int_req() run concurrently, adding and completing SBALs on the Request Queue. There's a theoretical race where zfcp_qdio_int_req() completes a number of SBALs & increments the queue's free-level _before_ zfcp_qdio_send() was able to decrement it. This can cause ->req_q_free to momentarily hold a value larger than QDIO_MAX_BUFFERS_PER_Q. Luckily zfcp_qdio_send() is always called under ->req_q_lock, and all readers of the free-level also take this lock. So we can trust that zfcp_qdio_send() will clean up such a temporary overflow before anyone can actually observe it. But it's still confusing and annoying to worry about. So adjust the code to avoid this race. Link: https://lore.kernel.org/r/7f61f59a1f8db270312e64644f9173b8f1ac895f.1593780621.git.bblock@linux.ibm.comReviewed-by:
Steffen Maier <maier@linux.ibm.com> Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
Instead of manually moving each element of the unit and port lists into our temporary on-stack lists, splice them over in one go. Link: https://lore.kernel.org/r/cacb179f49ece50fd4dce119c61252d632cdc1d4.1593780621.git.bblock@linux.ibm.comReviewed-by:
-
Julian Wiedmann authored
We already maintain a pointer to act->adapter. Use it consistently to avoid any confusion about whose ->erp_ready_head and ->erp_ready_wq we are accessing. Link: https://lore.kernel.org/r/d1bb04322f240dee32f4c4a551bc93bc736f4b01.1593780621.git.bblock@linux.ibm.comReviewed-by:
-
Benjamin Block authored
IBM decided to retire a lot of the content that was previously hosted on "developerworks", and so some of the links we've used for documentation are now dead or redirect to some general landing page with no correlation to what the links were meant to provide. Change the provided link in the Kconfig file for zfcp to rather refer to our device drivers book that we regularly update and publish for free, and whose name hasn't been changed since it was first published. Our hardware is also not called "IBM eServer zSeries" anymore - in fact, it hasn't been called like that since 2006. Use a broader term that covers different server names over time. Lastly, add a short paragraph about how our HBAs are typically named, to have some more tangible references. Link: https://lore.kernel.org/r/96069b9f4c4f056a515b37e89b2bdfccc282e3d3.1593780621.git.bblock@linux.ibm.comReviewed-by:
-
Benjamin Block authored
IBM decided to retire a lot of the content that was previously hosted on "developerworks", and so some of the links we've used for documentation are now dead or redirect to some general landing page with no correlation to what the links were meant to provide. The s390-tools package is meanwhile also hosted on github, so we can link to the script directly instead of to the archive. Link: https://lore.kernel.org/r/9ab0341d6ddca46cfc885e4cd9dc38f535969b02.1593780621.git.bblock@linux.ibm.comReviewed-by:
-
Julian Wiedmann authored
zfcp no longer uses the qdio PCI flag, update the comment. Link: https://lore.kernel.org/r/6717c26fc986bff8776d110e27c199b523684c63.1593780621.git.bblock@linux.ibm.com Fixes: 21ddaa53 ("[SCSI] zfcp: Remove PCI flag") Reviewed-by:
Fedor Loshakov <loshakov@linux.ibm.com> Signed-off-by:
-
George Spelvin authored
We don't need crypto-grade random numbers for randomized backoffs. Instead use prandom_u32_max(ep_ro) which generates a pseudo-random number uniformly distributed in the interval [0, ep_ro). Link: https://lore.kernel.org/r/8fc7c4c4069ff1783f4a9ccd84a923f581a09ec5.1593780621.git.bblock@linux.ibm.comReviewed-by:
George Spelvin <lkml@sdf.org> Signed-off-by:
-
Bob Liu authored
Register sysfs for workqueue iscsi_destroy so that users can set CPU affinity through "cpumask" for this workqueue to get better isolation in cloud multi-tenant scenario. This patch unfolded create_singlethread_workqueue(), added WQ_SYSFS and drop __WQ_ORDERED_EXPLICIT since __WQ_ORDERED_EXPLICIT workqueue isn't allowed to change "cpumask". Link: https://lore.kernel.org/r/20200703051603.1473-1-bob.liu@oracle.comSuggested-by:
Mike Christie <michael.christie@oracle.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Reviewed-by:
Bob Liu <bob.liu@oracle.com> Signed-off-by:
-
Mike Christie authored
SPC4 has: The first ISCSI INITIATOR SESSION ID field byte containing an ASCII null character terminates the ISCSI INITIATOR SESSION ID field without regard for the specified length of the iSCSI TransportID or the contents of the ADDITIONAL LENGTH field. ---------------------------------------- which sounds like we can get an iSID shorter than 12 chars. SPC and the iSCSI RFC do not say how to handle that case other than just cutting off the iSID. This patch just makes sure that if we get an iSID like that, we only copy/send that string. There is no OS that does this right now, so there was no test case. I did test with sg utils to check it works as expected and nothing breaks. Link: https://lore.kernel.org/r/1593654203-12442-8-git-send-email-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
The isid returned to the initiator is in string format which is 12 bytes. We also only add 1 terminating NULL and not one after the initiator name and another one after the isid. Link: https://lore.kernel.org/r/1593654203-12442-7-git-send-email-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
This fixes the following bugs with the transport id setup for iscsi: 1. Incorrectly adding NULL after initiator name for TPID format 1. 2. For TPID format 1 buffer setup we are doing off+len, off++ and then also len+=some_value. This results in the isid going past buffer boundaries when we then do buf[off+len] 3. The pr_reg_isid is the isid in string format which is 12 bytes, but we are only copying 6 bytes. Link: https://lore.kernel.org/r/1593654203-12442-6-git-send-email-michael.christie@oracle.comSigned-off-by: -
Mike Christie authored
The length passed in the ADDITIONAL LENGTH field includes padding and the terminating NULL for the last field (name or isid depending on the format), so we should not also try to calculate that and then double add that to the returned length. Link: https://lore.kernel.org/r/1593654203-12442-5-git-send-email-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
__core_scsi3_add_registration clears the t10_pr_registration pr_reg_deve and does a core_scsi3_lunacl_undepend_item which does an undepend and also does a kref_put from the get done in __core_scsi3_alloc_registration. So when we get to the bottom of core_scsi3_decode_spec_i_port the pr_reg_deve is NULL and we crash when trying to access the local_pr_reg's pr_reg_deve. We've also done an extra undepend for local_pr_reg and if we didn't crash on the NULL we would have done an extra kref_put too. This patch has us do a core_scsi3_lunacl_depend_item for local_pr_reg and then let __core_scsi3_add_registration handle the cleanup for the pr_reg_deve. We then just skip the undepend for the acl and tpg for the local pr_reg. The error path then works in a similar way, but we always do the core_scsi3_lunacl_undepend_item since we never call __core_scsi3_add_registration in that code path. Link: https://lore.kernel.org/r/1593654203-12442-4-git-send-email-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
transport_init_session can allocate memory via percpu_ref_init, and target_xcopy_release_pt never frees it. This adds a transport_uninit_session function to handle cleanup of resources allocated in the init function. Link: https://lore.kernel.org/r/1593654203-12442-3-git-send-email-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
Move the check for enforce_pr_isids to the registration code where we can fail at the time an initiator tries to register a path without an isid. In its current place in __core_scsi3_locate_pr_reg, it is too late because it can be registered and be reported in PR in commands and it is stuck in this state because we cannot unregister it. [mkp: applied by hand] Link: https://lore.kernel.org/r/1593654203-12442-2-git-send-email-michael.christie@oracle.comReviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
-
- 03 Jul, 2020 1 commit
-
-
Christophe JAILLET authored
The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200626040553.944352-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
