1 .. SPDX-License-Identifier: GPL-2.0
2
3 .. include:: ../disclaimer-zh_TW.rst
4
5 :Original: :doc:`../../../admin-guide/bug-hunting`
6
7 :譯者:
8
9 吳想成 Wu XiangCheng <bobwxc@email.cn>
10 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
11
12 追蹤缺陷
13 =========
14
15 內核錯誤報告通常附帶如下堆棧轉儲::
16
17 ------------[ cut here ]------------
18 WARNING: CPU: 1 PID: 28102 at kernel/module.c:1108 module_put+0x57/0x70
19 Modules linked in: dvb_usb_gp8psk(-) dvb_usb dvb_core nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore nvidia(PO) [last unloaded: rc_core]
20 CPU: 1 PID: 28102 Comm: rmmod Tainted: P WC O 4.8.4-build.1 #1
21 Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009
22 00000000 c12ba080 00000000 00000000 c103ed6a c1616014 00000001 00006dc6
23 c1615862 00000454 c109e8a7 c109e8a7 00000009 ffffffff 00000000 f13f6a10
24 f5f5a600 c103ee33 00000009 00000000 00000000 c109e8a7 f80ca4d0 c109f617
25 Call Trace:
26 [<c12ba080>] ? dump_stack+0x44/0x64
27 [<c103ed6a>] ? __warn+0xfa/0x120
28 [<c109e8a7>] ? module_put+0x57/0x70
29 [<c109e8a7>] ? module_put+0x57/0x70
30 [<c103ee33>] ? warn_slowpath_null+0x23/0x30
31 [<c109e8a7>] ? module_put+0x57/0x70
32 [<f80ca4d0>] ? gp8psk_fe_set_frontend+0x460/0x460 [dvb_usb_gp8psk]
33 [<c109f617>] ? symbol_put_addr+0x27/0x50
34 [<f80bc9ca>] ? dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb]
35 [<f80bb3bf>] ? dvb_usb_exit+0x2f/0xd0 [dvb_usb]
36 [<c13d03bc>] ? usb_disable_endpoint+0x7c/0xb0
37 [<f80bb48a>] ? dvb_usb_device_exit+0x2a/0x50 [dvb_usb]
38 [<c13d2882>] ? usb_unbind_interface+0x62/0x250
39 [<c136b514>] ? __pm_runtime_idle+0x44/0x70
40 [<c13620d8>] ? __device_release_driver+0x78/0x120
41 [<c1362907>] ? driver_detach+0x87/0x90
42 [<c1361c48>] ? bus_remove_driver+0x38/0x90
43 [<c13d1c18>] ? usb_deregister+0x58/0xb0
44 [<c109fbb0>] ? SyS_delete_module+0x130/0x1f0
45 [<c1055654>] ? task_work_run+0x64/0x80
46 [<c1000fa5>] ? exit_to_usermode_loop+0x85/0x90
47 [<c10013f0>] ? do_fast_syscall_32+0x80/0x130
48 [<c1549f43>] ? sysenter_past_esp+0x40/0x6a
49 ---[ end trace 6ebc60ef3981792f ]---
50
51 這樣的堆棧跟蹤提供了足夠的信息來識別內核源代碼中發生錯誤的那一行。根據問題的
52 嚴重性，它還可能包含 **“Oops”** 一詞，比如::
53
54 BUG: unable to handle kernel NULL pointer dereference at (null)
55 IP: [<c06969d4>] iret_exc+0x7d0/0xa59
56 *pdpt = 000000002258a001 *pde = 0000000000000000
57 Oops: 0002 [#1] PREEMPT SMP
58 ...
59
60 儘管有 **Oops** 或其他類型的堆棧跟蹤，但通常需要找到出問題的行來識別和處理缺
61 陷。在本章中，我們將參考“Oops”來了解需要分析的各種堆棧跟蹤。
62
63 如果內核是用 ``CONFIG_DEBUG_INFO`` 編譯的，那麼可以使用文件：
64 `scripts/decode_stacktrace.sh` 。
65
66 鏈接的模塊
67 -----------
68
69 受到污染或正在加載/卸載的模塊用“（…）”標記，污染標誌在
70 `Documentation/admin-guide/tainted-kernels.rst` 文件中進行了描述，“正在被加
71 載”用“+”標註，“正在被卸載”用“-”標註。
72
73
74 Oops消息在哪？
75 ---------------
76
77 通常，Oops文本由klogd從內核緩衝區讀取，然後交給 ``syslogd`` ，後者將其寫入
78 syslog文件，通常是 ``/var/log/messages`` （取決於 ``/etc/syslog.conf`` ）。
79 在使用systemd的系統上，它也可以由 ``journald`` 守護進程存儲，並通過運行
80 ``journalctl`` 命令進行訪問。
81
82 有時 ``klogd`` 會掛掉，這種情況下您可以運行 ``dmesg > file`` 從內核緩衝區
83 讀取數據並保存它。或者您可以 ``cat /proc/kmsg > file`` ，但是您必須適時
84 中斷以停止傳輸，因爲 ``kmsg`` 是一個“永無止境的文件”。
85
86 如果機器嚴重崩潰，無法輸入命令或磁盤不可用，那還有三個選項：
87
88 (1) 手動複製屏幕上的文本，並在機器重新啓動後輸入。很難受，但這是突然崩潰下
89 唯一的選擇。或者你可以用數碼相機拍下屏幕——雖然不那麼好，但總比什麼都沒
90 有好。如果消息滾動超出控制檯頂部，使用更高分辨率（例如 ``vga=791`` ）
91 引導啓動將允許您閱讀更多文本。（警告：這需要 ``vesafb`` ，因此對“早期”
92 的Oppses沒有幫助）
93
94 (2) 從串口終端啓動（參見
95 :ref:`Documentation/admin-guide/serial-console.rst <serial_console>` ），
96 在另一臺機器上運行調制解調器然後用你喜歡的通信程序捕獲輸出。
97 Minicom運行良好。
98
99 (3) 使用Kdump（參閱 Documentation/admin-guide/kdump/kdump.rst ），使用
100 Documentation/admin-guide/kdump/gdbmacros.txt 中的dmesg gdbmacro從舊內存
101 中提取內核環形緩衝區。
102
103 找到缺陷位置
104 -------------
105
106 如果你能指出缺陷在內核源代碼中的位置，則報告缺陷的效果會非常好。這有兩種方法。
107 通常來說使用 ``gdb`` 會比較容易，不過內核需要用調試信息來預編譯。
108
109 gdb
110 ^^^^
111
112 GNU 調試器（GNU debugger， ``gdb`` ）是從 ``vmlinux`` 文件中找出OOPS的確切
113 文件和行號的最佳方法。
114
115 在使用 ``CONFIG_DEBUG_INFO`` 編譯的內核上使用gdb效果最好。可通過運行以下命令
116 進行設置::
117
118 $ ./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO
119
120 在用 ``CONFIG_DEBUG_INFO`` 編譯的內核上，你可以直接從OOPS複製EIP值::
121
122 EIP: 0060:[<c021e50e>] Not tainted VLI
123
124 並使用GDB來將其翻譯成可讀形式::
125
126 $ gdb vmlinux
127 (gdb) l *0xc021e50e
128
129 如果沒有啓用 ``CONFIG_DEBUG_INFO`` ，則使用OOPS的函數偏移::
130
131 EIP is at vt_ioctl+0xda8/0x1482
132
133 並在啓用 ``CONFIG_DEBUG_INFO`` 的情況下重新編譯內核::
134
135 $ ./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO
136 $ make vmlinux
137 $ gdb vmlinux
138 (gdb) l *vt_ioctl+0xda8
139 0x1888 is in vt_ioctl (drivers/tty/vt/vt_ioctl.c:293).
140 288 {
141 289 struct vc_data *vc = NULL;
142 290 int ret = 0;
143 291
144 292 console_lock();
145 293 if (VT_BUSY(vc_num))
146 294 ret = -EBUSY;
147 295 else if (vc_num)
148 296 vc = vc_deallocate(vc_num);
149 297 console_unlock();
150
151 或者若您想要更詳細的顯示::
152
153 (gdb) p vt_ioctl
154 $1 = {int (struct tty_struct *, unsigned int, unsigned long)} 0xae0 <vt_ioctl>
155 (gdb) l *0xae0+0xda8
156
157 您也可以使用對象文件作爲替代::
158
159 $ make drivers/tty/
160 $ gdb drivers/tty/vt/vt_ioctl.o
161 (gdb) l *vt_ioctl+0xda8
162
163 如果你有調用跟蹤，類似::
164
165 Call Trace:
166 [<ffffffff8802c8e9>] :jbd:log_wait_commit+0xa3/0xf5
167 [<ffffffff810482d9>] autoremove_wake_function+0x0/0x2e
168 [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
169 ...
170
171 這表明問題可能在 :jbd: 模塊中。您可以在gdb中加載該模塊並列出相關代碼::
172
173 $ gdb fs/jbd/jbd.ko
174 (gdb) l *log_wait_commit+0xa3
175
176 .. note::
177
178 您還可以對堆棧跟蹤處的任何函數調用執行相同的操作，例如::
179
180 [<f80bc9ca>] ? dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb]
181
182 上述調用發生的位置可以通過以下方式看到::
183
184 $ gdb drivers/media/usb/dvb-usb/dvb-usb.o
185 (gdb) l *dvb_usb_adapter_frontend_exit+0x3a
186
187 objdump
188 ^^^^^^^^
189
190 要調試內核，請使用objdump並從崩潰輸出中查找十六進制偏移，以找到有效的代碼/匯
191 編行。如果沒有調試符號，您將看到所示例程的彙編程序代碼，但是如果內核有調試
192 符號，C代碼也將可見（調試符號可以在內核配置菜單的hacking項中啓用）。例如::
193
194 $ objdump -r -S -l --disassemble net/dccp/ipv4.o
195
196 .. note::
197
198 您需要處於內核樹的頂層以便此獲得您的C文件。
199
200 如果您無法訪問源代碼，仍然可以使用以下方法調試一些崩潰轉儲（如Dave Miller的
201 示例崩潰轉儲輸出所示）::
202
203 EIP is at +0x14/0x4c0
204 ...
205 Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00
206 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08
207 <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85
208
209 Put the bytes into a "foo.s" file like this:
210
211 .text
212 .globl foo
213 foo:
214 .byte .... /* bytes from Code: part of OOPS dump */
215
216 Compile it with "gcc -c -o foo.o foo.s" then look at the output of
217 "objdump --disassemble foo.o".
218
219 Output:
220
221 ip_queue_xmit:
222 push %ebp
223 push %edi
224 push %esi
225 push %ebx
226 sub $0xbc, %esp
227 mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb)
228 mov 0x8(%ebp), %ebx ! %ebx = skb->sk
229 mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
230
231 `scripts/decodecode` 文件可以用來自動完成大部分工作，這取決於正在調試的CPU
232 體系結構。
233
234 報告缺陷
235 ---------
236
237 一旦你通過定位缺陷找到了其發生的地方，你可以嘗試自己修復它或者向上遊報告它。
238
239 爲了向上遊報告，您應該找出用於開發受影響代碼的郵件列表。這可以使用 ``get_maintainer.pl`` 。
240
241
242 例如，您在gspca的sonixj.c文件中發現一個缺陷，則可以通過以下方法找到它的維護者::
243
244 $ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
245 Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
246 Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer:MEDIA INPUT INFRASTRUCTURE (V4L/DVB),commit_signer:1/1=100%)
247 Tejun Heo <tj@kernel.org> (commit_signer:1/1=100%)
248 Bhaktipriya Shridhar <bhaktipriya96@gmail.com> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:4/4=100%,removed_lines:9/9=100%)
249 linux-media@vger.kernel.org (open list:GSPCA USB WEBCAM DRIVER)
250 linux-kernel@vger.kernel.org (open list)
251
252 請注意它將指出：
253
254 - 最後接觸源代碼的開發人員（如果這是在git樹中完成的）。在上面的例子中是Tejun
255 和Bhaktipriya（在這個特定的案例中，沒有人真正參與這個文件的開發）；
256 - 驅動維護人員（Hans Verkuil）；
257 - 子系統維護人員（Mauro Carvalho Chehab）；
258 - 驅動程序和/或子系統郵件列表（linux-media@vger.kernel.org）；
259 - Linux內核郵件列表（linux-kernel@vger.kernel.org）。
260
261 通常，修復缺陷的最快方法是將它報告給用於開發相關代碼的郵件列表（linux-media
262 ML），抄送驅動程序維護者（Hans）。
263
264 如果你完全不知道該把報告寄給誰，且 ``get_maintainer.pl`` 也沒有提供任何有用
265 的信息，請發送到linux-kernel@vger.kernel.org。
266
267 感謝您的幫助，這使Linux儘可能穩定:-)
268
269 修復缺陷
270 ---------
271
272 如果你懂得編程，你不僅可以通過報告錯誤來幫助我們，還可以提供一個解決方案。
273 畢竟，開源就是分享你的工作，你不想因爲你的天才而被認可嗎？
274
275 如果你決定這樣做，請在制定解決方案後將其提交到上游。
276
277 請務必閱讀
278 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` ，
279 以幫助您的代碼被接受。
280
281
282 ---------------------------------------------------------------------------
283
284 用 ``klogd`` 進行Oops跟蹤的注意事項
285 ------------------------------------
286
287 爲了幫助Linus和其他內核開發人員， ``klogd`` 對保護故障的處理提供了大量支持。
288 爲了完整支持地址解析，至少應該使用 ``sysklogd`` 包的1.3-pl3版本。
289
290 當發生保護故障時， ``klogd`` 守護進程會自動將內核日誌消息中的重要地址轉換爲
291 它們的等效符號。然後通過 ``klogd`` 使用的任何報告機制來轉發這個已翻譯的內核
292 消息。保護錯誤消息可以直接從消息文件中剪切出來並轉發給內核開發人員。
293
294 ``klogd`` 執行兩種類型的地址解析，靜態翻譯和動態翻譯。靜態翻譯使用System.map
295 文件。爲了進行靜態轉換， ``klogd`` 守護進程必須能夠在守護進程初始化時找到系
296 統映射文件。有關 ``klogd`` 如何搜索映射文件的信息，請參見klogd手冊頁。
297
298 當使用內核可加載模塊時，動態地址轉換非常重要。由於內核模塊的內存是從內核的
299 動態內存池中分配的，因此無論是模塊的開頭還是模塊中的函數和符號都沒有固定的
300 位置。
301
302 內核支持系統調用，允許程序確定加載哪些模塊及其在內存中的位置。klogd守護進程
303 使用這些系統調用構建了一個符號表，可用於調試可加載內核模塊中發生的保護錯誤。
304
305 klogd至少會提供產生保護故障的模塊的名稱。如果可加載模塊的開發人員選擇從模塊
306 導出符號信息，則可能會有其他可用的符號信息。
307
308 由於內核模塊環境可以是動態的，因此當模塊環境發生變化時，必須有一種通知
309 ``klogd`` 守護進程的機制。有一些可用的命令行選項允許klogd向當前正在執行的守
310 護進程發出信號示意應該刷新符號信息。有關更多信息，請參閱 ``klogd`` 手冊頁。
311
312 sysklogd發行版附帶了一個補丁，它修改了 ``modules-2.0.0`` 包，以便在加載或
313 卸載模塊時自動向klogd發送信號。應用此補丁基本上可無縫支持調試內核可加載模塊
314 發生的保護故障。
315
316 以下是 ``klogd`` 處理的可加載模塊中的保護故障示例::
317
318 Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc
319 Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000
320 Aug 29 09:51:01 blizard kernel: *pde = 00000000
321 Aug 29 09:51:01 blizard kernel: Oops: 0002
322 Aug 29 09:51:01 blizard kernel: CPU: 0
323 Aug 29 09:51:01 blizard kernel: EIP: 0010:[oops:_oops+16/3868]
324 Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212
325 Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c
326 Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c
327 Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
328 Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000)
329 Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001
330 Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00
331 Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036
332 Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128]
333 Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3
334
335 ---------------------------------------------------------------------------
336
337 ::
338
339 Dr. G.W. Wettstein Oncology Research Div. Computing Facility
340 Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com
341 820 4th St. N.
342 Fargo, ND 58122
343 Phone: 701-234-7556
344
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.