"Linux kernel Design and implementation" Chapter 18th reading notes

18th Chapter Commissioning

First, the preparation before the start of commissioning

1. Getting Started

• Bug
• The version that hides the bug
• Knowledge of related kernel code

The key to successful debugging is the ability to reproduce the error

2. Bugs in the kernel

There are countless reasons for this, and there are many different appearances. From the error hidden in the source code to the occurrence of the bug, it may be triggered by a series of chain reactions.

Second, through the printing and debugging

1. Robustness

The robustness of the PRINTK () function makes it possible to invoke it at any time, anywhere.

• Use in interrupt context and process up and down
• When any hold lock is transferred
• Called at the same time on multiple processors

2. Log level

The most important difference between PRINTK () and printf () is that the former can specify a log level, and the kernel determines whether the terminal prints messages based on this level;

Kern_warning and kern_debug are simple macro definitions in <linux/kernel.h>, extending the string of <4> and <7>, adding the PRINTK () function to the beginning of the printing.

The kernel records the most important record level as <0>, and the most insignificant record level is set to <7>.

3. Record buffers

• Record messages are saved in a ring queue, and read-write is performed in a ring-queue manner
• The kernel can only hold 16KB messages at the same time, and when the message queue reaches its maximum value, the new message overwrites the old message in the queue.
• Pros: Synchronization issues are easy to solve, and record maintenance is easy.
• Cons: Messages may be lost

4.syslogd and KLOGD

The daemon of the user space klogd the kernel messages from the record buffers and then saves them in the system log file through the daemon syslogd.

Third, oops

1. The process of releasing Oops

This includes outputting error messages to the terminal, storing information in the output register, and outputting backtracking clues that can be traced. Typically, the kernel will be in an unstable state after it is sent.

2. Result

If the interrupt context occurs, the kernel will fall into chaos and the system freezes;

If the idle or init process occurs, the system will also fall into chaos, missing these two processes, the kernel will not work.

If it occurs while another process is running, the kernel kills the process and attempts to continue.

3. Cause of Occurrence

Memory access out of bounds or illegal instructions

4. Structure of information contained

Register context and backtracking clues

• Trace clues show the chain of function calls that caused the error to occur
• Register data can help rebuild the problem site

Iv. causing bugs and printing information

Bugs () and bug_on () are commonly used to mark bugs in kernel calls, and are invoked when the oops is thrown, causing the stack's backtracking and error messages to be printed.

Use panic () to cause more serious errors, not only to print the error message, but also to suspend the entire system.

Five, Magic SysRq Key

When this feature is enabled, no matter what state the kernel is in, a special key combination can be used to communicate with the kernel.

• Using the Define CONFIG_MAGIC_SYSRQ configuration options and commands echo 1 >/PROC/SYS/KERNEL/SYSYRQ Enable

VI. Kernel Debugger and system probing

1. Kernel Debugger

• The running kernel can be viewed using the standard GNU kernel debugger
• You can use all of GDB's commands to get information

2. Detection System

• Using the UID as the selection condition, you can arrange which algorithm to execute exactly.
• Using a condition variable, create a global variable as a conditional selector switch
• Use statistics to provide some mechanism to access their statistical results by creating statistics
• Repetition frequency limit, used for an event to occur frequently, but also to observe its overall situation. To avoid a blowout of information, print can be performed every few seconds.

Seven or two-point lookup and Git tools

1. When you do not know which kernel version introduced the bug, but it does exist using dichotomy to find

Suppose one version has a problem and the other does not, choose a version check from the middle, narrowing the scope, and so on.

2. Using Git for binary search

If you use Git to control a copy of the Linux source tree, it will automatically perform a binary search process

• Tell Git to do a two-point search

$ git bisect start

• Provide Git with an early kernel version of the problem

$ git bisect bad <revision>

• Provides an up-to-date, healthy kernel version

$ git bisect good version number

In this way, GIT will automatically detect which of the normal and bug versions are in danger, then compile and run and test the tested version.

　

　　

　　

"Linux kernel Design and implementation" Chapter 18th reading notes