1. 11 Nov, 2016 1 commit
  2. 28 Oct, 2016 1 commit
    • 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>
  3. 28 Jul, 2016 1 commit
  4. 06 May, 2016 1 commit
  5. 29 Apr, 2016 1 commit
  6. 25 Mar, 2016 1 commit
    • Alexander Potapenko's avatar
      mm, kasan: stackdepot implementation. Enable stackdepot for SLAB · cd11016e
      Alexander Potapenko authored
      Implement the stack depot and provide CONFIG_STACKDEPOT.  Stack depot
      will allow KASAN store allocation/deallocation stack traces for memory
      chunks.  The stack traces are stored in a hash table and referenced by
      handles which reside in the kasan_alloc_meta and kasan_free_meta
      structures in the allocated memory chunks.
      IRQ stack traces are cut below the IRQ entry point to avoid unnecessary
      Right now stackdepot support is only enabled in SLAB allocator.  Once
      KASAN features in SLAB are on par with those in SLUB we can switch SLUB
      to stackdepot as well, thus removing the dependency on SLUB stack
      bookkeeping, which wastes a lot of memory.
      This patch is based on the "mm: kasan: stack depots" patch originally
      prepared by Dmitry Chernenkov.
      Joonsoo has said that he plans to reuse the stackdepot code for the
      mm/page_owner.c debugging facility.
      [akpm@linux-foundation.org: s/depot_stack_handle/depot_stack_handle_t]
      [aryabinin@virtuozzo.com: comment style fixes]
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Andrey Konovalov <adech.fo@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>