1. 01 Nov, 2018 1 commit
  2. 02 Mar, 2017 2 commits
  3. 15 Dec, 2016 1 commit
  4. 19 Feb, 2015 2 commits
    • Colin Cross's avatar
      debug: prevent entering debug mode on panic/exception. · 5516fd7b
      Colin Cross authored
      On non-developer devices, kgdb prevents the device from rebooting
      after a panic.
      Incase of panics and exceptions, to allow the device to reboot, prevent
      entering debug mode to avoid getting stuck waiting for the user to
      interact with debugger.
      To avoid entering the debugger on panic/exception without any extra
      configuration, panic_timeout is being used which can be set via
      /proc/sys/kernel/panic at run time and CONFIG_PANIC_TIMEOUT sets the
      default value.
      Setting panic_timeout indicates that the user requested machine to
      perform unattended reboot after panic. We dont want to get stuck waiting
      for the user input incase of panic.
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: kgdb-bugreport@lists.sourceforge.net
      Cc: linux-kernel@vger.kernel.org
      Cc: Android Kernel Team <kernel-team@android.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarColin Cross <ccross@android.com>
      [Kiran: Added context to commit message.
      panic_timeout is used instead of break_on_panic and
      break_on_exception to honor CONFIG_PANIC_TIMEOUT
      Modified the commit as per community feedback]
      Signed-off-by: default avatarKiran Raparthy <kiran.kumar@linaro.org>
      Signed-off-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      kdb: Fix off by one error in kdb_cpu() · df0036d1
      Jason Wessel authored
      There was a follow on replacement patch against the prior
      "kgdb: Timeout if secondary CPUs ignore the roundup".
      See: https://lkml.org/lkml/2015/1/7/442
      This patch is the delta vs the patch that was committed upstream:
        * Fix an off-by-one error in kdb_cpu().
        * Replace NR_CPUS with CONFIG_NR_CPUS to tell checkpatch that we
          really want a static limit.
        * Removed the "KGDB: " prefix from the pr_crit() in debug_core.c
          (kgdb-next contains a patch which introduced pr_fmt() to this file
          to the tag will now be applied automatically).
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
  5. 11 Nov, 2014 2 commits
  6. 18 Apr, 2014 1 commit
  7. 07 Apr, 2014 1 commit
    • Davidlohr Bueso's avatar
      mm: per-thread vma caching · 615d6e87
      Davidlohr Bueso authored
      This patch is a continuation of efforts trying to optimize find_vma(),
      avoiding potentially expensive rbtree walks to locate a vma upon faults.
      The original approach (https://lkml.org/lkml/2013/11/1/410), where the
      largest vma was also cached, ended up being too specific and random,
      thus further comparison with other approaches were needed.  There are
      two things to consider when dealing with this, the cache hit rate and
      the latency of find_vma().  Improving the hit-rate does not necessarily
      translate in finding the vma any faster, as the overhead of any fancy
      caching schemes can be too high to consider.
      We currently cache the last used vma for the whole address space, which
      provides a nice optimization, reducing the total cycles in find_vma() by
      up to 250%, for workloads with good locality.  On the other hand, this
      simple scheme is pretty much useless for workloads with poor locality.
      Analyzing ebizzy runs shows that, no matter how many threads are
      running, the mmap_cache hit rate is less than 2%, and in many situations
      below 1%.
      The proposed approach is to replace this scheme with a small per-thread
      cache, maximizing hit rates at a very low maintenance cost.
      Invalidations are performed by simply bumping up a 32-bit sequence
      number.  The only expensive operation is in the rare case of a seq
      number overflow, where all caches that share the same address space are
      flushed.  Upon a miss, the proposed replacement policy is based on the
      page number that contains the virtual address in question.  Concretely,
      the following results are seen on an 80 core, 8 socket x86-64 box:
      1) System bootup: Most programs are single threaded, so the per-thread
         scheme does improve ~50% hit rate by just adding a few more slots to
         the cache.
      | caching scheme | hit-rate | cycles (billion) |
      | baseline       | 50.61%   | 19.90            |
      | patched        | 73.45%   | 13.58            |
      2) Kernel build: This one is already pretty good with the current
         approach as we're dealing with good locality.
      | caching scheme | hit-rate | cycles (billion) |
      | baseline       | 75.28%   | 11.03            |
      | patched        | 88.09%   | 9.31             |
      3) Oracle 11g Data Mining (4k pages): Similar to the kernel build workload.
      | caching scheme | hit-rate | cycles (billion) |
      | baseline       | 70.66%   | 17.14            |
      | patched        | 91.15%   | 12.57            |
      4) Ebizzy: There's a fair amount of variation from run to run, but this
         approach always shows nearly perfect hit rates, while baseline is just
         about non-existent.  The amounts of cycles can fluctuate between
         anywhere from ~60 to ~116 for the baseline scheme, but this approach
         reduces it considerably.  For instance, with 80 threads:
      | caching scheme | hit-rate | cycles (billion) |
      | baseline       | 1.06%    | 91.54            |
      | patched        | 99.97%   | 14.18            |
      [akpm@linux-foundation.org: fix nommu build, per Davidlohr]
      [akpm@linux-foundation.org: document vmacache_valid() logic]
      [akpm@linux-foundation.org: attempt to untangle header files]
      [akpm@linux-foundation.org: add vmacache_find() BUG_ON]
      [hughd@google.com: add vmacache_valid_mm() (from Oleg)]
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: adjust and enhance comments]
      Signed-off-by: default avatarDavidlohr Bueso <davidlohr@hp.com>
      Reviewed-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reviewed-by: default avatarMichel Lespinasse <walken@google.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Tested-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  8. 26 Feb, 2014 1 commit
  9. 25 Jan, 2014 1 commit
  10. 03 Oct, 2013 1 commit
  11. 01 May, 2013 1 commit
  12. 04 Feb, 2013 1 commit
  13. 12 Oct, 2012 1 commit
  14. 26 Sep, 2012 1 commit
  15. 29 Mar, 2012 1 commit
    • Jason Wessel's avatar
      kgdb,debug_core: pass the breakpoint struct instead of address and memory · 98b54aa1
      Jason Wessel authored
      There is extra state information that needs to be exposed in the
      kgdb_bpt structure for tracking how a breakpoint was installed.  The
      debug_core only uses the the probe_kernel_write() to install
      breakpoints, but this is not enough for all the archs.  Some arch such
      as x86 need to use text_poke() in order to install a breakpoint into a
      read only page.
      Passing the kgdb_bpt structure to kgdb_arch_set_breakpoint() and
      kgdb_arch_remove_breakpoint() allows other archs to set the type
      variable which indicates how the breakpoint was installed.
      Cc: stable@vger.kernel.org # >= 2.6.36
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
  16. 28 Mar, 2012 1 commit
  17. 22 Mar, 2012 2 commits
  18. 26 Jul, 2011 1 commit
  19. 31 Mar, 2011 1 commit
  20. 29 Oct, 2010 1 commit
  21. 22 Oct, 2010 5 commits
    • Jason Wessel's avatar
      kdb,debug_core: adjust master cpu switch logic against new debug_core locking · 495363d3
      Jason Wessel authored
      The kdb shell needs to enforce switching back to the original CPU that
      took the exception before restoring normal kernel execution.  Resuming
      from a different CPU than what took the original exception will cause
      problems with spin locks that are freed from the a different processor
      than had taken the lock.
      The special logic in dbg_cpu_switch() can go away entirely with
      because the state of what cpus want to be masters or slaves will
      remain unchanged between entry and exit of the debug_core exception
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      debug_core: refactor locking for master/slave cpus · dfee3a7b
      Jason Wessel authored
      For quite some time there have been problems with memory barriers and
      various races with NMI on multi processor systems using the kernel
      debugger.  The algorithm for entering the kernel debug core and
      resuming kernel execution was racy and had several known edge case
      problems with attempting to debug something on a heavily loaded system
      using breakpoints that are hit repeatedly and quickly.
      The prior "locking" design entry worked as follows:
        * The atomic counter kgdb_active was used with atomic exchange in
          order to elect a master cpu out of all the cpus that may have
          taken a debug exception.
        * The master cpu increments all elements of passive_cpu_wait[].
        * The master cpu issues the round up cpus message.
        * Each "slave cpu" that enters the debug core increments its own
          element in cpu_in_kgdb[].
        * Each "slave cpu" spins on passive_cpu_wait[] until it becomes 0.
        * The master cpu debugs the system.
      The new scheme removes the two arrays of atomic counters and replaces
      them with 2 single counters.  One counter is used to count the number
      of cpus waiting to become a master cpu (because one or more hit an
      exception). The second counter is use to indicate how many cpus have
      entered as slave cpus.
      The new entry logic works as follows:
        * One or more cpus enters via kgdb_handle_exception() and increments
          the masters_in_kgdb. Each cpu attempts to get the spin lock called
        * The master cpu sets kgdb_active to the current cpu.
        * The master cpu takes the spinlock dbg_slave_lock.
        * The master cpu asks to round up all the other cpus.
        * Each slave cpu that is not already in kgdb_handle_exception()
          will enter and increment slaves_in_kgdb.  Each slave will now spin
          try_locking on dbg_slave_lock.
        * The master cpu waits for the sum of masters_in_kgdb and slaves_in_kgdb
          to be equal to the sum of the online cpus.
        * The master cpu debugs the system.
      In the new design the kgdb_active can only be changed while holding
      dbg_master_lock.  Stress testing has not turned up any further
      entry/exit races that existed in the prior locking design.  The prior
      locking design suffered from atomic variables not being truly atomic
      (in the capacity as used by kgdb) along with memory barrier races.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Acked-by: default avatarDongdong Deng <dongdong.deng@windriver.com>
    • Dongdong Deng's avatar
      debug_core: disable hw_breakpoints on all cores in kgdb_cpu_enter() · c1bb9a9c
      Dongdong Deng authored
      The slave cpus do not have the hw breakpoints disabled upon entry to
      the debug_core and as a result could cause unrecoverable recursive
      faults on badly placed breakpoints, or get out of sync with the arch
      specific hw breakpoint operations.
      This patch addresses the problem by invoking kgdb_disable_hw_debug()
      earlier in kgdb_enter_cpu for each cpu that enters the debug core.
      The hw breakpoint dis/enable flow should be:
      master_debug_cpu   slave_debug_cpu
               \              /
              kgdb_disable_hw_debug --> uninstall pre-enabled hw_breakpoint
       do add/rm dis/enable operates to hw_breakpoints on master_debug_cpu..
              correct_hw_break --> correct/install the enabled hw_breakpoint
      Signed-off-by: default avatarDongdong Deng <dongdong.deng@windriver.com>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      debug_core: stop rcu warnings on kernel resume · fb70b588
      Jason Wessel authored
      When returning from the kernel debugger reset the rcu jiffies_stall
      value to prevent the rcu stall detector from sending NMI events which
      invoke a stack dump for each cpu in the system.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      debug_core: move all watch dog syncs to a single function · 16cdc628
      Jason Wessel authored
      Move the various clock and watch dog syncs to a single function in
      advance of adding another sync for the rcu stall detector.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
  22. 20 Aug, 2010 1 commit
  23. 05 Aug, 2010 1 commit
  24. 22 Jul, 2010 1 commit
  25. 19 Jul, 2010 1 commit
  26. 21 May, 2010 7 commits
    • Jason Wessel's avatar
      x86, kgdb, init: Add early and late debug states · 0b4b3827
      Jason Wessel authored
      The kernel debugger can operate well before mm_init(), but the x86
      hardware breakpoint code which uses the perf api requires that the
      kernel allocators are initialized.
      This means the kernel debug core needs to provide an optional arch
      specific call back to allow the initialization functions to run after
      the kernel has been further initialized.
      The kdb shell already had a similar restriction with an early
      initialization and late initialization.  The kdb_init() was moved into
      the debug core's version of the late init which is called
      CC: kgdb-bugreport@lists.sourceforge.net
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      kdb,debug_core: Allow the debug core to receive a panic notification · 4402c153
      Jason Wessel authored
      It is highly desirable to trap into kdb on panic.  The debug core will
      attempt to register as the first in line for the panic notifier.
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      debug_core,kdb: Allow the debug core to process a recursive debug entry · 6d906340
      Jason Wessel authored
      This allows kdb to debug a crash with in the kms code with a
      single level recursive re-entry.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      kgdb: Add the ability to schedule a breakpoint via a tasklet · 1cee5e35
      Jason Wessel authored
      Some kgdb I/O modules require the ability to create a breakpoint
      tasklet, such as kgdboc and external modules such as kgdboe.  The
      breakpoint tasklet is used as an asynchronous entry point into the
      debugger which will have a different function scope than the current
      execution path where it might not be safe to have an inline
      breakpoint.  This is true of some of the kgdb I/O drivers which share
      code with kgdb and rest of the kernel users.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      x86,kgdb: Add low level debug hook · f503b5ae
      Jason Wessel authored
      The only way the debugger can handle a trap in inside rcu_lock,
      notify_die, or atomic_notifier_call_chain without a triple fault is
      to have a low level "first opportunity handler" in the int3 exception
      Generally this will be something the vast majority of folks will not
      need, but for those who need it, it is added as a kernel .config
      option called KGDB_LOW_LEVEL_TRAP.
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: H. Peter Anvin <hpa@zytor.com>
      CC: x86@kernel.org
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      kgdb: remove post_primary_code references · 98ec1878
      Jason Wessel authored
      Remove all the references to the kgdb_post_primary_code.  This
      function serves no useful purpose because you can obtain the same
      information from the "struct kgdb_state *ks" from with in the
      debugger, if for some reason you want the data.
      Also remove the unintentional duplicate assignment for ks->ex_vector.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
    • Jason Wessel's avatar
      kgdb: gdb "monitor" -> kdb passthrough · a0de055c
      Jason Wessel authored
      One of the driving forces behind integrating another front end (kdb)
      to the debug core is to allow front end commands to be accessible via
      gdb's monitor command.  It is true that you could write gdb macros to
      get certain data, but you may want to just use gdb to access the
      commands that are available in the kdb front end.
      This patch implements the Rcmd gdb stub packet.  In gdb you access
      this with the "monitor" command.  For instance you could type "monitor
      help", "monitor lsmod" or "monitor ps A" etc...
      There is no error checking or command restrictions on what you can and
      cannot access at this point.  Doing something like trying to set
      breakpoints with the monitor command is going to cause nothing but
      problems.  Perhaps in the future only the commands that are actually
      known to work with the gdb monitor command will be available.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>