On Mon, 2016-12-12 at 11:23 -0500, Ewan D. Milne wrote:
> ...I have not heard back yet
> from the site that reported this problem to me on their reproducer.
Not that it matters much now, but..
The response from my original reporter is that indeed the state was
being changed from SDEV_BLOCK -> SDE
Hi, James, Ewan,
On 2016/12/13 0:43, James Bottomley wrote:
> On Mon, 2016-12-12 at 11:23 -0500, Ewan D. Milne wrote:
>> On Mon, 2016-12-12 at 10:20 +0800, Wei Fang wrote:
>>> A race between scanning and fc_remote_port_delete() may result in a
>>> permanent stop if the device gets blocked before
>
On Mon, 2016-12-12 at 11:23 -0500, Ewan D. Milne wrote:
> On Mon, 2016-12-12 at 10:20 +0800, Wei Fang wrote:
> > A race between scanning and fc_remote_port_delete() may result in a
> > permanent stop if the device gets blocked before
> > scsi_sysfs_add_sdev()
> > and unblocked after. The reason is
On Mon, 2016-12-12 at 10:20 +0800, Wei Fang wrote:
> A race between scanning and fc_remote_port_delete() may result in a
> permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
> and unblocked after. The reason is that blocking a device sets both
> the SDEV_BLOCKED state and the Q
A race between scanning and fc_remote_port_delete() may result in a
permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
and unblocked after. The reason is that blocking a device sets both
the SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However,
scsi_sysfs_add_sdev() uncondit
5 matches
Mail list logo
