Hi,
You said that you get an oops because of dereferencing cache name via
/proc/slabinfo even though you destroy the cache with
kmem_cache_destroy()?
First of all, as far as I remember, Mark Hemment (author of slab) put the
comment about not destroying the cache *before* Andrea Arcangeli added the
destroy functioniality so your observation about it doesn't indicate that
there should be a problem with kmem_cache_destroy()
I think your idea of writing a kmem_cache_find_byname() is not a very good
one, but unrelated to this problem. (why is it not good? because slab
allows to allocate multiple caches under the same name, although it prints
a warning about it).
I think the problem here is not that destroy does not work (it does work!)
but that you probably tried to destroy the cache with some objects still
allocated from it. So, kmem_cache_destroy() tried to __kmem_cache_shrink()
it but it couldn't, so, if you had checked the return from
kmem_cache_destroy() you would probably have found that the above is the
case.
I cc'd Mark so he can correct me if I am totally wrong.
Regards,
------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:17 EST