summaryrefslogtreecommitdiffstats
path: root/arch/sh/Makefile
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2013-08-08 09:06:37 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2013-08-08 09:06:37 -0700
commit370905069ce6515f38d5de0a5b1c899cbe58fe22 (patch)
tree4838e5a5d97c5cc94330bc65249ee147ab93afae /arch/sh/Makefile
parentb7bc9e7d808ba55729bd263b0210cda36965be32 (diff)
Revert "slub: do not put a slab to cpu partial list when cpu_partial is 0"
This reverts commit 318df36e57c0ca9f2146660d41ff28e8650af423. This commit caused Steven Rostedt's hackbench runs to run out of memory due to a leak. As noted by Joonsoo Kim, it is buggy in the following scenario: "I guess, you may set 0 to all kmem caches's cpu_partial via sysfs, doesn't it? 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" And Steven does indeed have cpu_partial set to 0 due to RT testing. Joonsoo is cooking up a patch, but everybody agrees that reverting this for now is the right thing to do. Reported-and-bisected-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Acked-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/sh/Makefile')
0 files changed, 0 insertions, 0 deletions