Documentation/translations/zh_TW/admin-guide/bug-hunting.rst

   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 <src.res@email.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