Mike Christie wrote:
> Dev, Vasu wrote:
>>> -----Original Message-----
>>> From: Mike Christie [mailto:[EMAIL PROTECTED]
>>> Sent: Tuesday, August 12, 2008 12:45 PM
>>> To: Dev, Vasu
>>> Cc: [email protected]
>>> Subject: Re: [Open-FCoE] [RFC PATCH 1/2] libfc: removed checks for
>>> timer_pending and then updating exch ref count.
>>>
>>> Dev, Vasu wrote:
>>>>>> exch_done would then need to be modified so that instead of
>>>>>> fc_exch_release doing
>>>>>>
>>>>>>                  spin_lock_bh(&mp->em_lock);
>>>>>>                  WARN_ON(mp->total_exches <= 0);
>>>>>>                  mp->total_exches--;
>>>>>>                  mp->exches[ep->xid - mp->min_xid] = NULL;
>>>>>>                  list_del(&ep->ex_list);
>>>>>>                  spin_unlock_bh(&mp->em_lock);
>>>>>>
>>>>>> exch_done would do that, then release its hold. And actually exch_done
>>>>>> would need to check that if there were multiple ep->resp functions (one
>>>>>> from fc_fcp_send_cmd and one from the abort)
>>>>>> then we do not do the mp
>>>>>> manipulation above until the exch_done has been called for the last
>>>>>> ep->resp.
>>>>>>
>>>> I don't understand calling exch_done() twice from upper layer of
>>> fc_exch.c
>>>> and checking for multiple ep->resp functions to fix above described issue
>>> Do you mean you do not understand how moving the clearing of the mp
>>> exches ref removes the need for the hack to add the extra check refcount
>>> check in the original patch?
>> I thought you were talking about issue of fcp exch abort and extra exch done
>> issue and so called hack is different thing. The hack is for receiving any
>> frame when we are about free exch, that can be from jammer or mal formed
>> corrupt frame. So I think two issues are mixed here.
> 
> My suggestion for moving the mp clearing is for the same thing you 
> describe above. It is to prevent the race where one process is trying to 
> do a hold while the other is trying to do the final release.
> 
> With your patch, if there was a valid exchange that we are trying to 
> free and we get invalid frames then your patch will allow the invalid 
> frame to get a hold on the ep instead of accessing freed memory. Or if 
> it gets the lock after the release function has cleared ep from the mp 
> array then we drop it.

I mean we can drop it.
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel

Reply via email to