Re: [PATCH 1/1] libfc: fix queue command rport checks

[Mike Christie <michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>]

James.Smart-iH1Dq9VlAzfQT0dZR+AlfA@public.gmane.org wrote:
>  
> 
>> michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org wrote:
>> Oh yeah, I ccd linux-scsi for this patch and not others, 
>> because JamesS 
>> and them are not on fcoe devel list, and it seems like all fc drivers 
>> fail the sync cache command.
>>
>> What happens is that we remove the rport which sets the rport state, 
>> then the fc class removes the target. This causes the target and its 
>> devices to be removed, which can cause a sync cache to be sent. But 
>> because the the rport is not in the online state it will fail 
>> the command.
> 
> Well, excepting detachment paths, if we're tearing the rport down, it's
> because
> we've already lost connectivity to the target, so there's no way a sync
> cache would ever succeed. It's a suprise-removal scenario.
> 

Yeah, I am only talking about the paths where we want a clean shutdown 
like if for fcoe we did echo ethX > /sys/module/fcoe/destroy. For normal 
fc do we want to be able to remove rpots too? Did you guys do that with 
the ioctl modules before? Then there is the module removal case. I think 
for module removal we want a clean shutdown too, but I am not sure if 
other people feel that for module removal there are gaurantees like that.

So during a clean shutdown are drivers supposed to remove the targets by 
calling scsi_remove_target to remove the devices, then remove the rports 
through the class?