Re: Bug in kmem_cache_create with duplicate names

From: Peter W. Morreale
Date: Tue Dec 07 2004 - 12:51:23 EST



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@xxxxxxxxxxxxxxx
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.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/