Taming System Complexity: Demystifying Software Engineering Agents in Diagnosing Linux Kernel Faults

Idea

论文用LinuxFLBench系统检验通用software engineering agents在Linux kernel的fault localization能力，再提出LinuxFL+对已有预测做目录与潜在原因扩展。它利用文件结构和历史LKML邮件补足搜索范围，以较小额外推理成本重新排序可能的故障文件。

Research Problem

SWE-bench等常见环境以规模较小的Python项目为主，不能代表kernel庞大文件空间、复杂日志和硬件相关故障。研究发现agents经常识别到相关module却选错邻近文件，或只检验少数看似最可能的原因，从而漏掉真实根因。

Insight

初始预测即使不精确，也可提供局部目录和相关代码文件作为检索先验；独立生成更多原因假设并用历史修复讨论补充，可从另一条路径找回漏掉候选。结构邻近与原因推断互补，最终合并排序比完全重新运行完整agent更节约成本。

Method

1. 从Kernel Bugzilla收集CLOSED/CODE_FIX且有patch的报告，只保留官方版本代码与单个.c/.h文件修改，再人工删除非bug、信息不足和直接泄露位置/修法的样本，得到250项、覆盖120版本的file/method localization任务。
2. 用统一GPT-4o比较SWE-Agent、AutoCodeRover、Agentless及IR baselines，以Recall@1/5/10与MRR评估；人工分析共同失败案例，提炼相关文件混淆和原因探索不足。
3. Directory-Aware Expansion查看初始预测目录中的所有文件并选top-10；Direct Hypothesis要求模型列潜在原因、可能修复及需改文件；Mail-Augmented Hypothesis检索含patch的历史LKML邮件，按初始文件限制范围并用重写bug描述做BM25。
4. 邮件限于报告之前、去除过多文件修改及特定链接/bugzilla内容；三个来源以reciprocal rank sum合并候选，再由LLM按path与report语义重排，必要时利用文件skeleton进一步定位函数、结构体等代码块。