We suspect some SLAB allocation failures handling code is not ideal
and leads to memory corruptions, in particular we often see slab freelist
corruptions.
In order to minimize damage / possibility of those corruptions we have
implemented several things:
1. Moved slab freelist pointer to the midd
From: Waiman Long
In a couple of places in the slub memory allocator, the code uses
"s->offset" as a check to see if the free pointer is put right after the
object. That check is no longer true with commit 3202fa62fb43 ("slub:
relocate freelist pointer to middle of object").
As a result, echoin
Introduce 2 ways to setup/configure "unlimited_slabs" tweak:
1. "unlimited_slabs=" kernel boot option
* "unlimited_slabs=1" to enable the tweak
* "unlimited_slabs=0" to disable the tweak
2. /sys/kernel/debug/unlimited_slabs entry
* echo 1 > /sys/kernel/debug/unlimited_slabs to enable
From: Kees Cook
In a recent discussion[1] with Vitaly Nikolenko and Silvio Cesare, it
became clear that moving the freelist pointer away from the edge of
allocations would likely improve the overall defensive posture of the
inline freelist pointer. My benchmarks show no meaningful change to
perf
Pretend marked SLABs are always allocated by a PF_MEMALLOC process to
bypass memory cgroup limits.
Added per-SLAB "pf_memalloc" attribute to disable/enable the logic on
the fly.
https://virtuozzo.atlassian.net/browse/PSBM-155867
Signed-off-by: Konstantin Khorenko
---
include/linux/slab.h | 1
From: Pavel Tikhomirov
We saw crashes where slub percpu freelist was corrupted, this may catch
the problem earlier where we first time see bad freelist, and suppress
further corruption.
This is enabled with 'slub_debug=F'.
https://virtuozzo.atlassian.net/browse/PSBM-155867
Signed-off-by: Pavel
