linux-kernel - Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG_fn=XQ1jvUXG2xWM9rEgqBEB-DBrA-G6wWOZ9t_SvfrKjdsg@mail.gmail.com>
Date:	Mon, 11 Apr 2016 16:51:47 +0200
From:	Alexander Potapenko <glider@...gle.com>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>
Cc:	Andrey Konovalov <adech.fo@...il.com>,
	Christoph Lameter <cl@...ux.com>,
	Dmitriy Vyukov <dvyukov@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Kostya Serebryany <kcc@...gle.com>,
	kasan-dev <kasan-dev@...glegroups.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable
 stackdepot for SLAB

On Mon, Apr 11, 2016 at 4:39 PM, Alexander Potapenko <glider@...gle.com> wrote:
> On Mon, Apr 11, 2016 at 9:44 AM, Joonsoo Kim <iamjoonsoo.kim@....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