24 Jan, 2018

1 commit

  • commit 883d50f56d263f70fd73c0d96b09eb36c34e9305 upstream.

    Since kernel 4.9, the thread_info has been moved into task_struct, no
    longer locates at the bottom of kernel stack.

    See commits c65eacbe290b ("sched/core: Allow putting thread_info into
    task_struct") and 15f4eae70d36 ("x86: Move thread_info into
    task_struct").

    Before fix:
    (gdb) set $current = $lx_current()
    (gdb) p $lx_thread_info($current)
    $1 = {flags = 1470918301}
    (gdb) p $current.thread_info
    $2 = {flags = 2147483648}

    After fix:
    (gdb) p $lx_thread_info($current)
    $1 = {flags = 2147483648}
    (gdb) p $current.thread_info
    $2 = {flags = 2147483648}

    Link: http://lkml.kernel.org/r/20180118210159.17223-1-imxikangjie@gmail.com
    Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct")
    Signed-off-by: Xi Kangjie
    Acked-by: Jan Kiszka
    Acked-by: Kieran Bingham
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Xi Kangjie
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

01 Sep, 2017

1 commit

  • Kbuild conventionally uses $(shell cd ... && /bin/pwd) idiom to get
    the absolute path of the directory because GNU Make 3.80, the minimal
    supported version at that time, did not support $(abspath ...) or
    $(realpath ...).

    Commit 37d69ee30808 ("docs: bump minimal GNU Make version to 3.81")
    dropped the GNU Make 3.80 support, so we are now allowed to use those
    make-builtin helpers.

    This conversion will provide better portability without relying on
    the pwd command or its location /bin/pwd.

    I am intentionally using $(realpath ...) instead $(abspath ...) in
    some places. The difference between the two is $(realpath ...)
    returns an empty string if the given path does not exist. It is
    convenient in places where we need to error-out if the makefile fails
    to create an output directory.

    Signed-off-by: Masahiro Yamada
    Acked-by: Thierry Reding

    Masahiro Yamada
     

13 Jul, 2017

3 commits

  • Use errors=replace because it is never desirable for lx-dmesg to fail on
    string decoding errors, not even if the log buffer is corrupt and we
    show incorrect info.

    The kernel will sometimes print utf8, for example the copyright symbol
    from jffs2. In order to make this work specify 'utf8' everywhere
    because python2 otherwise defaults to 'ascii'.

    In theory the second errors='replace' is not be required because
    everything that can be decoded as utf8 should also be encodable back to
    utf8. But it's better to be extra safe here. It's worth noting that
    this is definitely not true for encoding='ascii', unknown characters are
    replaced with U+FFFD REPLACEMENT CHARACTER and they fail to encode back
    to ascii.

    Link: http://lkml.kernel.org/r/acee067f3345954ed41efb77b80eebdc038619c6.1498481469.git.leonard.crestez@nxp.com
    Signed-off-by: Leonard Crestez
    Acked-by: Jan Kiszka
    Cc: Jason Wessel
    Cc: Kieran Bingham
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Leonard Crestez
     
  • In some cases it is possible for the str() conversion here to throw
    encoding errors because log_buf might not point to valid ascii. For
    example:

    (gdb) python print str(gdb.parse_and_eval("log_buf"))
    Traceback (most recent call last):
    File "", line 1, in
    UnicodeEncodeError: 'ascii' codec can't encode character u'\u0303' in
    position 24: ordinal not in range(128)

    Avoid this by explicitly casting to (void *) inside the gdb expression.

    Link: http://lkml.kernel.org/r/ba6f85dbb02ca980ebd0e2399b0649423399b565.1498481469.git.leonard.crestez@nxp.com
    Signed-off-by: Leonard Crestez
    Reviewed-by: Jan Kiszka
    Cc: Jason Wessel
    Cc: Kieran Bingham
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Leonard Crestez
     
  • lx-fdtdump dumps the flattened device tree passed to the kernel from the
    bootloader to the filename specified as the command argument. If no
    argument is provided it defaults to fdtdump.dtb. This then allows
    further post processing on the machine running GDB. The fdt header is
    also also printed in the GDB console. For example:

    (gdb) lx-fdtdump
    fdt_magic: 0xD00DFEED
    fdt_totalsize: 0xC108
    off_dt_struct: 0x38
    off_dt_strings: 0x3804
    off_mem_rsvmap: 0x28
    version: 17
    last_comp_version: 16
    Dumped fdt to fdtdump.dtb

    >fdtdump fdtdump.dtb | less

    This command is useful as the bootloader can often re-write parts of the
    device tree, and this can sometimes cause the kernel to not boot.

    Link: http://lkml.kernel.org/r/1481280065-5336-2-git-send-email-kbingham@kernel.org
    Signed-off-by: Peter Griffin
    Signed-off-by: Kieran Bingham
    Cc: Jason Wessel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Griffin
     

03 Jun, 2017

1 commit

  • lx-dmesg needs access to the log_buf symbol from printk.c.
    Unfortunately, the symbol log_buf also exists in BPF's verifier.c and
    hence gdb can pick one or the other. If it happens to pick BPF's
    log_buf, lx-dmesg doesn't work:

    (gdb) lx-dmesg
    Python Exception Cannot access memory at address 0x0:
    Error occurred in Python command: Cannot access memory at address 0x0
    (gdb) p log_buf
    $15 = 0x0

    Luckily, GDB has a way to deal with this, see
    https://sourceware.org/gdb/onlinedocs/gdb/Symbols.html

    (gdb) info variables ^log_buf$
    All variables matching regular expression "^log_buf$":

    File /kernel/bpf/verifier.c:
    static char *log_buf;

    File /kernel/printk/printk.c:
    static char *log_buf;
    (gdb) p 'verifier.c'::log_buf
    $1 = 0x0
    (gdb) p 'printk.c'::log_buf
    $2 = 0x811a6aa0 ""
    (gdb) p &log_buf
    $3 = (char **) 0x8120fe40
    (gdb) p &'verifier.c'::log_buf
    $4 = (char **) 0x8120fe40
    (gdb) p &'printk.c'::log_buf
    $5 = (char **) 0x8048b7d0

    By being explicit about the location of the symbol, we can make lx-dmesg
    work again. While at it, do the same for the other symbols we need from
    printk.c

    Link: http://lkml.kernel.org/r/20170526112222.3414-1-git@andred.net
    Signed-off-by: André Draszik
    Tested-by: Kieran Bingham
    Acked-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    André Draszik
     

15 Jul, 2016

5 commits

  • This reverts commit e127a73d41ac ("scripts/gdb: add a Radix Tree
    Parser")

    The python implementation of radix-tree was merged at the same time as
    the radix-tree system was heavily reworked from commit e9256efcc8e3
    ("radix-tree: introduce radix_tree_empty") to 3bcadd6fa6c4 ("radix-tree:
    free up the bottom bit of exceptional entries for reuse") and no longer
    functions, but also prevents other gdb scripts from loading.

    This functionality has not yet hit a release, so simply remove it for
    now

    Link: http://lkml.kernel.org/r/1467127337-11135-6-git-send-email-kieran@bingham.xyz
    Signed-off-by: Kieran Bingham
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • Python doesn't do automatic expansion of paths. In case one passes path
    of the from ~/foo/bar the gdb scripts won't automatically expand that
    and as a result the symbols files won't be loaded.

    Fix this by explicitly expanding all paths which begin with "~"

    Link: http://lkml.kernel.org/r/1467127337-11135-5-git-send-email-kieran@bingham.xyz
    Signed-off-by: Nikolay Borisov
    Signed-off-by: Kieran Bingham
    Reviewed-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nikolay Borisov
     
  • Since scripts/gdb/linux/constants.py is autogenerated, this should have
    been added to .gitignore when it was introduced.

    Fixes: f197d75fcad1 ("scripts/gdb: provide linux constants")
    Link: http://lkml.kernel.org/r/1467127337-11135-4-git-send-email-kieran@bingham.xyz
    Signed-off-by: Omar Sandoval
    Signed-off-by: Kieran Bingham
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Omar Sandoval
     
  • The autogenerated constants.py file was only being built on the initial
    call, and if the constants.py.in file changed. As we are utilising the
    CPP hooks, we can successfully use the call if_changed_dep rules to
    determine when to rebuild the file based on it's inclusions.

    Link: http://lkml.kernel.org/r/1467127337-11135-3-git-send-email-kieran@bingham.xyz
    Signed-off-by: Kieran Bingham
    Reported-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • The constants.py generation, involves a rule to link into the main
    makefile. This rule has no command and generates a spurious warning
    message in the build logs when CONFIG_SCRIPTS_GDB is enabled.

    Fix simply by giving a no-op action

    Link: http://lkml.kernel.org/r/1467127337-11135-2-git-send-email-kieran@bingham.xyz
    Signed-off-by: Kieran Bingham
    Reported-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     

24 May, 2016

16 commits

  • The recent fixes to lx-dmesg, now allow the command to print
    successfully on Python3, however the python interpreter wraps the bytes
    for each line with a b'' marker.

    To remove this, we need to decode the line, where .decode() will default
    to 'UTF-8'

    Link: http://lkml.kernel.org/r/d67ccf93f2479c94cb3399262b9b796e0dbefcf2.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Acked-by: Dom Cote
    Tested-by: Dom Cote
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • When built against Python 3, GDB differs in the return type for its
    read_memory function, causing the lx-dmesg command to fail.

    Now that we have an improved read_16() we can use the new
    read_memoryview() abstraction to make lx-dmesg return valid data on both
    current Python APIs

    Tested with python 3.4 and 2.7
    Tested with gdb 7.7

    Link: http://lkml.kernel.org/r/28477b727ff7fe3101fd4e426060e8a68317a639.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Dom Cote
    [kieran@bingham.xyz: Adjusted commit log to better reflect code changes]
    Tested-by: Kieran Bingham (Py2.7,Py3.4,GDB10)
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dom Cote
     
  • Change the read_u16 function so it accepts both 'str' and 'byte' as type
    for the arguments.

    When calling read_memory() from gdb API, depending on if it was built
    with 2.7 or 3.X, the format used to return the data will differ ( 'str'
    for 2.7, and 'byte' for 3.X ).

    Add a function read_memoryview() to be able to get a 'memoryview' object
    back from read_memory() both with python 2.7 and 3.X .

    Tested with python 3.4 and 2.7
    Tested with gdb 7.7

    Link: http://lkml.kernel.org/r/73621f564503137a002a639d174e4fb35f73f462.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Dom Cote
    Tested-by: Kieran Bingham (Py2.7,Py3.4,GDB10)
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dom Cote
     
  • The tasks module already provides helpers to find the task struct by
    pid, and the thread_info by task struct; however this is cumbersome to
    utilise on the gdb commandline.

    Wrap these two functionalities together in an extra single helper to
    allow exploring the thread info, from a PID value

    Link: http://lkml.kernel.org/r/dadc5667f053ec811eb3e3033d99d937fedbc93b.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • Linux makes use of the Radix Tree data structure to store pointers
    indexed by integer values. This structure is utilised across many
    structures in the kernel including the IRQ descriptor tables, and
    several filesystems.

    This module provides a method to lookup values from a structure given
    its head node.

    Usage:

    The function lx_radix_tree_lookup, must be given a symbol of type struct
    radix_tree_root, and an index into that tree.

    The object returned is a generic integer value, and must be cast
    correctly to the type based on the storage in the data structure.

    For example, to print the irq descriptor in the sparse irq_desc_tree at
    index 18, try the following:

    (gdb) print (struct irq_desc)$lx_radix_tree_lookup(irq_desc_tree, 18)

    Link: http://lkml.kernel.org/r/d2028c55e50cf95a9b7f8ca0d11885174b0cc709.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • We won't see more than 2 billion CPUs any time soon, and having cpu_list
    return long makes the output of lx-cpus a bit ugly.

    Link: http://lkml.kernel.org/r/dcb45c3b0a59e0fd321fa56ff7aa398458c689b3.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kiszka
     
  • The linux kernel provides macro's for iterating against values from the
    cpu_list masks. By providing some commonly used masks, we can mirror
    the kernels helper macros with easy to use generators.

    Link: http://lkml.kernel.org/r/d045c6599771ada1999d49612ee30fd2f9acf17f.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • lx-mounts will identify current mount points based on the 'init_task'
    namespace by default, as we do not yet have a kernel thread list
    implementation to select the current running thread.

    Optionally, a user can specify a PID to list from that process'
    namespace

    Link: http://lkml.kernel.org/r/e614c7bc32d2350b4ff1627ec761a7148e65bfe6.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • Provide iomem_resource and ioports_resource printers and command hooks

    It can be quite interesting to halt the kernel as it's booting and check
    to see this list as it is being populated.

    It should be useful in the event that a kernel is not booting, you can
    identify what memory resources have been registered

    Link: http://lkml.kernel.org/r/f0a6b9fa9c92af4d7ed2e7343ccc84150e9c6fc5.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • Walk the VFS entries, pre-pending the iname strings to generate a full
    VFS path name from a dentry.

    Link: http://lkml.kernel.org/r/4328fdb2d15ba7f1b21ad21c2eecc38d9cfc4d13.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • If CONFIG_MODULES is not enabled, lx-lsmod tries to find a non-existent
    symbol and generates an unfriendly traceback:

    (gdb) lx-lsmod
    Address Module Size Used by
    Traceback (most recent call last):
    File "scripts/gdb/linux/modules.py", line 75, in invoke
    for module in module_list():
    File "scripts/gdb/linux/modules.py", line 24, in module_list
    module_ptr_type = module_type.get_type().pointer()
    File "scripts/gdb/linux/utils.py", line 28, in get_type
    self._type = gdb.lookup_type(self._name)
    gdb.error: No struct type named module.
    Error occurred in Python command: No struct type named module.

    Catch the error and return an empty module_list() for a clean command
    output as follows:

    (gdb) lx-lsmod
    Address Module Size Used by
    (gdb)

    Link: http://lkml.kernel.org/r/94d533819437408b85ae5864f939dd7ca6fbfcd6.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • If we attempt to read a value that is not available to GDB, an exception
    is raised. Most of the time, this is a good thing; however on occasion
    we will want to be able to determine if a symbol is available.

    By catching the exception to simply return None, we can determine if we
    tried to read an invalid value, without the exception taking our
    execution context away from us

    Link: http://lkml.kernel.org/r/c72b25c06fc66e1d68371154097e2cbb112555d8.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • Simplify the module list functions with the new list_for_each_entry
    abstractions

    Link: http://lkml.kernel.org/r/ad0101c9391088608166fcec26af179868973d86.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • Facilitate linked-list items by providing a generator to return the
    dereferenced, and type-cast objects from a kernel linked list

    Link: http://lkml.kernel.org/r/2b0998564e6e5abe53585d466f87e491331fd2a4.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Cc: Jeff Mahoney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • Some macro's and defines are needed when parsing memory, and without
    compiling the kernel as -g3 they are not available in the debug-symbols.

    We use the pre-processor here to extract constants to a dedicated module
    for the linux debugger extensions

    Top level Kbuild is used to call in and generate the constants file,
    while maintaining dependencies on autogenerated files in
    include/generated

    Link: http://lkml.kernel.org/r/bc3df9c25f57ea72177c066a51a446fc19e2c27f.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Cc: Michal Marek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • This takes the MODULE_REF_BASE into account.

    Link: http://lkml.kernel.org/r/d926d2d54caa034adb964b52215090cbdb875249.1462865983.git.jan.kiszka@siemens.com
    Signed-off-by: Jan Kiszka
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kiszka
     

23 Mar, 2016

3 commits

  • Commit 7523e4dc5057 ("module: use a structure to encapsulate layout.")
    factored out the module_layout structure. Adjust the symbol loader and
    the lsmod command to this.

    Signed-off-by: Jan Kiszka
    Reviewed-by: Kieran Bingham
    Tested-by: Kieran Bingham (qemu-{ARM,x86})
    Cc: Rusty Russell
    Cc: Jiri Kosina
    Cc: Jason Wessel
    Cc: [4.4+]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kiszka
     
  • lx-cmdline Report the Linux Commandline used in the current kernel

    [jan.kiszka@siemens.com: remove blank line from help output and fix pep8 warning]
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Cc: Jason Wessel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     
  • lx-version Report the Linux Version of the current kernel.

    Add a command to identify the version specified by the banner in the
    debugged kernel.

    This lets the user identify the kernel of the running kernel, and will
    let later scripts compare the banner of the attached kernel against the
    banner in the vmlinux symbols files to verify that the files are
    correct.

    [jan.kiszka@siemens.com: remove blank line from help output and fix pep8 warning]
    Signed-off-by: Kieran Bingham
    Signed-off-by: Jan Kiszka
    Cc: Jason Wessel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kieran Bingham
     

01 Jul, 2015

7 commits


29 May, 2015

1 commit

  • Commit 2f35c41f58a9 ("module: Replace module_ref with atomic_t refcnt")
    changes the way refcnt is handled but did not update the gdb script to
    use the new variable.

    Since refcnt is not per-cpu anymore, we can directly read its value.

    Signed-off-by: Adrien Schildknecht
    Reviewed-by: Jan Kiszka
    Cc: Pantelis Koukousoulas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrien Schildknecht
     

01 Mar, 2015

1 commit