• Dmitry Vyukov's avatar
    lib/stackdepot.c: bump stackdepot capacity from 16MB to 128MB · 02754e0a
    Dmitry Vyukov authored
    KASAN uses stackdepot to memorize stacks for all kmalloc/kfree calls.
    Current stackdepot capacity is 16MB (1024 top level entries x 4 pages on
    second level).  Size of each stack is (num_frames + 3) * sizeof(long).
    Which gives us ~84K stacks.  This capacity was chosen empirically and it
    is enough to run kernel normally.
    
    However, when lots of configs are enabled and a fuzzer tries to maximize
    code coverage, it easily hits the limit within tens of minutes.  I've
    tested for long a time with number of top level entries bumped 4x
    (4096).  And I think I've seen overflow only once.  But I don't have all
    configs enabled and code coverage has not reached maximum yet.  So bump
    it 8x to 8192.
    
    Since we have two-level table, memory cost of this is very moderate --
    currently the top-level table is 8KB, with this patch it is 64KB, which
    is negligible under KASAN.
    
    Here is some approx math.
    
    128MB allows us to memorize ~670K stacks (assuming stack is ~200b).
    I've grepped kernel for kmalloc|kfree|kmem_cache_alloc|kmem_cache_free|
    kzalloc|kstrdup|kstrndup|kmemdup and it gives ~60K matches.  Most of
    alloc/free call sites are reachable with only one stack.  But some
    utility functions can have large fanout.  Assuming average fanout is 5x,
    total number of alloc/free stacks is ~300K.
    
    Link: http://lkml.kernel.org/r/1476458416-122131-1-git-send-email-dvyukov@google.comSigned-off-by: default avatarDmitry Vyukov <dvyukov@google.com>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Baozeng Ding <sploving1@gmail.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    02754e0a
stackdepot.c 8.41 KB