util-linux项目中lscpu命令在uWSGI环境下崩溃问题分析与修复

问题背景
在特定环境下，当通过uWSGI服务调用util-linux工具包中的lscpu命令时，会出现核心转储（coredump）现象。该问题最初在util-linux 2.33.1版本中被发现，但在最新版本中依然存在。

技术分析
通过核心转储分析发现，崩溃发生在lscpu的虚拟化检测功能模块中。具体而言，是vmware_bdoor()函数尝试处理SIGSEGV信号时失败。深入分析表明：

1. 信号处理机制
   lscpu通过故意触发SIGSEGV信号来检测VMware虚拟化环境，这是通过以下步骤实现的：

   • 设置自定义SIGSEGV信号处理器
   • 执行可能引发段错误的指令
   • 通过sigsetjmp/siglongjmp实现异常恢复

2. uWSGI环境干扰
   uWSGI服务在子线程中会屏蔽所有信号（包括SIGSEGV），这种信号掩码会被继承到其子进程（如lscpu）。当lscpu尝试处理SIGSEGV信号时，由于信号被屏蔽，导致无法正常捕获和处理段错误，最终引发崩溃。

3. 根本原因
   问题的本质是信号处理环境的不兼容：lscpu假设它可以自由处理SIGSEGV信号，而uWSGI环境则默认屏蔽了所有信号，两者行为产生了冲突。

解决方案
修复方案需要在lscpu的信号处理逻辑中显式解除对SIGSEGV信号的屏蔽，并在处理后恢复原始信号掩码。具体实现包括：

1. 在信号处理器设置前保存原始信号掩码
2. 显式解除对SIGSEGV信号的屏蔽
3. 在信号处理完成后恢复原始信号掩码
4. 在异常恢复路径中也确保信号掩码被正确恢复

修复代码要点
关键修改集中在lscpu-virt.c文件中：

• 新增信号掩码保存变量oset
• 在segv_handler中恢复原始信号掩码
• 在is_vmware_platform()中临时解除SIGSEGV屏蔽
• 确保所有执行路径都正确恢复信号环境

技术启示
这个案例揭示了几个重要的系统编程实践：

1. 信号处理需要考虑执行环境的特殊性
2. 信号掩码的继承性可能引发意料之外的问题
3. 系统工具需要更健壮地处理受限的执行环境
4. 信号相关操作应该总是成对出现（保存/恢复）

兼容性考虑
该修复方案不仅解决了uWSGI环境下的问题，同时也保持了工具在其他环境中的原有行为，是一个向后兼容的解决方案。

总结
通过对util-linux中lscpu命令信号处理机制的改进，有效解决了在uWSGI等特殊环境下崩溃的问题。这个案例展示了系统工具开发中环境适应性的重要性，也为类似信号处理相关问题提供了参考解决方案。