RE: [PATCH v6 3/4] scsi_transport_fc: Added a new rport state FC_PORTSTATE_MARGINAL

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

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

Hi Mike,
Thanks for the input.
Below are my replies.


>Hey sorry for the late reply. I was trying to test some things out but am
>not sure if all drivers work the same.

>For the code above, what will happen if we have passed that check in the
>driver, then the driver does the report del and add sequence? Let's say
>it's initially calling the abort callout, and we passed that check, we then
>do the >del/add seqeuence, what will happen next? Do the fc drivers return
>success or failure for the abort call. What happens for the other callouts
>too?

>If failure, then the eh escalates and when we call the next callout, and we
>hit the check above and will clear it, so we are ok.

If success then we would not get a chance to clear it right?
[Muneendra]Agreed. So what about clearing the flags in fc_remote_port_del. I
think this should address all the concerns?

> If this is the case, then I think you need to instead go the route where
> you add the eh cmd completion/decide_disposition callout. You would call
> it in scmd_eh_abort_handler, scsi_eh_bus_device_reset, etc when we are
> deciding if we want to retry/fail the command.
[Muneendra]Sorry I didn't get what you are saying could you please elaborate
on the same.

In this approach you do not need the eh_timed_out changes, since we only
seem to care about the port state after the eh callout has completed.
[Muneendra]what about setting the SCMD_NORETRIES_ABORT bit?

Regards,
Muneendra.

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