linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
	Bart Van Assche <bvanassche@acm.org>,
	Hannes Reinecke <hare@suse.de>, Ming Lei <ming.lei@redhat.com>,
	John Garry <john.garry@huawei.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>
Subject: [PATCH 03/21] Clear host_eh_scheduled from inside the SCSI error handler
Date: Thu,  1 Jul 2021 14:12:06 -0700	[thread overview]
Message-ID: <20210701211224.17070-4-bvanassche@acm.org> (raw)
In-Reply-To: <20210701211224.17070-1-bvanassche@acm.org>

The current protocol for scheduling the SCSI error handler explicitly
is as follows:
1. The LLD registers a transport layer that defines a eh_strategy_handler.
2. The LLD observes an error, sets variables that indicate the nature of the
   error and calls scsi_schedule_eh(). Currently only the ATA core and libsas
   use scsi_schedule_eh().
3. scsi_schedule_eh() increments host_eh_scheduled.
4. The SCSI error handling thread wakes up and invokes eh_strategy_handler.
5. After all errors have been handled and before the eh_strategy_handler
   implementation returns, host_eh_scheduled is cleared. This must be done
   in such a way that all errors that happened while the error handler was
   running are either handled or result in rerunning the error handler.

Making LLDs responsible for clearing host_eh_scheduled is error prone.
Hence clear host_eh_scheduled from inside the SCSI error handler. A side
effect of this patch is that if scsi_schedule_eh() is called while the
SCSI error handler is active that it will be reactivated immediately.

Cc: Hannes Reinecke <hare@suse.de>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: John Garry <john.garry@huawei.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/scsi/scsi_error.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c6cd5a8e5c85..665cc44d8877 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -2242,6 +2242,13 @@ int scsi_error_handler(void *data)
 			continue;
 		}
 
+		/*
+		 * Clear host_eh_scheduled before handling any errors such that
+		 * calling scsi_schedule_eh() while errors are being handled
+		 * causes the error handler to be rerun.
+		 */
+		shost->host_eh_scheduled = 0;
+
 		if (shost->transportt->eh_strategy_handler)
 			shost->transportt->eh_strategy_handler(shost);
 		else

  parent reply	other threads:[~2021-07-01 21:12 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01 21:12 [PATCH 00/21] UFS patches for kernel v5.15 Bart Van Assche
2021-07-01 21:12 ` [PATCH 01/21] Fix the documentation of the scsi_execute() time parameter Bart Van Assche
2021-07-05  5:51   ` Avri Altman
2021-07-01 21:12 ` [PATCH 02/21] libsas: Only abort commands from inside the error handler Bart Van Assche
2021-07-03  2:32   ` Jason Yan
2021-07-04 23:52     ` Bart Van Assche
2021-07-05  7:16     ` Hannes Reinecke
2021-07-01 21:12 ` Bart Van Assche [this message]
2021-07-01 21:12 ` [PATCH 04/21] libsas: Stop clearing host_eh_scheduled from " Bart Van Assche
2021-07-01 21:12 ` [PATCH 05/21] ata: Stop clearing host_eh_scheduled from error handlers Bart Van Assche
2021-07-01 21:12 ` [PATCH 06/21] ufs: Reduce power management code duplication Bart Van Assche
2021-07-05  6:18   ` Avri Altman
2021-07-01 21:12 ` [PATCH 07/21] ufs: Only include power management code if necessary Bart Van Assche
2021-07-05  6:33   ` Avri Altman
2021-07-07 20:44     ` Bart Van Assche
2021-07-08  5:50   ` Avri Altman
2021-07-01 21:12 ` [PATCH 08/21] ufs: Rename the second ufshcd_probe_hba() argument Bart Van Assche
2021-07-01 21:12 ` [PATCH 09/21] ufs: Use DECLARE_COMPLETION_ONSTACK() where appropriate Bart Van Assche
2021-07-05  6:38   ` Avri Altman
2021-07-01 21:12 ` [PATCH 10/21] ufs: Remove ufshcd_valid_tag() Bart Van Assche
2021-07-05  6:46   ` Avri Altman
2021-07-05 18:08     ` Bart Van Assche
2021-07-05 19:01       ` Avri Altman
2021-07-05 19:02   ` Avri Altman
2021-07-01 21:12 ` [PATCH 11/21] ufs: Verify UIC locking requirements at runtime Bart Van Assche
2021-07-05  6:52   ` Avri Altman
2021-07-01 21:12 ` [PATCH 12/21] ufs: Improve static type checking for the host controller state Bart Van Assche
2021-07-01 21:12 ` [PATCH 13/21] ufs: Remove several wmb() calls Bart Van Assche
2021-07-01 22:26   ` Asutosh Das (asd)
2021-07-01 22:52     ` Bart Van Assche
2021-07-01 21:12 ` [PATCH 14/21] ufs: Inline ufshcd_outstanding_req_clear() Bart Van Assche
2021-07-05  7:03   ` Avri Altman
2021-07-01 21:12 ` [PATCH 15/21] ufs: Rename __ufshcd_transfer_req_compl() Bart Van Assche
2021-07-01 21:12 ` [PATCH 16/21] ufs: Fix the SCSI abort handler Bart Van Assche
2021-07-01 21:12 ` [PATCH 17/21] ufs: Fix a race in the completion path Bart Van Assche
2021-07-01 21:12 ` [PATCH 18/21] ufs: Use the doorbell register instead of the UTRLCNR register Bart Van Assche
2021-07-01 21:12 ` [PATCH 19/21] ufs: Request sense data asynchronously Bart Van Assche
2021-07-01 21:12 ` [PATCH 20/21] ufs: Synchronize SCSI and UFS error handling Bart Van Assche
2021-07-01 21:12 ` [PATCH 21/21] ufs: Retry aborted SCSI commands instead of completing these successfully Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210701211224.17070-4-bvanassche@acm.org \
    --to=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=jaegeuk@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=john.garry@huawei.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).