>> Oh, that's too bad. Any idea what that does to connection rate? > > No idea. > > All IRPs against the EP need to be completed before WvEpFree returns, so > there may be other options to fix this. No fix that keeps the async > operation seems trivial though. (WorkQueueFlush seems hard, but I think > provides the most generic solution.)
A ref count on the WvProvider for any queued work items should prevent the provider from being freed (though it's ID/handle could get invalidated.) This would avoid having to implement something complicated to flush the work queue, and any delay in destroying the object because of the IRP being in the queue is unlikely to have much of an impact on the app - it's trying to destroy things, so performance shouldn't really be an issue. > WvEpCompleteDisconnect also queues IRPs to the work queue, and I *think* > may have an issue. It can leave an IRP outstanding after an application > crashes, which has the potential to touch the WvProvider structure after > it's been deleted. I say potential because I really can't tell if > that's the case or not. Shouldn't the IRP take a reference on the WvProvider, to prevent it from being freed (its ID can be freed, so that further IOCTLs will fail, but the object itself should be ref counted.) Freeing the WvProvider should block until all related IRPs have been completed. If you have that, the IRP can do a CM ID lookup based on the IRP parameters to ensure that it is still valid, and if not fail the IRP with the appropriate return value (probably canceled status.) I believe that's what I had done when I implemented the asynchronous EP::Modify functionality. > The race in both of these cases is fairly small, but I was able to hit > the case where an asynchronous WvEpAccept call touched the IbCmId after > it was freed. Sounds like a ref counting issue to me... -_Fab _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
