Messages in this thread | | | From | Roland Dreier <> | Subject | Re: kmem_cache_destroy() badness with SLUB | Date | Mon, 05 Jul 2010 20:58:27 -0700 |
| |
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.
-- Roland Dreier <rolandd@cisco.com> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
| |