With 2.6.17-rc3 I'm running into something which seems as a bug related to kmem_cache. Doing some allocations/deallocations from a kmem_cache and later attempting to destroy it yields the following message and trace ============================================================================ slab error in kmem_cache_destroy(): cache `my_cache': Can't free all objects Call Trace: <ffffffff8106e46b>{kmem_cache_destroy+150} <ffffffff88204033>{:my_kcache:kcache_cleanup_module+51} <ffffffff81044cd3>{sys_delete_module+415} <ffffffff8112fb5b>{__up_write+20} <ffffffff8105d42b>{sys_munmap+91} <ffffffff8100966a>{system_call+126} Failed to destroy cache ============================================================================ I was hitting it as an Infiniband/iSCSI user as IB/iSCSI/SCSI code use kmem_caches, but since the failure happens on a code which works fine on 2.6.16 i have decided to try it with a synthetic module and had this hit... Below is a sample code that reproduces it, if i only do kmem_cache_create and later destroy it does not happen, attached is my .config please note that some of the CONFIG_DEBUG_ options are open. Please CC [email protected] at least with the resolution of the matter since it kind of hard to do testing over 2.6.17-rcX with this issue, the tests run fine but some modules are crashing on rmmod so a reboot it needed... thanks, Or. This is the related slab info line once the module is loaded my_cache 256 264 328 12 1 : tunables 32 16 8 : slabdata 22 22 0 : globalstat 264 264 22 0 --- /deb/null 1970-01-01 02:00:00.000000000 +0200 +++ kcache/kcache.c 2006-04-27 10:43:18.000000000 +0300 @@ -0,0 +1,61 @@ +#include <linux/module.h> +#include <linux/slab.h> + +kmem_cache_t *cache; + +struct foo { + char bar[300]; +}; + + +#define TRIES 256 + +struct foo *foo_arr[TRIES]; + +static int __init kcache_init_module(void) +{ + int i, j; + + cache = kmem_cache_create("my_cache", + sizeof (struct foo), + 0, + SLAB_HWCACHE_ALIGN, + NULL, + NULL); + if (!cache) { + printk(KERN_ERR "couldn't create cache\n"); + goto error1; + } + + for (i = 0; i < TRIES; i++) { + foo_arr[i] = kmem_cache_alloc(cache, GFP_KERNEL); + if (foo_arr[i] == NULL) { + printk(KERN_ERR "couldn't allocate from cache\n"); + goto error2; + } + } + + return 0; +error2: + for (j = 0; j < i; j++) + kmem_cache_free(cache, foo_arr[j]); +error1: + return -ENOMEM; +} + +static void __exit kcache_cleanup_module(void) +{ + int i; + + for (i = 0; i < TRIES; i++) + kmem_cache_free(cache, foo_arr[i]); + + if (kmem_cache_destroy(cache)) { + printk(KERN_DEBUG "Failed to destroy cache\n"); + } +} + +MODULE_LICENSE("GPL"); + +module_init(kcache_init_module); +module_exit(kcache_cleanup_module);
Attachment:
kmem-cache-config.bz2
Description: BZip2 compressed data
- Follow-Ups:
- Re: possible bug in kmem_cache related code
- From: "Pekka Enberg" <[email protected]>
- Re: possible bug in kmem_cache related code
- Prev by Date: Re: Lockless page cache test results
- Next by Date: Re: [PATCH] likely cleanup: remove unlikely for kfree(NULL)
- Previous by thread: A possibility of turning off file caching for certain operations
- Next by thread: Re: possible bug in kmem_cache related code
- Index(es):