Tigran writes:
> 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 did some further testing on this, and it appears that kmem_cache_destroy()
actually works (although nobody uses it anywhere yet). I will use this in
my module now.
The problem that arises is when __kmem_cache_shrink() doesn't free all of
the slabs for a cache, so the cache isn't destroyed. This leaves a dangling
pointer for name in the kernel cache_cache chain when the module is unloaded,
allowing any user to make the kernel unstable and crash by catting
/proc/slabinfo (granted that a module has to have a loose pointer somewhere
in order to generate this problem).
I think the patch I sent earlier to move the name into the kmem_cache_s
will fix this problem, and kmem_cache_destroy() will work. However, it
still means that all modules should call kmem_cache_destroy() at exit, and
the comment above kmem_cache_shrink() should be removed. At least we
won't have the OOPS problem, only memory leakage at the moment.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
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:18 EST