Re: [PATCH 1/1] scsi: storvsc: Avoid allocating memory for temp cpumasks

On Thu, 17 May 2018 14:07:40 -0700 Michael Kelley wrote: > Current code allocates 240 Kbytes (in typical configs) for > each synthetic SCSI controller to use as temp cpumask variables. > Recode to avoid needing the temp cpumask variables and remove the > memory allocation.

[PATCH 1/1] scsi: storvsc: Avoid allocating memory for temp cpumasks

Current code allocates 240 Kbytes (in typical configs) for each synthetic SCSI controller to use as temp cpumask variables. Recode to avoid needing the temp cpumask variables and remove the memory allocation. Signed-off-by: Michael Kelley --- This patch is for the

Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup

Christoph Hellwig writes: > On Thu, May 17, 2018 at 12:28:01AM -0500, Eric W. Biederman wrote: >> > struct pid_namespace *proc_pid_namespace(struct inode *inode) >> > { >> >// maybe warn on for s_magic not on procfs?? >> >return inode->i_sb->s_fs_info; >> > } >> >> That

[PATCH 08/25] zfcp: decouple SCSI traces for scsi_eh / TMF from scsi_cmnd

The SCSI command pointer passed to scsi_eh callbacks is just one arbitrary command of potentially many that are in the eh queue to be processed. The command is only used to indirectly pass the TMF scope in terms of SCSI ID/target and SCSI LUN for LUN reset. Hence, zfcp had filled in SCSI trace

[PATCH 25/25] zfcp: enhance comments on fc_link_speed and supported_speed

From: Jens Remus The comment on fsf_qtcb_bottom_port.supported_speed did read as if the field can only assume one of two possible values (i.e. 0x1 for 1 GBit/s or 0x2 for 2 GBit/s). This is not true for two reasons: first it is a flag field and can thus assume any

[PATCH 23/25] zfcp: assert that the ERP lock is held when tracing a recovery trigger

From: Jens Remus Otherwise iterating with list_for_each() over the adapter->erp_ready_head and adapter->erp_running_head lists can lead to an infinite loop. See commit "zfcp: fix infinite iteration on erp_ready_head list". The run-time check is only performed for debug

[PATCH 22/25] zfcp: cleanup indentation for posting FC events

I just happened to see the function header indentation of zfcp_fc_enqueue_event() and I picked some more from checkpatch: $ checkpatch.pl --strict -f drivers/s390/scsi/zfcp_fc.c ... CHECK: Alignment should match open parenthesis #113: FILE: drivers/s390/scsi/zfcp_fc.c:113: +

[PATCH 21/25] zfcp: support SCSI_ADAPTER_RESET via scsi_host sysfs attribute host_reset

Make use of feature introduced with v3.2 commit 294436914454 ("[SCSI] scsi: Added support for adapter and firmware reset"). The common code interface was introduced for commit 95d31262b3c1 ("[SCSI] qla4xxx: Added support for adapter and firmware reset"). $ echo adapter >

[PATCH 24/25] zfcp: add port speed capabilities

From: Jens Remus Add port speed capabilities as defined in FC-LS RPSC ELS that have a counterpart FC_PORTSPEED_* defined in scsi/scsi_transport_fc.h. Suggested-by: Steffen Maier Signed-off-by: Jens Remus Reviewed-by: Steffen

[PATCH 18/25] zfcp: zfcp_erp_action_exists() does only check for running

Simplify its signature to return boolean and rename it to zfcp_erp_action_is_running() to indicate its actual unmodified semantics. It has always been used like this since v2.6.0 history commit ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter."). Signed-off-by: Steffen Maier

[PATCH 09/25] zfcp: decouple TMF response handler from scsi_cmnd

Originally, I planned for TMF handling to have different context data in fsf_req->data depending on the TMF scope in fcp_cmnd->fc_tm_flags: * scsi_device if FCP_TMF_LUN_RESET, * zfcp_port if FCP_TMF_TGT_RESET. However, the FCP channel requires a valid LUN handle so we now use scsi_device as

[PATCH 16/25] zfcp: consistently use function name space prefix

I've been mixing up zfcp_task_mgmt_function() [SCSI] and zfcp_fsf_fcp_task_mgmt() [FSF] so often lately that I wanted to fix this. SCSI changes complement v2.6.27 commit f76af7d7e363 ("[SCSI] zfcp: Cleanup of code in zfcp_scsi.c"). While at it, also fixup the other inconsistencies elsewhere.

[PATCH 05/25] zfcp: fix missing REC trigger trace on terminate_rport_io for ERP_FAILED

For problem determination we always want to see when we were invoked on the terminate_rport_io callback whether we perform something or not. Temporal event sequence of interest with a long fast_io_fail_tmo of 27 sec: loose remote port t workqueue [s] zfcp_q_ IRQ zfcperp

[PATCH 14/25] zfcp: decouple our scsi_eh callbacks from scsi_cmnd

Note: zfcp_scsi_eh_host_reset_handler() will be converted in a later patch. zfcp_scsi_eh_device_reset_handler() now only depends on scsi_device. zfcp_scsi_eh_target_reset_handler() now only depends on scsi_target. All derive other objects from these intended callback arguments.

[PATCH 17/25] zfcp: remove unused ERP enum values

All constant defines were introduced with v2.6.0 history commit ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter.") and refactored into enums with commit 287ac01acf22 ("[SCSI] zfcp: Cleanup code in zfcp_erp.c"). ZFCP_STATUS_ERP_DISMISSING and ZFCP_ERP_STEP_FSF_XCONFIG were never used.

[PATCH 19/25] zfcp: remove unused return values of ERP trigger functions

Since v2.6.27 commit 553448f6c483 ("[SCSI] zfcp: Message cleanup"), none of the callers has been interested any more. Values were not returned consistently in all ERP trigger functions. Signed-off-by: Steffen Maier Reviewed-by: Benjamin Block ---

[PATCH 20/25] zfcp: explicitly support initiator in scsi_host_template

While the default did already correctly print "Initiator" let's make it explicit and convert zfcp to the feature. $ cat /sys/class/scsi_host/host0/supported_mode Initiator $ cat /sys/class/scsi_host/host0/active_mode Initiator The default worked, because not setting the field has it initialized

[PATCH 06/25] zfcp: fix missing REC trigger trace for all objects in ERP_FAILED

That other commit introduced an inconsistency because it would trace on ERP_FAILED for all callers of port forced reopen triggers (not just terminate_rport_io), but it would not trace on ERP_FAILED for all callers of other ERP triggers such as adapter, port regular, LUN. Therefore, generalize

[PATCH 03/25] zfcp: fix misleading REC trigger trace where erp_action setup failed

If a SCSI device is deleted during scsi_eh host reset, we cannot get a reference to the SCSI device anymore since scsi_device_get returns !=0 by design. Assuming the recovery of adapter and port(s) was successful, zfcp_erp_strategy_followup_success() attempts to trigger a LUN reset for the

[PATCH 07/25] zfcp: fix missing REC trigger trace on enqueue without ERP thread

Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea: 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 ZFCP_DBF_REC_TRIG Tag: ... LUN

[PATCH 15/25] workqueue,zfcp: set description for port work items with their WWPN as context

As a prerequisite, complement commit 3d1cb2059d93 ("workqueue: include workqueue info when printing debug dump of a worker task") to be usable with kernel modules by exporting the symbol set_worker_desc(). Current built-in user was introduced with commit ef3b101925f2 ("writeback: set worker desc

[PATCH 13/25] zfcp: decouple TMFs from scsi_cmnd by using fc_block_rport

Intentionally retrieve the rport by walking SCSI common code objects rather than zfcp_sdev->port->rport. The latter is used for pairing the calls to fc_remote_port_add() and fc_remote_port_delete(). [see v2.6.31 commit 379d6bf6573e ("[SCSI] zfcp: Add port only once to FC transport class")]

[PATCH 12/25] zfcp: decouple SCSI setup of TMF from scsi_cmnd

Actually change the signature of zfcp_fsf_fcp_task_mgmt(). Since it was prepared in the previous patch, we only need to delete a local auto variable which is now the intended argument. Prepare zfcp_fsf_fcp_task_mgmt's caller zfcp_task_mgmt_function() to have its function body only depend on a

[PATCH 11/25] zfcp: decouple FSF request setup of TMF from scsi_cmnd

In zfcp_fsf_fcp_task_mgmt() resolve the still old argument scsi_cmnd into scsi_device very early and only depend on scsi_device and derived objects in the function body. This prepares to later change the function signature replacing the scsi_cmnd argument with scsi_device. Signed-off-by: Steffen

[PATCH 10/25] zfcp: split FCP_CMND IU setup between SCSI I/O and TMF again

This reverts commit 2443c8b23aea ("[SCSI] zfcp: Merge FCP task management setup with regular FCP command setup"), because this introduced a dependency on the unsuitable SCSI command for scsi_eh / TMF. Signed-off-by: Steffen Maier Reviewed-by: Hannes Reinecke

[PATCH 02/25] zfcp: fix missing SCSI trace for retry of abort / scsi_eh TMF

We already have a SCSI trace for the end of abort and scsi_eh TMF. Due to zfcp_erp_wait() and fc_block_scsi_eh() time can pass between the start of our eh callback and an actual send/recv of an abort / TMF request. In order to see the temporal sequence including any abort / TMF send retries, add a

[PATCH 04/25] zfcp: fix missing REC trigger trace on terminate_rport_io early return

get_device() and its internally used kobject_get() only return NULL if they get passed NULL as argument. zfcp_get_port_by_wwpn() loops over adapter->port_list so the iteration variable port is always non-NULL. Struct device is embedded in struct zfcp_port so >dev is always non-NULL. This is the

[PATCH 01/25] zfcp: fix missing SCSI trace for result of eh_host_reset_handler

For problem determination we need to see whether and why we were successful or not. This allows deduction of scsi_eh escalation. Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : SCSI Subarea: 00 Level : 1 Exception : - CPU

[PATCH 00/25] zfcp: updates for v4.18

James, Martin, this is the zfcp patch set for the v4.18 merge window. The patches apply to Martin's 4.18/scsi-queue. The patches eventually go on top of the bug fix commit fa89adba1941e4f3b213399b81732a5c12fd9131 ("scsi: zfcp: fix infinite iteration on ERP ready list") in Martin's 4.17/scsi-fixes

[PATCH] scsi: snic: fix a couple of spelling mistakes: "COMPLETE"

From: Colin Ian King Trivial fix to spelling mistakes/typos: "SNIC_IOREQ_ABTS_COMPELTE" -> "SNIC_IOREQ_ABTS_COMPLETE" "SNIC_IOREQ_LR_COMPELTE" -> "SNIC_IOREQ_LR_COMPLETE" "SNIC_IOREQ_CMD_COMPELTE" -> "SNIC_IOREQ_CMD_COMPLETE" Signed-off-by: Colin Ian King

Re: [PATCH 1/1] qla2xxx: Allow SCSI-MQ to be enabled selectively

On Wed, May 16, 2018 at 08:54:11PM -0700, Himanshu Madhani wrote: > when ql2xmqsupport=1, use that value to selectively > enable SCSI-MQ NAK. This is not something that we should grow driver parameters for. Btw, should we look into enabling blk-mq by default again now that all the performance

Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup

On Thu, May 17, 2018 at 12:28:01AM -0500, Eric W. Biederman wrote: > > struct pid_namespace *proc_pid_namespace(struct inode *inode) > > { > > // maybe warn on for s_magic not on procfs?? > > return inode->i_sb->s_fs_info; > > } > > That should work. Ideally out of line for the proc_fs.h