[Open-FCoE] [RFC PATCH 00/16] rport state machine and locking

Mike Christie michaelc at cs.wisc.edu
Wed Sep 10 15:03:39 UTC 2008


Robert Love wrote:
> On Tue, 2008-09-09 at 10:22 -0700, Robert Love wrote:
>> The following series implements a change to the rport state machine and
>> applies a locking strategy to that state machine.
>>
>> 1) A callback function is added to the LP for RP events (READY, FAILED, LOGO)
>> 2) GNN_ID and GPN_ID are removed, rport state machine starts at PLOGI
>>    - uses a dummy rport until PLOGI response
>> 3) A READY state is added to the RP state machine
>> 4) The RP state machine locking has been given a locking strategy
>> 5) RP only has one error/retry handling routine
>> 6) Naming conventions are changed
>>     rport (remote port) = fc_rport pointer
>>     rdata (remote port private) = fc_rport_libfc_priv pointer
>>
>> I think these patches still need a little cleaning up, but they're mostly good.
>> I'm curious what everyone thinks about the folowing changes to:
>>
>> a) the locking policy
>> b) the event callback mechanism
>> c) the consolidation of fc_rport_error and fc_rport_retry.
>>
>> All comments are welcome. If there are no major issues I'll do a little cleanup,
>> drop the RFC, resubmit and then commit.
> 
> I have three problems with this patch-set right now.
> 
> 1. Need to delete dummy rports when there is a timeout scenario since
> they're not tracked by the FC transport class.
> 
> 2. Should delay the retry a bit if there is a resource allocation error.
> 
> 3. Can't hold locks while calling some functions.
> 
> It's this last one that's going to be difficult. My problem is that I
> want to call fc_remote_port_add/delete while I'm holding the rport lock.
> Those functions expect to be called without a lock held. Also, I haven't
> finished the lport locking, but I expect that the event_callback
> function will want to lock the lport so that it can change the lport's
> state.
> 
> In all of these cases I want to call a function while I'm holding the
> rport lock and those functions expect to be called without the lock
> held. Right now my patches drop the lock momentarily before calling one
> of these functions and then re-grab the lock when the function returns.
> This is not ideal. If I keep it this way I'd need to re-check the state
> once I re-grab the lock and it'll get ugly.
> 

For the fc class rport issues the problem is that those functions can 
use GFP_KERNEL or flush a work queue? Do we have to use spin locks for 
the rport and lrport locking? Why not use a mutex or semaphore, since we 
have process context and it is not performance critical?



More information about the devel mailing list