Linux kernel release 5.x (4/4)

https://www.kernel.org/doc/html/latest/admin-guide/README.html

Docs » The Linux kernel user’s and administrator’s guide »
Linux kernel release 5.x ＜ http://kernel.org/ ＞

# If something goes wrong

> If you have problems that seem to be due to kernel bugs, please check the file MAINTAINERS to see if there is a particular person associated with the part of the kernel that you are having trouble with. If there isn’t anyone listed there, then the second best thing is to mail them to me (torvalds at linux-foundation.org), and possibly to any other relevant mailing-list or to the newsgroup.

カーネルのバグが原因であると思われる問題がある場合は、file MAINTAINERSを確認して、問題のあるカーネルの一部に関連する特定の人物がいないかどうかを確認してください。 もし、そこに誰もリストされていない場合には、2番目に良いことは私（Torvalds at linux-foundation.org）に、そしておそらく他の関連するメーリングリストまたはニュースグループに連絡することです。

> In all bug-reports, please tell what kernel you are talking about, how to duplicate the problem, and what your setup is (use your common sense). If the problem is new, tell me so, and if the problem is old, please try to tell me when you first noticed it.

全てのバグ報告に対しては、どのカーネルについてなのか、問題を再現するにはどうしたらよいのか、どのようにセットアップをしているのか（常識を使って）教えてください。もし問題が新しい場合には教えてください。もし問題が古い場合には、最初に気が付いたのがいつかを教えてください。

> If the bug results in a message like:

バグにより次のようなメッセージが表示される場合：

```
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP:   0010:XXXXXXXX
eax: xxxxxxxx   ebx: xxxxxxxx   ecx: xxxxxxxx   edx: xxxxxxxx
esi: xxxxxxxx   edi: xxxxxxxx   ebp: xxxxxxxx
ds: xxxx  es: xxxx  fs: xxxx  gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
```

> or similar kernel debugging information on your screen or in your system log, please duplicate it exactly. The dump may look incomprehensible to you, but it does contain information that may help debugging the problem. The text above the dump is also important: it tells something about why the kernel dumped code (in the above example, it’s due to a bad kernel pointer). More information on making sense of the dump is in Documentation/admin-guide/bug-hunting.rst

あるいは、画面上にやシステムログに出力されるkernel debugging informationは、正確に複製してください。dumpはあなたにとってわかりにくいかもしれませんが、デバッグに役立つ情報も含まれていいます。ダンプ上のテキストも、重要です：これは、kernel dump codeがなぜ発生したのかを教えてくれます（前述の例では、kernel pointerの不正によって起きたものです）dumpの意味についての詳細は、Documentation/admin-guide/bug-hunting.rstにあります。

> If you compiled the kernel with CONFIG_KALLSYMS you can send the dump as is, otherwise you will have to use the ksymoops program to make sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). This utility can be downloaded from https://www.kernel.org/pub/linux/utils/kernel/ksymoops/ . Alternatively, you can do the dump lookup by hand:

CONFIG_KALLSYMSを付けてkernelをコンパイルした場合は、dumpをそのまま送信できます。そうでない場合には、ksymoops プログラムを使ってdumpを検出する必要があります（ただし、CONFIG_KALLSYMSが一般的には推奨されます）。このユーティリティは、`https://www.kernel.org/pub/linux/utils/kernel/ksymoops/` からダウンロードできます。または、手動でダンプ検索をすることもできます。

> In debugging dumps like the above, it helps enormously if you can look up what the EIP value means. The hex value as such doesn’t help me or anybody else very much: it will depend on your particular kernel setup. What you should do is take the hex value from the EIP line (ignore the 0010:), and look it up in the kernel namelist to see which kernel function contains the offending address.

