linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Potapenko <glider@google.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrey Konovalov <adech.fo@gmail.com>,
	Dmitriy Vyukov <dvyukov@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	JoonSoo Kim <js1304@gmail.com>,
	Kostya Serebryany <kcc@google.com>,
	kasan-dev@googlegroups.com, LKML <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH v2 0/7] SLAB support for KASAN
Date: Thu, 18 Feb 2016 18:48:54 +0100	[thread overview]
Message-ID: <CAG_fn=WnLoM8SGDxa8Dvz62drPsh9_Mi_G_c2X-OENF_Oy8nFw@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1602181131320.24647@east.gentwo.org>

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 lot of memory.

On Thu, Feb 18, 2016 at 6:32 PM, Christoph Lameter <cl@linux.com> wrote:
> 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 the dependency on SLUB_DEBUG.
>
> This needs to be clarified a bit. CONFIG_SLUB_DEBUG is on by default. So
> the dependency does not matter much. I think you depend on the slowpath
> debug processing right? The issue is that you want to do these things in
> the fastpath?
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den
Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
This e-mail is confidential. If you are not the right addressee please
do not forward it, please inform the sender, and please erase this
e-mail including any attachments. Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2016-02-18 17:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-18 17:16 Alexander Potapenko
     [not found] ` <cover.1455814741.git.glider@google.com>
2016-02-18 17:16   ` [PATCH v2 1/7] kasan: Modify kmalloc_large_oob_right(), add kmalloc_pagealloc_oob_right() Alexander Potapenko
2016-02-18 17:16   ` [PATCH v2 2/7] mm, kasan: SLAB support Alexander Potapenko
2016-02-18 17:16   ` [PATCH v2 3/7] mm, kasan: Added GFP flags to KASAN API Alexander Potapenko
2016-02-18 17:16   ` [PATCH v2 4/7] arch, ftrace: For KASAN put hard/soft IRQ entries into separate sections Alexander Potapenko
2016-02-18 17:16   ` [PATCH v2 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB Alexander Potapenko
2016-02-18 17:16   ` [PATCH v2 6/7] kasan: Test fix: Warn if the UAF could not be detected in kmalloc_uaf2 Alexander Potapenko
2016-02-18 17:16   ` [PATCH v2 7/7] mm: kasan: Initial memory quarantine implementation Alexander Potapenko
2016-02-18 17:32 ` [PATCH v2 0/7] SLAB support for KASAN Christoph Lameter
2016-02-18 17:48   ` Alexander Potapenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAG_fn=WnLoM8SGDxa8Dvz62drPsh9_Mi_G_c2X-OENF_Oy8nFw@mail.gmail.com' \
    --to=glider@google.com \
    --cc=adech.fo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=dvyukov@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=js1304@gmail.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kcc@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rostedt@goodmis.org \
    --cc=ryabinin.a.a@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox