为什么 mce 恐慌@4.18内核传递@5.15内核

Question 1

基于下面列出的几个事实，我的工作理论是发生了未纠正的硬件内存错误 (UHME)，导致了 NMI。在处理NMI期间，发生页面错误。增加抢占计数可能会出现操作顺序问题，或者可能会出现允许 nmi_handler 内部出现页面错误的错误。

CentOS 4.18.0.348 的代码与主线 Linux 4.18.0 代码库有很大不同。 5.x 版本的许多功能已向后移植到 CentOS 的 4.18.0.x 中。此代码仅经过 RedHat 审查，因此出现错误的可能性可能较高。

我的研究意见是该图展示了事件的流程。

用户态 einj_mem_uc。
启动nmi_enter()，in_nmi()为假，直到preempt_count_add()设置为真。
nmi 处理程序内部开始处理 NMI 中断。
发生页面错误，我们跳转到页面错误处理程序。
页面错误处理程序将 in_nmi() 保留为 true 并以 iret 退出。
Intel iret 缺陷强制将 in_nmi() 值清除为 false。
返回 hmi 处理程序，处理程序内的 in_nmi() 为 false。
nmi 处理程序返回 nmi_exit，触发 BUG_ON(!in_nmi()) 检查。
这会导致恐慌，然后停止或重新启动。

我有预感主线 4.18.1 也会像 5.15 内核一样工作。

最初我完成了另一个的源代码工作问题。

Answer

基于下面列出的几个事实，我的工作理论是发生了未纠正的硬件内存错误 (UHME)，导致了 NMI。在处理NMI期间，发生页面错误。增加抢占计数可能会出现操作顺序问题，或者可能会出现允许 nmi_handler 内部出现页面错误的错误。

CentOS 4.18.0.348 的代码与主线 Linux 4.18.0 代码库有很大不同。 5.x 版本的许多功能已向后移植到 CentOS 的 4.18.0.x 中。此代码仅经过 RedHat 审查，因此出现错误的可能性可能较高。

我的研究意见是该图展示了事件的流程。

用户态 einj_mem_uc。
启动nmi_enter()，in_nmi()为假，直到preempt_count_add()设置为真。
nmi 处理程序内部开始处理 NMI 中断。
发生页面错误，我们跳转到页面错误处理程序。
页面错误处理程序将 in_nmi() 保留为 true 并以 iret 退出。
Intel iret 缺陷强制将 in_nmi() 值清除为 false。
返回 hmi 处理程序，处理程序内的 in_nmi() 为 false。
nmi 处理程序返回 nmi_exit，触发 BUG_ON(!in_nmi()) 检查。
这会导致恐慌，然后停止或重新启动。

我有预感主线 4.18.1 也会像 5.15 内核一样工作。

最初我完成了另一个的源代码工作问题。

Question 2

正如我在评论和回答时所怀疑的那样你的第一个相关问题你通常会面临双重错误。我在这里添加：可能还有三重。（4.18下）

仅针对 4.18（因为此内核选项仅适用于 5.7），我建议您检查内核 .config 文件中的设置CONFIG_双重故障这应该启用双错误异常处理程序。
（请注意评论：禁用此选项...可能会导致您白发增多。;-)）如果未设置，则内核将无法处理这种情况，并且会默默地重新启动。
如果你确实设置了它，那么你的 4.18 实际上面临着三重故障。（我认为这不太可能，因为我预计至少会开始第二次跟踪转储）=>我怀疑您的 4.18 配置中未设置 CONFIG_DOUBLEFAULT。

为什么5.15下不会出现这种情况:

从 5.8 开始，如果 x32 架构保留以前处理双故障的方法，则 x86_64 架构将受益于一项功能（i386 上不可用）：中断堆栈表。这使得能够针对指定事件（例如双故障或 NMI）自动切换到新堆栈。
由于初始内存故障涉及堆栈（在原子上下文中调度），因此在跟踪转储时会发生双重故障，在回溯转储时会发生三重故障。
而从 x86_64 上的 5.8 开始，切换到某些新堆栈（无内存错误）的可能性有助于优雅地处理双重错误。

Answer

正如我在评论和回答时所怀疑的那样你的第一个相关问题你通常会面临双重错误。我在这里添加：可能还有三重。（4.18下）

仅针对 4.18（因为此内核选项仅适用于 5.7），我建议您检查内核 .config 文件中的设置CONFIG_双重故障这应该启用双错误异常处理程序。
（请注意评论：禁用此选项...可能会导致您白发增多。;-)）如果未设置，则内核将无法处理这种情况，并且会默默地重新启动。
如果你确实设置了它，那么你的 4.18 实际上面临着三重故障。（我认为这不太可能，因为我预计至少会开始第二次跟踪转储）=>我怀疑您的 4.18 配置中未设置 CONFIG_DOUBLEFAULT。

为什么5.15下不会出现这种情况:

从 5.8 开始，如果 x32 架构保留以前处理双故障的方法，则 x86_64 架构将受益于一项功能（i386 上不可用）：中断堆栈表。这使得能够针对指定事件（例如双故障或 NMI）自动切换到新堆栈。
由于初始内存故障涉及堆栈（在原子上下文中调度），因此在跟踪转储时会发生双重故障，在回溯转储时会发生三重故障。
而从 x86_64 上的 5.8 开始，切换到某些新堆栈（无内存错误）的可能性有助于优雅地处理双重错误。

Question 3

认为它与内核无关，而只是一个硬件内存错误，即您使用较新的内核命中该内存地址，而不是使用旧内核命中该内存地址。您进行过内存测试吗？

Answer

认为它与内核无关，而只是一个硬件内存错误，即您使用较新的内核命中该内存地址，而不是使用旧内核命中该内存地址。您进行过内存测试吗？

Question 4

似乎BUG_ON(true)会触发一个内核BUG，即invalid opcode 0000

如果在这种情况下是，那么

BUG_ON(!in_nmi());

触发此转储。

Answer

似乎BUG_ON(true)会触发一个内核BUG，即invalid opcode 0000

如果在这种情况下是，那么

BUG_ON(!in_nmi());

触发此转储。

为什么 mce 恐慌@4.18内核传递@5.15内核

答案1

答案2

答案3

答案4

相关内容