diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2013-08-08 09:06:37 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2013-08-08 09:06:37 -0700 |
commit | 370905069ce6515f38d5de0a5b1c899cbe58fe22 (patch) | |
tree | 4838e5a5d97c5cc94330bc65249ee147ab93afae /MAINTAINERS | |
parent | b7bc9e7d808ba55729bd263b0210cda36965be32 (diff) | |
download | kernel-common-370905069ce6515f38d5de0a5b1c899cbe58fe22.tar.gz kernel-common-370905069ce6515f38d5de0a5b1c899cbe58fe22.tar.bz2 kernel-common-370905069ce6515f38d5de0a5b1c899cbe58fe22.zip |
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 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions