linux-toradex.git/lib/stackdepot.c, branch v5.10-rc1

kasan: stackdepot: move filter_irq_stacks() to stackdepot.c

2020-04-07T17:43:43+00:00

filter_irq_stacks() can be used by other tools (e.g.  KMSAN), so it needs
to be moved to a common location.  lib/stackdepot.c seems a good place, as
filter_irq_stacks() is usually applied to the output of
stack_trace_save().

This patch has been previously mailed as part of KMSAN RFC patch series.

[glider@google.co: nds32: linker script: add SOFTIRQENTRY_TEXT\
  Link: http://lkml.kernel.org/r/20200311121002.241430-1-glider@google.com
[glider@google.com: add IRQENTRY_TEXT and SOFTIRQENTRY_TEXT to linker script]
  Link: http://lkml.kernel.org/r/20200311121124.243352-1-glider@google.com
Signed-off-by: Alexander Potapenko 
Signed-off-by: Andrew Morton 
Cc: Vegard Nossum 
Cc: Dmitry Vyukov 
Cc: Marco Elver 
Cc: Andrey Konovalov 
Cc: Andrey Ryabinin 
Cc: Arnd Bergmann 
Cc: Sergey Senozhatsky 
Link: http://lkml.kernel.org/r/20200220141916.55455-3-glider@google.com
Signed-off-by: Linus Torvalds

lib/stackdepot.c: check depot_index before accessing the stack slab

2020-04-07T17:43:43+00:00

Avoid crashes on corrupted stack ids.  Despite stack ID corruption may
indicate other bugs in the program, we'd better fail gracefully on such
IDs instead of crashing the kernel.

This patch has been previously mailed as part of KMSAN RFC patch series.

Link: http://lkml.kernel.org/r/20200220141916.55455-1-glider@google.com
Signed-off-by: Alexander Potapenko 
Cc: Vegard Nossum 
Cc: Dmitry Vyukov 
Cc: Marco Elver 
Cc: Andrey Konovalov 
Cc: Andrey Ryabinin 
Cc: Arnd Bergmann 
Cc: Sergey Senozhatsky 
From: Dan Carpenter 
Subject: lib/stackdepot.c: fix a condition in stack_depot_fetch()

We should check for a NULL pointer first before adding the offset.
Otherwise if the pointer is NULL and the offset is non-zero, it will lead
to an Oops.

Fixes: d45048e65a59 ("lib/stackdepot.c: check depot_index before accessing the stack slab")
Signed-off-by: Dan Carpenter 
Signed-off-by: Andrew Morton 
Acked-by: Alexander Potapenko 
Link: http://lkml.kernel.org/r/20200312113006.GA20562@mwanda
Signed-off-by: Linus Torvalds

lib/stackdepot.c: fix global out-of-bounds in stack_slabs

2020-02-21T19:22:15+00:00

Walter Wu has reported a potential case in which init_stack_slab() is
called after stack_slabs[STACK_ALLOC_MAX_SLABS - 1] has already been
initialized.  In that case init_stack_slab() will overwrite
stack_slabs[STACK_ALLOC_MAX_SLABS], which may result in a memory
corruption.

Link: http://lkml.kernel.org/r/20200218102950.260263-1-glider@google.com
Fixes: cd11016e5f521 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB")
Signed-off-by: Alexander Potapenko 
Reported-by: Walter Wu 
Cc: Dmitry Vyukov 
Cc: Matthias Brugger 
Cc: Thomas Gleixner 
Cc: Josh Poimboeuf 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/stackdepot: Fix outdated comments

2019-08-19T10:57:28+00:00

Replace "depot_save_stack" with "stack_depot_save" in code comments because
depot_save_stack() was replaced in commit c0cfc337264c ("lib/stackdepot:
Provide functions which operate on plain storage arrays") and removed in
commit 56d8f079c51a ("lib/stackdepot: Remove obsolete functions")

Signed-off-by: Miles Chen 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20190815113246.18478-1-miles.chen@mediatek.com

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174

2019-05-30T18:26:41+00:00

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation this program is
  distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 655 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Allison Randal 
Reviewed-by: Kate Stewart 
Reviewed-by: Richard Fontana 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de
Signed-off-by: Greg Kroah-Hartman

lib/stackdepot: Remove obsolete functions

2019-04-29T10:37:57+00:00

No more users of the struct stack_trace based interfaces.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Josh Poimboeuf 
Acked-by: Alexander Potapenko 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexey Dobriyan 
Cc: Andrew Morton 
Cc: Christoph Lameter 
Cc: Pekka Enberg 
Cc: linux-mm@kvack.org
Cc: David Rientjes 
Cc: Catalin Marinas 
Cc: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: kasan-dev@googlegroups.com
Cc: Mike Rapoport 
Cc: Akinobu Mita 
Cc: Christoph Hellwig 
Cc: iommu@lists.linux-foundation.org
Cc: Robin Murphy 
Cc: Marek Szyprowski 
Cc: Johannes Thumshirn 
Cc: David Sterba 
Cc: Chris Mason 
Cc: Josef Bacik 
Cc: linux-btrfs@vger.kernel.org
Cc: dm-devel@redhat.com
Cc: Mike Snitzer 
Cc: Alasdair Kergon 
Cc: Daniel Vetter 
Cc: intel-gfx@lists.freedesktop.org
Cc: Joonas Lahtinen 
Cc: Maarten Lankhorst 
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tom Zanussi 
Cc: Miroslav Benes 
Cc: linux-arch@vger.kernel.org
Link: https://lkml.kernel.org/r/20190425094803.617937448@linutronix.de

lib/stackdepot: Provide functions which operate on plain storage arrays

2019-04-29T10:37:47+00:00

The struct stack_trace indirection in the stack depot functions is a truly
pointless excercise which requires horrible code at the callsites.

Provide interfaces based on plain storage arrays.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Josh Poimboeuf 
Acked-by: Alexander Potapenko 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexey Dobriyan 
Cc: Andrew Morton 
Cc: Christoph Lameter 
Cc: Pekka Enberg 
Cc: linux-mm@kvack.org
Cc: David Rientjes 
Cc: Catalin Marinas 
Cc: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: kasan-dev@googlegroups.com
Cc: Mike Rapoport 
Cc: Akinobu Mita 
Cc: Christoph Hellwig 
Cc: iommu@lists.linux-foundation.org
Cc: Robin Murphy 
Cc: Marek Szyprowski 
Cc: Johannes Thumshirn 
Cc: David Sterba 
Cc: Chris Mason 
Cc: Josef Bacik 
Cc: linux-btrfs@vger.kernel.org
Cc: dm-devel@redhat.com
Cc: Mike Snitzer 
Cc: Alasdair Kergon 
Cc: Daniel Vetter 
Cc: intel-gfx@lists.freedesktop.org
Cc: Joonas Lahtinen 
Cc: Maarten Lankhorst 
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tom Zanussi 
Cc: Miroslav Benes 
Cc: linux-arch@vger.kernel.org
Link: https://lkml.kernel.org/r/20190425094801.414574828@linutronix.de

lib/stackdepot.c: use a non-instrumented version of memcmp()

2018-02-07T02:32:44+00:00

stackdepot used to call memcmp(), which compiler tools normally
instrument, therefore every lookup used to unnecessarily call instrumented
code.  This is somewhat ok in the case of KASAN, but under KMSAN a lot of
time was spent in the instrumentation.

Link: http://lkml.kernel.org/r/20171117172149.69562-1-glider@google.com
Signed-off-by: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Dmitry Vyukov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/stackdepot: export save/fetch stack for drivers

2016-11-11T16:12:37+00:00

Some drivers would like to record stacktraces in order to aide leak
tracing.  As stackdepot already provides a facility for only storing the
unique traces, thereby reducing the memory required, export that
functionality for use by drivers.

The code was originally created for KASAN and moved under lib in commit
cd11016e5f521 ("mm, kasan: stackdepot implementation.  Enable stackdepot
for SLAB") so that it could be shared with mm/.  In turn, we want to
share it now with drivers.

Link: http://lkml.kernel.org/r/20161108133209.22704-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: Joonsoo Kim 
Cc: "Kirill A. Shutemov" 
Cc: Daniel Vetter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/stackdepot.c: bump stackdepot capacity from 16MB to 128MB

2016-10-28T01:43:43+00:00

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.com
Signed-off-by: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Joonsoo Kim 
Cc: Baozeng Ding 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds