Skip to content

L
linux
Commit 5512128f authored by Jonathan Corbet's avatar Jonathan Corbet
Browse files
Options

Merge branch 'dev-tools' into doc/4.9 

Coalesce development-tool documents into a single directory and sphinxify
them.
parents 44f4ddd1 5f096274
Expand all Show whitespace changes
Inline Side-by-side
Showing with 1567 additions and 325 deletions
Documentation/gdb-kernel-debugging.txt → Documentation/dev-tools/gdb-kernel-debugging.rst
View file @ 5512128f
.. highlight:: none
Debugging kernel and modules via gdb Debugging kernel and modules via gdb
==================================== ====================================
...@@ -13,54 +15,58 @@ be transferred to the other gdb stubs as well. ...@@ -13,54 +15,58 @@ be transferred to the other gdb stubs as well.
Requirements Requirements
------------ ------------
o gdb 7.2+ (recommended: 7.4+) with python support enabled (typically true - gdb 7.2+ (recommended: 7.4+) with python support enabled (typically true
for distributions) for distributions)
Setup Setup
----- -----
o Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and - Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and
www.qemu.org for more details). For cross-development, www.qemu.org for more details). For cross-development,
http://landley.net/aboriginal/bin keeps a pool of machine images and http://landley.net/aboriginal/bin keeps a pool of machine images and
toolchains that can be helpful to start from. toolchains that can be helpful to start from.
o Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave - Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave
CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
CONFIG_FRAME_POINTER, keep it enabled. CONFIG_FRAME_POINTER, keep it enabled.
o Install that kernel on the guest. - Install that kernel on the guest.
Alternatively, QEMU allows to boot the kernel directly using -kernel, Alternatively, QEMU allows to boot the kernel directly using -kernel,
-append, -initrd command line switches. This is generally only useful if -append, -initrd command line switches. This is generally only useful if
you do not depend on modules. See QEMU documentation for more details on you do not depend on modules. See QEMU documentation for more details on
this mode. this mode.
o Enable the gdb stub of QEMU/KVM, either - Enable the gdb stub of QEMU/KVM, either
- at VM startup time by appending "-s" to the QEMU command line - at VM startup time by appending "-s" to the QEMU command line
or or
- during runtime by issuing "gdbserver" from the QEMU monitor - during runtime by issuing "gdbserver" from the QEMU monitor
console console
o cd /path/to/linux-build - cd /path/to/linux-build
o Start gdb: gdb vmlinux - Start gdb: gdb vmlinux
Note: Some distros may restrict auto-loading of gdb scripts to known safe Note: Some distros may restrict auto-loading of gdb scripts to known safe
directories. In case gdb reports to refuse loading vmlinux-gdb.py, add directories. In case gdb reports to refuse loading vmlinux-gdb.py, add::
add-auto-load-safe-path /path/to/linux-build add-auto-load-safe-path /path/to/linux-build
to ~/.gdbinit. See gdb help for more details. to ~/.gdbinit. See gdb help for more details.
o Attach to the booted guest: - Attach to the booted guest::
(gdb) target remote :1234 (gdb) target remote :1234
Examples of using the Linux-provided gdb helpers Examples of using the Linux-provided gdb helpers
------------------------------------------------ ------------------------------------------------
o Load module (and main kernel) symbols: - Load module (and main kernel) symbols::
(gdb) lx-symbols (gdb) lx-symbols
loading vmlinux loading vmlinux
scanning for modules in /home/user/linux/build scanning for modules in /home/user/linux/build
...@@ -72,17 +78,20 @@ Examples of using the Linux-provided gdb helpers ...@@ -72,17 +78,20 @@ Examples of using the Linux-provided gdb helpers
... ...
loading @0xffffffffa0000000: /home/user/linux/build/drivers/ata/ata_generic.ko loading @0xffffffffa0000000: /home/user/linux/build/drivers/ata/ata_generic.ko
o Set a breakpoint on some not yet loaded module function, e.g.: - Set a breakpoint on some not yet loaded module function, e.g.::
(gdb) b btrfs_init_sysfs (gdb) b btrfs_init_sysfs
Function "btrfs_init_sysfs" not defined. Function "btrfs_init_sysfs" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (btrfs_init_sysfs) pending. Breakpoint 1 (btrfs_init_sysfs) pending.
o Continue the target - Continue the target::
(gdb) c (gdb) c
o Load the module on the target and watch the symbols being loaded as well as - Load the module on the target and watch the symbols being loaded as well as
the breakpoint hit: the breakpoint hit::
loading @0xffffffffa0034000: /home/user/linux/build/lib/libcrc32c.ko loading @0xffffffffa0034000: /home/user/linux/build/lib/libcrc32c.ko
loading @0xffffffffa0050000: /home/user/linux/build/lib/lzo/lzo_compress.ko loading @0xffffffffa0050000: /home/user/linux/build/lib/lzo/lzo_compress.ko
loading @0xffffffffa006e000: /home/user/linux/build/lib/zlib_deflate/zlib_deflate.ko loading @0xffffffffa006e000: /home/user/linux/build/lib/zlib_deflate/zlib_deflate.ko
...@@ -91,7 +100,8 @@ Examples of using the Linux-provided gdb helpers ...@@ -91,7 +100,8 @@ Examples of using the Linux-provided gdb helpers
Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36 Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36
36 btrfs_kset = kset_create_and_add("btrfs", NULL, fs_kobj); 36 btrfs_kset = kset_create_and_add("btrfs", NULL, fs_kobj);
o Dump the log buffer of the target kernel: - Dump the log buffer of the target kernel::
(gdb) lx-dmesg (gdb) lx-dmesg
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpu
...@@ -102,19 +112,22 @@ Examples of using the Linux-provided gdb helpers ...@@ -102,19 +112,22 @@ Examples of using the Linux-provided gdb helpers
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
.... ....
o Examine fields of the current task struct: - Examine fields of the current task struct::
(gdb) p $lx_current().pid (gdb) p $lx_current().pid
$1 = 4998 $1 = 4998
(gdb) p $lx_current().comm (gdb) p $lx_current().comm
$2 = "modprobe\000\000\000\000\000\000\000" $2 = "modprobe\000\000\000\000\000\000\000"
o Make use of the per-cpu function for the current or a specified CPU: - Make use of the per-cpu function for the current or a specified CPU::
(gdb) p $lx_per_cpu("runqueues").nr_running (gdb) p $lx_per_cpu("runqueues").nr_running
$3 = 1 $3 = 1
(gdb) p $lx_per_cpu("runqueues", 2).nr_running (gdb) p $lx_per_cpu("runqueues", 2).nr_running
$4 = 0 $4 = 0
o Dig into hrtimers using the container_of helper: - Dig into hrtimers using the container_of helper::
(gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next (gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next
(gdb) p *$container_of($next, "struct hrtimer", "node") (gdb) p *$container_of($next, "struct hrtimer", "node")
$5 = { $5 = {
...@@ -144,7 +157,7 @@ List of commands and functions ...@@ -144,7 +157,7 @@ List of commands and functions
------------------------------ ------------------------------
The number of commands and convenience functions may evolve over the time, The number of commands and convenience functions may evolve over the time,
this is just a snapshot of the initial version: this is just a snapshot of the initial version::
(gdb) apropos lx (gdb) apropos lx
function lx_current -- Return current task function lx_current -- Return current task
......
Documentation/kasan.txt → Documentation/dev-tools/kasan.rst
View file @ 5512128f
KernelAddressSanitizer (KASAN) The Kernel Address Sanitizer (KASAN)
============================== ====================================
0. Overview Overview
=========== --------
KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides
a fast and comprehensive solution for finding use-after-free and out-of-bounds a fast and comprehensive solution for finding use-after-free and out-of-bounds
...@@ -12,12 +12,12 @@ KASAN uses compile-time instrumentation for checking every memory access, ...@@ -12,12 +12,12 @@ KASAN uses compile-time instrumentation for checking every memory access,
therefore you will need a GCC version 4.9.2 or later. GCC 5.0 or later is therefore you will need a GCC version 4.9.2 or later. GCC 5.0 or later is
required for detection of out-of-bounds accesses to stack or global variables. required for detection of out-of-bounds accesses to stack or global variables.
Currently KASAN is supported only for x86_64 and arm64 architecture. Currently KASAN is supported only for the x86_64 and arm64 architectures.
1. Usage Usage
======== -----
To enable KASAN configure kernel with: To enable KASAN configure kernel with::
CONFIG_KASAN = y CONFIG_KASAN = y
...@@ -32,26 +32,28 @@ For better bug detection and nicer reporting, enable CONFIG_STACKTRACE. ...@@ -32,26 +32,28 @@ For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
To disable instrumentation for specific files or directories, add a line To disable instrumentation for specific files or directories, add a line
similar to the following to the respective kernel Makefile: similar to the following to the respective kernel Makefile:
For a single file (e.g. main.o): - For a single file (e.g. main.o)::
KASAN_SANITIZE_main.o := n KASAN_SANITIZE_main.o := n
For all files in one directory: - For all files in one directory::
KASAN_SANITIZE := n KASAN_SANITIZE := n
1.1 Error reports Error reports
================= ~~~~~~~~~~~~~
A typical out of bounds access report looks like this: A typical out of bounds access report looks like this::
================================================================== ==================================================================
BUG: AddressSanitizer: out of bounds access in kmalloc_oob_right+0x65/0x75 [test_kasan] at addr ffff8800693bc5d3 BUG: AddressSanitizer: out of bounds access in kmalloc_oob_right+0x65/0x75 [test_kasan] at addr ffff8800693bc5d3
Write of size 1 by task modprobe/1689 Write of size 1 by task modprobe/1689
============================================================================= =============================================================================
BUG kmalloc-128 (Not tainted): kasan error BUG kmalloc-128 (Not tainted): kasan error
----------------------------------------------------------------------------- -----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint Disabling lock debugging due to kernel taint
INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689 INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689
__slab_alloc+0x4b4/0x4f0 __slab_alloc+0x4b4/0x4f0
kmem_cache_alloc_trace+0x10b/0x190 kmem_cache_alloc_trace+0x10b/0x190
kmalloc_oob_right+0x3d/0x75 [test_kasan] kmalloc_oob_right+0x3d/0x75 [test_kasan]
...@@ -60,26 +62,26 @@ INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689 ...@@ -60,26 +62,26 @@ INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689
load_module+0x2cb3/0x3b20 load_module+0x2cb3/0x3b20
SyS_finit_module+0x76/0x80 SyS_finit_module+0x76/0x80
system_call_fastpath+0x12/0x17 system_call_fastpath+0x12/0x17
INFO: Slab 0xffffea0001a4ef00 objects=17 used=7 fp=0xffff8800693bd728 flags=0x100000000004080 INFO: Slab 0xffffea0001a4ef00 objects=17 used=7 fp=0xffff8800693bd728 flags=0x100000000004080
INFO: Object 0xffff8800693bc558 @offset=1368 fp=0xffff8800693bc720 INFO: Object 0xffff8800693bc558 @offset=1368 fp=0xffff8800693bc720
Bytes b4 ffff8800693bc548: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ Bytes b4 ffff8800693bc548: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
Object ffff8800693bc558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8800693bc558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800693bc568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8800693bc568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800693bc578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8800693bc578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800693bc588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8800693bc588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800693bc598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8800693bc598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800693bc5a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8800693bc5a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800693bc5b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8800693bc5b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800693bc5c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk. Object ffff8800693bc5c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Redzone ffff8800693bc5d8: cc cc cc cc cc cc cc cc ........ Redzone ffff8800693bc5d8: cc cc cc cc cc cc cc cc ........
Padding ffff8800693bc718: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Padding ffff8800693bc718: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
CPU: 0 PID: 1689 Comm: modprobe Tainted: G B 3.18.0-rc1-mm1+ #98 CPU: 0 PID: 1689 Comm: modprobe Tainted: G B 3.18.0-rc1-mm1+ #98
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
ffff8800693bc000 0000000000000000 ffff8800693bc558 ffff88006923bb78 ffff8800693bc000 0000000000000000 ffff8800693bc558 ffff88006923bb78
ffffffff81cc68ae 00000000000000f3 ffff88006d407600 ffff88006923bba8 ffffffff81cc68ae 00000000000000f3 ffff88006d407600 ffff88006923bba8
ffffffff811fd848 ffff88006d407600 ffffea0001a4ef00 ffff8800693bc558 ffffffff811fd848 ffff88006d407600 ffffea0001a4ef00 ffff8800693bc558
Call Trace: Call Trace:
[<ffffffff81cc68ae>] dump_stack+0x46/0x58 [<ffffffff81cc68ae>] dump_stack+0x46/0x58
[<ffffffff811fd848>] print_trailer+0xf8/0x160 [<ffffffff811fd848>] print_trailer+0xf8/0x160
[<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan] [<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]
...@@ -101,20 +103,20 @@ Call Trace: ...@@ -101,20 +103,20 @@ Call Trace:
[<ffffffff8110fd70>] ? m_show+0x240/0x240 [<ffffffff8110fd70>] ? m_show+0x240/0x240
[<ffffffff81115f06>] SyS_finit_module+0x76/0x80 [<ffffffff81115f06>] SyS_finit_module+0x76/0x80
[<ffffffff81cd3129>] system_call_fastpath+0x12/0x17 [<ffffffff81cd3129>] system_call_fastpath+0x12/0x17
Memory state around the buggy address: Memory state around the buggy address:
ffff8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8800693bc380: fc fc 00 00 00 00 00 00 00 00 00 00 00 00 00 fc ffff8800693bc380: fc fc 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
ffff8800693bc400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800693bc400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8800693bc480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800693bc480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8800693bc500: fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00 ffff8800693bc500: fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00
>ffff8800693bc580: 00 00 00 00 00 00 00 00 00 00 03 fc fc fc fc fc >ffff8800693bc580: 00 00 00 00 00 00 00 00 00 00 03 fc fc fc fc fc
^ ^
ffff8800693bc600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800693bc600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8800693bc680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800693bc680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8800693bc700: fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb fb ffff8800693bc700: fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb fb
ffff8800693bc780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8800693bc780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
================================================================== ==================================================================
The header of the report discribe what kind of bug happened and what kind of The header of the report discribe what kind of bug happened and what kind of
access caused it. It's followed by the description of the accessed slub object access caused it. It's followed by the description of the accessed slub object
...@@ -137,8 +139,8 @@ In the report above the arrows point to the shadow byte 03, which means that ...@@ -137,8 +139,8 @@ In the report above the arrows point to the shadow byte 03, which means that
the accessed address is partially accessible. the accessed address is partially accessible.
2. Implementation details Implementation details
========================= ----------------------
From a high level, our approach to memory error detection is similar to that From a high level, our approach to memory error detection is similar to that
of kmemcheck: use shadow memory to record whether each byte of memory is safe of kmemcheck: use shadow memory to record whether each byte of memory is safe
...@@ -150,15 +152,15 @@ AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory ...@@ -150,15 +152,15 @@ AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory
offset to translate a memory address to its corresponding shadow address. offset to translate a memory address to its corresponding shadow address.
Here is the function which translates an address to its corresponding shadow Here is the function which translates an address to its corresponding shadow
address: address::
static inline void *kasan_mem_to_shadow(const void *addr) static inline void *kasan_mem_to_shadow(const void *addr)
{ {
return ((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT) return ((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
+ KASAN_SHADOW_OFFSET; + KASAN_SHADOW_OFFSET;
} }
where KASAN_SHADOW_SCALE_SHIFT = 3. where ``KASAN_SHADOW_SCALE_SHIFT = 3``.
Compile-time instrumentation used for checking memory accesses. Compiler inserts Compile-time instrumentation used for checking memory accesses. Compiler inserts
function calls (__asan_load*(addr), __asan_store*(addr)) before each memory function calls (__asan_load*(addr), __asan_store*(addr)) before each memory
......
Documentation/kcov.txt → Documentation/dev-tools/kcov.rst
View file @ 5512128f
...@@ -12,38 +12,38 @@ To achieve this goal it does not collect coverage in soft/hard interrupts ...@@ -12,38 +12,38 @@ To achieve this goal it does not collect coverage in soft/hard interrupts
and instrumentation of some inherently non-deterministic parts of kernel is and instrumentation of some inherently non-deterministic parts of kernel is
disbled (e.g. scheduler, locking). disbled (e.g. scheduler, locking).
Usage: Usage
====== -----
Configure kernel with: Configure the kernel with::
CONFIG_KCOV=y CONFIG_KCOV=y
CONFIG_KCOV requires gcc built on revision 231296 or later. CONFIG_KCOV requires gcc built on revision 231296 or later.
Profiling data will only become accessible once debugfs has been mounted: Profiling data will only become accessible once debugfs has been mounted::
mount -t debugfs none /sys/kernel/debug mount -t debugfs none /sys/kernel/debug
The following program demonstrates kcov usage from within a test program: The following program demonstrates kcov usage from within a test program::
#include <stdio.h> #include <stdio.h>
#include <stddef.h> #include <stddef.h>
#include <stdint.h> #include <stdint.h>
#include <stdlib.h> #include <stdlib.h>
#include <sys/types.h> #include <sys/types.h>
#include <sys/stat.h> #include <sys/stat.h>
#include <sys/ioctl.h> #include <sys/ioctl.h>
#include <sys/mman.h> #include <sys/mman.h>
#include <unistd.h> #include <unistd.h>
#include <fcntl.h> #include <fcntl.h>
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
#define KCOV_ENABLE _IO('c', 100) #define KCOV_ENABLE _IO('c', 100)
#define KCOV_DISABLE _IO('c', 101) #define KCOV_DISABLE _IO('c', 101)
#define COVER_SIZE (64<<10) #define COVER_SIZE (64<<10)
int main(int argc, char **argv) int main(int argc, char **argv)
{ {
int fd; int fd;
unsigned long *cover, n, i; unsigned long *cover, n, i;
...@@ -83,24 +83,24 @@ int main(int argc, char **argv) ...@@ -83,24 +83,24 @@ int main(int argc, char **argv)
if (close(fd)) if (close(fd))
perror("close"), exit(1); perror("close"), exit(1);
return 0; return 0;
} }
After piping through addr2line output of the program looks as follows: After piping through addr2line output of the program looks as follows::
SyS_read SyS_read
fs/read_write.c:562 fs/read_write.c:562
__fdget_pos __fdget_pos
fs/file.c:774 fs/file.c:774
__fget_light __fget_light
fs/file.c:746 fs/file.c:746
__fget_light __fget_light
fs/file.c:750 fs/file.c:750
__fget_light __fget_light
fs/file.c:760 fs/file.c:760
__fdget_pos __fdget_pos
fs/file.c:784 fs/file.c:784
SyS_read SyS_read
fs/read_write.c:562 fs/read_write.c:562
If a program needs to collect coverage from several threads (independently), If a program needs to collect coverage from several threads (independently),
it needs to open /sys/kernel/debug/kcov in each thread separately. it needs to open /sys/kernel/debug/kcov in each thread separately.
......
Documentation/kmemleak.txt → Documentation/dev-tools/kmemleak.rst
View file @ 5512128f
Kernel Memory Leak Detector Kernel Memory Leak Detector
=========================== ===========================
Introduction
------------
Kmemleak provides a way of detecting possible kernel memory leaks in a Kmemleak provides a way of detecting possible kernel memory leaks in a
way similar to a tracing garbage collector way similar to a tracing garbage collector
(https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors), (https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors),
with the difference that the orphan objects are not freed but only with the difference that the orphan objects are not freed but only
reported via /sys/kernel/debug/kmemleak. A similar method is used by the reported via /sys/kernel/debug/kmemleak. A similar method is used by the
Valgrind tool (memcheck --leak-check) to detect the memory leaks in Valgrind tool (``memcheck --leak-check``) to detect the memory leaks in
user-space applications. user-space applications.
Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile. Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile.
...@@ -19,20 +16,20 @@ Usage ...@@ -19,20 +16,20 @@ Usage
CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel
thread scans the memory every 10 minutes (by default) and prints the thread scans the memory every 10 minutes (by default) and prints the
number of new unreferenced objects found. To display the details of all number of new unreferenced objects found. To display the details of all
the possible memory leaks: the possible memory leaks::
# mount -t debugfs nodev /sys/kernel/debug/ # mount -t debugfs nodev /sys/kernel/debug/
# cat /sys/kernel/debug/kmemleak # cat /sys/kernel/debug/kmemleak
To trigger an intermediate memory scan: To trigger an intermediate memory scan::
# echo scan > /sys/kernel/debug/kmemleak # echo scan > /sys/kernel/debug/kmemleak
To clear the list of all current possible memory leaks: To clear the list of all current possible memory leaks::
# echo clear > /sys/kernel/debug/kmemleak # echo clear > /sys/kernel/debug/kmemleak
New leaks will then come up upon reading /sys/kernel/debug/kmemleak New leaks will then come up upon reading ``/sys/kernel/debug/kmemleak``
again. again.
Note that the orphan objects are listed in the order they were allocated Note that the orphan objects are listed in the order they were allocated
...@@ -40,22 +37,31 @@ and one object at the beginning of the list may cause other subsequent ...@@ -40,22 +37,31 @@ and one object at the beginning of the list may cause other subsequent
objects to be reported as orphan. objects to be reported as orphan.
Memory scanning parameters can be modified at run-time by writing to the Memory scanning parameters can be modified at run-time by writing to the
/sys/kernel/debug/kmemleak file. The following parameters are supported: ``/sys/kernel/debug/kmemleak`` file. The following parameters are supported:
off - disable kmemleak (irreversible) - off
stack=on - enable the task stacks scanning (default) disable kmemleak (irreversible)
stack=off - disable the tasks stacks scanning - stack=on
scan=on - start the automatic memory scanning thread (default) enable the task stacks scanning (default)
scan=off - stop the automatic memory scanning thread - stack=off
scan=<secs> - set the automatic memory scanning period in seconds disable the tasks stacks scanning
- scan=on
start the automatic memory scanning thread (default)
- scan=off
stop the automatic memory scanning thread
- scan=<secs>
set the automatic memory scanning period in seconds
(default 600, 0 to stop the automatic scanning) (default 600, 0 to stop the automatic scanning)
scan - trigger a memory scan - scan
clear - clear list of current memory leak suspects, done by trigger a memory scan
- clear
clear list of current memory leak suspects, done by
marking all current reported unreferenced objects grey, marking all current reported unreferenced objects grey,
or free all kmemleak objects if kmemleak has been disabled. or free all kmemleak objects if kmemleak has been disabled.
dump=<addr> - dump information about the object found at <addr> - dump=<addr>
dump information about the object found at <addr>
Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on Kmemleak can also be disabled at boot-time by passing ``kmemleak=off`` on
the kernel command line. the kernel command line.
Memory may be allocated or freed before kmemleak is initialised and Memory may be allocated or freed before kmemleak is initialised and
...@@ -63,13 +69,14 @@ these actions are stored in an early log buffer. The size of this buffer ...@@ -63,13 +69,14 @@ these actions are stored in an early log buffer. The size of this buffer
is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option. is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option.
If CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF are enabled, the kmemleak is If CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF are enabled, the kmemleak is
disabled by default. Passing "kmemleak=on" on the kernel command disabled by default. Passing ``kmemleak=on`` on the kernel command
line enables the function. line enables the function.
Basic Algorithm Basic Algorithm
--------------- ---------------
The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`,
:c:func:`kmem_cache_alloc` and
friends are traced and the pointers, together with additional friends are traced and the pointers, together with additional
information like size and stack trace, are stored in a rbtree. information like size and stack trace, are stored in a rbtree.
The corresponding freeing function calls are tracked and the pointers The corresponding freeing function calls are tracked and the pointers
...@@ -113,13 +120,13 @@ when doing development. To work around these situations you can use the ...@@ -113,13 +120,13 @@ when doing development. To work around these situations you can use the
you can find new unreferenced objects; this should help with testing you can find new unreferenced objects; this should help with testing
specific sections of code. specific sections of code.
To test a critical section on demand with a clean kmemleak do: To test a critical section on demand with a clean kmemleak do::
# echo clear > /sys/kernel/debug/kmemleak # echo clear > /sys/kernel/debug/kmemleak
... test your kernel or modules ... ... test your kernel or modules ...
# echo scan > /sys/kernel/debug/kmemleak # echo scan > /sys/kernel/debug/kmemleak
Then as usual to get your report with: Then as usual to get your report with::
# cat /sys/kernel/debug/kmemleak # cat /sys/kernel/debug/kmemleak
...@@ -131,7 +138,7 @@ disabled by the user or due to an fatal error, internal kmemleak objects ...@@ -131,7 +138,7 @@ disabled by the user or due to an fatal error, internal kmemleak objects
won't be freed when kmemleak is disabled, and those objects may occupy won't be freed when kmemleak is disabled, and those objects may occupy
a large part of physical memory. a large part of physical memory.
In this situation, you may reclaim memory with: In this situation, you may reclaim memory with::
# echo clear > /sys/kernel/debug/kmemleak # echo clear > /sys/kernel/debug/kmemleak
...@@ -140,20 +147,20 @@ Kmemleak API ...@@ -140,20 +147,20 @@ Kmemleak API
See the include/linux/kmemleak.h header for the functions prototype. See the include/linux/kmemleak.h header for the functions prototype.
kmemleak_init - initialize kmemleak - ``kmemleak_init`` - initialize kmemleak
kmemleak_alloc - notify of a memory block allocation - ``kmemleak_alloc`` - notify of a memory block allocation
kmemleak_alloc_percpu - notify of a percpu memory block allocation - ``kmemleak_alloc_percpu`` - notify of a percpu memory block allocation
kmemleak_free - notify of a memory block freeing - ``kmemleak_free`` - notify of a memory block freeing
kmemleak_free_part - notify of a partial memory block freeing - ``kmemleak_free_part`` - notify of a partial memory block freeing
kmemleak_free_percpu - notify of a percpu memory block freeing - ``kmemleak_free_percpu`` - notify of a percpu memory block freeing
kmemleak_update_trace - update object allocation stack trace - ``kmemleak_update_trace`` - update object allocation stack trace
kmemleak_not_leak - mark an object as not a leak - ``kmemleak_not_leak`` - mark an object as not a leak
kmemleak_ignore - do not scan or report an object as leak - ``kmemleak_ignore`` - do not scan or report an object as leak
kmemleak_scan_area - add scan areas inside a memory block - ``kmemleak_scan_area`` - add scan areas inside a memory block
kmemleak_no_scan - do not scan a memory block - ``kmemleak_no_scan`` - do not scan a memory block
kmemleak_erase - erase an old value in a pointer variable - ``kmemleak_erase`` - erase an old value in a pointer variable
kmemleak_alloc_recursive - as kmemleak_alloc but checks the recursiveness - ``kmemleak_alloc_recursive`` - as kmemleak_alloc but checks the recursiveness
kmemleak_free_recursive - as kmemleak_free but checks the recursiveness - ``kmemleak_free_recursive`` - as kmemleak_free but checks the recursiveness
Dealing with false positives/negatives Dealing with false positives/negatives
-------------------------------------- --------------------------------------
......
Documentation/sparse.txt → Documentation/dev-tools/sparse.rst
View file @ 5512128f
Copyright 2004 Linus Torvalds .. Copyright 2004 Linus Torvalds
Copyright 2004 Pavel Machek <pavel@ucw.cz> .. Copyright 2004 Pavel Machek <pavel@ucw.cz>
Copyright 2006 Bob Copeland <me@bobcopeland.com> .. Copyright 2006 Bob Copeland <me@bobcopeland.com>
Sparse
======
Sparse is a semantic checker for C programs; it can be used to find a
number of potential problems with kernel code. See
https://lwn.net/Articles/689907/ for an overview of sparse; this document
contains some kernel-specific sparse information.
Using sparse for typechecking Using sparse for typechecking
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----------------------------
"__bitwise" is a type attribute, so you have to do something like this: "__bitwise" is a type attribute, so you have to do something like this::
typedef int __bitwise pm_request_t; typedef int __bitwise pm_request_t;
...@@ -20,13 +29,13 @@ but in this case we really _do_ want to force the conversion). And because ...@@ -20,13 +29,13 @@ but in this case we really _do_ want to force the conversion). And because
the enum values are all the same type, now "enum pm_request" will be that the enum values are all the same type, now "enum pm_request" will be that
type too. type too.
And with gcc, all the __bitwise/__force stuff goes away, and it all ends And with gcc, all the "__bitwise"/"__force stuff" goes away, and it all
up looking just like integers to gcc. ends up looking just like integers to gcc.
Quite frankly, you don't need the enum there. The above all really just Quite frankly, you don't need the enum there. The above all really just
boils down to one special "int __bitwise" type. boils down to one special "int __bitwise" type.
So the simpler way is to just do So the simpler way is to just do::
typedef int __bitwise pm_request_t; typedef int __bitwise pm_request_t;
...@@ -50,7 +59,7 @@ __bitwise - noisy stuff; in particular, __le*/__be* are that. We really ...@@ -50,7 +59,7 @@ __bitwise - noisy stuff; in particular, __le*/__be* are that. We really
don't want to drown in noise unless we'd explicitly asked for it. don't want to drown in noise unless we'd explicitly asked for it.
Using sparse for lock checking Using sparse for lock checking
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------
The following macros are undefined for gcc and defined during a sparse The following macros are undefined for gcc and defined during a sparse
run to use the "context" tracking feature of sparse, applied to run to use the "context" tracking feature of sparse, applied to
...@@ -69,22 +78,22 @@ annotation is needed. The tree annotations above are for cases where ...@@ -69,22 +78,22 @@ annotation is needed. The tree annotations above are for cases where
sparse would otherwise report a context imbalance. sparse would otherwise report a context imbalance.
Getting sparse Getting sparse
~~~~~~~~~~~~~~ --------------
You can get latest released versions from the Sparse homepage at You can get latest released versions from the Sparse homepage at
https://sparse.wiki.kernel.org/index.php/Main_Page https://sparse.wiki.kernel.org/index.php/Main_Page
Alternatively, you can get snapshots of the latest development version Alternatively, you can get snapshots of the latest development version
of sparse using git to clone.. of sparse using git to clone::
git://git.kernel.org/pub/scm/devel/sparse/sparse.git git://git.kernel.org/pub/scm/devel/sparse/sparse.git
DaveJ has hourly generated tarballs of the git tree available at.. DaveJ has hourly generated tarballs of the git tree available at::
http://www.codemonkey.org.uk/projects/git-snapshots/sparse/ http://www.codemonkey.org.uk/projects/git-snapshots/sparse/
Once you have it, just do Once you have it, just do::
make make
make install make install
...@@ -92,7 +101,7 @@ Once you have it, just do ...@@ -92,7 +101,7 @@ Once you have it, just do
as a regular user, and it will install sparse in your ~/bin directory. as a regular user, and it will install sparse in your ~/bin directory.
Using sparse Using sparse
~~~~~~~~~~~~ ------------
Do a kernel make with "make C=1" to run sparse on all the C files that get Do a kernel make with "make C=1" to run sparse on all the C files that get
recompiled, or use "make C=2" to run sparse on the files whether they need to recompiled, or use "make C=2" to run sparse on the files whether they need to
...@@ -101,7 +110,7 @@ have already built it. ...@@ -101,7 +110,7 @@ have already built it.
The optional make variable CF can be used to pass arguments to sparse. The The optional make variable CF can be used to pass arguments to sparse. The
build system passes -Wbitwise to sparse automatically. To perform endianness build system passes -Wbitwise to sparse automatically. To perform endianness
checks, you may define __CHECK_ENDIAN__: checks, you may define __CHECK_ENDIAN__::
make C=2 CF="-D__CHECK_ENDIAN__" make C=2 CF="-D__CHECK_ENDIAN__"
......
Documentation/dev-tools/tools.rst 0 → 100644
View file @ 5512128f
================================
Development tools for the kernel
================================
This document is a collection of documents about development tools that can
be used to work on the kernel. For now, the documents have been pulled
together without any significant effot to integrate them into a coherent
whole; patches welcome!
.. class:: toc-title
Table of contents
.. toctree::
:maxdepth: 2
coccinelle
sparse
kcov
gcov
kasan
ubsan
kmemleak
kmemcheck
gdb-kernel-debugging
Documentation/ubsan.txt → Documentation/dev-tools/ubsan.rst
View file @ 5512128f
Undefined Behavior Sanitizer - UBSAN The Undefined Behavior Sanitizer - UBSAN
========================================
Overview
--------
UBSAN is a runtime undefined behaviour checker. UBSAN is a runtime undefined behaviour checker.
...@@ -10,11 +8,13 @@ Compiler inserts code that perform certain kinds of checks before operations ...@@ -10,11 +8,13 @@ Compiler inserts code that perform certain kinds of checks before operations
that may cause UB. If check fails (i.e. UB detected) __ubsan_handle_* that may cause UB. If check fails (i.e. UB detected) __ubsan_handle_*
function called to print error message. function called to print error message.
GCC has that feature since 4.9.x [1] (see -fsanitize=undefined option and GCC has that feature since 4.9.x [1_] (see ``-fsanitize=undefined`` option and
its suboptions). GCC 5.x has more checkers implemented [2]. its suboptions). GCC 5.x has more checkers implemented [2_].
Report example Report example
--------------- --------------
::
================================================================================ ================================================================================
UBSAN: Undefined behaviour in ../include/linux/bitops.h:110:33 UBSAN: Undefined behaviour in ../include/linux/bitops.h:110:33
...@@ -47,28 +47,32 @@ Report example ...@@ -47,28 +47,32 @@ Report example
Usage Usage
----- -----
To enable UBSAN configure kernel with: To enable UBSAN configure kernel with::
CONFIG_UBSAN=y CONFIG_UBSAN=y
and to check the entire kernel: and to check the entire kernel::
CONFIG_UBSAN_SANITIZE_ALL=y CONFIG_UBSAN_SANITIZE_ALL=y
To enable instrumentation for specific files or directories, add a line To enable instrumentation for specific files or directories, add a line
similar to the following to the respective kernel Makefile: similar to the following to the respective kernel Makefile:
For a single file (e.g. main.o): - For a single file (e.g. main.o)::
UBSAN_SANITIZE_main.o := y UBSAN_SANITIZE_main.o := y
For all files in one directory: - For all files in one directory::
UBSAN_SANITIZE := y UBSAN_SANITIZE := y
To exclude files from being instrumented even if To exclude files from being instrumented even if
CONFIG_UBSAN_SANITIZE_ALL=y, use: ``CONFIG_UBSAN_SANITIZE_ALL=y``, use::
UBSAN_SANITIZE_main.o := n UBSAN_SANITIZE_main.o := n
and:
and::
UBSAN_SANITIZE := n UBSAN_SANITIZE := n
Detection of unaligned accesses controlled through the separate option - Detection of unaligned accesses controlled through the separate option -
...@@ -80,5 +84,5 @@ reports. ...@@ -80,5 +84,5 @@ reports.
References References
---------- ----------
[1] - https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html .. _1: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html
[2] - https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html .. _2: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Documentation/index.rst
View file @ 5512128f
...@@ -12,6 +12,7 @@ Contents: ...@@ -12,6 +12,7 @@ Contents:
:maxdepth: 2 :maxdepth: 2
kernel-documentation kernel-documentation
dev-tools/tools
media/index media/index
gpu/index gpu/index
......
MAINTAINERS
View file @ 5512128f
...@@ -3124,7 +3124,7 @@ L: cocci@systeme.lip6.fr (moderated for non-subscribers) ...@@ -3124,7 +3124,7 @@ L: cocci@systeme.lip6.fr (moderated for non-subscribers)
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git misc T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git misc
W: http://coccinelle.lip6.fr/ W: http://coccinelle.lip6.fr/
S: Supported S: Supported
F: Documentation/coccinelle.txt F: Documentation/dev-tools/coccinelle.rst
F: scripts/coccinelle/ F: scripts/coccinelle/
F: scripts/coccicheck F: scripts/coccicheck
...@@ -5118,7 +5118,7 @@ GCOV BASED KERNEL PROFILING ...@@ -5118,7 +5118,7 @@ GCOV BASED KERNEL PROFILING
M: Peter Oberparleiter <oberpar@linux.vnet.ibm.com> M: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
S: Maintained S: Maintained
F: kernel/gcov/ F: kernel/gcov/
F: Documentation/gcov.txt F: Documentation/dev-tools/gcov.rst
GDT SCSI DISK ARRAY CONTROLLER DRIVER GDT SCSI DISK ARRAY CONTROLLER DRIVER
M: Achim Leubner <achim_leubner@adaptec.com> M: Achim Leubner <achim_leubner@adaptec.com>
...@@ -6587,7 +6587,7 @@ L: kasan-dev@googlegroups.com ...@@ -6587,7 +6587,7 @@ L: kasan-dev@googlegroups.com
S: Maintained S: Maintained
F: arch/*/include/asm/kasan.h F: arch/*/include/asm/kasan.h
F: arch/*/mm/kasan_init* F: arch/*/mm/kasan_init*
F: Documentation/kasan.txt F: Documentation/dev-tools/kasan.rst
F: include/linux/kasan*.h F: include/linux/kasan*.h
F: lib/test_kasan.c F: lib/test_kasan.c
F: mm/kasan/ F: mm/kasan/
...@@ -6803,7 +6803,7 @@ KMEMCHECK ...@@ -6803,7 +6803,7 @@ KMEMCHECK
M: Vegard Nossum <vegardno@ifi.uio.no> M: Vegard Nossum <vegardno@ifi.uio.no>
M: Pekka Enberg <penberg@kernel.org> M: Pekka Enberg <penberg@kernel.org>
S: Maintained S: Maintained
F: Documentation/kmemcheck.txt F: Documentation/dev-tools/kmemcheck.rst
F: arch/x86/include/asm/kmemcheck.h F: arch/x86/include/asm/kmemcheck.h
F: arch/x86/mm/kmemcheck/ F: arch/x86/mm/kmemcheck/
F: include/linux/kmemcheck.h F: include/linux/kmemcheck.h
...@@ -6812,7 +6812,7 @@ F: mm/kmemcheck.c ...@@ -6812,7 +6812,7 @@ F: mm/kmemcheck.c
KMEMLEAK KMEMLEAK
M: Catalin Marinas <catalin.marinas@arm.com> M: Catalin Marinas <catalin.marinas@arm.com>
S: Maintained S: Maintained
F: Documentation/kmemleak.txt F: Documentation/dev-tools/kmemleak.rst
F: include/linux/kmemleak.h F: include/linux/kmemleak.h
F: mm/kmemleak.c F: mm/kmemleak.c
F: mm/kmemleak-test.c F: mm/kmemleak-test.c
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7