On Mon, 2008-08-18 at 09:06 -0500, Brian King wrote: > James Bottomley wrote: > > What this seems to be exposing is a bug in the state model around the > > blocked state. > > > > The transition: > > > > CREATED -> BLOCK -> RUNNING > > > > shouldn't be legal. My initial reaction is just to forbid the CREATED > > -> BLOCK transition, but it looks like the fc transport code never > > checks return values from scsi_target_block() (sigh!) > > > > So an alternate fix should be to correct the state model rather than try > > and work around the deficiencies with additional flags. > > > > It looks like, to allow the CREATED -> BLOCK -> CREATED transition we > > need an extra state (CREATED_BLOCK) and we forbid the CREATED -> BLOCK > > in favour of it. > > > > The model also now allows an online transition to do CREATED_BLOCK -> > > BLOCK > > > > This is a rough code of that, does it work for you? > > I loaded up your patch and this fixes my issue as well. Do we need to also > add a check for SDEV_CREATED_BLOCK in scsi_dispatch_cmd? Yes ... everywhere we previously checked for SDEV_BLOCK ... really, that check now needs to be made into an inline function. I'll reroll the patch properly with that included. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
