* [PATCH] libfc: fix error handling in fc_exch_rrq_resp()
@ 2010-10-22 15:21 Hillf Danton
[not found] ` <AANLkTik3GbuiEGVPigGZp+=RH7qRMarn0cdZJ49Toso7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Hillf Danton @ 2010-10-22 15:21 UTC (permalink / raw)
To: devel; +Cc: linux-scsi
There seems no cleanup left when FC_EX_CLOSED encountered, which may
be from fc_exch_reset().
Signed-off-by: Hillf Danton <dhillf@gmail.com>
---
--- a/drivers/scsi/libfc/fc_exch.c 2010-09-13 07:07:38.000000000 +0800
+++ b/drivers/scsi/libfc/fc_exch.c 2010-10-22 23:17:50.000000000 +0800
@@ -1827,7 +1827,9 @@ static void fc_exch_rrq_resp(struct fc_s
if (IS_ERR(fp)) {
int err = PTR_ERR(fp);
- if (err == -FC_EX_CLOSED || err == -FC_EX_TIMEOUT)
+ if (err == -FC_EX_CLOSED)
+ return;
+ if (err == -FC_EX_TIMEOUT)
goto cleanup;
FC_EXCH_DBG(aborted_ep, "Cannot process RRQ, "
"frame error %d\n", err);
^ permalink raw reply [flat|nested] 4+ messages in thread[parent not found: <AANLkTik3GbuiEGVPigGZp+=RH7qRMarn0cdZJ49Toso7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] libfc: fix error handling in fc_exch_rrq_resp() [not found] ` <AANLkTik3GbuiEGVPigGZp+=RH7qRMarn0cdZJ49Toso7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-10-22 18:57 ` Joe Eykholt 2010-10-23 7:56 ` [Open-FCoE] " Hillf Danton 0 siblings, 1 reply; 4+ messages in thread From: Joe Eykholt @ 2010-10-22 18:57 UTC (permalink / raw) To: Hillf Danton Cc: devel-s9riP+hp16TNLxjTenLetw, linux-scsi-u79uwXL29TY76Z2rM5mHXA On 10/22/10 8:21 AM, Hillf Danton wrote: > There seems no cleanup left when FC_EX_CLOSED encountered, which may > be from fc_exch_reset(). Are you sure? It seems that the RRQ exchange has a hold on another exchange, the one that's the subject of the RRQ. That exchange still needs to be released. I could be wrong, it's been a while. > Signed-off-by: Hillf Danton <dhillf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > --- > > --- a/drivers/scsi/libfc/fc_exch.c 2010-09-13 07:07:38.000000000 +0800 > +++ b/drivers/scsi/libfc/fc_exch.c 2010-10-22 23:17:50.000000000 +0800 > @@ -1827,7 +1827,9 @@ static void fc_exch_rrq_resp(struct fc_s > if (IS_ERR(fp)) { > int err = PTR_ERR(fp); > > - if (err == -FC_EX_CLOSED || err == -FC_EX_TIMEOUT) > + if (err == -FC_EX_CLOSED) > + return; > + if (err == -FC_EX_TIMEOUT) > goto cleanup; > FC_EXCH_DBG(aborted_ep, "Cannot process RRQ, " > "frame error %d\n", err); > _______________________________________________ > devel mailing list > devel-s9riP+hp16TNLxjTenLetw@public.gmane.org > http://www.open-fcoe.org/mailman/listinfo/devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Open-FCoE] [PATCH] libfc: fix error handling in fc_exch_rrq_resp() 2010-10-22 18:57 ` Joe Eykholt @ 2010-10-23 7:56 ` Hillf Danton [not found] ` <4CC521C7.4010001@cisco.com> 0 siblings, 1 reply; 4+ messages in thread From: Hillf Danton @ 2010-10-23 7:56 UTC (permalink / raw) To: Joe Eykholt; +Cc: devel, linux-scsi On Sat, Oct 23, 2010 at 2:57 AM, Joe Eykholt <jeykholt@cisco.com> wrote: > > > On 10/22/10 8:21 AM, Hillf Danton wrote: >> There seems no cleanup left when FC_EX_CLOSED encountered, which may >> be from fc_exch_reset(). > > Are you sure? It seems that the RRQ exchange has a hold on another > exchange, the one that's the subject of the RRQ. That exchange In case of fc_exch_pool_reset(), each exch on ex_list is delivered to fc_exch_reset(), so "another" and "that" exch are treated in same way. After cleanup, then the resp handler, if attached, is issued with FC_EX_CLOSED, so no more work left for the resp handler. If still needed, overwork occurs before calling resp handler. > still needs to be released. I could be wrong, it's been a while. > >> Signed-off-by: Hillf Danton <dhillf@gmail.com> >> --- >> >> --- a/drivers/scsi/libfc/fc_exch.c 2010-09-13 07:07:38.000000000 +0800 >> +++ b/drivers/scsi/libfc/fc_exch.c 2010-10-22 23:17:50.000000000 +0800 >> @@ -1827,7 +1827,9 @@ static void fc_exch_rrq_resp(struct fc_s >> if (IS_ERR(fp)) { >> int err = PTR_ERR(fp); >> >> - if (err == -FC_EX_CLOSED || err == -FC_EX_TIMEOUT) >> + if (err == -FC_EX_CLOSED) >> + return; >> + if (err == -FC_EX_TIMEOUT) >> goto cleanup; >> FC_EXCH_DBG(aborted_ep, "Cannot process RRQ, " >> "frame error %d\n", err); >> _______________________________________________ >> devel mailing list >> devel@open-fcoe.org >> http://www.open-fcoe.org/mailman/listinfo/devel > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <4CC521C7.4010001@cisco.com>]
* Re: [Open-FCoE] [PATCH] libfc: fix error handling in fc_exch_rrq_resp() [not found] ` <4CC521C7.4010001@cisco.com> @ 2010-10-25 13:16 ` Hillf Danton 0 siblings, 0 replies; 4+ messages in thread From: Hillf Danton @ 2010-10-25 13:16 UTC (permalink / raw) To: Joe Eykholt; +Cc: devel, linux-scsi On Mon, Oct 25, 2010 at 2:20 PM, Joe Eykholt <jeykholt@cisco.com> wrote: > <dropped scsi alias> > > On 10/23/10 12:56 AM, Hillf Danton wrote: >> >> On Sat, Oct 23, 2010 at 2:57 AM, Joe Eykholt<jeykholt@cisco.com> wrote: >>> >>> >>> On 10/22/10 8:21 AM, Hillf Danton wrote: >>>> >>>> There seems no cleanup left when FC_EX_CLOSED encountered, which may >>>> be from fc_exch_reset(). >>> >>> Are you sure? It seems that the RRQ exchange has a hold on another >>> exchange, the one that's the subject of the RRQ. That exchange >> >> In case of fc_exch_pool_reset(), each exch on ex_list is delivered to >> fc_exch_reset(), so "another" and "that" exch are treated in same way. > > True, but nothing else is going to release the other exchange. Here is snippet from fc_exch_reset(), if (ep->esb_stat & ESB_ST_REC_QUAL) atomic_dec(&ep->ex_refcnt); /* drop hold for rec_qual */ ep->esb_stat &= ~ESB_ST_REC_QUAL; the hold does get dropped, based upon which it looks the cleanup in fc_exch_reset() gets no more work left for response-handler. > >> After cleanup, then the resp handler, if attached, is issued with >> FC_EX_CLOSED, >> so no more work left for the resp handler. >> >> If still needed, overwork occurs before calling resp handler. > > This happens so infrequently that the amount of extra work, if any, > is not significant. > >>> still needs to be released. I could be wrong, it's been a while. >>> >>>> Signed-off-by: Hillf Danton<dhillf@gmail.com> >>>> --- >>>> >>>> --- a/drivers/scsi/libfc/fc_exch.c 2010-09-13 07:07:38.000000000 >>>> +0800 >>>> +++ b/drivers/scsi/libfc/fc_exch.c 2010-10-22 23:17:50.000000000 >>>> +0800 >>>> @@ -1827,7 +1827,9 @@ static void fc_exch_rrq_resp(struct fc_s >>>> if (IS_ERR(fp)) { >>>> int err = PTR_ERR(fp); >>>> >>>> - if (err == -FC_EX_CLOSED || err == -FC_EX_TIMEOUT) >>>> + if (err == -FC_EX_CLOSED) >>>> + return; >>>> + if (err == -FC_EX_TIMEOUT) >>>> goto cleanup; >>>> FC_EXCH_DBG(aborted_ep, "Cannot process RRQ, " >>>> "frame error %d\n", err); >>>> _______________________________________________ >>>> devel mailing list >>>> devel@open-fcoe.org >>>> http://www.open-fcoe.org/mailman/listinfo/devel >>> > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-10-25 13:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-22 15:21 [PATCH] libfc: fix error handling in fc_exch_rrq_resp() Hillf Danton
[not found] ` <AANLkTik3GbuiEGVPigGZp+=RH7qRMarn0cdZJ49Toso7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-10-22 18:57 ` Joe Eykholt
2010-10-23 7:56 ` [Open-FCoE] " Hillf Danton
[not found] ` <4CC521C7.4010001@cisco.com>
2010-10-25 13:16 ` Hillf Danton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).