On 5 Mar 2010, at 18:57, Andrew Deason wrote:
We call afs_pag_destroy when the key goes away, but that only
invalidates the credentials; it doesn't remove it from the appropriate
afs_users chain. So, correct me if I'm wrong, but I think until we
afs_GCUserData, afs_users lists can grow very large.
afs_ComputePAGStats traverses the whole list, so that could explain it
taking so much time.
That's my theory - just waiting for the data to confirm it.
Could we remove the unixuser from the list in afs_PutUser if the
refCount drops to zero (possibly only under the same conditions as the
checks in afs_GCUserData)? I'm not sure I get the rationale for
having a
separate occasional GC for the linked list.
We need to be very careful what we do in afs_pag_destroy(), as we
don't have much control over the context in which it's called. In
theory, we shouldn't do anything that sleeps - our caller may hold a
spinlock. I'd be very wary of adding additional logic to that code,
unless we change the way that the user list is protected.
S.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
