From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Bart Van Assche <Bart.VanAssche@sandisk.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"israelr@mellanox.com" <israelr@mellanox.com>
Cc: "maxg@mellanox.com" <maxg@mellanox.com>
Subject: Re: [PATCH v2] scsi_sysfs: fix hang when removing scsi device
Date: Mon, 13 Mar 2017 12:23:06 -0700 [thread overview]
Message-ID: <1489432986.23810.12.camel@HansenPartnership.com> (raw)
In-Reply-To: <1489430936.2658.9.camel@sandisk.com>
On Mon, 2017-03-13 at 18:49 +0000, Bart Van Assche wrote:
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 7bfbcfa7af40..b3bb49d06943 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -602,7 +602,7 @@ EXPORT_SYMBOL(scsi_device_get);
> */
> void scsi_device_put(struct scsi_device *sdev)
> {
> - module_put(sdev->host->hostt->module);
> + module_put(sdev->hostt->module);
> put_device(&sdev->sdev_gendev);
> }
> EXPORT_SYMBOL(scsi_device_put);
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 6f7128f49c30..7134487abbb1 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -227,6 +227,7 @@ static struct scsi_device *scsi_alloc_sdev(struct
> scsi_target *starget,
> sdev->model = scsi_null_device_strs;
> sdev->rev = scsi_null_device_strs;
> sdev->host = shost;
> + sdev->hostt = shost->hostt;
> sdev->queue_ramp_up_period = SCSI_DEFAULT_RAMP_UP_PERIOD;
> sdev->id = starget->id;
> sdev->lun = lun;
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index 6f22b39f1b0c..cda620ed5922 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -82,6 +82,7 @@ struct scsi_event {
>
> struct scsi_device {
> struct Scsi_Host *host;
> + struct scsi_host_template *hostt;
> struct request_queue *request_queue;
>
The apparent assumption behind this patch is that sdev->host can be
freed but the sdev will still exist? That shouldn't be correct: the
rule for struct devices is that the child always holds the parent and
the host is parented (albeit not necessarily directly) to the sdev, so
it looks like something has gone wrong if the host had been freed
before the sdev.
James
next prev parent reply other threads:[~2017-03-13 19:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-09 16:37 [PATCH v2] scsi_sysfs: fix hang when removing scsi device Israel Rukshin
2017-03-09 19:36 ` Bart Van Assche
2017-03-12 10:26 ` Israel Rukshin
2017-03-13 18:49 ` Bart Van Assche
2017-03-13 19:23 ` James Bottomley [this message]
2017-03-13 20:33 ` Bart Van Assche
2017-03-13 21:55 ` James Bottomley
2017-03-14 2:35 ` Bart Van Assche
2017-03-14 9:44 ` Israel Rukshin
2017-03-14 14:23 ` Israel Rukshin
2017-03-15 23:27 ` Bart Van Assche
2017-03-16 9:02 ` Israel Rukshin
2017-03-16 15:42 ` Bart Van Assche
2017-03-16 15:59 ` Israel Rukshin
2017-03-16 23:00 ` Bart Van Assche
2017-03-18 0:05 ` Bart Van Assche
2017-03-18 11:17 ` Hannes Reinecke
2017-03-18 15:28 ` 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=1489432986.23810.12.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=Bart.VanAssche@sandisk.com \
--cc=israelr@mellanox.com \
--cc=linux-scsi@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox