On Thu, 2013-08-08 at 14:04 +0900, Joonsoo Kim wrote: > Sorry about it. > Now, I think that this is a buggy commit, so should be reverted. > > For confirm that, could I ask a question about your configuration, Steven? > I guess, you may set 0 to all kmem caches's cpu_partial via sysfs, doesn't it?
Ah, you're right. As this box is also used to test the -rt patch, there's a script installed to disable all cpu_partials. This is because cpu_partials are known to cause non-deterministic behavior in -rt. I forgot about that script, as this box is used for regular mainline testing as well. > > In this case, memory leak is possible in following case. > Code flow of possible leak is follwing case. > > * in __slab_free() > 1. (!new.inuse || !prior) && !was_frozen > 2. !kmem_cache_debug && !prior > 3. new.frozen = 1 > 4. after cmpxchg_double_slab, run the (!n) case with new.frozen=1 > 5. with this patch, put_cpu_partial() doesn't do anything, > because this cache's cpu_partial is 0 > 6. return > > In step 5, leak occur. > > I have a solution to prevent this problem, but in this stage, IMHO, > reverting it may be better. Yeah, I would suggest that too. As this seems to be a serious regression. Thanks! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/