diff options
| author | Christoph Lameter <[email protected]> | 2006-09-25 23:31:38 -0700 |
|---|---|---|
| committer | Linus Torvalds <[email protected]> | 2006-09-26 08:48:50 -0700 |
| commit | 2ed3a4ef95ef1a13a424378c34ebd9b7e593f212 (patch) | |
| tree | bb08e0b3526ab71639197fad649349dc222e0451 /tools/perf/scripts/python | |
| parent | 117f6eb1d8b8deb6f19fc88fc15bdb413c2a0c79 (diff) | |
[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 <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Manfred Spraul <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions