Messages in this thread | | | Date | Thu, 11 Feb 1999 11:17:05 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [patch] real fix [Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algorithm |
| |
On Thu, 11 Feb 1999, Mark Hemment wrote:
> One reason this feature isn't implemented is my belief the slab allocator > should trap badly behaved code (or at least try its best, when the > detection code isn't too heavy). > Suppose an allocation from the cache is in progress when an attempt to > destory it occurs? Not legal, it is an indication that something is > wrong, but I won't want a system to fall over because of it. The > reason being the "fall over" could occur in a different part of the > system, making it difficult to debug.
Aha. I see. Well, all reasonable places where dropping the cache might be needed are actually on the module unloading. If we have a code running in that module in the same moment... It will be pretty spectacular oops. And pretty visible one. So maybe we need a way to mark a slab (on creation) as belonging to given module and destroy such beasts from sys_delete_module(). Since sys_delete_module() checks usage counter we should be reasonably safe with it. Again, if something runs within the module with zero usage counter we *are* in trouble. If it happens in the moment when sys_delete_module() is called we'll see a large oops. I'ld suggest the following: kmem_cache_module_create() that creates a new slab and either marks it as belonging to that module or simply adds it to cyclic list anchored in a struct module. Usage: call from module and never touch the resulting slab outside of said module (or modules depending on it). delete_module(2) will try to shrink such slabs and if all of them will become empty it will destroy them. Would any of such slabs happen to be non-empty delete_module(2) will fail with -EBUSY and will generate a KERN_ERR level message for each of non-empty slabs. Note: kmem_cache_module_create() is a wrapper for __kmem_cache_module_create(), defined by #define kmem_cache_module_create(name,m,n,flags,f,g) \ __kmem_cache_module_create(name,m,n,flags,f,g,&__this_module) Thus its usage requires #include <linux/module.h>
Would such beast be OK? Come to think of that, we don't need a separate function - just define kmem_cache_create() by #ifdef MODULE #define kmem_cache_create(name,m,n,flags,f,g) \ __kmem_cache_module_create(name,m,n,flags,f,g,&__this_module) #else #define kmem_cache_create(name,m,n,flags,f,g) \ __kmem_cache_kernel_create(name,m,n,flags,f,g) #endif That way all we need is to warn about usage of slab created in module by anything outside of said module and modules depending on it. I can do modules-related side if you will provide a (static in mm/slab.c) kmem_cache_destroy(). Comments? Al
- 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/
| |