diff options
author | Christoph Lameter <clameter@sgi.com> | 2006-09-25 23:31:38 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-09-26 08:48:50 -0700 |
commit | 2ed3a4ef95ef1a13a424378c34ebd9b7e593f212 (patch) | |
tree | bb08e0b3526ab71639197fad649349dc222e0451 /include/linux/icmpv6.h | |
parent | 117f6eb1d8b8deb6f19fc88fc15bdb413c2a0c79 (diff) | |
download | blackbird-op-linux-2ed3a4ef95ef1a13a424378c34ebd9b7e593f212.tar.gz blackbird-op-linux-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 'include/linux/icmpv6.h')
0 files changed, 0 insertions, 0 deletions