All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: James.Smart@Emulex.Com
Cc: devel@open-fcoe.org, linux-scsi@vger.kernel.org
Subject: Re: [Open-FCoE] [PATCH 1/1] libfc: fix queue command rport checks
Date: Wed, 16 Jul 2008 14:51:51 -0500	[thread overview]
Message-ID: <487E5157.7050709@cs.wisc.edu> (raw)
In-Reply-To: <487E4FE3.8040904@cs.wisc.edu>

Mike Christie wrote:
> Mike Christie wrote:
>> James.Smart@Emulex.Com wrote:
>>>  
>>>
>>>> michaelc@cs.wisc.edu 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?
> 
> Or for the case where we are stopping a host (rmmod or single host stop 
> like with fcoe), should drivers call
> 
> 1. fc_remove_host()
>     This could be modified to cleanup shutdown targets then remove 
> rports. We could then have a rport shutdown callback which the class 
> could call and drivers could cleanup and shutdown the rport here before

I guess we have the terminate_rport_io callback already. So we could do:


fc_remove_host()
for each target
	scsi_remove_target();
for each rport
	fc_queue_work(shost, &rport->rport_delete_work);

.....


fc_rport_final_delete()
	i->f->terminate_rport_io

.......

then in the fcoe termniate_rport_io function we could stop the port?

  reply	other threads:[~2008-07-16 19:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-16 18:50 [PATCH 1/1] libfc: fix queue command rport checks michaelc-hcNo3dDEHLuVc3sceRu5cw
     [not found] ` <1216234249-10812-1-git-send-email-michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>
2008-07-16 18:56   ` Mike Christie
2008-07-16 19:08     ` James.Smart
     [not found]       ` <D1D4C3FF75F9354393DB8314DF43DEF2E7F01C-0GoafHKvaWWVoqRKY1PiFtBPR1lH4CV8@public.gmane.org>
2008-07-16 19:36         ` Mike Christie
2008-07-16 19:45           ` [Open-FCoE] " Mike Christie
2008-07-16 19:51             ` Mike Christie [this message]
2008-07-16 21:11               ` James.Smart-iH1Dq9VlAzfQT0dZR+AlfA
2008-07-16 21:22                 ` [Open-FCoE] " Mike Christie
2008-07-17 13:43                   ` James.Smart-iH1Dq9VlAzfQT0dZR+AlfA
2008-07-16 20:07             ` James.Smart-iH1Dq9VlAzfQT0dZR+AlfA
2008-07-16 20:49               ` [Open-FCoE] " Mike Christie
     [not found]                 ` <487E5ED6.9040302-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>
2008-07-16 20:55                   ` Mike Christie

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=487E5157.7050709@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=James.Smart@Emulex.Com \
    --cc=devel@open-fcoe.org \
    --cc=linux-scsi@vger.kernel.org \
    /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.