Re: Bug in kmem_cache_create with duplicate names

["Peter W. Morreale" <morreale@radiantdata.com>]

Steven Rostedt wrote:

>On Tue, 2004-12-07 at 11:15 -0500, Arjan van de Ven wrote:
>
>  
>
>>>However, I agree with you.  I don't see a good reason for it.
>>>      
>>>
>>I do...
>>because if the registration gives success..... then you unregister it
>>later during module unload and the INITIAL user goes bang.
>>It's a bad bug. Don't do it. Fix your code ;)
>>
>>    
>>
>
>Your module should fail to load if you can't register a cache. If you
>are a good boy and check your return codes from the kmem_cache_create,
>you would know that the cache failed and not load the module.
>Otherwise, if it failed for other reasons, then you can be causing bugs
>later when you go to use it. 
>

This would preclude the use of a dynamic cache, not all initializations 
are performed during module
insertion.    It also breaks since there is no relationship between the 
size of the objects in the cache
and the cache name (which is causing the BUG).  

This BUG specifically means that you (or somebody else) allocated 
something and did not free it.  

That is broken.  FYC (Fix Yer Code ;-) is the answer.

>
>Now this raises the issue of name space, this will bug if two modules
>use the same cache name. If this happens with two different vendors,
>than the poor user will have to figure out who to blame.
>

No different than any other global namespace issue.

-PWM

-- 
Peter W. Morreale                            email: morreale@radiantdata.com
Director of Engineering                      Niwot, Colorado, USA
Radiant Data Corporation                     voice: (303) 652-0870 x108 
-----------------------------------------------------------------------------
This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format. Thank you.