You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
svc_xprt_lookup() looks up in hash table, places a ref and passes to the
caller. The xprt gets an additional initial refcount for being in the
hash table itself. The caller will do SVC_RELEASE() once he is done with
the xprt. SVC_DESTROY() gets called when the xprt gets an error which
will eventually make the additional hash refcount go away, finally
leading to zero refcount. The xprt is deleted only at the very end,
before destroying. Once an SVC_DESTROY() is called, the refcount could
go to zero, xprt gets deleted from hash table, then it gets destroyed.
svc_xprt_lookup() can fairly assume that xprt memory won't be freed as
long as it is in the hash table and it holds the hash lock. It should
NOT access the xprt after releasing the hash lock if the refcount was
bumped from zero. In such a case, we bailout and return failure.
TODO: If we can delete the xprt from the hash table (RBT) as part of
SVC_DESTROY() before decrementing the refcount, we will never have zero
refcount xprt in the hash table, and this special code can be avoided.
0 commit comments