From: James Bottomley <jejb@linux.vnet.ibm.com>
To: Wei Fang <fangwei1@huawei.com>, emilne@redhat.com
Cc: Bart Van Assche <bart.vanassche@sandisk.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
chenzengxi@huawei.com
Subject: Re: [PATCH] scsi: avoid a permanent stop of the scsi device's request queue
Date: Wed, 07 Dec 2016 18:33:01 -0800 [thread overview]
Message-ID: <1481164381.2354.81.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <5848C535.5010408@huawei.com>
On Thu, 2016-12-08 at 10:28 +0800, Wei Fang wrote:
> Hi, James, Ewan,
>
> On 2016/12/8 7:43, James Bottomley wrote:
> > On Wed, 2016-12-07 at 15:30 -0500, Ewan D. Milne wrote:
> > > On Wed, 2016-12-07 at 12:09 -0800, James Bottomley wrote:
> > > > Hm, it looks like the state set in scsi_sysfs_add_sdev() is
> > > > bogus.
> > > > We expect the state to have been properly set before that (in
> > > > scsi_add_lun), so can we not simply remove it?
> > > >
> > > > James
> > > >
> > >
> > > I was considering that, but...
> > >
> > > enum scsi_device_state {
> > > SDEV_CREATED = 1, /* device created but not added
> > > to
> > > sysfs
> > >
> > >
> > >
> > >
> > > * Only internal commands allowed
> > > (for inq) */
> > >
> > > So it seems the intent was for the state to not change until
> > > then.
> >
> > I think this is historical. There was a change somewhere that
> > moved
> > the sysfs state handling out of the sdev stat to is_visible, so the
> > sdev state no-longer reflects it.
> >
> > > The call to set the SDEV_RUNNING state earlier in scsi_add_lun()
> > > was added with:
> > >
> > > commit 6f4267e3bd1211b3d09130e626b0b3d885077610
> > > Author: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > Date: Fri Aug 22 16:53:31 2008 -0500
> > >
> > > [SCSI] Update the SCSI state model to allow blocking in the
> > > created state
> > >
> > > Which allows the device to go into ->BLOCK (which is needed,
> > > since it
> > > actually happens).
> > >
> > > Should we remove the call from scsi_sysfs_add_sdev() and change
> > > the
> > > comment in scsi_device.h to reflect the intent?
>
> This sounds reasonable.
>
> > Assuming someone with the problem actually tests it, yes.
>
> This problem can be stably reproduced on Zengxi Chen's machine, who
> reported the bug. We can test it on this machine.
>
> The patch is as below, just for sure:
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 0734927..82dfe07 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1204,10 +1204,6 @@ int scsi_sysfs_add_sdev(struct scsi_device
> *sdev)
> struct request_queue *rq = sdev->request_queue;
> struct scsi_target *starget = sdev->sdev_target;
>
> - error = scsi_device_set_state(sdev, SDEV_RUNNING);
> - if (error)
> - return error;
> -
That's it, although not the second hunk: CREATED still means device not
added to sysfs. It's just that RUNNING now doesn't mean it is.
James
next prev parent reply other threads:[~2016-12-08 2:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-06 9:12 [PATCH] scsi: avoid a permanent stop of the scsi device's request queue Wei Fang
2016-12-06 15:51 ` Bart Van Assche
2016-12-07 1:20 ` Wei Fang
2016-12-07 2:45 ` Bart Van Assche
2016-12-07 3:41 ` Wei Fang
2016-12-07 4:40 ` Bart Van Assche
2016-12-07 6:59 ` Wei Fang
2016-12-07 16:48 ` Bart Van Assche
2016-12-07 16:55 ` Bart Van Assche
2016-12-07 17:40 ` Ewan D. Milne
2016-12-07 18:16 ` James Bottomley
2016-12-07 19:24 ` Ewan D. Milne
2016-12-07 20:09 ` James Bottomley
2016-12-07 20:30 ` Ewan D. Milne
2016-12-07 23:43 ` James Bottomley
2016-12-08 2:28 ` Wei Fang
2016-12-08 2:33 ` James Bottomley [this message]
2016-12-08 3:22 ` Wei Fang
2016-12-08 6:38 ` Wei Fang
2016-12-08 14:04 ` Ewan D. Milne
2016-12-08 15:39 ` James Bottomley
2016-12-09 1:08 ` Wei Fang
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=1481164381.2354.81.camel@linux.vnet.ibm.com \
--to=jejb@linux.vnet.ibm.com \
--cc=bart.vanassche@sandisk.com \
--cc=chenzengxi@huawei.com \
--cc=emilne@redhat.com \
--cc=fangwei1@huawei.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.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.