Re: [RFC] slub memory quarantine

[Dmitry Chernenkov <dmitryc@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

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@linux.com> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 2288 bytes --]