Regarding Issues with Memory Credential Cache
raeburn at MIT.EDU
Wed Aug 20 03:15:12 EDT 2008
On Aug 19, 2008, at 21:49, Ezra Peisach wrote:
> I will look at this. I have been playing with the ccache code
Thanks, Ezra. (And thanks for the memory leak fixes you've been doing.)
>> But, as mentioned in the ticket itself, this alone will not ensure
>> the safe access, as a thread can still free a Krb5_mcc_list_node
>> when another is still accessing it. And thus it requires some kind
>> of reference count mechanism which will ensure freeing up
>> Krb5_mcc_list_node happens only when refcount is zero (No one else
>> accessing it). This is already implemented in File Cache handling.
> Should be easy to implement.
I think we may have a general class of "shared linked list not
adequately protected when one thread deletes an element another is
using or iterating past" type issues in a few areas like re-
initialization, and combining iterators with simultaneous
modifications. I was starting to look into the memory ccache issue a
while back, and thinking about trying to implement a generic "ordered
collection of thing, with iterator support, reference counting and
locking" on top of which various collections (some needing to support
exported iterators that can maybe -- our specifications aren't very
specific -- be used interleaved with other operations like additions
and deletions, some not; some needing element ordering to be
preserved, some not; most needing some types of lookup functions)
could be built with a few macros or thin wrapper functions. But then
something came up, and something else came up, etc., and it's floated
down a ways in my queue for now.
> So - to be consistent, I would say that if you initialize a cache
> another thread is iterating through it - the other thread should be
> screwed - but
> should fail in a reliable way - without crashing the application.
I think that sounds right.
(And -- interesting point about the file caches. We remember the
position we were at but don't check that it's the same file. Perhaps
we should record device/inode/generation values and compare on
More information about the krbdev