From: Alexander Potapenko <glider@google.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrey Konovalov <adech.fo@gmail.com>,
Christoph Lameter <cl@linux.com>,
Dmitriy Vyukov <dvyukov@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Kostya Serebryany <kcc@google.com>,
kasan-dev <kasan-dev@googlegroups.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB
Date: Mon, 11 Apr 2016 16:51:47 +0200 [thread overview]
Message-ID: <CAG_fn=XQ1jvUXG2xWM9rEgqBEB-DBrA-G6wWOZ9t_SvfrKjdsg@mail.gmail.com> (raw)
In-Reply-To: <CAG_fn=W_zM0u_NjSzJNi9KiNRY=rtQSYWTVfOQ2nGedApWMBdg@mail.gmail.com>
On Mon, Apr 11, 2016 at 4:39 PM, Alexander Potapenko <glider@google.com> wrote:
> On Mon, Apr 11, 2016 at 9:44 AM, Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
>> On Mon, Mar 14, 2016 at 11:43:43AM +0100, Alexander Potapenko wrote:
>>> +depot_stack_handle_t depot_save_stack(struct stack_trace *trace,
>>> + gfp_t alloc_flags)
>>> +{
>>> + u32 hash;
>>> + depot_stack_handle_t retval = 0;
>>> + struct stack_record *found = NULL, **bucket;
>>> + unsigned long flags;
>>> + struct page *page = NULL;
>>> + void *prealloc = NULL;
>>> + bool *rec;
>>> +
>>> + if (unlikely(trace->nr_entries == 0))
>>> + goto fast_exit;
>>> +
>>> + rec = this_cpu_ptr(&depot_recursion);
>>> + /* Don't store the stack if we've been called recursively. */
>>> + if (unlikely(*rec))
>>> + goto fast_exit;
>>> + *rec = true;
>>> +
>>> + hash = hash_stack(trace->entries, trace->nr_entries);
>>> + /* Bad luck, we won't store this stack. */
>>> + if (hash == 0)
>>> + goto exit;
>>
>> Hello,
>>
>> why is hash == 0 skipped?
>>
>> Thanks.
> We have to keep a special value to distinguish allocations for which
> we don't have the stack trace for some reason.
> Making 0 such a value seems natural.
Well, the above statement is false.
Because we only compare the hash to the records that are already in
the depot, there's no point in reserving this value.
>
> --
> 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
--
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
--
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>
next prev parent reply other threads:[~2016-04-11 14:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 10:43 [PATCH v7 0/7] SLAB support for KASAN Alexander Potapenko
2016-03-14 10:43 ` [PATCH v7 1/7] kasan: Modify kmalloc_large_oob_right(), add kmalloc_pagealloc_oob_right() Alexander Potapenko
2016-03-14 10:43 ` [PATCH v7 2/7] mm, kasan: SLAB support Alexander Potapenko
2016-03-14 10:43 ` [PATCH v7 3/7] mm, kasan: Added GFP flags to KASAN API Alexander Potapenko
2016-03-14 10:43 ` [PATCH v7 4/7] arch, ftrace: For KASAN put hard/soft IRQ entries into separate sections Alexander Potapenko
2016-03-14 10:43 ` [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB Alexander Potapenko
2016-03-14 16:56 ` Andrey Ryabinin
2016-03-15 9:27 ` Alexander Potapenko
2016-03-15 12:22 ` Andrey Ryabinin
2016-03-18 15:12 ` Alexander Potapenko
2016-04-11 7:44 ` Joonsoo Kim
2016-04-11 14:39 ` Alexander Potapenko
2016-04-11 14:51 ` Alexander Potapenko [this message]
2016-04-12 4:51 ` Joonsoo Kim
2016-03-14 10:43 ` [PATCH v7 6/7] kasan: Test fix: Warn if the UAF could not be detected in kmalloc_uaf2 Alexander Potapenko
2016-03-14 10:43 ` [PATCH v7 7/7] mm: kasan: Initial memory quarantine implementation Alexander Potapenko
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=XQ1jvUXG2xWM9rEgqBEB-DBrA-G6wWOZ9t_SvfrKjdsg@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=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