xref: /linux/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst (revision 06d07429858317ded2db7986113a9e0129cd599b) 
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
74Oops消息在哪？
75---------------
76
77通常，Oops文本由klogd從內核緩衝區讀取，然後交給 ``syslogd`` ，後者將其寫入
78syslog文件，通常是 ``/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
109gdb
110^^^^
111
112GNU 調試器（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
187objdump
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
262ML），抄送驅動程序維護者（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
305klogd至少會提供產生保護故障的模塊的名稱。如果可加載模塊的開發人員選擇從模塊
306導出符號信息，則可能會有其他可用的符號信息。
307
308由於內核模塊環境可以是動態的，因此當模塊環境發生變化時，必須有一種通知
309``klogd`` 守護進程的機制。有一些可用的命令行選項允許klogd向當前正在執行的守
310護進程發出信號示意應該刷新符號信息。有關更多信息，請參閱 ``klogd`` 手冊頁。
311
312sysklogd發行版附帶了一個補丁，它修改了 ``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
345