- 24 Aug, 2016 14 commits
-
-
Jitendra Bhivare authored
Wrong settings displayed for iface: iface.header_digest = 192.168.197.22 iface.data_digest = 255.255.255.0 iface.immediate_data = 192.168.197.1 Process ISCSI_NET_PARAM only in beiscsi_iface_get_param. Signed-off-by:
Jitendra Bhivare <jitendra.bhivare@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Jitendra Bhivare authored
Rename mgmt_get_if_info to be consistent with APIs name. Rename create/destroy APIs to indicate IFACE operations. Remove legacy be2iscsi and use beiscsi. Signed-off-by:
-
Jitendra Bhivare authored
Move mgmt_get_all_if_id before any set param operation. Rename mgmt_get_all_if_id to beiscsi_if_get_handle. Signed-off-by:
-
Jitendra Bhivare authored
VLAN tag is L2 construct, move VLAN code out from configuring IP. Rearrange and rename the APIs to make it consistent. Replace ENOSYS with EPERM. Signed-off-by:
-
Jitendra Bhivare authored
If BOOTPROTO is changed to static, the DHCP IP address should be released. All cases are being handled mgmt_set_ip and mgmt_static_ip_modify. Rearrange IFACE APIs to: beiscsi_if_clr_ip beiscsi_if_set_ip beiscsi_if_en_static beiscsi_if_en_dhcp This simplifies release of DHCP IP when BOOTPROTO is set to static. Signed-off-by:
-
Jitendra Bhivare authored
Gateway APIs assume IP type as IPv4. Modify it to be generic to allow clearing of IPv6 gateway set using BIOS. Signed-off-by:
-
Jitendra Bhivare authored
ipv4_iface and ipv6_iface fields need to be set to NULL when destroyed. Before creation these are checked. Use these to report correct states. Signed-off-by:
-
Jitendra Bhivare authored
Driver takes significant time to load 1m:20s and unload 40s. Checkpatch script threw warning: WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt To eliminate this warning msleep(1) was replaced with msleep(20) before submitting. msleep(20) in init and uninit path for creation and destroying of number of WRBQs, CQs, and EQs is adding to load/unload time. Replace msleep with schedule_timeout_uninterruptible of 1ms as its enough in most cases. Signed-off-by:
-
Jitendra Bhivare authored
This got unnecessarily introduced with other changes in previous commits. mcc_lock is taken only in process contexts. Signed-off-by:
-
Jitendra Bhivare authored
Following configuration is created with what driver exports: iface.vlan_id = 65535 iface.vlan_priority = 255 iface.vlan_state = <empty> vlan_state is empty as iscsiadm doesn't process "Disabled". When applying this configuration, iscsiadm checks for if vlan_state is "disable" if not it enables with value in vlan_id. 65535 not being valid value, 0 is applied. Use "enable" or "disable" for ISCSI_NET_PARAM. Signed-off-by:
-
Johannes Thumshirn authored
Provide a translation table between Ethernet and FC port speeds so odd speeds (from a Ethernet POV) like 8 Gbit are correctly mapped to sysfs and open-fcoe's fcoeadm. Before: Description: BCM57840 NetXtreme II 10/20-Gigabit Ethernet Revision: 11 Manufacturer: Broadcom Corporation Serial Number: 6CC2173EA1D0 Driver: bnx2x 1.712.30-0 Number of Ports: 1 Symbolic Name: bnx2fc (QLogic BCM57840) v2.10.3 over eth2 OS Device Name: host1 Node Name: 0x20006cc2173ea1d1 Port Name: 0x10006cc2173ea1d1 FabricName: 0x100000c0dd0ce717 Speed: unknown Supported Speed: 1 Gbit, 10 Gbit MaxFrameSize: 2048 bytes FC-ID (Port ID): 0x660702 State: Online After: Description: BCM57840 NetXtreme II 10/20-Gigabit Ethernet Revision: 11 Manufacturer: Broadcom Corporation Serial Number: 6CC2173EA1D0 Driver: bnx2x 1.712.30-0 Number of Ports: 1 Symbolic Name: bnx2fc (QLogic BCM57840) v2.10.3 over eth2 OS Device Name: host1 Node Name: 0x20006cc2173ea1d1 Port Name: 0x10006cc2173ea1d1 FabricName: 0x100000c0dd0ce717 Speed: 8 Gbit Supported Speed: 1 Gbit, 10 Gbit MaxFrameSize: 2048 bytes FC-ID (Port ID): 0x660701 State: Online Signed-off-by:Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Hannes Reinicke <hare@suse.de> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
-
Matthew R. Ochs authored
Update the block library link in the API documentation. Signed-off-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Signed-off-by:
-
Matthew R. Ochs authored
The adapter file descriptor was previously cached within the kernel for a given context in order to support performing a close on behalf of an application. This is no longer needed as applications are now required to perform a close on the adapter file descriptor. Inspired-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Matthew R. Ochs authored
Caching the adapter file descriptor and performing a close on behalf of an application is a poor design. This is due to the fact that once a file descriptor in installed, it is free to be altered without the knowledge of the cxlflash driver. This can lead to inconsistencies between the application and kernel. Furthermore, the nature of the former design is more exploitable and thus should be abandoned. To support applications performing a close on the adapter file that is associated with a context, a new flag is introduced to the user API to indicate to applications that they are responsible for the close following the cleanup (detach) of a context. The documentation is also updated to reflect this change in behavior. Inspired-by:
-
- 19 Aug, 2016 7 commits
-
-
Matthew R. Ochs authored
Currently, context user references are tracked via the list of LUNs that have attached to the context. While convenient, this is not intuitive without a deep study of the code and is inconsistent with the existing reference tracking patterns within the kernel. This design choice can lead to future bug injection. To improve code comprehension and better protect against future bugs, add explicit reference counting to contexts and migrate the context removal code to the kref release handler. Inspired-by:
-
Matthew R. Ochs authored
The context removal routine requires access to the owning adapter structure to reset the context within the AFU as part of the tear down sequence. In order to support kref adoption, the owning adapter must be accessible from the release handler. As the kref framework only provides the kref reference as the sole parameter, another means is needed to derive the owning adapter. As a remedy, the owning adapter reference is saved off within the context during initialization. Signed-off-by:
-
Matthew R. Ochs authored
Context information structures are protected by a mutex that is held when accessing/manipulating the context. When the code that manages these structures was authored, a decision was made to include taking the mutex as part of the allocation/initialization sequence and also handle the scenario where the mutex was already held when freeing the context. While not a problem outright, this design decision has been deemed as too flexible and the code should be made more rigid to avoid future bugs. In addition, further review of the code yields that the existing mutex manipulations in both of these context management paths are superfluous. This commit removes the obtaining of the context mutex in the context initialization routine and assumes the mutex is not held in the context free path. Inspired-by:
-
Hannes Reinecke authored
When all exchanges are reset the upper layers have already logged out of the remote port, so the exchanges can be reset without sending any ABTS. Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Tested-by:
-
Hannes Reinecke authored
FC-LS mandates that we should invalidate all sequences before sending a LOGO. And we should set the event to RPORT_EV_STOP when a LOGO request has been received to signal that all exchanges are terminated. Signed-off-by:
-
Hannes Reinecke authored
When running in point-to-multipoint mode PLOGI is done after FLOGI completed. So when the PLOGI fails we should be sending a LOGO to the remote port. [mkp: Applied by hand] Signed-off-by:
-
Hannes Reinecke authored
When receiving a PRLO it just means that the operating parameters have changed, it does _not_ mean that the port doesn't want to communicate with us. So instead of implicitly logging out we should be issueing a PRLI to figure out the new operating parameters. We can always recover once PRLI fails. Signed-off-by:
-
- 12 Aug, 2016 11 commits
-
-
Steffen Maier authored
This was lost with commit 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") but is necessary for problem determination, e.g. to see the currently active zone set during automatic port scan. For the large GPN_FT response (4 pages), save space by not dumping any empty residual entries. Signed-off-by:
Steffen Maier <maier@linux.vnet.ibm.com> Fixes: 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") Cc: <stable@vger.kernel.org> #2.6.38+ Reviewed-by:
Alexey Ishchuk <aishchuk@linux.vnet.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.vnet.ibm.com> Reviewed-by:
-
Steffen Maier authored
commit 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") started to add FC_CT_HDR_LEN which made zfcp dump random data out of bounds for RSPN GS responses because u.rspn.rsp is the largest and last field in the union of struct zfcp_fc_req. Other request/response types only happened to stay within bounds due to the padding of the union or due to the trace capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD. Timestamp : ... Area : SAN Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : ... Record id : 2 Tag : fsscth2 Request id : 0x... Destination ID : 0x00fffffc Payload short : 01000000 fc020000 80020000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <=== 00000000 00000000 00000000 00000000 Payload length : 32 <=== struct zfcp_fc_req { [0] struct zfcp_fsf_ct_els ct_els; [56] struct scatterlist sg_req; [96] struct scatterlist sg_rsp; union { struct {req; rsp;} adisc; SIZE: 28+28= 56 struct {req; rsp;} gid_pn; SIZE: 24+20= 44 struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180 struct {req; rsp;} gspn; SIZE: 20+273= 293 struct {req; rsp;} rspn; SIZE: 277+16= 293 [136] } u; } SIZE: 432 Signed-off-by:
-
Steffen Maier authored
With commit 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") we lost the N_Port-ID where an ELS response comes from. With commit 7c7dc196 ("[SCSI] zfcp: Simplify handling of ct and els requests") we lost the N_Port-ID where a CT response comes from. It's especially useful if the request SAN trace record with D_ID was already lost due to trace buffer wrap. GS uses an open WKA port handle and ELS just a D_ID, and only for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req. To cover both cases, add a new field to zfcp_fsf_ct_els and fill it in on request to use in SAN response trace. Strictly speaking the D_ID on SAN response is the FC frame's S_ID. We don't need a field for the other end which is always us. Signed-off-by:
-
Steffen Maier authored
This information was lost with commit a54ca0f6 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") but is required to debug e.g. invalid handle situations. Signed-off-by:
-
Steffen Maier authored
Since commit a54ca0f6 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") HBA records no longer contain WWPN, D_ID, or LUN to reduce duplicate information which is already in REC records. In contrast to "regular" target ports, we don't use recovery to open WKA ports such as directory/nameserver, so we don't get REC records. Therefore, introduce pseudo REC running records without any actual recovery action but including D_ID of WKA port on open/close. Signed-off-by:
-
Steffen Maier authored
bring back commit d21e9daa ("[SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace") which was lost with commit ae0904f6 ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") Signed-off-by:
-
Steffen Maier authored
While retaining the actual filtering according to trace level, the following commits started to write such filtered records with a hardcoded record level of 1 instead of the actual record level: commit 250a1352 ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.") commit a54ca0f6 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Now we can distinguish written records again for offline level filtering. Signed-off-by:
-
Steffen Maier authored
On a successful end of reopen port forced, zfcp_erp_strategy_followup_success() re-uses the port erp_action and the subsequent zfcp_erp_action_cleanup() now sees ZFCP_ERP_SUCCEEDED with erp_action->action==ZFCP_ERP_ACTION_REOPEN_PORT instead of ZFCP_ERP_ACTION_REOPEN_PORT_FORCED but must not perform zfcp_scsi_schedule_rport_register(). We can detect this because the fresh port reopen erp_action is in its very first step ZFCP_ERP_STEP_UNINITIALIZED. Otherwise this opens a time window with unblocked rport (until the followup port reopen recovery would block it again). If a scsi_cmnd timeout occurs during this time window fc_timed_out() cannot work as desired and such command would indeed time out and trigger scsi_eh. This prevents a clean and timely path failover. This should not happen if the path issue can be recovered on FC transport layer such as path issues involving RSCNs. Also, unnecessary and repeated DID_IMM_RETRY for pending and undesired new requests occur because internally zfcp still has its zfcp_port blocked. As follow-on errors with scsi_eh, it can cause, in the worst case, permanently lost paths due to one of: sd <scsidev>: [<scsidisk>] Medium access timeout failure. Offlining disk! sd <scsidev>: Device offlined - not ready after error recovery For fix validation and to aid future debugging with other recoveries we now also trace (un)blocking of rports. Signed-off-by:
-
Steffen Maier authored
In the hardware data router case, introduced with kernel 3.2 commit 86a9668a ("[SCSI] zfcp: support for hardware data router") the ELS/GS request&response length needs to be initialized as in the chained SBAL case. Otherwise, the FCP channel rejects ELS requests with FSF_REQUEST_SIZE_TOO_LARGE. Such ELS requests can be issued by user space through BSG / HBA API, or zfcp itself uses ADISC ELS for remote port link test on RSCN. The latter can cause a short path outage due to unnecessary remote target port recovery because the always failing ADISC cannot detect extremely short path interruptions beyond the local FCP channel. Below example is decoded with zfcpdbf from s390-tools: Timestamp : ... Area : SAN Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : zfcp_dbf_san_req+0408 Record id : 1 Tag : fssels1 Request id : 0x<reqid> Destination ID : 0x00<target d_id> Payload info : 52000000 00000000 <our wwpn > [ADISC] <our wwnn > 00<s_id> 00000000 00000000 00000000 00000000 00000000 Timestamp : ... Area : HBA Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : zfcp_dbf_hba_fsf_res+0740 Record id : 1 Tag : fs_ferr Request id : 0x<reqid> Request status : 0x00000010 FSF cmnd : 0x0000000b [FSF_QTCB_SEND_ELS] FSF sequence no: 0x... FSF issued : ... FSF stat : 0x00000061 [FSF_REQUEST_SIZE_TOO_LARGE] FSF stat qual : 00000000 00000000 00000000 00000000 Prot stat : 0x00000100 Prot stat qual : 00000000 00000000 00000000 00000000 Signed-off-by:
-
Steffen Maier authored
For an NPIV-enabled FCP device, zfcp can erroneously show "NPort (fabric via point-to-point)" instead of "NPIV VPORT" for the port_type sysfs attribute of the corresponding fc_host. s390-tools that can be affected are dbginfo.sh and ziomon. zfcp_fsf_exchange_config_evaluate() ignores fsf_qtcb_bottom_config.connection_features indicating NPIV and only sets fc_host_port_type to FC_PORTTYPE_NPORT if fsf_qtcb_bottom_config.fc_topology is FSF_TOPO_FABRIC. Only the independent zfcp_fsf_exchange_port_evaluate() evaluates connection_features to overwrite fc_host_port_type to FC_PORTTYPE_NPIV in case of NPIV. Code was introduced with upstream kernel 2.6.30 commit 0282985d ("[SCSI] zfcp: Report fc_host_port_type as NPIV"). This works during FCP device recovery (such as set online) because it performs FSF_QTCB_EXCHANGE_CONFIG_DATA followed by FSF_QTCB_EXCHANGE_PORT_DATA in sequence. However, the zfcp-specific scsi host sysfs attributes "requests", "megabytes", or "seconds_active" trigger only zfcp_fsf_exchange_config_evaluate() resetting fc_host port_type to FC_PORTTYPE_NPORT despite NPIV. The zfcp-specific scsi host sysfs attribute "utilization" triggers only zfcp_fsf_exchange_port_evaluate() correcting the fc_host port_type again in case of NPIV. Evaluate fsf_qtcb_bottom_config.connection_features in zfcp_fsf_exchange_config_evaluate() where it belongs to. Signed-off-by:
-
Kevin Barnett authored
This initial commit contains Microsemi's smartpqi module. [mkp: Minor tweaks to apply to 4.9/scsi-queue] Reviewed-by:
Scott Benesh <scott.benesh@microsemi.com> Reviewed-by:
Kevin Barnett <kevin.barnett@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
- 09 Aug, 2016 6 commits
-
-
Dan Carpenter authored
The "if (test_bit(UNLOADING..." line was indented one tab more than it should have been. There was an extra parenthesis around the qla2x00_reset_active() function call. I lined up the conditions a bit so that it shows how they group together. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Himanshu Madhani <himanshu.madhani@qlogic.com> Signed-off-by:
-
Johannes Thumshirn authored
In _scsih_io_done() we test if the ioc->logging_level does _not_ have the MPT_DEBUG_REPLY bit set and if it hasn't we print the debug messages. This unfortunately is the wrong way around. Note, the actual bug is older than af009411 but this commit removed the CONFIG_SCSI_MPT3SAS_LOGGING Kconfig option which hid the bug. Fixes: af009411 'mpt2sas, mpt3sas: Remove SCSI_MPTXSAS_LOGGING entry from Kconfig' Signed-off-by:
Chaitra P B <chaitra.basappa@broadcom.com> Signed-off-by:
-
Calvin Owens authored
Trivial non-functional changes for a couple annoying things: 1) Functions local to files are not declared static, which is frustrating when reading the code because it's non-obvious at first glance what's actually called from other files. 2) Set-but-unused variables abound, presumably to mask -Wunused-result errors in the past. None of these are flagged today though (with one exception noted below), so remove them. Fixing (2) exposed the fact that we improperly ignore the return value of scsi_device_reprobe() in _scsih_reprobe_lun(). Fixing the calling code to deal with the potential error is non-trivial, so for now just WARN(). Signed-off-by:
Calvin Owens <calvinowens@fb.com> Acked-by:
-
Calvin Owens authored
With the exception of a single call to wait_for_doorbell_int(), all this conditional sleeping code is dead. So delete it. Signed-off-by:
-
Calvin Owens authored
This flag that conditionally acquires the mutex is confusing and prone to bugginess: refactor it into two separate function calls, and make the unlocked one complain if it's called outside the mutex. Signed-off-by:
-
Calvin Owens authored
We blindly trust the hardware to give us NUL-terminated strings, which is a bad idea because it doesn't always do that. For example: [ 481.184784] mpt3sas_cm0: enclosure level(0x0000), connector name( \x3) In this case, connector_name is four spaces. We got lucky here because the 2nd byte beyond our character array happens to be a NUL. Fix this by explicitly writing '\0' to the end of the string to ensure we don't run off the edge of the world in printk(). Signed-off-by:
-
- 08 Aug, 2016 1 commit
-
-
Linus Torvalds authored
-
- 07 Aug, 2016 1 commit
-
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull more block fixes from Jens Axboe: "As mentioned in the pull the other day, a few more fixes for this round, all related to the bio op changes in this series. Two fixes, and then a cleanup, renaming bio->bi_rw to bio->bi_opf. I wanted to do that change right after or right before -rc1, so that risk of conflict was reduced. I just rebased the series on top of current master, and no new ->bi_rw usage has snuck in" * 'for-linus' of git://git.kernel.dk/linux-block: block: rename bio bi_rw to bi_opf target: iblock_execute_sync_cache() should use bio_set_op_attrs() mm: make __swap_writepage() use bio_set_op_attrs() block/mm: make bdev_ops->rw_page() take a bool for read/write
-
