public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <jbottomley@parallels.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Mike Christie <michaelc@cs.wisc.edu>,
	Hannes Reinecke <hare@suse.de>, Chanho Min <chanho.min@lge.com>,
	Joe Lawrence <jdl1291@gmail.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	David Milburn <dmilburn@redhat.com>, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 3/4] Avoid re-enabling I/O after the transport became offline
Date: Tue, 2 Jul 2013 13:44:35 +0000	[thread overview]
Message-ID: <1372772674.2821.5.camel@dabdike> (raw)
In-Reply-To: <51D2D08D.4020301@acm.org>

On Tue, 2013-07-02 at 15:07 +0200, Bart Van Assche wrote:
> Disallow the SDEV_TRANSPORT_OFFLINE to SDEV_CANCEL transition such
> that no I/O is sent to devices for which the transport is offline.
> Notes:
> - Functions like sd_shutdown() use scsi_execute_req() and hence
>   set the REQ_PREEMPT flag. Such requests are passed to the LLD
>   queuecommand callback in the SDEV_CANCEL state.
> - This patch does not affect Fibre Channel LLD drivers since these
>   drivers invoke fc_remote_port_chkready() before submitting a SCSI
>   request to the HBA. That prevents a timeout to occur in state
>   SDEV_CANCEL if the transport is offline.
> 
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> Cc: Mike Christie <michaelc@cs.wisc.edu>
> Cc: James Bottomley <JBottomley@Parallels.com>
> Cc: Hannes Reinecke <hare@suse.de>
> Cc: Tejun Heo <tj@kernel.org>
> ---
>  drivers/scsi/scsi_lib.c   |    1 -
>  drivers/scsi/scsi_sysfs.c |    9 ++++++++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 124392f..a0fb56b 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -2178,7 +2178,6 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state)
>  		case SDEV_RUNNING:
>  		case SDEV_QUIESCE:
>  		case SDEV_OFFLINE:
> -		case SDEV_TRANSPORT_OFFLINE:
>  		case SDEV_BLOCK:
>  			break;
>  		default:
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 931a7d9..1711617 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -955,7 +955,14 @@ void __scsi_remove_device(struct scsi_device *sdev)
>  	struct device *dev = &sdev->sdev_gendev;
>  
>  	if (sdev->is_visible) {
> -		if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0)
> +		/*
> +		 * The transition from SDEV_TRANSPORT_OFFLINE into
> +		 * SDEV_CANCEL is not allowed since this transition would
> +		 * reenable I/O. However, if the device state was already
> +		 * SDEV_TRANSPORT_OFFLINE, proceed with device removal.
> +		 */
> +		if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0 &&
> +		    sdev->sdev_state != SDEV_TRANSPORT_OFFLINE)

This isn't the right way to do this, because it's adding uncharted state
to the state model.  What should happen is that this should be reflected
in the actual state model.  It sounds like we need a CANCEL_OFFLINE
state to which TRANSPORT_OFFLINE (and possibly OFFLINE) can transition.

The comment on the transition should state that CANCEL_OFFLINE won't
allow any I/O.

James


  reply	other threads:[~2013-07-02 13:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02 13:04 [PATCH v13 0/4] SCSI device removal fixes Bart Van Assche
2013-07-02 13:05 ` [PATCH 1/4] Fix race between starved list and device removal Bart Van Assche
2013-07-02 13:06 ` [PATCH 2/4] Avoid calling __scsi_remove_device() twice Bart Van Assche
2013-07-02 13:07 ` [PATCH 3/4] Avoid re-enabling I/O after the transport became offline Bart Van Assche
2013-07-02 13:44   ` James Bottomley [this message]
2013-07-02 13:08 ` [PATCH 4/4] Disallow changing the device state via sysfs into "deleted" 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=1372772674.2821.5.camel@dabdike \
    --to=jbottomley@parallels.com \
    --cc=bvanassche@acm.org \
    --cc=chanho.min@lge.com \
    --cc=dmilburn@redhat.com \
    --cc=hare@suse.de \
    --cc=jdl1291@gmail.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=tj@kernel.org \
    /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