lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