| Message ID | 1604556596-27228-4-git-send-email-muneendra.kumar@broadcom.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | scsi: Support to handle Intermittent errors | expand |
On 11/5/20 12:09 AM, Muneendra wrote: > int fc_block_scsi_eh(struct scsi_cmnd *cmnd) > { > struct fc_rport *rport = starget_to_rport(scsi_target(cmnd->device)); > + int ret = 0; > > if (WARN_ON_ONCE(!rport)) > return FAST_IO_FAIL; > > - return fc_block_rport(rport); > + ret = fc_block_rport(rport); > + /* > + * Clear the SCMD_NORETRIES_ABORT bit if the Port state has > + * changed from marginal to online due to > + * fc_remote_port_delete and fc_remote_port_add > + */ > + if (rport->port_state != FC_PORTSTATE_MARGINAL) > + clear_bit(SCMD_NORETRIES_ABORT, &cmnd->state); > + return ret; > } 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? 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. 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.
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.
On 11/5/20 11:27 AM, Muneendra Kumar M wrote: > 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? > I don't think you need it. It sounds like we only care about the port state when the cmd is completing. For example we have: 1. the case where the cmd times out, we do aborts/resets, then the port state goes into marginal, then the aborts/resets complete. We want to fail the cmds without retries. 2. If the port state is in marginal, the cmd times out, we do the aborts/resets and when we are done if the port state is still marginal we want to fail the cmd without retries. 3. If the port state is marginal (or any value), before or after the cmd initially times out, but the port state goes back to online, then when the aborts/resets complete we want to retry the cmd. So can we just add a callout to check the port state when the eh has completed like the untested unfinished patch below: diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c index 983eeb0..8ad3a9a 100644 --- a/drivers/scsi/lpfc/lpfc_scsi.c +++ b/drivers/scsi/lpfc/lpfc_scsi.c @@ -6041,6 +6041,7 @@ struct scsi_host_template lpfc_template = { .info = lpfc_info, .queuecommand = lpfc_queuecommand, .eh_timed_out = fc_eh_timed_out, + .eh_timed_out = fc_eh_should_retry_cmd, .eh_abort_handler = lpfc_abort_handler, .eh_device_reset_handler = lpfc_device_reset_handler, .eh_target_reset_handler = lpfc_target_reset_handler, diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index f11f51e..7c66d17 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -140,6 +140,7 @@ static bool scsi_cmd_retry_allowed(struct scsi_cmnd *cmd) struct scsi_cmnd *scmd = container_of(work, struct scsi_cmnd, abort_work.work); struct scsi_device *sdev = scmd->device; + struct Scsi_Host *host = sdev->host; int rtn; if (scsi_host_eh_past_deadline(sdev->host)) { @@ -159,7 +160,8 @@ static bool scsi_cmd_retry_allowed(struct scsi_cmnd *cmd) "eh timeout, not retrying " "aborted command\n")); } else if (!scsi_noretry_cmd(scmd) && - scsi_cmd_retry_allowed(scmd)) { + scsi_cmd_retry_allowed(scmd) && + host->hostt->eh_should_retry_cmd(scmd)) { SCSI_LOG_ERROR_RECOVERY(3, scmd_printk(KERN_WARNING, scmd, "retry aborted command\n")); @@ -2105,7 +2107,8 @@ void scsi_eh_flush_done_q(struct list_head *done_q) list_for_each_entry_safe(scmd, next, done_q, eh_entry) { list_del_init(&scmd->eh_entry); if (scsi_device_online(scmd->device) && - !scsi_noretry_cmd(scmd) && scsi_cmd_retry_allowed(scmd)) { + !scsi_noretry_cmd(scmd) && scsi_cmd_retry_allowed(scmd) && + host->hostt->eh_should_retry_cmd(scmd)) { SCSI_LOG_ERROR_RECOVERY(3, scmd_printk(KERN_INFO, scmd, "%s: flush retry cmd\n", diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 2ff7f06..7011963 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2043,6 +2043,18 @@ static int fc_vport_match(struct attribute_container *cont, return &i->vport_attr_cont.ac == cont; } +bool fc_eh_should_retry_cmd(struct scsi_cmnd *scmd) +{ + struct fc_rport *rport = starget_to_rport(scsi_target(scmd->device)); + + if (rport->port_state == FC_PORTSTATE_MARGINAL) + return false; + + /* Other port states will set the sdev state */ + /* TODO check comment above */ + return true; +} +EXPORT_SYMBOL_GPL(fc_eh_should_retry_cmd); /** * fc_eh_timed_out - FC Transport I/O timeout intercept handler diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h index 701f178..51d5af0 100644 --- a/include/scsi/scsi_host.h +++ b/include/scsi/scsi_host.h @@ -315,6 +315,13 @@ struct scsi_host_template { */ enum blk_eh_timer_return (*eh_timed_out)(struct scsi_cmnd *); + /* + * Optional routine that allows the transport to decide if a cmd is + * retryable. Return true if the transport is in a state the cmd + * should be retried on. + */ + bool (*eh_should_retry_cmd)(struct scsi_cmnd *); + /* This is an optional routine that allows transport to initiate * LLD adapter or firmware reset using sysfs attribute. * diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h index 1c7dd35..f21b583 100644 --- a/include/scsi/scsi_transport_fc.h +++ b/include/scsi/scsi_transport_fc.h @@ -803,6 +803,7 @@ struct fc_vport *fc_vport_create(struct Scsi_Host *shost, int channel, int fc_block_rport(struct fc_rport *rport); int fc_block_scsi_eh(struct scsi_cmnd *cmnd); enum blk_eh_timer_return fc_eh_timed_out(struct scsi_cmnd *scmd); +bool fc_eh_should_retry_cmd(struct scsi_cmnd *scmd); static inline struct Scsi_Host *fc_bsg_to_shost(struct bsg_job *job) {
Hi Mike, Thanks for the detailed input. I will apply the below changes and will resubmit the patches. Regards, Muneendra. -----Original Message----- From: Mike Christie [mailto:michael.christie@oracle.com] Sent: Thursday, November 5, 2020 9:29 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 v6 3/4] scsi_transport_fc: Added a new rport state FC_PORTSTATE_MARGINAL On 11/5/20 12:09 AM, Muneendra wrote: > int fc_block_scsi_eh(struct scsi_cmnd *cmnd) > { > struct fc_rport *rport = > starget_to_rport(scsi_target(cmnd->device)); > + int ret = 0; > > if (WARN_ON_ONCE(!rport)) > return FAST_IO_FAIL; > > - return fc_block_rport(rport); > + ret = fc_block_rport(rport); > + /* > + * Clear the SCMD_NORETRIES_ABORT bit if the Port state has > + * changed from marginal to online due to > + * fc_remote_port_delete and fc_remote_port_add > + */ > + if (rport->port_state != FC_PORTSTATE_MARGINAL) > + clear_bit(SCMD_NORETRIES_ABORT, &cmnd->state); > + return ret; > } 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? 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. 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.
Hi Mike, Thanks for the detailed input. I will apply the below changes and will resubmit the patches. Regards, Muneendra. -----Original Message----- From: Mike Christie [mailto:michael.christie@oracle.com] Sent: Friday, November 6, 2020 12:46 AM To: Muneendra Kumar M <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 v6 3/4] scsi_transport_fc: Added a new rport state FC_PORTSTATE_MARGINAL On 11/5/20 11:27 AM, Muneendra Kumar M wrote: > 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? > I don't think you need it. It sounds like we only care about the port state when the cmd is completing. For example we have: 1. the case where the cmd times out, we do aborts/resets, then the port state goes into marginal, then the aborts/resets complete. We want to fail the cmds without retries. 2. If the port state is in marginal, the cmd times out, we do the aborts/resets and when we are done if the port state is still marginal we want to fail the cmd without retries. 3. If the port state is marginal (or any value), before or after the cmd initially times out, but the port state goes back to online, then when the aborts/resets complete we want to retry the cmd. So can we just add a callout to check the port state when the eh has completed like the untested unfinished patch below: diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c index 983eeb0..8ad3a9a 100644 --- a/drivers/scsi/lpfc/lpfc_scsi.c +++ b/drivers/scsi/lpfc/lpfc_scsi.c @@ -6041,6 +6041,7 @@ struct scsi_host_template lpfc_template = { .info = lpfc_info, .queuecommand = lpfc_queuecommand, .eh_timed_out = fc_eh_timed_out, + .eh_timed_out = fc_eh_should_retry_cmd, .eh_abort_handler = lpfc_abort_handler, .eh_device_reset_handler = lpfc_device_reset_handler, .eh_target_reset_handler = lpfc_target_reset_handler, diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index f11f51e..7c66d17 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -140,6 +140,7 @@ static bool scsi_cmd_retry_allowed(struct scsi_cmnd *cmd) struct scsi_cmnd *scmd = container_of(work, struct scsi_cmnd, abort_work.work); struct scsi_device *sdev = scmd->device; + struct Scsi_Host *host = sdev->host; int rtn; if (scsi_host_eh_past_deadline(sdev->host)) { @@ -159,7 +160,8 @@ static bool scsi_cmd_retry_allowed(struct scsi_cmnd *cmd) "eh timeout, not retrying " "aborted command\n")); } else if (!scsi_noretry_cmd(scmd) && - scsi_cmd_retry_allowed(scmd)) { + scsi_cmd_retry_allowed(scmd) && + host->hostt->eh_should_retry_cmd(scmd)) { SCSI_LOG_ERROR_RECOVERY(3, scmd_printk(KERN_WARNING, scmd, "retry aborted command\n")); @@ -2105,7 +2107,8 @@ void scsi_eh_flush_done_q(struct list_head *done_q) list_for_each_entry_safe(scmd, next, done_q, eh_entry) { list_del_init(&scmd->eh_entry); if (scsi_device_online(scmd->device) && - !scsi_noretry_cmd(scmd) && scsi_cmd_retry_allowed(scmd)) { + !scsi_noretry_cmd(scmd) && scsi_cmd_retry_allowed(scmd) && + host->hostt->eh_should_retry_cmd(scmd)) { SCSI_LOG_ERROR_RECOVERY(3, scmd_printk(KERN_INFO, scmd, "%s: flush retry cmd\n", diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 2ff7f06..7011963 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2043,6 +2043,18 @@ static int fc_vport_match(struct attribute_container *cont, return &i->vport_attr_cont.ac == cont; } +bool fc_eh_should_retry_cmd(struct scsi_cmnd *scmd) { + struct fc_rport *rport = starget_to_rport(scsi_target(scmd->device)); + + if (rport->port_state == FC_PORTSTATE_MARGINAL) + return false; + + /* Other port states will set the sdev state */ + /* TODO check comment above */ + return true; +} +EXPORT_SYMBOL_GPL(fc_eh_should_retry_cmd); /** * fc_eh_timed_out - FC Transport I/O timeout intercept handler diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h index 701f178..51d5af0 100644 --- a/include/scsi/scsi_host.h +++ b/include/scsi/scsi_host.h @@ -315,6 +315,13 @@ struct scsi_host_template { */ enum blk_eh_timer_return (*eh_timed_out)(struct scsi_cmnd *); + /* + * Optional routine that allows the transport to decide if a cmd is + * retryable. Return true if the transport is in a state the cmd + * should be retried on. + */ + bool (*eh_should_retry_cmd)(struct scsi_cmnd *); + /* This is an optional routine that allows transport to initiate * LLD adapter or firmware reset using sysfs attribute. * diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h index 1c7dd35..f21b583 100644 --- a/include/scsi/scsi_transport_fc.h +++ b/include/scsi/scsi_transport_fc.h @@ -803,6 +803,7 @@ struct fc_vport *fc_vport_create(struct Scsi_Host *shost, int channel, int fc_block_rport(struct fc_rport *rport); int fc_block_scsi_eh(struct scsi_cmnd *cmnd); enum blk_eh_timer_return fc_eh_timed_out(struct scsi_cmnd *scmd); +bool fc_eh_should_retry_cmd(struct scsi_cmnd *scmd); static inline struct Scsi_Host *fc_bsg_to_shost(struct bsg_job *job) {
On 11/5/20 8:15 PM, Mike Christie wrote: > On 11/5/20 11:27 AM, Muneendra Kumar M wrote: >> 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? >> > > I don't think you need it. It sounds like we only care about the port state > when the cmd is completing. For example we have: > > 1. the case where the cmd times out, we do aborts/resets, then the > port state goes into marginal, then the aborts/resets complete. We want to > fail the cmds without retries. > > 2. If the port state is in marginal, the cmd times out, we do the aborts/resets > and when we are done if the port state is still marginal we want to fail the > cmd without retries. > > 3. If the port state is marginal (or any value), before or after the cmd > initially times out, but the port state goes back to online, then when the > aborts/resets complete we want to retry the cmd. > Actually, I don't think the third case can (or should) happen. A transition from marginal to online should always include a link bounce (ie a rport_del/rport_add sequence), which would cancel all outstanding commands anyway. And if we have the above provision we could clear the flag in rport_del() and everything would be dandy. Cheers, Hannes
On 11/6/20 1:23 AM, Hannes Reinecke wrote: > On 11/5/20 8:15 PM, Mike Christie wrote: >> On 11/5/20 11:27 AM, Muneendra Kumar M wrote: >>> 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? >>> >> >> I don't think you need it. It sounds like we only care about the port state >> when the cmd is completing. For example we have: >> >> 1. the case where the cmd times out, we do aborts/resets, then the >> port state goes into marginal, then the aborts/resets complete. We want to >> fail the cmds without retries. >> >> 2. If the port state is in marginal, the cmd times out, we do the aborts/resets >> and when we are done if the port state is still marginal we want to fail the >> cmd without retries. >> >> 3. If the port state is marginal (or any value), before or after the cmd >> initially times out, but the port state goes back to online, then when the >> aborts/resets complete we want to retry the cmd. >> > Actually, I don't think the third case can (or should) happen. > A transition from marginal to online should always include a link bounce (ie a rport_del/rport_add sequence), which would cancel all outstanding commands anyway. > And if we have the above provision we could clear the flag in rport_del() and everything would be dandy. That is the part I didn't like or I thought could have issues: 1. What if we go back into marginal after the add() but before we have done scsi_eh_flush_done_q? You need the original looping code and some code for del() right? 2. My issue with #1 is why do we want to add code that loops over commands when we only care about the port state and when scsi_eh_flush_done_q and the abort completion code is already looping over them. 3. This is probably a matter of preference, and I can see why people would not like an extra callout. However, I like the idea that we have an eh callout for the transport class that checks if it's even worth it to run the eh code based on the port state and then we have a eh completion callout that can also check the port state and determine if it's ok. If we had a marginal scsi_device state or even a bit then you would not actually need #3. The fc class could just set the device state/bit and we could check that in the eh completion code paths.
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 2ff7f06203da..276826db0832 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -142,20 +142,23 @@ fc_enum_name_search(host_event_code, fc_host_event_code, static struct { enum fc_port_state value; char *name; + int matchlen; } fc_port_state_names[] = { - { FC_PORTSTATE_UNKNOWN, "Unknown" }, - { FC_PORTSTATE_NOTPRESENT, "Not Present" }, - { FC_PORTSTATE_ONLINE, "Online" }, - { FC_PORTSTATE_OFFLINE, "Offline" }, - { FC_PORTSTATE_BLOCKED, "Blocked" }, - { FC_PORTSTATE_BYPASSED, "Bypassed" }, - { FC_PORTSTATE_DIAGNOSTICS, "Diagnostics" }, - { FC_PORTSTATE_LINKDOWN, "Linkdown" }, - { FC_PORTSTATE_ERROR, "Error" }, - { FC_PORTSTATE_LOOPBACK, "Loopback" }, - { FC_PORTSTATE_DELETED, "Deleted" }, + { FC_PORTSTATE_UNKNOWN, "Unknown", 7}, + { FC_PORTSTATE_NOTPRESENT, "Not Present", 11 }, + { FC_PORTSTATE_ONLINE, "Online", 6 }, + { FC_PORTSTATE_OFFLINE, "Offline", 7 }, + { FC_PORTSTATE_BLOCKED, "Blocked", 7 }, + { FC_PORTSTATE_BYPASSED, "Bypassed", 8 }, + { FC_PORTSTATE_DIAGNOSTICS, "Diagnostics", 11 }, + { FC_PORTSTATE_LINKDOWN, "Linkdown", 8 }, + { FC_PORTSTATE_ERROR, "Error", 5 }, + { FC_PORTSTATE_LOOPBACK, "Loopback", 8 }, + { FC_PORTSTATE_DELETED, "Deleted", 7 }, + { FC_PORTSTATE_MARGINAL, "Marginal", 8 }, }; fc_enum_name_search(port_state, fc_port_state, fc_port_state_names) +fc_enum_name_match(port_state, fc_port_state, fc_port_state_names) #define FC_PORTSTATE_MAX_NAMELEN 20 @@ -2074,6 +2077,7 @@ fc_eh_timed_out(struct scsi_cmnd *scmd) if (rport->port_state == FC_PORTSTATE_BLOCKED) return BLK_EH_RESET_TIMER; + fc_rport_chkmarginal_set_noretries(rport, scmd); return BLK_EH_DONE; } EXPORT_SYMBOL(fc_eh_timed_out); @@ -2095,7 +2099,8 @@ fc_user_scan_tgt(struct Scsi_Host *shost, uint channel, uint id, u64 lun) if (rport->scsi_target_id == -1) continue; - if (rport->port_state != FC_PORTSTATE_ONLINE) + if ((rport->port_state != FC_PORTSTATE_ONLINE) && + (rport->port_state != FC_PORTSTATE_MARGINAL)) continue; if ((channel == rport->channel) && @@ -2958,7 +2963,8 @@ fc_remote_port_delete(struct fc_rport *rport) spin_lock_irqsave(shost->host_lock, flags); - if (rport->port_state != FC_PORTSTATE_ONLINE) { + if ((rport->port_state != FC_PORTSTATE_ONLINE) && + (rport->port_state != FC_PORTSTATE_MARGINAL)) { spin_unlock_irqrestore(shost->host_lock, flags); return; } @@ -3100,7 +3106,8 @@ fc_timeout_deleted_rport(struct work_struct *work) * target, validate it still is. If not, tear down the * scsi_target on it. */ - if ((rport->port_state == FC_PORTSTATE_ONLINE) && + if (((rport->port_state == FC_PORTSTATE_ONLINE) || + (rport->port_state == FC_PORTSTATE_MARGINAL)) && (rport->scsi_target_id != -1) && !(rport->roles & FC_PORT_ROLE_FCP_TARGET)) { dev_printk(KERN_ERR, &rport->dev, @@ -3243,7 +3250,8 @@ fc_scsi_scan_rport(struct work_struct *work) struct fc_internal *i = to_fc_internal(shost->transportt); unsigned long flags; - if ((rport->port_state == FC_PORTSTATE_ONLINE) && + if (((rport->port_state == FC_PORTSTATE_ONLINE) || + (rport->port_state == FC_PORTSTATE_MARGINAL)) && (rport->roles & FC_PORT_ROLE_FCP_TARGET) && !(i->f->disable_target_scan)) { scsi_scan_target(&rport->dev, rport->channel, @@ -3308,11 +3316,20 @@ EXPORT_SYMBOL(fc_block_rport); int fc_block_scsi_eh(struct scsi_cmnd *cmnd) { struct fc_rport *rport = starget_to_rport(scsi_target(cmnd->device)); + int ret = 0; if (WARN_ON_ONCE(!rport)) return FAST_IO_FAIL; - return fc_block_rport(rport); + ret = fc_block_rport(rport); + /* + * Clear the SCMD_NORETRIES_ABORT bit if the Port state has + * changed from marginal to online due to + * fc_remote_port_delete and fc_remote_port_add + */ + if (rport->port_state != FC_PORTSTATE_MARGINAL) + clear_bit(SCMD_NORETRIES_ABORT, &cmnd->state); + return ret; } EXPORT_SYMBOL(fc_block_scsi_eh); @@ -3747,7 +3764,8 @@ static blk_status_t fc_bsg_rport_prep(struct fc_rport *rport) !(rport->flags & FC_RPORT_FAST_FAIL_TIMEDOUT)) return BLK_STS_RESOURCE; - if (rport->port_state != FC_PORTSTATE_ONLINE) + if ((rport->port_state != FC_PORTSTATE_ONLINE) && + (rport->port_state != FC_PORTSTATE_MARGINAL)) return BLK_STS_IOERR; return BLK_STS_OK; diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h index 1c7dd35cb7a0..829bade13b89 100644 --- a/include/scsi/scsi_transport_fc.h +++ b/include/scsi/scsi_transport_fc.h @@ -14,6 +14,7 @@ #include <linux/bsg-lib.h> #include <asm/unaligned.h> #include <scsi/scsi.h> +#include <scsi/scsi_cmnd.h> #include <scsi/scsi_netlink.h> #include <scsi/scsi_host.h> @@ -67,6 +68,7 @@ enum fc_port_state { FC_PORTSTATE_ERROR, FC_PORTSTATE_LOOPBACK, FC_PORTSTATE_DELETED, + FC_PORTSTATE_MARGINAL, }; @@ -707,6 +709,22 @@ struct fc_function_template { unsigned long disable_target_scan:1; }; +/** + * fc_rport_chkmarginal_set_noretries - Set the SCMD_NORETRIES_ABORT bit + * in cmd->state if port state is marginal + * @rport: remote port to be checked + * @scmd: scsi_cmd to set/clear the SCMD_NORETRIES_ABORT bit on Marginal state + **/ +static inline void +fc_rport_chkmarginal_set_noretries(struct fc_rport *rport, struct scsi_cmnd *cmd) +{ + if ((rport->port_state == FC_PORTSTATE_MARGINAL) && + (cmd->request->cmd_flags & REQ_FAILFAST_TRANSPORT)) + set_bit(SCMD_NORETRIES_ABORT, &cmd->state); + else + clear_bit(SCMD_NORETRIES_ABORT, &cmd->state); + +} /** * fc_remote_port_chkready - called to validate the remote port state @@ -723,6 +741,7 @@ fc_remote_port_chkready(struct fc_rport *rport) switch (rport->port_state) { case FC_PORTSTATE_ONLINE: + case FC_PORTSTATE_MARGINAL: if (rport->roles & FC_PORT_ROLE_FCP_TARGET) result = 0; else if (rport->flags & FC_RPORT_DEVLOSS_PENDING)
Added a new rport state FC_PORTSTATE_MARGINAL. Added a new inline function fc_rport_chkmarginal_set_noretries which will set the SCMD_NORETRIES_ABORT bit in cmd->state if rport state is marginal. Made changes in fc_eh_timed_out to call fc_rport_chkmarginal_set_noretries Also made changes in fc_remote_port_delete,fc_user_scan_tgt, fc_timeout_deleted_rport functions to handle the new rport state FC_PORTSTATE_MARGINAL. Made changes in fc_block_scsi_eh to clear the SCMD_NORETRIES_ABORT bit if the port_state is not marginal Signed-off-by: Muneendra <muneendra.kumar@broadcom.com> --- v6: No change v5: Made changes to clear the SCMD_NORETRIES_ABORT bit if the port_state has changed from marginal to online due to port_delete and port_add as we need the normal cmd retry behaviour Made changes in fc_scsi_scan_rport as we are checking FC_PORTSTATE_ONLINE instead of FC_PORTSTATE_ONLINE and FC_PORTSTATE_MARGINAL v4: Made changes in fc_eh_timed_out to call fc_rport_chkmarginal_set_noretries so that SCMD_NORETRIES_ABORT bit in cmd->state is set if rport state is marginal. Removed the newly added scsi_cmd argument to fc_remote_port_chkready as the current patch handles only SCSI EH timeout/abort case. v3: Rearranged the patch so that all the changes with respect to new rport state is part of this patch. Added a new argument to scsi_cmd to fc_remote_port_chkready v2: New patch --- drivers/scsi/scsi_transport_fc.c | 52 +++++++++++++++++++++----------- include/scsi/scsi_transport_fc.h | 19 ++++++++++++ 2 files changed, 54 insertions(+), 17 deletions(-)