22 Feb, 2016

1 commit

  • It may be useful to debug writes to the readonly sections of memory,
    so provide a cmdline "rodata=off" to allow for this. This can be
    expanded in the future to support "log" and "write" modes, but that
    will need to be architecture-specific.

    This also makes KDB software breakpoints more usable, as read-only
    mappings can now be disabled on any kernel.

    Suggested-by: H. Peter Anvin
    Signed-off-by: Kees Cook
    Cc: Andy Lutomirski
    Cc: Arnd Bergmann
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: David Brown
    Cc: Denys Vlasenko
    Cc: Emese Revfy
    Cc: Linus Torvalds
    Cc: Mathias Krause
    Cc: Michael Ellerman
    Cc: PaX Team
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: kernel-hardening@lists.openwall.com
    Cc: linux-arch
    Link: http://lkml.kernel.org/r/1455748879-21872-3-git-send-email-keescook@chromium.org
    Signed-off-by: Ingo Molnar

    Kees Cook
     

05 Dec, 2015

1 commit

  • Makes it easier to handle init vs core cleanly, though the change is
    fairly invasive across random architectures.

    It simplifies the rbtree code immediately, however, while keeping the
    core data together in the same cachline (now iff the rbtree code is
    enabled).

    Acked-by: Peter Zijlstra
    Reviewed-by: Josh Poimboeuf
    Signed-off-by: Rusty Russell
    Signed-off-by: Jiri Kosina

    Rusty Russell
     

20 Feb, 2015

