[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190506081234.GA69602@gmail.com>
Date: Mon, 6 May 2019 10:12:34 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>,
Borislav Petkov <bp@...en8.de>
Subject: [GIT PULL] core/stacktrace updates for v5.2
Linus,
Please pull the latest core-stacktrace-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-stacktrace-for-linus
# HEAD: 3599fe12a125fa7118da2bcc5033d7741fb5f3a1 x86/stacktrace: Use common infrastructure
So Thomas looked at the stacktrace code recently and noticed a few
weirdnesses, and we all know how such stories of crummy kernel code
meeting German engineering perfection end: a 45-patch series to clean it
all up! :-)
Here's the changes in Thomas's words:
"Struct stack_trace is a sinkhole for input and output parameters which is
largely pointless for most usage sites. In fact if embedded into other data
structures it creates indirections and extra storage overhead for no benefit.
Looking at all usage sites makes it clear that they just require an
interface which is based on a storage array. That array is either on stack,
global or embedded into some other data structure.
Some of the stack depot usage sites are outright wrong, but fortunately the
wrongness just causes more stack being used for nothing and does not have
functional impact.
Another oddity is the inconsistent termination of the stack trace with
ULONG_MAX. It's pointless as the number of entries is what determines the
length of the stored trace. In fact quite some call sites remove the
ULONG_MAX marker afterwards with or without nasty comments about it. Not
all architectures do that and those which do, do it inconsistenly either
conditional on nr_entries == 0 or unconditionally.
The following series cleans that up by:
1) Removing the ULONG_MAX termination in the architecture code
2) Removing the ULONG_MAX fixups at the call sites
3) Providing plain storage array based interfaces for stacktrace and
stackdepot.
4) Cleaning up the mess at the callsites including some related
cleanups.
5) Removing the struct stack_trace based interfaces
This is not changing the struct stack_trace interfaces at the architecture
level, but it removes the exposure to the generic code."
Thanks,
Ingo
------------------>
Thomas Gleixner (45):
um/stacktrace: Remove the pointless ULONG_MAX marker
x86/stacktrace: Remove the pointless ULONG_MAX marker
arm/stacktrace: Remove the pointless ULONG_MAX marker
sh/stacktrace: Remove the pointless ULONG_MAX marker
unicore32/stacktrace: Remove the pointless ULONG_MAX marker
riscv/stacktrace: Remove the pointless ULONG_MAX marker
arm64/stacktrace: Remove the pointless ULONG_MAX marker
parisc/stacktrace: Remove the pointless ULONG_MAX marker
s390/stacktrace: Remove the pointless ULONG_MAX marker
lockdep: Remove the ULONG_MAX stack trace hackery
mm/slub: Remove the ULONG_MAX stack trace hackery
mm/page_owner: Remove the ULONG_MAX stack trace hackery
mm/kasan: Remove the ULONG_MAX stack trace hackery
latency_top: Remove the ULONG_MAX stack trace hackery
drm: Remove the ULONG_MAX stack trace hackery
tracing: Remove the ULONG_MAX stack trace hackery
tracing: Cleanup stack trace code
stacktrace: Provide helpers for common stack trace operations
lib/stackdepot: Provide functions which operate on plain storage arrays
backtrace-test: Simplify stack trace handling
proc: Simplify task stack retrieval
latency_top: Simplify stack trace handling
mm/slub: Simplify stack trace retrieval
mm/kmemleak: Simplify stacktrace handling
mm/kasan: Simplify stacktrace handling
mm/page_owner: Simplify stack trace handling
fault-inject: Simplify stacktrace retrieval
dma/debug: Simplify stracktrace retrieval
btrfs: ref-verify: Simplify stack trace retrieval
dm bufio: Simplify stack trace retrieval
dm persistent data: Simplify stack trace handling
drm: Simplify stacktrace handling
lockdep: Remove unused trace argument from print_circular_bug()
lockdep: Remove save argument from check_prev_add()
lockdep: Simplify stack trace handling
tracing: Simplify stacktrace retrieval in histograms
tracing: Use percpu stack trace buffer more intelligently
tracing: Make ftrace_trace_userstack() static and conditional
tracing: Simplify stack trace retrieval
tracing: Remove the last struct stack_trace usage
livepatch: Simplify stack trace retrieval
stacktrace: Remove obsolete functions
lib/stackdepot: Remove obsolete functions
stacktrace: Provide common infrastructure
x86/stacktrace: Use common infrastructure
arch/arm/kernel/stacktrace.c | 6 -
arch/arm64/kernel/stacktrace.c | 4 -
arch/parisc/kernel/stacktrace.c | 5 -
arch/riscv/kernel/stacktrace.c | 2 -
arch/s390/kernel/stacktrace.c | 6 -
arch/sh/kernel/stacktrace.c | 4 -
arch/um/kernel/stacktrace.c | 2 -
arch/unicore32/kernel/stacktrace.c | 2 -
arch/x86/Kconfig | 1 +
arch/x86/kernel/stacktrace.c | 128 ++--------
drivers/gpu/drm/drm_mm.c | 25 +-
drivers/gpu/drm/i915/i915_vma.c | 11 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 25 +-
drivers/md/dm-bufio.c | 15 +-
drivers/md/persistent-data/dm-block-manager.c | 19 +-
fs/btrfs/ref-verify.c | 15 +-
fs/proc/base.c | 17 +-
include/linux/ftrace.h | 18 +-
include/linux/lockdep.h | 9 +-
include/linux/stackdepot.h | 8 +-
include/linux/stacktrace.h | 81 +++++--
kernel/backtracetest.c | 11 +-
kernel/dma/debug.c | 14 +-
kernel/latencytop.c | 29 +--
kernel/livepatch/transition.c | 22 +-
kernel/locking/lockdep.c | 87 +++----
kernel/stacktrace.c | 333 ++++++++++++++++++++++++--
kernel/trace/trace.c | 105 ++++----
kernel/trace/trace.h | 8 -
kernel/trace/trace_events_hist.c | 14 +-
kernel/trace/trace_stack.c | 85 +++----
lib/Kconfig | 4 +
lib/fault-inject.c | 12 +-
lib/stackdepot.c | 54 +++--
mm/kasan/common.c | 35 +--
mm/kasan/report.c | 7 +-
mm/kmemleak.c | 24 +-
mm/page_owner.c | 82 +++----
mm/slub.c | 21 +-
39 files changed, 694 insertions(+), 656 deletions(-)
Powered by blists - more mailing lists