[bootlin/training-materials updates] master: debugging-labs: reorder section to be more logical (86eb4112)

Clément Léger clement.leger at bootlin.com
Thu Nov 24 11:40:55 CET 2022


Repository : https://github.com/bootlin/training-materials
On branch  : master
Link       : https://github.com/bootlin/training-materials/commit/86eb4112a7dae75af3388ab052637e50841d80ed

>---------------------------------------------------------------

commit 86eb4112a7dae75af3388ab052637e50841d80ed
Author: Clément Léger <clement.leger at bootlin.com>
Date:   Thu Nov 24 11:40:55 2022 +0100

    debugging-labs: reorder section to be more logical
    
    Signed-off-by: Clément Léger <clement.leger at bootlin.com>


>---------------------------------------------------------------

86eb4112a7dae75af3388ab052637e50841d80ed
 .../debugging-kernel-debugging.tex                 | 82 +++++++++++-----------
 1 file changed, 41 insertions(+), 41 deletions(-)

diff --git a/labs/debugging-kernel-debugging/debugging-kernel-debugging.tex b/labs/debugging-kernel-debugging/debugging-kernel-debugging.tex
index 7985503a..9993052f 100644
--- a/labs/debugging-kernel-debugging/debugging-kernel-debugging.tex
+++ b/labs/debugging-kernel-debugging/debugging-kernel-debugging.tex
@@ -2,13 +2,52 @@
 {Kernel debugging}
 {Objectives:
   \begin{itemize}
-    \item Analyzing an {\em oops} with {\em addr2line}.
-    \item Debugging with {\em KGDB}.
     \item Debugging a deadlock problem using {\em PROVE\_LOCKING} options.
     \item Find a module memory leak using {\em kmemleak}.
+    \item Analyzing an {\em oops} with {\em addr2line}.
+    \item Debugging with {\em KGDB}.
+    \item Setting up {\em Kexec \& kdump}.
   \end{itemize}
 }
 
+\section{Locking problems}
+
+\kconfig{CONFIG_PROVE_LOCKING} has been enabled in the provided kernel image.
+Load the \code{locking.ko} module and look at the output in dmesg. Once
+analyzed, unload the module. Try to understand and fix all the problems that
+have been reported by the \code{lockdep} system.
+
+\section{Kmemleak}
+
+The provided kernel image contains kmemleak but it is disabled by default to
+avoid having a large overhead. In order to enable it, reboot and enable it by
+adding \code{kmemleak=on} on the command line. Interrupt U-Boot at reboot and
+modify the \code{bootargs} variable:
+
+\begin{bashinput}
+STM32MP> env edit bootargs
+STM32MP> <existing bootargs> kmemleak=on
+STM32MP> boot
+\end{bashinput}
+
+Once done, use the \code{boot} command to actually boot the kernel. Once booted,
+load the \code{leaky_module.ko} and trigger an immediate kmemleak scan using:
+
+\begin{bashinput}
+# echo scan > /sys/kernel/module/kmemleak
+\end{bashinput}
+
+Soon after that, the kernel will report that some leaks have been identified.
+Display them and analyze them using:
+
+\begin{bashinput}
+# cat /sys/kernel/module/kmemleak
+\end{bashinput}
+
+You can use \code{addr2line} to identify the location in source code of the
+lines that did cause the reports. You will also notice other memory leaks that
+are actually some real memory leaks that did exist in the 5.13 kernel version !
+
 \section{OOPS analysis}
 We noticed that the watchdog command generated a crash on the kernel. In order
 to reproduce the crash, run the following command:
@@ -149,45 +188,6 @@ the problem using the \code{watchdog} command.
 was modified but the arm32 platforms do not provide watchpoints support with
 KGDB.}
 
-\section{Locking problems}
-
-\kconfig{CONFIG_PROVE_LOCKING} has been enabled in the provided kernel image.
-Load the \code{locking.ko} module and look at the output in dmesg. Once
-analyzed, unload the module. Try to understand and fix all the problems that
-have been reported by the \code{lockdep} system.
-
-\section{Kmemleak}
-
-The provided kernel image contains kmemleak but it is disabled by default to
-avoid having a large overhead. In order to enable it, reboot and enable it by
-adding \code{kmemleak=on} on the command line. Interrupt U-Boot at reboot and
-modify the \code{bootargs} variable:
-
-\begin{bashinput}
-STM32MP> env edit bootargs
-STM32MP> <existing bootargs> kmemleak=on
-STM32MP> boot
-\end{bashinput}
-
-Once done, use the \code{boot} command to actually boot the kernel. Once booted,
-load the \code{leaky_module.ko} and trigger an immediate kmemleak scan using:
-
-\begin{bashinput}
-# echo scan > /sys/kernel/module/kmemleak
-\end{bashinput}
-
-Soon after that, the kernel will report that some leaks have been identified.
-Display them and analyze them using:
-
-\begin{bashinput}
-# cat /sys/kernel/module/kmemleak
-\end{bashinput}
-
-You can use \code{addr2line} to identify the location in source code of the
-lines that did cause the reports. You will also notice other memory leaks that
-are actually some real memory leaks that did exist in the 5.13 kernel version !
-
-
 \section{kdump \& kexec}
 
 As presented in the course, kdump/kexec allows to boot a new kernel and dump a




More information about the training-materials-updates mailing list