On 04/18/2014 05:41 PM, Johannes Weiner wrote: >> Thus we have a piece of code that works only when we explicitly call >> kmem_cache_shrink, but complicates the whole picture a lot. Moreover, >> it's racy in fact. For instance, kmem_cache_shrink may free the last >> slab and thus schedule cache destruction before it finishes checking >> that the cache is empty, which can lead to use-after-free. > > Can't this still happen when the last object free races with css > destruction? AFAIU, yes, it still can happen, but we have less places to fix now. I'm planning to sort this out by rearranging operations inside kmem_cache_free so that we do not touch the cache after we've decremented memcg_cache_params::nr_pages and made the cache potentially destroyable. Or, if we could reparent individual slabs as you proposed earlier, we wouldn't have to bother about it at all any more as well as about per memcg cache destruction. Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>