Hello all,
Having looked into this slab cache/module problem some more (I read the
comments that a slab cache should NOT be destroyed at all), it still
leaves the problem of how to get at the existing cache after a module is
unloaded and reloaded, if it doesn't keep any memory pointer in-kernel.
Having "static cache_p" in the module is no good if the module itself
is unloaded, and patching the kernel for this filesystem module just to
hold a static pointer is not desirable.
Since we are not allowed to destroy a slab cache (I'm working with 2.3.34,
but don't see any changes to this area in 35-38), we need to then
copy the slab name into the kmem_cache_struct rather than just
having a reference, or unloading the module will cause the OOPS below.
I'm looking at mm/slab.c:kmem_cache_create(), and it does a check if the
"name" of the slab cache already exists, but it doesn't appear to do anything
about it - the result of the search isn't even used, except to print out a
message. This should probably be done at the start of the function and
return the existing cache pointer of the same name.
Alternately, there could be a
kmem_cache_t *kmem_cache_find(char *name)
kind of function to return a pointer to an existing slab cache if it
already exists.
A patch to implement this will follow shortly...
Cheers, Andreas
I previously wrote:
> Hello, I'm writing a filesystem module (OBDFS - www.lustre.org) which is
> trying to use a slab cache. It allocates the cache at module initialization
> time using kmem_cache_create(), and tries to free it when the module is
> unloaded. I have tried both kmem_cache_destroy() and kmem_cache_shrink(),
> and both cause an OOPS when /proc/slabinfo is catted.
>
> Since the module has absolutely no in-kernel memory (it interfaces only with
> the VFS, and does not need a kernel patch), it is not possible for the
> slab cache to keep a static cache pointer to the cache (as is indicated by
> the comment before kmem_cache_shrink()). However, even kmem_cache_destroy()
> seems to have a problem with the cache list - I suspect that this is because
> even the "name" string for the cache is in the module memory space, and it
> is not available when the module is unloaded, hence the OOPS in sprintf.
>
> Jan 10 14:38:45 webber kernel: c01ced75
> Jan 10 14:38:45 webber kernel: Oops: 0000
> Jan 10 14:38:45 webber kernel: CPU: 1
> Jan 10 14:38:45 webber kernel: EIP: 0010:[vsprintf+425/844]
> Jan 10 14:38:45 webber kernel: EFLAGS: 00010297
> Jan 10 14:38:45 webber kernel: eax: c8840f06 ebx: ffffffff ecx: c8840f06 edx: fffffffe
> Jan 10 14:38:45 webber kernel: esi: c54d7038 edi: c5621f18 ebp: 00000011 esp: c5621ee4
> Jan 10 14:38:45 webber kernel: ds: 0018 es: 0018 ss: 0018
> Jan 10 14:38:45 webber kernel: Process cat (pid: 353, stackpage=c5621000)
> Jan 10 14:38:45 webber kernel: Stack: c1265c20 00000000 00000010 00000010 0000000a c01cef2c c54d7038 c01e14ea
> Jan 10 14:38:45 webber kernel: c5621f14 c0132b04 c54d7038 c01e14e6 c8840f 06 00000000 00000000 00000c00
> Jan 10 14:38:45 webber kernel: 00000000 c54d7000 c54d7000 c025ca00 c54d7038 00000038 00000286 00000000
> Jan 10 14:38:45 webber kernel: Call Trace: [sprintf+20/3812] [tvecs+8766/28276] [get_slabinfo+336/444] [tvecs+8762/28276] [<c8840f06>] [slabinfo_read_proc+21/72] [proc_file_read+284/532]
> Jan 10 14:38:45 webber kernel: [sys_read+269/308] [system_call+52/56]
> Jan 10 14:38:45 webber kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 8b 54 24 14 89 c3
>
> --
> 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:17 EST