summaryrefslogtreecommitdiff
path: root/fs/ufs
diff options
context:
space:
mode:
authorChristoph Lameter <clameter@sgi.com>2006-09-25 23:31:38 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-09-26 08:48:50 -0700
commit2ed3a4ef95ef1a13a424378c34ebd9b7e593f212 (patch)
treebb08e0b3526ab71639197fad649349dc222e0451 /fs/ufs
parent117f6eb1d8b8deb6f19fc88fc15bdb413c2a0c79 (diff)
downloadlinux-3.10-2ed3a4ef95ef1a13a424378c34ebd9b7e593f212.tar.gz
linux-3.10-2ed3a4ef95ef1a13a424378c34ebd9b7e593f212.tar.bz2
linux-3.10-2ed3a4ef95ef1a13a424378c34ebd9b7e593f212.zip
[PATCH] slab: do not panic when alloc_kmemlist fails and slab is up
It is fairly easy to get a system to oops by simply sizing a cache via /proc in such a way that one of the chaches (shared is easiest) becomes bigger than the maximum allowed slab allocation size. This occurs because enable_cpucache() fails if it cannot reallocate some caches. However, enable_cpucache() is used for multiple purposes: resizing caches, cache creation and bootstrap. If the slab is already up then we already have working caches. The resize can fail without a problem. We just need to return the proper error code. F.e. after this patch: # echo "size-64 10000 50 1000" >/proc/slabinfo -bash: echo: write error: Cannot allocate memory notice no OOPS. If we are doing a kmem_cache_create() then we also should not panic but return -ENOMEM. If on the other hand we do not have a fully bootstrapped slab allocator yet then we should indeed panic since we are unable to bring up the slab to its full functionality. Signed-off-by: Christoph Lameter <clameter@sgi.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/ufs')
0 files changed, 0 insertions, 0 deletions