Regarding Issues with Memory Credential Cache

[Ken Raeburn]

On Aug 19, 2008, at 21:49, Ezra Peisach wrote:
> I will look at this.  I have been playing with the ccache code  
> recently...

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  
> while
> 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  
reopening.)

Ken