故障现象

某客户ISV日常巡检过程中发现三天内有两台主机的操作系统有异常重启记录，但未在message中发现任何异常信息。所以请求我们技术团队配合查找异常宕机的故障原因。

排查过程

现场服务工程师使用 sosreport 命令收集故障主机的系统信息后，转发给我。

1. 粗看两台主机故障时间段的message日志，确实没有发现任何问题

2. 在./var/crash/下发现kdump内存转储日志，故障时主要相关信息记录信息如下：

[7008765.331940] BUG: unable to handle kernel NULL pointer dereference at 0000000000000007
[7008765.331972] PGD 0 P4D 0
[7008765.331984] Oops: 0002 [#1] SMP PTI
[7008765.332000] CPU: 6 PID: 195 Comm: kswapd0 Kdump: loaded Not tainted 4.19.0-240.23.11.el8_2.bclinux.x86_64 #1
[7008765.332029] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.16707776.B64.2008070230 08/07/2020
[7008765.332681] RIP: 0010:split_swap_cluster+0x4a/0x60
[7008765.332698] Code: c1 e3 06 48 c1 eb 0f 48 8d 1c d8 48 89 df e8 fd 61 64 00 80 63 07 fb 48 85 db 74 16 48 89 df c6 07 00 0f 1f 40 00 31 c0 5b c3 <80> 24 25 07 00 00 00 fb 31 c0 5b c3 b8 f0 ff ff ff 5b c3 0f 1f 00
[7008765.332752] RSP: 0018:ffffb40d06abbb98 EFLAGS: 00010246
[7008765.332767] RAX: 0000000000000000 RBX: 000000000001b3ed RCX: ffffb40d077fc000
[7008765.332787] RDX: 000000000001b3ed RSI: ffff89ecbddb05e0 RDI: 000000000001b3ed
[7008765.332806] RBP: fffff5c611ea0080 R08: fffff5c611ea1548 R09: ffff89ecfffd6000
[7008765.332826] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[7008765.332845] R13: fffff5c611ea8000 R14: fffff5c611ea8000 R15: ffff89ec8f2e47e8
[7008765.332865] FS:  0000000000000000(0000) GS:ffff89ecbdd80000(0000) knlGS:0000000000000000
[7008765.332887] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[7008765.332904] CR2: 0000000000000007 CR3: 0000000fd900a001 CR4: 00000000007606e0
[7008765.332958] PKRU: 55555554
[7008765.332968] Call Trace:
[7008765.333011]  split_huge_page_to_list+0x7bd/0x830
[7008765.333030]  deferred_split_scan+0x1ca/0x320
[7008765.333050]  do_shrink_slab+0x132/0x280
[7008765.333068]  shrink_slab+0xad/0x2b0
[7008765.333080]  shrink_node+0xcd/0x3d0
[7008765.333097]  balance_pgdat+0x1f0/0x340
[7008765.333110]  kswapd+0x217/0x400
[7008765.333122]  ? finish_wait+0x80/0x80
[7008765.333134]  ? balance_pgdat+0x340/0x340
[7008765.333147]  kthread+0x112/0x130
[7008765.333162]  ? __kthread_parkme+0x70/0x70
[7008765.333182]  ret_from_fork+0x35/0x40
[7008765.333198] Modules linked in: udp_diag tcp_diag inet_diag binfmt_misc vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock sunrpc vfat fat intel_rapl_msr intel_rapl_common isst_if_mbox_msr isst_if_common nfit mousedev libnvdimm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper vmw_balloon intel_rapl_perf psmouse pcspkr vmw_vmci i2c_piix4 ip_tables xfs libcrc32c sr_mod cdrom sd_mod sg ata_generic vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crc32c_intel drm serio_raw vmw_pvscsi vmxnet3 ata_piix dm_mirror dm_region_hash dm_log dm_mod
[7008765.334725] CR2: 0000000000000007

通过以上信息，可知该操作系统为某国产操作系统，使用的是  4.19.0 版本的Linux Kernel。

通过故障上下文的关系，初步可判断为操作系统在拆分内存大页（huge pages）的过程中出现问题，导致 系统无法处理一个内核的空指针应用。

检查内核参数，确实操作系统是否默认开启了内存大页的使用权限：

# cat ./sos_commands/kernel/sysctl_-a | grep vm.nr_hugepages
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0

检查结果为0，未默认启动。

再检查GURB菜单项是否有默认启动参数

# cat ./proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-4.19.0-240.23.11.el8_2.bclinux.x86_64 root=/dev/mapper/bel-root ro crashkernel=auto resume=/dev/mapper/bel-swap rd.lvm.lv=bel/root rd.lvm.lv=bel/swap rhgb quiet

检查结果未发现在GRUB菜单中配置有默认的大页使用参数。

综上所述，整理已知信息如下：

操作系统：BC Linux el8.2

内核版本：Kernel 4.19.0

故障现象：操作系统在未启用大页(huge pages)的情况下，系统在处理拆分大页时出现了问题。

怀疑是一个操作系统的bug。

解决方案

因为粗看使用的是4.19的内核，我习惯性的在国内的龙蜥和欧拉两个社区进行检索查找，未果。最后在Linux基金会的网站上找到一个相关补丁修复说明：

[032/156] mm: fix a race during THP splitting

但是，这个补丁修复是针对kernel 5.9.0的，我尝试查询该国产操作系统是否有相关的补丁回合记录，但是该操作系统未提供相关查询功能，所以暂时只能选择退而求稳的笨办法，建议客户将当前的kernel版本升级成该国产操作系统相对较新的版本BC Linux el8.8 所使用的内核，再进一步观察是否还会持续报错。

写在最后

该国产操作系统对外宣传的其el8系列是基于OpenAnolis 8系列发布的商业发行版。

但是请大家注意：

OpenAnolis 8 默认使用的Linux Kernel是 4.19.91

openEuler 20.03LTS 默认使用的Linux Kernel是 4.19.90

而本次故障，生产环境当中使用的Linux Kernel版本号是4.19.0。

理论上从4.19.0到4.19.91，作为Linux Kernel的核心管理团队是修复了大量的相关内核漏洞和bug的。但是该国产操作系统宣传的和实际生产环境使用的情况不一致，会导致最终用户使用成本的增加和各种运行风险。这是提倡国产化的当下大环境下不应该出现的。更何况本次故障Linux基金会是针对在5.9.0及以上做了修复。以前使用红帽、CentOS和SUSE的经验来说，至少可用通过查询新发布的Linux Kernel的changelog，确认这些高版本补丁是否向下移植到了当前正在使用的低版本Linux Kernel上。但是我通过各种尝试最终还是没有办法进行相关确认。这样看来我们的操作系统国产化之路，依然任重而道远啊。