uma for acpi object cache

[Andriy Gapon]

on 25/01/2013 10:38 Andriy Gapon said the following:
> on 24/01/2013 22:33 Jung-uk Kim said the following:
>> On 2013-01-24 13:49:07 -0500, Andriy Gapon wrote:
>>> on 24/01/2013 20:29 Jung-uk Kim said the following:
>>>> When utcache.c works, it works fairly well, actually. :-)
>>
>>> Well, my primary motivation for the patch is all the reports about
>>> mysterious panics that seem to involve the cache: 
>>> http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7562 
>>> http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7613 
>>> http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7077
>>
>>> There were a few more reports with the same theme. I hoped that
>>> using uma(9) instead of hand-rolled code would lead to better 
>>> diagnostic and debugging cabilities.
>>
>> Hmm...  I am not really sure local cache is to blame here.  If you
>> really want to prove your theory, I think a simple modification to
>> utcache.c should do:
>>
>>      Cache->LinkOffset = 8;
>>      Cache->ListName   = CacheName;
>>      Cache->ObjectSize = ObjectSize;
>> -    Cache->MaxDepth   = MaxDepth;
>> +    Cache->MaxDepth   = 0;
>>
>>      *ReturnCache = Cache;
>>      return (AE_OK);
>>
>> This should effectively kill object caching.
> 
> That's a very simple trick, I wonder why I didn't think about it :-)
> Now I need to wait until one of the reporters resurfaces.
> 

And just to clarify - I didn't and don't suspect the cache code itself.
I suspect some code that uses the cache (directly or indirectly) - something
like double-free or use-after-free, etc.

-- 
Andriy Gapon