I'm working on a different set of tools for KASan, independent of slub_debug (so it can be turned off either by cmdline flag or kernel config). Most of the ideas are taken from the userspace ASan.
- Use our own data structures (metadata, redzones, stacks, quarantine), so the same code works in SLAB/SLUB, and Kasan is less dependent on allocator internals.
- Redzone size is flexible based on object size.
- Store alloc/free stacks separately, in a compact structure (stack depot) and index them via a hashtable, so we don't store identical stacks multiple times. SLUB_DEBUG stacks have overhead of 256 bytes per object. Stack depot takes ~100 times less.
- Quarantine is global (not per-slab or per-cache), with per-cpu queues periodically flushed into a global one. kmem_cache_destroy and kmem_cache_shrink launch a scan of quarantine to return all objects from associated caches to the freelist. Thus, we don't need a separate shrinker hook.
On Tue, Mar 3, 2015 at 7:42 PM, Christoph Lameter <cl@xxxxxxxxx> wrote:
On Tue, 3 Mar 2015, Andrey Ryabinin wrote:
> On 03/03/2015 12:10 PM, Dmitry Vyukov wrote:
> > Please hold on with this.
> > Dmitry Chernenkov is working on a quarantine that works with both slub
> > and slab, does not cause spurious OOMs and does not depend on
> > slub-debug which has unacceptable performance (acquires global lock).
>
> I think that it's a separate issue. KASan already depend on slub_debug - it required for redzones/user tracking.
> I think that some parts slub debugging (like user tracking and this quarantine)
> could be moved (for CONFIG_KASAN=y) to the fast path without any locking.
In general these features need to be ifdeffed out since they add
significant overhead for the data structures and execution paths.