Messages in this thread | | | Subject | kmem_cache_destroy() badness with SLUB | From | Benjamin Herrenschmidt <> | Date | Mon, 28 Jun 2010 11:31:41 +1000 |
| |
Hi folks !
Internally, I'm hitting a little "nit"...
sysfs_slab_add() has this check:
if (slab_state < SYSFS) /* Defer until later */ return 0;
But sysfs_slab_remove() doesn't.
So if the slab is created -and- destroyed at, for example, arch_initcall time, then we hit a WARN in the kobject code, trying to dispose of a non-existing kobject.
Now, at first sight, just adding the same test to sysfs_slab_remove() would do the job... but it all seems very racy to me.
I don't understand in fact how this slab_state deals with races at all.
What prevents us from hitting slab_sysfs_init() at the same time as another CPU deos sysfs_slab_add() ? How do that deal with collisions trying to register the same kobject twice ? Similar race with remove...
Shouldn't we have a mutex around those guys ?
Cheers, Ben.
| |