All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ewan D. Milne" <emilne@redhat.com>
To: James Bottomley <jejb@linux.vnet.ibm.com>
Cc: Bart Van Assche <bart.vanassche@sandisk.com>,
	Wei Fang <fangwei1@huawei.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] scsi: avoid a permanent stop of the scsi device's request queue
Date: Wed, 07 Dec 2016 15:30:48 -0500	[thread overview]
Message-ID: <1481142648.28416.244.camel@localhost.localdomain> (raw)
In-Reply-To: <1481141375.2354.53.camel@linux.vnet.ibm.com>

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.

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?

I have not verified the async vs. non-async scan path yet but it looks
like it would be OK.

-Ewan



  reply	other threads:[~2016-12-07 20:31 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 [this message]
2016-12-07 23:43                           ` James Bottomley
2016-12-08  2:28                             ` Wei Fang
2016-12-08  2:33                               ` James Bottomley
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=1481142648.28416.244.camel@localhost.localdomain \
    --to=emilne@redhat.com \
    --cc=bart.vanassche@sandisk.com \
    --cc=fangwei1@huawei.com \
    --cc=jejb@linux.vnet.ibm.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.