From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "James.Bottomley@HansenPartnership.com"
<James.Bottomley@HansenPartnership.com>,
"bblock@linux.vnet.ibm.com" <bblock@linux.vnet.ibm.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"maxg@mellanox.com" <maxg@mellanox.com>,
"israelr@mellanox.com" <israelr@mellanox.com>,
"hare@suse.de" <hare@suse.de>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Subject: Re: [PATCH v3 3/4] sd: Make synchronize cache upon shutdown asynchronous
Date: Thu, 20 Apr 2017 21:59:11 +0000 [thread overview]
Message-ID: <1492725550.2642.9.camel@sandisk.com> (raw)
In-Reply-To: <1492559772.3306.58.camel@HansenPartnership.com>
On Tue, 2017-04-18 at 16:56 -0700, James Bottomley wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index e5a2d590a104..31171204cfd1 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -2611,7 +2611,6 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state)
> case SDEV_QUIESCE:
> case SDEV_OFFLINE:
> case SDEV_TRANSPORT_OFFLINE:
> - case SDEV_BLOCK:
> break;
> default:
> goto illegal;
> @@ -2625,6 +2624,7 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state)
> case SDEV_OFFLINE:
> case SDEV_TRANSPORT_OFFLINE:
> case SDEV_CANCEL:
> + case SDEV_BLOCK:
> case SDEV_CREATED_BLOCK:
> break;
> default:
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 82dfe07b1d47..e477f95bf169 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1282,8 +1282,17 @@ void __scsi_remove_device(struct scsi_device *sdev)
> return;
>
> if (sdev->is_visible) {
> - if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0)
> - return;
> + /*
> + * If blocked, we go straight to DEL so any commands
> + * issued during the driver shutdown (like sync cache)
> + * are errored
> + */
> + if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0) {
> + if (scsi_device_set_state(sdev, SDEV_DEL) != 0)
> + return;
> + else
> + scsi_start_queue(sdev);
> + }
>
> bsg_unregister_queue(sdev->request_queue);
> device_unregister(&sdev->sdev_dev);
Hello James,
This approach cannot work. A scsi_target_block() call by the transport
layer can happen concurrently with the __scsi_remove_device() call and hence
can occur at any time between the scsi_start_queue() call by
__scsi_remove_device() and the sd_shutdown() call, resulting in a deadlock.
I have been able to trigger this with my tests by simulating a cable pull
shortly before running "rmmod ib_srp".
That deadlock did not occur with the patch series that makes synchronize
cache upon shutdown asynchronous. I'm going to resubmit that patch series.
Bart.
next prev parent reply other threads:[~2017-04-20 21:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-17 17:34 [PATCH v3 0/4] Avoid that __scsi_remove_device() hangs Bart Van Assche
2017-04-17 17:34 ` [PATCH v3 1/4] Introduce scsi_start_queue() Bart Van Assche
2017-04-17 17:34 ` [PATCH v3 2/4] Introduce scsi_execute_async() Bart Van Assche
2017-04-17 17:34 ` [PATCH v3 3/4] sd: Make synchronize cache upon shutdown asynchronous Bart Van Assche
2017-04-18 14:44 ` Benjamin Block
2017-04-18 15:34 ` Bart Van Assche
2017-04-18 15:56 ` James Bottomley
2017-04-18 16:06 ` Bart Van Assche
2017-04-18 23:47 ` Bart Van Assche
2017-04-18 23:56 ` James Bottomley
2017-04-19 0:02 ` Bart Van Assche
2017-04-19 0:05 ` James Bottomley
2017-04-19 18:42 ` Bart Van Assche
2017-04-20 21:59 ` Bart Van Assche [this message]
2017-04-20 22:13 ` James Bottomley
2017-04-20 22:27 ` Bart Van Assche
2017-04-20 22:52 ` Bart Van Assche
2017-04-23 17:28 ` James Bottomley
2017-04-24 21:46 ` Bart Van Assche
2017-04-26 18:53 ` Bart Van Assche
2017-04-28 18:45 ` James Bottomley
2017-04-24 7:14 ` [lkp-robot] [sd] ab1218235c: INFO:possible_recursive_locking_detected kernel test robot
2017-04-24 7:14 ` kernel test robot
2017-04-17 17:34 ` [PATCH v3 4/4] Avoid that __scsi_remove_device() hangs Bart Van Assche
2017-04-18 11:58 ` [PATCH v3 0/4] " Israel Rukshin
2017-04-18 15:40 ` 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=1492725550.2642.9.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bblock@linux.vnet.ibm.com \
--cc=hare@suse.de \
--cc=israelr@mellanox.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=maxg@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.