7.2 静态分析与编码规范

7.2 静态分析与编码规范

本节摘要：一大类驱动缺陷不需要运行就会暴露——前提是用对工具。本节讲稀疏检查如何借类型标注抓用户指针误用、锁平衡检查如何抓加解锁不对称，编码规范为什么是内核社区的门禁而非洁癖，以及把检查自动化进构建流程的实践。

7.1 节两起故障都靠动态排查破案，成本高昂。而像"把用户指针当内核指针解引用""锁路径漏解锁"这类缺陷，静态分析工具在编译期就能点名道姓——调试的高级形态是让缺陷根本没有机会运行。

稀疏检查：让类型系统替你站岗

内核代码里那些看似多余的标注——__user、__iomem、__percpu——不是注释，是给稀疏检查器的合同。检查器用一套独立于编译器的类型规则审查代码，专抓"跨地址空间的越界使用"：

$ make C=2 M=drivers/leds      # C=2 对全部文件跑稀疏检查
drivers/leds/board-led.c:88:13: warning: incorrect type in argument 1
    (different address spaces)  expected void const [noderef] __user *buf
    got char *buf               ← write 回调把用户指针传给了普通函数

drivers/leds/board-led.c:132:9: warning: dereference of noderef expression
                               ← 直接解引用了 __iomem 指针
​

第一类告警正是 2.3 节翻车现场的静态版：某个函数的参数声明为普通指针，调用时却把用户指针塞了进去——检查器不运行代码，仅凭类型不匹配就能断定"跨边界未拷贝"。第二类对应 3.1 节的规矩：__iomem 指针必须走专用访问函数，裸解引用一律报警。

治理办法是把标注当 API 的一部分认真写：回调签名照抄内核原型、跨边界传参前先拷贝、检查器告警清零才提交。一个告警背后是一类地址空间违规，不是风格问题。

锁平衡检查：不对称路径无所遁形

6.1 节强调"锁保护操作序列"，但序列对称性靠人眼审查非常脆弱：提前返回的错误路径漏解锁、中断版本与进程版本的锁配对错误、递归加锁自死锁——这些都能被内核自带的锁依赖检查器在运行时抓现行，而静态检查器在编译期就能找出"某条路径上锁数量不平衡"的函数。

/* 检查器能看出的典型不对称 */
static long demo_ioctl(unsigned int cmd, unsigned long arg)
{
    mutex_lock(&cfg_lock);

    switch (cmd) {
    case CMD_SET:
        if (arg > MAX) {
            return -EINVAL;        ← 提前返回：锁没放！
        }
        apply_config(arg);
        break;
    default:
        mutex_unlock(&cfg_lock);
        return -ENOTTY;
    }

    mutex_unlock(&cfg_lock);
    return 0;
}
​

这类"错误路径漏放锁"在高频命令下表现为设备随机卡死，动态定位极难——静态检查一眼点名。治理模式是单一出口：函数体统一走到底部解锁，或用框架的自动化清理机制（内核的 goto 清理链、托管资源）保证每条路径的锁动作配平。

检查工具谱系：各抓一类问题

实践中的顺序：本地提交前跑风格与稀疏检查（秒级成本）、集成环境跑静态扫描（分钟级）、开发板上长期挂锁检查与内存检查（小时级）——成本越高的检查越往后放，但一个都不能省。

编码规范：不是洁癖，是门禁

内核编码规范在圈内的名声两极分化：初学者觉得是繁文缛节，维护者视其为社区通用语。它的真实价值有三层。认知负担层：统一的缩进、命名、函数长度约定，让任何维护者能在五分钟内进入陌生代码——六百多万行的代码库靠这点维持着可读性。缺陷预防层：规范里许多条款直接对应缺陷模式，比如限制单文件内静态函数的可见性、要求错误处理不嵌套超过三层，都是在压制造错空间。协作门禁层：邮件列表的审查者对规范偏差零容忍——不是傲慢，是审查带宽有限，格式噪音会淹没真正的设计讨论。

$ ./scripts/checkpatch.pl --file drivers/leds/board-led.c
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: line over 80 characters
ERROR: do not use assignment in if condition
total: 1 errors, 2 warnings, 45 lines checked
​

对驱动作者的务实建议：把风格检查与稀疏检查做成构建的固定环节（构建脚本里一条命令），让机器当第一审查员；自己把精力留给审查者真正关心的东西——设计取舍与并发正确性。

💡 关键直觉：静态工具的价值密度随项目规模上升。单人小项目里它们抓的是"低级错误"，多人长周期项目里它们是保持代码库不腐化的免疫系统——每条告警都是一次"这里可能偏离了约定"的提醒。

把检查织进构建：本地流水线一瞥

零散跑工具靠自觉，织进构建才长久。一段实用的本地检查流水线长这样：

#!/bin/bash
set -e
KDIR=/path/to/target-kernel

# 一 风格检查：提交前必过
./scripts/checkpatch.pl --no-tree -f drivers/leds/board-led.c

# 二 稀疏检查：地址空间与上下文标注
make -C "$KDIR" M="$PWD" C=2 modules 2>&1 | grep -E "warning: (incorrect|dereference)"

# 三 静态缺陷扫描：独立工具全量扫
smatch_scripts/build-kernel.sh 2>/dev/null || true

# 四 构建产物一致性
ls -l *.ko && md5sum *.ko > build-artifacts.md5
​

四步按成本递增排列，任何一步报警都中止流水线——检查的价值在于"不过就不许继续"的强制性，而不在于跑过多少种工具。团队协作时把这条流水线挂到版本库钩子或持续集成的提交阶段，新人提交第一份补丁起就被同一标准约束，规范才真正长在项目里。

💡 关键直觉：静态检查的本质是"把类型系统借给约定用"。__user、__iomem 这些标注在编译器眼里什么都不是，专门的分析器却拿它们当类型不匹配的证据——你多写一个标注，机器就多替你站一班岗。这正是内核代码里"看着没用"的宏与标注如此密集的原因：每一处标注都是写给未来的检查器，也是写给未来的评审者。

本节要点回顾

• 类型标注是合同：__user 与 __iomem 配合稀疏检查，编译期抓跨空间违规。
• 锁平衡靠机器不靠眼：错误路径漏解锁是静态检查的高产区。
• 检查按成本分层前置：风格与稀疏在本地、扫描在集成、运行期检查在板上长跑。
• 规范是协作基础设施：格式噪音会淹没设计讨论，机器先把它们清干净。

静态手段管住了"写出来的缺陷"，但驱动还要经受"运行起来的世界"——下一节的压力测试专门制造恶劣环境。