>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.
Looking closer at the code, the provider should remain around until all IRPs complete - or at least that's my running theory. There is an issue that the provider's lookup tables could be accessed by the work item after they're freed. A reference on the provider would prevent this. To handle async Connect/Accept, changing the EP's state in WvEpFree should prevent accessing a freed IbCmId. The Connect and Accept handlers both lock around their use of the IbCmId with proper state checks. The Disconnect handler looks like it can be handled in a similar fashion. Disconnect is a little different in that it wants to access the QP handle. Since it appears that the disconnect handler still has an issue, I'm going to update this fix to get something that works with disconnect as well. - Sean _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