上記のようなdumpをデバッグするとき、EIP値の意味を調べることができると非常に役立ちます。 16進数の値自体は、私や他の人にはあまり役立ちません。それぞれのkernel setupに依存します。 あなたがすべきことは、EIP行から16進数の値（0010：は無視）を取得し、それをkernel namelistで調べて、問題のあるアドレスを含むカーネル関数を確認することです。
（訳注：コンパイルオプションなどで、アドレス情報が変わる恐れがあるので、数字そのものには意味がない。問題なのは、どこの関数/コードで問題が起きているかを見極める事なので、アドレス情報が必要という話）

> To find out the kernel function name, you’ll need to find the system binary associated with the kernel that exhibited the symptom. This is the file ‘linux/vmlinux’. To extract the namelist and match it against the EIP from the kernel crash, do:

kernel function nameを見つけ出すためには、問題が発生しているkernelと関連付けられているシステムバイナリーを見つける必要があります。これは"linux/vmlinux"です。namelistを抽出し、kernel crashしたEIPと照合するには、次のようにします。

` nm vmlinux | sort | less `

> This will give you a list of kernel addresses sorted in ascending order, from which it is simple to find the function that contains the offending address. Note that the address given by the kernel debugging messages will not necessarily match exactly with the function addresses (in fact, that is very unlikely), so you can’t just ‘grep’ the list: the list will, however, give you the starting point of each kernel function, so by looking for the function that has a starting address lower than the one you are searching for but is followed by a function with a higher address you will find the one you want. In fact, it may be a good idea to include a bit of “context” in your problem report, giving a few lines around the interesting one.

これによって、kernel addressが昇順でソートして得られ、問題のアドレスを含む関数をみつけることが容易になります。

注意してください、kernel debugging messageで表示されるアドレスは、function addressに完全に一致するとは限りません（実際にそれはほとんどありません）。そのため、'grep'するだけでは不十分です。ただ、リストは各カーネル関数の先頭位置を示しています。そのため、検索しているアドレスよりも小さい開始アドレスを持ち、そのアドレスよりも大きいアドレスが続く関数を探す事で、目的のアドレスを見つけることができます。また実際のところ、"context"を含めて、興味深い数行をまとめることは良い考えかもしれません。

> If you for some reason cannot do the above (you have a pre-compiled kernel image or similar), telling me as much about your setup as possible will help. Please read the admin-guide/reporting-bugs.rst document for details.

なんらかの理由で上記を実行できない場合（rep-compileされたカーネルイメージを利用している等）、setupについてできるだけ詳しく教えてください。 詳細については、admin-guide/reporting-bugs.rstドキュメントをご覧ください。

> Alternatively, you can use gdb on a running kernel. (read-only; i.e. you cannot change values or set break points.) To do this, first compile the kernel with -g; edit arch/x86/Makefile appropriately, then do a make clean. You’ll also need to enable CONFIG_PROC_FS (via make config).

あるいは、実行中のカーネルでgdbを使用することもできます。 （読み取り専用であって、値を変更したり、ブレークポイントを設定したりすることはできません。）これを行うには、まず-gを使用してカーネルをコンパイルします。 そのためには、arch/x86/Makefileを適切に編集して、make cleanを実行します。 また（make configを使用して）CONFIG_PROC_FSを有効にする必要があります。

> After you’ve rebooted with the new kernel, do gdb vmlinux /proc/kcore. You can now use all the usual gdb commands. The command to look up the point where your system crashed is l *0xXXXXXXXX. (Replace the XXXes with the EIP value.)

新しいカーネルで再起動したら、gdb vmlinux /proc/kcoreを実行します。 すべての通常のgdbコマンドを使用できます。 システムがクラッシュしたポイントを検索するコマンドは、l * 0xXXXXXXXXです（XXXesをEIP値に置き換えます。）。

> gdb’ing a non-running kernel currently fails because gdb (wrongly) disregards the starting offset for which the kernel is compiled.

カーネルがcompileされている開始オフセットを（誤って）gdbが無視するため、現在、実行されていないカーネルのgdbは失敗します。

---
もともと、Linux Kernelのソースコードの一部なので、GPLv2扱いになる（はずの認識）。

> https://www.kernel.org/doc/html/latest/index.html
> 
> Licensing documentation
> 
> The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
> 
> https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing