1. 01 2月, 2018 1 次提交
  2. 25 1月, 2018 3 次提交
    • R
      kdb: drop newline in unknown command output · b0f73bc7
      Randy Dunlap 提交于
      When an unknown command is entered, kdb prints "Unknown kdb command:"
      and then the unknown text, including the newline character. This
      causes the ending single-quote mark to be printed on the next line
      by itself, so just change the ending newline character to a null
      character (end of string) so that it won't be "printed."
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: kgdb-bugreport@lists.sourceforge.net
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      b0f73bc7
    • R
      kdb: make "mdr" command repeat · 1e0ce03b
      Randy Dunlap 提交于
      The "mdr" command should repeat (continue) when only Enter/Return
      is pressed, so make it do so.
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: kgdb-bugreport@lists.sourceforge.net
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      1e0ce03b
    • A
      kdb: use __ktime_get_real_seconds instead of __current_kernel_time · 6909e29f
      Arnd Bergmann 提交于
      kdb is the only user of the __current_kernel_time() interface, which is
      not y2038 safe and should be removed at some point.
      
      The kdb code also goes to great lengths to print the time in a
      human-readable format from 'struct timespec', again using a non-y2038-safe
      re-implementation of the generic time_to_tm() code.
      
      Using __current_kernel_time() here is necessary since the regular
      accessors that require a sequence lock might hang when called during the
      xtime update. However, this is safe in the particular case since kdb is
      only interested in the tv_sec field that is updated atomically.
      
      In order to make this y2038-safe, I'm converting the code to the generic
      time64_to_tm helper, but that introduces the problem that we have no
      interface like __current_kernel_time() that provides a 64-bit timestamp
      in a lockless, safe and architecture-independent way. I have multiple
      ideas for how to solve that:
      
      - __ktime_get_real_seconds() is lockless, but can return
        incorrect results on 32-bit architectures in the special case that
        we are in the process of changing the time across the epoch, either
        during the timer tick that overflows the seconds in 2038, or while
        calling settimeofday.
      
      - ktime_get_real_fast_ns() would work in this context, but does
        require a call into the clocksource driver to return a high-resolution
        timestamp. This may have undesired side-effects in the debugger,
        since we want to limit the interactions with the rest of the kernel.
      
      - Adding a ktime_get_real_fast_seconds() based on tk_fast_mono
        plus tkr->base_real without the tk_clock_read() delta. Not sure about
        the value of adding yet another interface here.
      
      - Changing the existing ktime_get_real_seconds() to use
        tk_fast_mono on 32-bit architectures rather than xtime_sec.  I think
        this could work, but am not entirely sure if this is an improvement.
      
      I picked the first of those for simplicity here. It's technically
      not correct but probably good enough as the time is only used for the
      debugging output and the race will likely never be hit in practice.
      Another downside is having to move the declaration into a public header
      file.
      
      Let me know if anyone has a different preference.
      
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Link: https://patchwork.kernel.org/patch/9775309/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      6909e29f
  3. 04 1月, 2018 1 次提交
    • E
      signal: Simplify and fix kdb_send_sig · 0b44bf9a
      Eric W. Biederman 提交于
      - Rename from kdb_send_sig_info to kdb_send_sig
        As there is no meaningful siginfo sent
      
      - Use SEND_SIG_PRIV instead of generating a siginfo for a kdb
        signal.  The generated siginfo had a bogus rationale and was
        not correct in the face of pid namespaces.  SEND_SIG_PRIV
        is simpler and actually correct.
      
      - As the code grabs siglock just send the signal with siglock
        held instead of dropping siglock and attempting to grab it again.
      
      - Move the sig_valid test into kdb_kill where it can generate
        a good error message.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      0b44bf9a
  4. 02 3月, 2017 3 次提交
  5. 15 12月, 2016 1 次提交
  6. 05 12月, 2015 1 次提交
  7. 20 2月, 2015 5 次提交
    • D
      kdb: Provide forward search at more prompt · fb6daa75
      Daniel Thompson 提交于
      Currently kdb allows the output of comamnds to be filtered using the
      | grep feature. This is useful but does not permit the output emitted
      shortly after a string match to be examined without wading through the
      entire unfiltered output of the command. Such a feature is particularly
      useful to navigate function traces because these traces often have a
      useful trigger string *before* the point of interest.
      
      This patch reuses the existing filtering logic to introduce a simple
      forward search to kdb that can be triggered from the more prompt.
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      fb6daa75
    • D
      kdb: Fix a prompt management bug when using | grep · ab08e464
      Daniel Thompson 提交于
      Currently when the "| grep" feature is used to filter the output of a
      command then the prompt is not displayed for the subsequent command.
      Likewise any characters typed by the user are also not echoed to the
      display. This rather disconcerting problem eventually corrects itself
      when the user presses Enter and the kdb_grepping_flag is cleared as
      kdb_parse() tries to make sense of whatever they typed.
      
      This patch resolves the problem by moving the clearing of this flag
      from the middle of command processing to the beginning.
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      ab08e464
    • D
      kdb: Remove stack dump when entering kgdb due to NMI · 54543881
      Daniel Thompson 提交于
      Issuing a stack dump feels ergonomically wrong when entering due to NMI.
      
      Entering due to NMI is normally a reaction to a user request, either the
      NMI button on a server or a "magic knock" on a UART. Therefore the
      backtrace behaviour on entry due to NMI should be like SysRq-g (no stack
      dump) rather than like oops.
      
      Note also that the stack dump does not offer any information that
      cannot be trivial retrieved using the 'bt' command.
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      54543881
    • J
      kdb: Fix off by one error in kdb_cpu() · df0036d1
      Jason Wessel 提交于
      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: NJason Wessel <jason.wessel@windriver.com>
      df0036d1
    • J
      kdb: fix incorrect counts in KDB summary command output · 14675592
      Jay Lan 提交于
      The output of KDB 'summary' command should report MemTotal, MemFree
      and Buffers output in kB. Current codes report in unit of pages.
      
      A define of K(x) as
      is defined in the code, but not used.
      
      This patch would apply the define to convert the values to kB.
      Please include me on Cc on replies. I do not subscribe to linux-kernel.
      Signed-off-by: NJay Lan <jlan@sgi.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      14675592
  8. 22 1月, 2015 1 次提交
  9. 11 11月, 2014 9 次提交
  10. 12 6月, 2014 1 次提交
  11. 05 6月, 2014 1 次提交
  12. 04 10月, 2013 1 次提交
  13. 02 3月, 2013 7 次提交
    • V
      kdb: Remove unhandled ssb command · 36dfea42
      Vincent 提交于
      The 'ssb' command can only be handled when we have a disassembler, to check for
      branches, so remove the 'ssb' command for now.
      Signed-off-by: NVincent Stehlé <vincent.stehle@laposte.net>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      36dfea42
    • J
      kdb: Prevent kernel oops with kdb_defcmd · a37372f6
      Jason Wessel 提交于
      The kdb_defcmd can only be used to display the available command aliases
      while using the kernel debug shell.  If you try to define a new macro
      while the kernel debugger is active it will oops.  The debug shell
      macros must use pre-allocated memory set aside at the time kdb_init()
      is run, and the kdb_defcmd is restricted to only working at the time
      that the kdb_init sequence is being run, which only occurs if you
      actually activate the kernel debugger.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      a37372f6
    • J
      kdb: Remove the ll command · 1b2caa2d
      Jason Wessel 提交于
      Recently some code inspection was done after fixing a problem with
      kmalloc used while in the kernel debugger context (which is not
      legal), and it turned up the fact that kdb ll command will oops the
      kernel.
      
      Given that there have been zero bug reports on the command combined
      with the fact it will oops the kernel it is clearly not being used.
      Instead of fixing it, it will be removed.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      1b2caa2d
    • J
      kdb_main: fix help print · 074604af
      Jason Wessel 提交于
      The help command was chopping all the usage instructions such that
      they were not readable.
      
      Example:
      
      bta             [D|R|S|T|C|Z|E|U|I| Backtrace all processes matching state flag
      per_cpu         <sym> [<bytes>] [<c Display per_cpu variables
      
      Where as it should look like:
      
      bta             [D|R|S|T|C|Z|E|U|I|M|A]
                                          Backtrace all processes matching state flag
      per_cpu         <sym> [<bytes>] [<cpu>]
                                          Display per_cpu variables
      
      All that is needed is to check the how long the cmd_usage is and jump
      to the next line when appropriate.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      074604af
    • J
      kdb: Fix overlap in buffers with strcpy · 4eb7a66d
      Jason Wessel 提交于
      Maxime reported that strcpy(s->usage, s->usage+1) has no definitive
      guarantee that it will work on all archs the same way when you have
      overlapping memory.  The fix is simple for the kdb code because we
      still have the original string memory in the function scope, so we
      just have to use that as the argument instead.
      Reported-by: NMaxime Villard <rustyBSD@gmx.fr>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      4eb7a66d
    • S
      kdb: use ARRAY_SIZE where possible · 5f784f79
      Sasha Levin 提交于
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      5f784f79
    • J
      kdb: A fix for kdb command table expansion · f7c82d5a
      John Blackwood 提交于
      When locally adding in some additional kdb commands, I stumbled
      across an issue with the dynamic expansion of the kdb command table.
      When the number of kdb commands exceeds the size of the statically
      allocated kdb_base_commands[] array, additional space is allocated in
      the kdb_register_repeat() routine.
      
      The unused portion of the newly allocated array was not being initialized
      to zero properly and this would result in segfaults when help '?' was
      executed or when a search for a non-existing command would traverse the
      command table beyond the end of valid command entries and then attempt
      to use the non-zeroed area as actual command entries.
      Signed-off-by: NJohn Blackwood <john.blackwood@ccur.com>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      f7c82d5a
  14. 12 1月, 2013 1 次提交
  15. 12 10月, 2012 1 次提交
  16. 27 9月, 2012 1 次提交
  17. 31 7月, 2012 1 次提交
  18. 22 7月, 2012 1 次提交