- 08 Jul, 2020 18 commits
-
-
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 <damien.lemoal@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
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 20 commits
-
-
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:
-
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/20200626035948.944148-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Douglas Gilbert authored
Heavy testing indicates the irqsave() spinlock around the __set_bit() is insufficient to stop following clear_bit() calls being rarely applied out-of-order. Also the nearby failed kzalloc() path leading to SCSI_MLQUEUE_HOST_BUSY does not properly undo the in_use bitmap and num_in_q, fix. Link: https://lore.kernel.org/r/20200702145355.522283-1-dgilbert@interlog.comSigned-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Mike Christie authored
Just delete the sess from the session list instead of adding it to some list we never use. Link: https://lore.kernel.org/r/1593632868-6808-4-git-send-email-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
There is no need for one session to flush the entire iscsi_eh_timer_workq when removing/unblocking a session. During removal we need to make sure our works are not running anymore. And iscsi_unblock_session only needs to make sure its work is done. The unblock work function will flush/cancel the works it has conflicts with. Link: https://lore.kernel.org/r/1593632868-6808-3-git-send-email-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
If we are doing async removal of the session, we could be doing a scsi_remove_target from the removal workqueue, and for the offload case we could be doing a new session addition and scan to the same host. The add/scan might then end up trying to use the target_id of the target we are removing. This patch just has a delay the freeing of the target_id until after the scsi_remove_target has completed, so we know it's no longer in use. Link: https://lore.kernel.org/r/1593632868-6808-2-git-send-email-michael.christie@oracle.comReviewed-by:
-
Bob Liu authored
Permit scsi_wq_xxx and scsi_tmf_xxx to be bound to different CPUs to get better isolation. Use alloc_workqueue with WQ_SYSFS and drop __WQ_ORDERED_EXPLICIT since a __WQ_ORDERED_EXPLICIT workqueue isn't allowed to change the CPU mask. Link: https://lore.kernel.org/r/20200701030745.16897-2-bob.liu@oracle.comReviewed-by:
-
Dick Kennedy authored
Update lpfc version to 12.8.0.2 Link: https://lore.kernel.org/r/20200630215001.70793-15-jsmart2021@gmail.comSigned-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
Dick Kennedy authored
The current logging methods typically end up requesting a reproduction with a different logging level set to figure out what happened. This was mainly by design to not clutter the kernel log messages with things that were typically not interesting and the messages themselves could cause other issues. When looking to make a better system, it was seen that in many cases when more data was wanted was when another message, usually at KERN_ERR level, was logged. And in most cases, what the additional logging that was then enabled was typically. Most of these areas fell into the discovery machine. Based on this summary, the following design has been put in place: The driver will maintain an internal log (256 elements of 256 bytes). The "additional logging" messages that are usually enabled in a reproduction will be changed to now log all the time to the internal log. A new logging level is defined - LOG_TRACE_EVENT. When this level is set (it is not by default) and a message marked as KERN_ERR is logged, all the messages in the internal log will be dumped to the kernel log before the KERN_ERR message is logged. There is a timestamp on each message added to the internal log. However, this timestamp is not converted to wall time when logged. The value of the timestamp is solely to give a crude time reference for the messages. Link: https://lore.kernel.org/r/20200630215001.70793-14-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Although the existing implementation is very good at high I/O load, on tests involving light load, especially on only a few hardware queues, latency was a little higher than it can be due to using workqueue scheduling. Other tasks in the system can delay handling. Change the lower level to use irq_poll by default which uses a softirq for I/O completion. This gives better latency as variance in when the cq is processed is reduced over the workqueue interface. However, as high load is better served by not being in softirq when the CPU is loaded, work queues are still used under high I/O load. Link: https://lore.kernel.org/r/20200630215001.70793-13-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Currently, if there has been an issue whereby an adapter dump was taken, there is nothing displayed to hint that it is present. Utilities must be run and they must query for the status in order to then download the dump. Add a message to the driver to query dump image presence when initializing the SLI Port. Link: https://lore.kernel.org/r/20200630215001.70793-12-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Currently the driver validates command codes received from the application. COMMON_SET_FEATURES is not currently being approved. Add definition of the missing command and allow it to be issued by applications. Link: https://lore.kernel.org/r/20200630215001.70793-11-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Change vocabulary of 0373 log msg from "error" to "cmpl" The current language of the 0373 message contains the word "error" which caused a number of customers to inquire about the "error" and if it should be a concern. It isn't an error, it's simply an io completion status. Revise the message to replace the word "error" with "cmpl" for completion. Link: https://lore.kernel.org/r/20200630215001.70793-10-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
When the kdump kernel shuts down lpfc calls flush_work_queue on an interrupt to schedule the cq handler. When there is only one CPU active on the kdump kernel, it is possible for the work_on to get scheduled on a non-active CPU causing it to never be scheduled. When in the kdump environment, per-CPU affinity of cq's to cpus is not necessary. In those cases, use a general queue_work rather than a queue_work_on(). Link: https://lore.kernel.org/r/20200630215001.70793-9-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
When vports are deleted, it is observed that there is memory/kthread leakage as the vport isn't fully being released. There is a shost reference taken in scsi_add_host_dma that is not released during scsi_remove_host. It was noticed that other drivers resolve this by doing a scsi_host_put after calling scsi_remove_host. The vport_delete routine is taking two references one that corresponds to an access to the scsi_host in the vport_delete routine and another that is released after the adapter mailbox command completes that destroys the VPI that corresponds to the vport. Remove one of the references taken such that the second reference that is put will complete the missing scsi_add_host_dma reference and the shost will be terminated. Link: https://lore.kernel.org/r/20200630215001.70793-8-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Call traces have been observed running different tests that involve aborts and setting the rrq active flag. The lpfc_set_rrq_active routine is doing a mempool_alloc under the soft_irq processing level. When the mempool needs to get a new buffer from the free pool and has to wait for memory to become free it will check the flags passed in on the alloc and dump the stack if the thread is running in interrupt context. Replace the GFP_KERNEL flag with GFP_ATOMIC so that the memory allocation will not attempt to sleep if there is no mem available. Link: https://lore.kernel.org/r/20200630215001.70793-7-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
When using DUMP on SLI3 to read VPD and Port status data (config region 23), the adapter is overruning the kmalloc'd buffer causing havoc on other consumers of the allocation pools. Rework the loops processing the dump data and validate/size memory lengths before performing bcopy. Link: https://lore.kernel.org/r/20200630215001.70793-6-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
During driver unload/reload testing, the NVMe initiator would not re-establish connectivity to NVMe controllers on reload. The failing NVMe array supports concurrent FCP and NVMe operation via different nport_id's. The array was repeatedly sending an ADISC every 2 seconds after PLOGI completed and while NVMe subsystems were executing discovery. The target would continue this state for roughly 45 seconds. The driver's current behavior on ADISC receipt is to validate a the ADISC vs the device and issue a RESUME_RPI to restore transmission. The receipt of the ADISC effectively caused a driver to take actions similar to a logout and login for the remote port, causing the deregistration of the nvme rport and a subsequent re-registration. This caused a constant reset and re-connect of the NVMe controller while this 45s window occurred. There was no need for the state changes as ADISC does not change login state. This patch corrects this behavior by validating if the remoteport is already logged in (MAPPED) and when true, avoids the call to set the ndlp state to MAPPED, which triggers the unreg/re-reg. Thus ADISC does not change the login state of the node. Link: https://lore.kernel.org/r/20200630215001.70793-5-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Visual code inspection of the MDS implementation revealed two errors in the driver: - The set features Feature Code had an incorrect value - The routine that classifies command type for cmd completions was missing the Send Frame definition. Send Frame is used for MDS driver loopback. Link: https://lore.kernel.org/r/20200630215001.70793-3-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Coverity reported the following error: Assigned value that is never used may represent unnecessary computation. The rc variable was initially assigned a value but in several cases, when an error case is detected, it is reassigned a new value. The initial value had little use. In code-reviewing this routine, it could use some cleanup: - Setting the initialization value to -ENODEV is a much better choice and lessens code in the routine. - The wasn't tracking logic errors vs no error and mailbox failure. Better to resolve by adding a status to track the mailbox failure and merge it with the logic error when the routine returns. Link: https://lore.kernel.org/r/20200630215001.70793-2-jsmart2021@gmail.comSigned-off-by:
-
- 02 Jul, 2020 2 commits
-
-
Shyam Sundar authored
* Firmware Initialization with SCM enabled based on NVRAM setting and firmware support (About Firmware). * Enable PUREX and add support for fabric performance impact notification (FPIN) handling. * Allocate a default PUREX item for each vha to handle memory allocation failures in ISR. Link: https://lore.kernel.org/r/20200630102229.29660-3-njavali@marvell.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Shyam Sundar <ssundar@marvell.com> Signed-off-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Shyam Sundar authored
SAN Congestion Management generates ELS pkts whose size can vary and be > 64 bytes. Change the PUREX handling code to support non-standard ELS pkt size. Link: https://lore.kernel.org/r/20200630102229.29660-2-njavali@marvell.comReviewed-by:
-
