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? _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
