宿主機配置(zhi)：Intel 8378 cpu + ctyunos 64內核， cpu 微(wei)碼版本(ben)：0d000311

卡死時的vmcore-dmesg.txt 中call trace如下：

圖-1

crash調試bt如下：

圖-2

圖-3

異常地址(zhi)0xfffef7efbfee2dba,但查看該地址(zhi)也不在(zai)正常的內核地址(zhi)映射(she)范(fan)圍(wei)之內:

圖-4

內核異常時的錯誤碼為0x0010，對應指令預取造成

圖-5

反匯編EIP對應地址為

圖-6

從上(shang)邊堆棧IP的(de)值是0xffffffff8c6e1e40，也就是x86_sys_ioctl的(de)入(ru)口地址。

也(ye)就(jiu)是說(shuo)異常發生(sheng)在x86_sys_ioctl的入口地址。

那我們看(kan)看(kan)是如何跳轉到x86_sys_ioctl，跳轉過程中有無異常。

__x64_sys_ioctl的更上(shang)一層的棧(zhan)信(xin)息（_MODULE_START_syshook_linux at ffffffffc08e5b93 [syshook_linux]）如下：

圖-7

上一個堆棧發生問題的地方是一條跳轉指令，反匯編跳轉地址0xffffffff8d003000。

圖-8

此處進入__x64_sys_ioctl路徑如下(xia)：

這個函數開始就執行了一條跳轉(zhuan)指令(ling)，跳轉(zhuan)到(dao)rax，根據上面(mian)異(yi)常堆棧的(de)情況，rax的(de)值為(wei)

0xffffffff8c6e1e40，也(ye)就是跳轉(zhuan)到__x64_sys_ioctl時發生了異常(chang)。

call 0xffffffff8d003000àjmpq *raxà__x64_sys_ioctl

結論：

從上面的分析日志和分析可以看出，內存中RAX和IP寄存器的值是正確的，不存在內存中IP地址非法的問題。但在跳轉過程中，cpu IP寄存器得到了一個非法地址，導致cpu指令預取失敗，內核crash。后續intel加入分析，發現有一個微碼bug和此問題類似，主機更新微碼后未再出現。
此類問題(ti)單純從軟件(jian)分析會發現非常奇怪，代(dai)碼(ma)突然跑飛，此時可以考慮微(wei)碼(ma)問題(ti)，可升級(ji)到(dao)最新(xin)微(wei)碼(ma)再驗證。