Re: [patch] real fix [Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algo

Alexander Viro (viro@math.psu.edu)
Thu, 11 Feb 1999 11:17:05 -0500 (EST)


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/