RE: [patch v4 4/5] scsi_transport_fc: Added a new rport state FC_PORTSTATE_MARGINAL

[Muneendra Kumar M <muneendra.kumar@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

Hi Mike,
Below are my replies.

-----Original Message-----
From: Mike Christie [mailto:michael.christie@oracle.com]
Sent: Monday, October 26, 2020 10:45 PM
To: Muneendra <muneendra.kumar@broadcom.com>; linux-scsi@vger.kernel.org;
hare@suse.de
Cc: jsmart2021@gmail.com; emilne@redhat.com; mkumar@redhat.com
Subject: Re: [patch v4 4/5] scsi_transport_fc: Added a new rport state
FC_PORTSTATE_MARGINAL

On 10/22/20 7:34 AM, Muneendra wrote:
> @@ -2071,6 +2074,7 @@ fc_eh_timed_out(struct scsi_cmnd *scmd)  {
>  	struct fc_rport *rport =
> starget_to_rport(scsi_target(scmd->device));
>
> +	fc_rport_chkmarginal_set_noretries(rport, scmd);
>  	if (rport->port_state == FC_PORTSTATE_BLOCKED)
>  		return BLK_EH_RESET_TIMER;

>If we are in port state marginal above, then we will try to abort the cmd,
>but if while doing the abort we call fc_remote_port_delete and
>fc_remote_port_add then the port state will be online when the EH callouts
>complete. In >this case, the port state is online in the end, but we would
>fail the command like it was in marginal.
[Muneendra] I have to  make sure the flag is set after the check for blocked
state.  If blocked, it's returning BLK_EH_RESET_TIMER, so it will restart
the eh
timer. The io will "sit out" like this, pending, until either the adapter
fails it back due to logout or io completion, or fastio fail or
rport devloss timesout and invokes the abort handler to force abort .

> +		(rport->port_state != FC_PORTSTATE_MARGINAL)) {
>  		spin_unlock_irqrestore(shost->host_lock, flags);
>  		return;

>It looks like if fc_remote_port_delete is called, then we will allow that
>function to set the port_state to blocked. If the problem is resolved then
>fc_remote_port_add will set the state to online. So it would look like the
>port state is >now ok in the kernel, but would userspace still have it in
>the marginal port group?

>Did you want this behavior or did you want it to stay in marginal until
>your daemon marks it as online?
[Muneendra] We need this behavior.User daemon
should not depend on the rport_state to move a path from marginal path
 group.It should only depends on RSCN and LINKUP events/manual
intervention. events that we look out (rscn for target-side cable  bounces
and link up/down for initiator cable bounces) will result in
port state changes - so although we don't drive one from the other, they are
correlated.

Regards,
Muneendra.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4177 bytes --]