On Thu, 28 Jun 2007, David Miller wrote: > > You can get such a reference and then the slab page will be in limbo if > > all objects are freed until that reference is given up. The reference > > method is also use by kmem_cache_vacate() (but that is slab internal). > > What about if someone kfree()'s that object meanwhile?
If that is the last object in the slab then the page is deslabified and it will stick around as a regular page until its refcount reaches zero. There is slab functionality in SLUB that uses this trick to insure that the slab does not go away. > Can we bump the SLAB object count just like we can a page? You can bump the slab page count. But you have to use virt_to_head_page() instead of virt_to_page() since slab pages may be compound pages (in both SLAB and SLUB). Incrementing the refcount of a tail page will cause an oops on free. > That's basically what's happening in the stuff Jens is > working on, he needs to grab a reference to a SLAB > object just like one can a page. Even if there is an > intervening kfree (like a put_page()) the SLAB object is > still live until all the references are put, and thus it > can't get reallocated and given to another client by SLAB. If you kfree the object then all slab allocators will feel free to immediately alloc the object for other purposes. If you want to prohibit further allocations from a slab then I can likely give you a function call that removes a slab from the partial lists so that the slab will not be allocated from. But this will only work with SLUB. At some point the slab will then need to be returned to the partial slab lists. Hmmmm... Maybe we are creating more of a mess with this. Isnt there some other way to handle these object. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
