LTP测试套件运行时为何频繁出现“test skipped: not supported”？

Question

LTP测试套件运行时频繁出现“test skipped: not supported”，通常并非缺陷，而是LTP的主动兼容性保护机制。根本原因在于：测试用例在编译或运行时检测到当前内核版本、配置选项（如`CONFIG_SECCOMP`、`CONFIG_USER_NS`）、硬件能力（如AVX指令集）或用户权限（如非root运行namespace/capability类测试）不满足其前置依赖，便自动跳过并输出该提示。常见诱因包括：内核未启用对应子系统（如`CONFIG_MEMCG`缺失导致memcg相关测试跳过）、glibc版本过低（影响nptl或time64测试）、缺少必要工具（如`unshare`未安装导致clone3测试跳过），或LTP未针对当前平台（如ARM64）完整适配。需结合`ltp-run.log`与`/proc/config.gz`交叉分析具体跳过原因，而非简单忽略——大量跳过往往反映环境配置与LTP预期严重不匹配，可能掩盖真实稳定性风险。

Answer 1

```html

一、现象识别：理解“test skipped: not supported”的语义本质

该提示并非测试失败（FAIL）或错误（ERROR），而是LTP（Linux Test Project）在运行时主动执行的兼容性守卫逻辑。每个测试用例（如 memcg_stress01、clone3_01）均内嵌预检函数（如 is_supported()），在setup()阶段即完成环境探针——若探测失败，立即返回TCONF（Test Configured Not Supported），触发跳过并输出标准提示。此机制设计初衷是避免因内核缺失功能、glibc ABI不兼容或硬件指令不可用导致的未定义行为（UB）或段错误（SIGSEGV），属于LTP工程化健壮性的核心体现。

二、根因分层：四维依赖模型解析跳过动因

LTP跳过行为可映射至如下四维依赖模型，任一维度不满足即触发跳过：

维度	典型检查项	对应配置/工具示例	跳过表现示例
内核配置	/proc/config.gz 或 CONFIG_USER_NS=y	zcat /proc/config.gz | grep CONFIG_USER_NS	userns01: test skipped: not supported (user namespaces not available)
用户空间栈	glibc版本、time64支持、NPTL线程模型	getconf GNU_LIBC_VERSION, ldd --version	time64_01: test skipped: not supported (glibc too old for time64)
硬件能力	CPU特性（AVX-512, SME, SVE）、内存拓扑	grep avx512 /proc/cpuinfo, lscpu | grep "Flags"	avx512f_01: test skipped: not supported (AVX-512F not detected)
运行时上下文	root权限、必需工具链、namespace隔离能力	which unshare, capsh --print	clone3_01: test skipped: not supported (unshare not found)

三、诊断路径：日志与内核配置的交叉验证法

关键诊断步骤需同步分析两份黄金数据源：ltp-run.log（含跳过堆栈与检测点）与/proc/config.gz（内核编译真相）。推荐执行以下链式命令：

# 提取所有跳过记录及前5行上下文
grep -A5 -B1 "test skipped: not supported" ltp-run.log | head -n 50

# 解压内核配置并定位相关选项（以USER_NS为例）
zcat /proc/config.gz 2>/dev/null | grep -E "(USER_NS|SECCOMP|MEMCG)" || \
  (echo "/proc/config.gz missing — fall back to /boot/config-$(uname -r)")

# 检查glibc是否支持time64（需≥2.34）
getconf GNU_LIBC_VERSION | awk -F' ' '{split($2,a,"."); if(a[1]<2 || (a[1]==2 && a[2]<34)) print "time64 unsupported"}'

四、平台适配：ARM64与RISC-V等新兴架构的特殊考量

LTP主干对x86_64覆盖最全，而ARM64/RISC-V平台存在显著适配缺口：

• 部分测试依赖x86专属寄存器（如rdtsc）、指令（cpuid）或中断向量，在ARM上硬编码返回TCONF；
• RISC-V缺少seccomp-bpf完整实现，导致seccomp01~09系列批量跳过；
• ARM64的SVE向量扩展需额外启用CONFIG_ARM64_SVE=y，否则sve_test01恒跳过。

五、解决方案全景图：从临时规避到长期治理

下图展示系统性解决路径，涵盖快速验证、配置加固、源码级修复三阶段：

graph TD A[发现大量TCONF] --> B{是否为已知平台缺陷？} B -->|是| C[应用LTP社区补丁
e.g. arm64-clone3-fix.patch] B -->|否| D[分析ltp-run.log定位首跳用例] D --> E[检查/proc/config.gz + glibc + 工具链] E --> F[启用缺失CONFIG_* 或 升级glibc] F --> G[重新编译LTP：make clean && make] G --> H[验证：runltp -f syscalls -s clone3_01] C --> H

六、工程实践建议：构建可审计的LTP基线环境

面向5年以上经验的SRE/Kernel Engineer，建议建立如下生产就绪规范：

1. 在CI流水线中强制校验/proc/config.gz与LTP要求清单（由scripts/gen_config_req.py生成）的一致性；
2. 为每个目标平台（x86_64/ARM64/RISC-V）维护独立的ltp-config-profile.yaml，声明必开CONFIG项与最小glibc版本；
3. 将ltp-run.log中的TCONF条目自动聚类并生成skip-report.html，标注“环境缺失”与“LTP未适配”两类根因；
4. 对长期无法启用的子系统（如CONFIG_MEMCG因性能顾虑被禁用），编写白名单跳过策略，避免污染稳定性指标。

七、风险警示：忽视TCONF可能掩盖深层稳定性隐患

当TCONF占比＞15%（按用例总数计），往往预示着更严峻的问题：例如内核启用了CONFIG_HARDENED_USERCOPY但未同步升级glibc，导致大量copy_from_user类测试跳过——这实际暴露了用户空间与内核ABI的隐性断裂；又如在容器环境中运行LTP却未挂载/proc/sys/kernel/ns_last_pid，造成namespace测试全跳，却掩盖了cgroup v2迁移过程中的资源泄漏风险。因此，TCONF不是噪音，而是系统健康度的早期预警信号。

```