Indeed, CONFIG_SLUB_DEBUG is not an issue by itself.
The biggest problem is the stack trace bookkeeping which currently
(with SLUB) requires 128 bytes for each allocation and deallocation
stack, bloating each memory object by 256 bytes.
If we make KASAN use the stack depot with SLUB we'll save a l
On Thu, 18 Feb 2016, Alexander Potapenko wrote:
> Unlike SLUB, SLAB doesn't store allocation/deallocation stacks for heap
> objects, therefore we reimplement this feature in mm/kasan/stackdepot.c.
> The intention is to ultimately switch SLUB to use this implementation as
> well, which will remove
This patch set implements SLAB support for KASAN
Unlike SLUB, SLAB doesn't store allocation/deallocation stacks for heap
objects, therefore we reimplement this feature in mm/kasan/stackdepot.c.
The intention is to ultimately switch SLUB to use this implementation as
well, which will remove the dep
3 matches
Mail list logo
