From: Christoph Hellwig <hch@infradead.org>
To: Song Liu <songliubraving@fb.com>
Cc: linux-scsi@vger.kernel.org, hch@infradead.org,
Bart.VanAssche@sandisk.com
Subject: Re: [RFC] scsi: reduce protection of scan_mutex in scsi_remove_device
Date: Mon, 24 Apr 2017 08:28:48 -0700 [thread overview]
Message-ID: <20170424152848.GA21855@infradead.org> (raw)
In-Reply-To: <20170421211302.2667649-1-songliubraving@fb.com>
On Fri, Apr 21, 2017 at 02:13:02PM -0700, Song Liu wrote:
> When a device is deleted through sysfs handle "delete", the code
> locks shost->scan_mutex. If multiple devices are deleted at the
> same time, these deletes will be handled in series.
>
> On the other hand, some devices do long latency IO during deletion,
> for example, sd_shutdown() may do sync cache and/or start_stop.
> It is not necessary for these commands to run in series.
>
> To reduce latency of parallel "delete" requests, this patch reduces
> the protection of scan_mutex. The only function with Scsi_Host
> called in __scsi_remove_device() is the optional slave_destroy().
> Therefore, the protection of scan_mutex is only necessary for this
> function.
And I don't think it makes sense for slave_destroy either. Please
do a quick audit of the instances and drop the lock for it, too.
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 82dfe07..e7a9e28 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -610,7 +610,7 @@ static int scsi_sdev_check_buf_bit(const char *buf)
> return 1;
> else if (buf[0] == '0')
> return 0;
> - else
> + else
> return -EINVAL;
Also the patch has a few odd whitespace changes like this. Please
remove those before reposting.
next prev parent reply other threads:[~2017-04-24 15:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 21:13 [RFC] scsi: reduce protection of scan_mutex in scsi_remove_device Song Liu
2017-04-21 21:17 ` Bart Van Assche
2017-04-21 22:20 ` Song Liu
2017-04-21 21:20 ` Bart Van Assche
2017-04-21 22:31 ` Song Liu
2017-04-25 20:59 ` Bart Van Assche
2017-04-25 21:29 ` Song Liu
2017-04-24 15:28 ` Christoph Hellwig [this message]
2017-04-25 17:23 ` Bart Van Assche
2017-04-25 17:42 ` Song Liu
2017-04-25 17:52 ` Bart Van Assche
2017-04-25 21:17 ` Song Liu
2017-04-25 22:17 ` Bart Van Assche
2017-04-26 0:41 ` Song Liu
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=20170424152848.GA21855@infradead.org \
--to=hch@infradead.org \
--cc=Bart.VanAssche@sandisk.com \
--cc=linux-scsi@vger.kernel.org \
--cc=songliubraving@fb.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.