8 commits

  • 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
    Cc: kgdb-bugreport@lists.sourceforge.net
    Cc: linux-kernel@vger.kernel.org
    Cc: Android Kernel Team
    Cc: John Stultz
    Cc: Sumit Semwal
    Signed-off-by: Colin Cross
    [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: Kiran Raparthy
    Signed-off-by: Daniel Thompson
    Signed-off-by: Jason Wessel

    Colin Cross
     
  • All current callers of kdb_getstr() can pass constant pointers via the
    prompt argument. This patch adds a const qualification to make explicit
    the fact that this is safe.

    Signed-off-by: Daniel Thompson
    Signed-off-by: Jason Wessel

    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: Daniel Thompson
    Signed-off-by: Jason Wessel

    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: Daniel Thompson
    Signed-off-by: Jason Wessel

    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: Daniel Thompson
    Signed-off-by: Jason Wessel

    Daniel Thompson
     
  • Currently when kdb traps printk messages then the raw log level prefix
    (consisting of '\001' followed by a numeral) does not get stripped off
    before the message is issued to the various I/O handlers supported by
    kdb. This causes annoying visual noise as well as causing problems
    grepping for ^. It is also a change of behaviour compared to normal usage
    of printk() usage. For example -h ends up with different output to
    that of kdb's "sr h".

    This patch addresses the problem by stripping log levels from messages
    before they are issued to the I/O handlers. printk() which can also
    act as an i/o handler in some cases is special cased; if the caller
    provided a log level then the prefix will be preserved when sent to
    printk().

    The addition of non-printable characters to the output of kdb commands is a
    regression, albeit and extremely elderly one, introduced by commit
    04d2c8c83d0e ("printk: convert the format for KERN_ to a 2 byte
    pattern"). Note also that this patch does *not* restore the original
    behaviour from v3.5. Instead it makes printk() from within a kdb command
    display the message without any prefix (i.e. like printk() normally does).

    Signed-off-by: Daniel Thompson
    Cc: Joe Perches
    Cc: stable@vger.kernel.org
    Signed-off-by: Jason Wessel

    Daniel Thompson
     
  • 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
    Cc:
    Signed-off-by: Jason Wessel

    Jason Wessel
     
  • 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: Jay Lan
    Cc:
    Signed-off-by: Jason Wessel

    Jay Lan
     

23 Jan, 2015

1 commit

  • Pull module and param fixes from Rusty Russell:
    "Surprising number of fixes this merge window :(

    The first two are minor fallout from the param rework which went in
    this merge window.

    The next three are a series which fixes a longstanding (but never
    previously reported and unlikely , so no CC stable) race between
    kallsyms and freeing the init section.

    Finally, a minor cleanup as our module refcount will now be -1 during
    unload"

    * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
    module: make module_refcount() a signed integer.
    module: fix race in kallsyms resolution during module load success.
    module: remove mod arg from module_free, rename module_memfree().
    module_arch_freeing_init(): new hook for archs before module->module_init freed.
    param: fix uninitialized read with CONFIG_DEBUG_LOCK_ALLOC
    param: initialize store function to NULL if not available.

    Linus Torvalds
     

22 Jan, 2015

1 commit

  • James Bottomley points out that it will be -1 during unload. It's
    only used for diagnostics, so let's not hide that as it could be a
    clue as to what's gone wrong.

    Cc: Jason Wessel
    Acked-and-documention-added-by: James Bottomley
    Reviewed-by: Masami Hiramatsu
    Signed-off-by: Rusty Russell

    Rusty Russell
     

11 Nov, 2014

10 commits

  • -Convert printk( to pr_foo()
    -Add pr_fmt
    -Coalesce formats

    Cc: Jason Wessel
    Cc: Andrew Morton
    Cc: Joe Perches
    Signed-off-by: Fabian Frederick
    Signed-off-by: Jason Wessel

    Fabian Frederick
     
  • Currently if an active CPU fails to respond to a roundup request the CPU
    that requested the roundup will become stuck. This needlessly reduces the
    robustness of the debugger.

    This patch introduces a timeout allowing the system state to be examined
    even when the system contains unresponsive processors. It also modifies
    kdb's cpu command to make it censor attempts to switch to unresponsive
    processors and to report their state as (D)ead.

    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Andrew Morton
    Signed-off-by: Jason Wessel

    Daniel Thompson
     
  • Currently kiosk mode must be explicitly requested by the bootloader or
    userspace. It is convenient to be able to change the default value in a
    similar manner to CONFIG_MAGIC_SYSRQ_DEFAULT_MASK.

    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Jason Wessel

    Daniel Thompson
     
  • Currently all kdb commands are enabled whenever kdb is deployed. This
    makes it difficult to deploy kdb to help debug certain types of
    systems.

    Android phones provide one example; the FIQ debugger found on some
    Android devices has a deliberately weak set of commands to allow the
    debugger to enabled very late in the production cycle.

    Certain kiosk environments offer another interesting case where an
    engineer might wish to probe the system state using passive inspection
    commands without providing sufficient power for a passer by to root it.

    Without any restrictions, obtaining the root rights via KDB is a matter of
    a few commands, and works everywhere. For example, log in as a normal
    user:

    cbou:~$ id
    uid=1001(cbou) gid=1001(cbou) groups=1001(cbou)

    Now enter KDB (for example via sysrq):

    Entering kdb (current=0xffff8800065bc740, pid 920) due to Keyboard Entry
    kdb> ps
    23 sleeping system daemon (state M) processes suppressed,
    use 'ps A' to see all.
    Task Addr Pid Parent [*] cpu State Thread Command
    0xffff8800065bc740 920 919 1 0 R 0xffff8800065bca20 *bash

    0xffff880007078000 1 0 0 0 S 0xffff8800070782e0 init
    [...snip...]
    0xffff8800065be3c0 918 1 0 0 S 0xffff8800065be6a0 getty
    0xffff8800065b9c80 919 1 0 0 S 0xffff8800065b9f60 login
    0xffff8800065bc740 920 919 1 0 R 0xffff8800065bca20 *bash

    All we need is the offset of cred pointers. We can look up the offset in
    the distro's kernel source, but it is unnecessary. We can just start
    dumping init's task_struct, until we see the process name:

    kdb> md 0xffff880007078000
    0xffff880007078000 0000000000000001 ffff88000703c000 ................
    0xffff880007078010 0040210000000002 0000000000000000 .....!@.........
    [...snip...]
    0xffff8800070782b0 ffff8800073e0580 ffff8800073e0580 ..>.......>.....
    0xffff8800070782c0 0000000074696e69 0000000000000000 init............

    ^ Here, 'init'. Creds are just above it, so the offset is 0x02b0.

    Now we set up init's creds for our non-privileged shell:

    kdb> mm 0xffff8800065bc740+0x02b0 0xffff8800073e0580
    0xffff8800065bc9f0 = 0xffff8800073e0580
    kdb> mm 0xffff8800065bc740+0x02b8 0xffff8800073e0580
    0xffff8800065bc9f8 = 0xffff8800073e0580

    And thus gaining the root:

    kdb> go
    cbou:~$ id
    uid=0(root) gid=0(root) groups=0(root)
    cbou:~$ bash
    root:~#

    p.s. No distro enables kdb by default (although, with a nice KDB-over-KMS
    feature availability, I would expect at least some would enable it), so
    it's not actually some kind of a major issue.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: John Stultz
    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Jason Wessel

    Anton Vorontsov
     
  • This patch introduces several new flags to collect kdb commands into
    groups (later allowing them to be optionally disabled).

    This follows similar prior art to enable/disable magic sysrq
    commands.

    The commands have been categorized as follows:

    Always on: go (w/o args), env, set, help, ?, cpu (w/o args), sr,
    dmesg, disable_nmi, defcmd, summary, grephelp
    Mem read: md, mdr, mdp, mds, ef, bt (with args), per_cpu
    Mem write: mm
    Reg read: rd
    Reg write: go (with args), rm
    Inspect: bt (w/o args), btp, bta, btc, btt, ps, pid, lsmod
    Flow ctrl: bp, bl, bph, bc, be, bd, ss
    Signal: kill
    Reboot: reboot
    All: cpu, kgdb, (and all of the above), nmi_console

    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Jason Wessel

    Daniel Thompson
     
  • Since we now treat KDB_REPEAT_* as flags, there is no need to
    pass KDB_REPEAT_NONE. It's just the default behaviour when no
    flags are specified.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: John Stultz
    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Jason Wessel

    Anton Vorontsov
     
  • The actual values of KDB_REPEAT_* enum values and overall logic stayed
    the same, but we now treat the values as flags.

    This makes it possible to add other flags and combine them, plus makes
    the code a lot simpler and shorter. But functionality-wise, there should
    be no changes.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: John Stultz
    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Jason Wessel

    Anton Vorontsov
     
  • We're about to add more options for commands behaviour, so let's give
    a more generic name to the low-level kdb command registration function.

    There are just various renames, no functional changes.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: John Stultz
    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Jason Wessel

    Anton Vorontsov
     
  • We're about to add more options for command behaviour, so let's expand
    the meaning of kdb_repeat_t.

    So far we just do various renames, there should be no functional changes.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: John Stultz
    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Jason Wessel

    Anton Vorontsov
     
  • The struct member is never used in the code, so we can remove it.

    We will introduce real flags soon by renaming cmd_repeat to cmd_flags.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: John Stultz
    Signed-off-by: Daniel Thompson
    Cc: Jason Wessel
    Signed-off-by: Jason Wessel

    Anton Vorontsov
     

14 Oct, 2014

1 commit

  • The kernel used to contain two functions for length-delimited,
    case-insensitive string comparison, strnicmp with correct semantics and
    a slightly buggy strncasecmp. The latter is the POSIX name, so strnicmp
    was renamed to strncasecmp, and strnicmp made into a wrapper for the new
    strncasecmp to avoid breaking existing users.

    To allow the compat wrapper strnicmp to be removed at some point in the
    future, and to avoid the extra indirection cost, do
    s/strnicmp/strncasecmp/g.

    Signed-off-by: Rasmus Villemoes
    Cc: Jason Wessel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rasmus Villemoes
     

12 Jun, 2014

1 commit

  • do_posix_clock_monotonic_gettime() is a leftover from the initial
    posix timer implementation which maps to ktime_get_ts().

    Signed-off-by: Thomas Gleixner
    Cc: John Stultz
    Cc: Peter Zijlstra
    Cc: Jason Wessel
    Link: http://lkml.kernel.org/r/20140611234607.261629142@linutronix.de
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

05 Jun, 2014

1 commit

  • ... instead of naked numbers.

    Stuff in sysrq.c used to set it to 8 which is supposed to mean above
    default level so set it to DEBUG instead as we're terminating/killing all
    tasks and we want to be verbose there.

    Also, correct the check in x86_64_start_kernel which should be >= as
    we're clearly issuing the string there for all debug levels, not only
    the magical 10.

    Signed-off-by: Borislav Petkov
    Acked-by: Kees Cook
    Acked-by: Randy Dunlap
    Cc: Joe Perches
    Cc: Valdis Kletnieks
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Borislav Petkov
     

18 Apr, 2014

1 commit

  • Mostly scripted conversion of the smp_mb__* barriers.

    Signed-off-by: Peter Zijlstra
    Acked-by: Paul E. McKenney
    Link: http://lkml.kernel.org/n/tip-55dhyhocezdw1dg7u19hmh1u@git.kernel.org
    Cc: Linus Torvalds
    Cc: linux-arch@vger.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

08 Apr, 2014

1 commit

  • 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: Davidlohr Bueso
    Reviewed-by: Rik van Riel
    Acked-by: Linus Torvalds
    Reviewed-by: Michel Lespinasse
    Cc: Oleg Nesterov
    Tested-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     

26 Feb, 2014

1 commit

  • The function kgdb_breakpoint() sets up break point at
    compile time by calling arch_kgdb_breakpoint();
    Though this call is surrounded by wmb() barrier,
    the compile can still re-order the break point,
    because this scheduling barrier is not a code motion
    barrier in gcc.

    Making kgdb_breakpoint() as noinline solves this problem
    of code reording around break point instruction and also
    avoids problem of being called as inline function from
    other places

    More details about discussion on this can be found here
    http://comments.gmane.org/gmane.linux.ports.arm.kernel/269732

    Signed-off-by: Vijaya Kumar K
    Acked-by: Will Deacon
    Acked-by: Jason Wessel
    Signed-off-by: Catalin Marinas

    Vijaya Kumar K
     

25 Jan, 2014

1 commit

  • Some code added to the debug_core module had KDB dependencies
    that it shouldn't have. Move the KDB dependent REASON back to
    the caller to remove the dependency in the debug core code.

    Update the call from the UV NMI handler to conform to the new
    interface.

    Signed-off-by: Mike Travis
    Reviewed-by: Hedi Berriche
    Cc: Russ Anderson
    Cc: Jason Wessel
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    Cc: Arnaldo Carvalho de Melo
    Link: http://lkml.kernel.org/r/20140114162551.318251993@asylum.americas.sgi.com
    Signed-off-by: Ingo Molnar

    Mike Travis
     

04 Oct, 2013

1 commit

  • This patch adds a kgdb_nmicallin() interface that can be used by
    external NMI handlers to call the KGDB/KDB handler. The primary
    need for this is for those types of NMI interrupts where all the
    CPUs have already received the NMI signal. Therefore no
    send_IPI(NMI) is required, and in fact it will cause a 2nd
    unhandled NMI to occur. This generates the "Dazed and Confuzed"
    messages.

    Since all the CPUs are getting the NMI at roughly the same time,
    it's not guaranteed that the first CPU that hits the NMI handler
    will manage to enter KGDB and set the dbg_master_lock before the
    slaves start entering. The new argument "send_ready" was added
    for KGDB to signal the NMI handler to release the slave CPUs for
    entry into KGDB.

    Signed-off-by: Mike Travis
    Acked-by: Jason Wessel
    Reviewed-by: Dimitri Sivanich
    Reviewed-by: Hedi Berriche
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    Cc: Arnaldo Carvalho de Melo
    Link: http://lkml.kernel.org/r/20131002151417.928886849@asylum.americas.sgi.com
    Signed-off-by: Ingo Molnar

    Mike Travis
     

01 May, 2013

1 commit

  • Currently help message of /proc/sysrq-trigger highlight its upper-case
    characters, like below:

    SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
    memory-full-oom-kill(F) kill-all-tasks(I) ...

    this would confuse user trigger sysrq by upper-case character, which is
    inconsistent with the real lower-case character registed key.

    This inconsistent help message will also lead more confused when
    26 upper-case letters put into use in future.

    This patch fix kgdb sysrq key: "debug(g)"

    Signed-off-by: zhangwei(Jovi)
    Cc: Jason Wessel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    zhangwei(Jovi)
     

03 Mar, 2013

1 commit

  • Pull KGDB/KDB fixes and cleanups from Jason Wessel:
    "For a change we removed more code than we added. If people aren't
    using it we shouldn't be carrying it. :-)

    Cleanups:
    - Remove kdb ssb command - there is no in kernel disassembler to
    support it

    - Remove kdb ll command - Always caused a kernel oops and there were
    no bug reports so no one was using this command

    - Use kernel ARRAY_SIZE macro instead of array computations

    Fixes:
    - Stop oops in kdb if user executes kdb_defcmd with args

    - kdb help command truncated text

    - ppc64 support for kgdbts

    - Add missing kconfig option from original kdb port for dealing with
    catastrophic kernel crashes such that you can reboot automatically
    on continue from kdb"

    * tag 'for_linux-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb:
    kdb: Remove unhandled ssb command
    kdb: Prevent kernel oops with kdb_defcmd
    kdb: Remove the ll command
    kdb_main: fix help print
    kdb: Fix overlap in buffers with strcpy
    Fixed dead ifdef block by adding missing Kconfig option.
    kdb: Setup basic kdb state before invoking commands via kgdb
    kdb: use ARRAY_SIZE where possible
    kgdb/kgdbts: support ppc64
    kdb: A fix for kdb command table expansion

    Linus Torvalds
     

02 Mar, 2013

8 commits

  • 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: Vincent Stehlé
    Signed-off-by: Jason Wessel

    Vincent
     
  • 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: Jason Wessel

    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: Jason Wessel

    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 [] [ [] []
    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: Jason Wessel

    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: Maxime Villard
    Signed-off-by: Jason Wessel

    Jason Wessel
     
  • Although invasive kdb commands are not supported via kgdb, some useful
    non-invasive commands like bt* require basic kdb state to be setup before
    calling into the kdb code. Factor out some of this code and call it before
    and after executing kdb commands via kgdb.

    Signed-off-by: Matt Klein
    Signed-off-by: Jason Wessel

    Matt Klein
     
  • Signed-off-by: Sasha Levin
    Signed-off-by: Jason Wessel

    Sasha Levin
     
  • 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: John Blackwood
    Signed-off-by: Jason Wessel

    John Blackwood