Re: [PATCH v4] mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB

[Alexander Potapenko]

On Mon, Jun 20, 2016 at 9:50 PM, Sasha Levin <sasha.levin@xxxxxxxxxx> wrote:
> On 06/20/2016 08:53 AM, Alexander Potapenko wrote:
>> On Sun, Jun 19, 2016 at 7:40 PM, Sasha Levin <sasha.levin@xxxxxxxxxx> wrote:
>>> > On 06/19/2016 03:24 AM, Alexander Potapenko wrote:
>>>> >> Hi Sasha,
>>>> >>
>>>> >> This commit delays the reuse of memory after it has been freed, so
>>>> >> it's intended to help people find more use-after-free errors.
>>> >
>>> > Is there a way to tell if the use-after-free access was to a memory
>>> > that is quarantined?
>>> >
>>>> >> But I'm puzzled why the stacks are missing.
>>> >
>>> > I looked at the logs, it looks like stackdepot ran out of room pretty
>>> > early during boot.
>> This is quite strange, as there's room for ~80k stacks in the depot,
>> and usually the number of unique stacks is lower than 30k.
>> I wonder if this is specific to your config, can you please share it
>> (assuming you're using ToT kernel)?
>> Attached is the patch that you can try out to dump the new stacks
>> after 30k - it's really interesting where do they come from (note the
>> patch is not for submission).
>
> Attached a log file generated with that patch, and my kernel config.
I haven't looked close yet, but your log contains 1455 unique
'DRIVERNAME_driver_init' function names, for which it's quite likely
that 80k allocation stacks are generated.
Can you remove the dump_stack() call from my patch, fuzz for a while
and see to which number does |alloc_cnt| converge on your machine?
Maybe our estimate was just too optimistic, and we need to increase
the memory limit for the stack depot.
>
> Thanks,
> Sasha
>



-- 
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