内核编程与应用编程对比

内核编程与应用编程对比

研究底层技术、阅读Linux内核源码，一直是很多技术人的兴趣所在。但坦白说，尽管对此抱有热情，真正专职从事内核开发的机会并不多。以笔者为例，早年工作虽涉及负载均衡，但数据处理仍停留在应用层——当然，这与应用编程常见的业务逻辑开发已有很大不同。

直到当前这份工作，才算真正扎进了内核开发的领域。对于资源有限的小公司而言，有时确实没有余力去构建应用层的协议栈。即便有netmap、DPDK这类成熟框架，以及轻量级的用户态协议栈如lwip可选。将数据包映射到用户空间，不仅会带来内存管理、连接控制等额外工作量，还意味着无法直接利用netfilter（例如iptables）已有的功能——尽管后者的效率或许不是最高。

尽管缺乏正式的内核开发经验，但凭借过往的技术积累，还是接下了内核模块的开发任务。这多少有些“被迫勇敢”的成分，毕竟团队里没有更合适的人选。好在负责的是相对独立的网络模块，从结果来看，整个过程还算顺利。

转眼三个多月过去，模块运行基本稳定，没出过大问题。期间踩过不少小坑，也解决了不少难题，于是决定写篇东西记录和分享一下——你看，铺垫了这么多才切入正题，我果然很会跑题。希望这些心得，能给有志于内核开发的朋友带来一些参考。

到目前为止，内核编程给人最深刻的体会，是程序的“执行流”异常复杂，其并发逻辑远比应用编程来得棘手。这里提到的“执行流”是个自创的说法，但大致能传达意思。在应用编程中，谈到并发，无非是多进程、多线程，通常用锁保护好共享资源，问题就不大了。一个线程可以看作一个执行流，只要不被信号打断，代码总是顺序执行。换言之，我们在应用层写的代码和业务逻辑，只会被我们自己创建的线程或进程执行。信号处理函数通常也写得很简单，多半只是设置个标志位。

但在内核里，情况就大不相同了。中断、软中断、定时器、系统调用……这些都可能成为切入业务逻辑的执行流。由于内核自身的特性，对共享资源的保护也需要仔细斟酌，选用不同的手段。

举个例子，某些共享资源最初用spin_lock保护，但随着功能增加，需要加入与用户空间的交互。实现时，有时会直接调用现有的代码模块。结果发现，那些模块里对共享资源的保护也用了spin_lock，而数据包转发的核心逻辑又跑在软中断里，一不小心，就导致了死锁。

除了自己踩坑，也修复过别人留下的bug。其中一个问题令人印象深刻：产品会不定期重启，但在我们本地环境却无法复现。刚接触产品代码时，面对这种难以重现的重启bug，最笨的方法往往最有效——代码审查。幸好核心功能的代码量不算庞大，花了两天时间读懂大部分逻辑，顺手修正了几个可能导致重启的隐患。客户升级后，问题大部分消失了，但仍有零星重启现象。这说明，还有漏网之鱼。

这时，整个关键流程已经在脑海里梳理清楚了。解决这个问题的过程很有意思：靠在椅背上，望着天花板，心里把数据包从入口到出口的完整流程，连同所有分支和特殊情况，从头到尾推演了一遍。然后，灵光一现！整个过程不到十五分钟。接着便是查看代码，验证猜想。

问题根源如下：出于某种业务需求，代码申请了一个动态结构体，并设置了超时定时器，到期释放。当业务逻辑访问该结构时，会刷新其访问时间，延长生命周期。但在某些情况下，需要提前删除这个结构，这时会调用del_timer删除定时器，然后释放内存。看到这样的代码，立刻让人警觉：如果调用del_timer时，定时器正在执行，怎么办？一查资料，果然，del_timer返回并不能保证定时器没有正在执行。那么，定时器还在执行，动态结构却被释放了，定时器也随之释放，这样的代码显然有问题。

如何解决？第一个念头是保证同步删除，用del_timer_sync。但仔细一想，这仍有问题。这个动态结构原本是靠定时器超时释放的，现在要强制释放，即便用del_timer_sync停掉了定时器，也可能定时器已经超时并完成了释放操作，此时再强制释放就成了双重释放。同时，del_timer_sync这种同步操作，必然带来性能开销。最终的解决方案是增加一个标志位，在强制删除时置位，确保释放操作只有一个执行者，同时引入引用计数机制。

最近，为了优化性能，自己也引入了两个bug，好在都及时修正了。出bug的原因，还是对Linux内核本身不够熟悉。其中一个最近发现的bug，足足花了一天时间才定位到原因。现象是：运行某个特定应用程序时，会导致内核崩溃。起初，甚至一度怀疑这是内核自身的bug——虽然觉得可能性不大，但还是着手验证排除。因为不运行这个程序时，内核模块完全正常；一运行，内核就崩溃。而这个应用程序与我们的内核模块没有任何直接交互。

后来分析该应用程序的代码，发现它与网络最相关的操作，就是注册了一个PF_PACKET类型的socket，用于抓取所有网卡的数据包。于是去查看相关代码，发现PF_PACKET的收包函数会检查skb是否被共享，如果是就克隆一份。同样地，ip_rcv入口处也有类似逻辑。这意味着，当该应用程序运行时，ip_rcv会检测到skb是共享的，从而执行克隆操作。这就是应用程序运行与否，内核处理数据包流程的最大区别。

于是，修改ip_rcv的代码，不再检查skb是否共享，而是直接克隆。果然，即使不启动那个应用程序，内核依然崩溃。这就证明了，问题出在自己的代码里，而且与skb相关。经过一番排查，最终找到了根本原因。

在netfilter的两个hook点上，注册了两个钩子函数。前一个钩子函数初始化了一些per cpu变量；后一个钩子函数则简单判断：如果per_cpu->skb与hook的参数skb相等，就不再初始化，直接使用per cpu的变量。问题就在于，当有skb_clone调用时，不同hook点被调用时，skb->data指向的内存地址发生了变化。第二个hook点处，skb->data与第一个hook点处不一致。但skb_clone本身并不会导致这个结果。这说明在netfilter的不同hook点之间，当skb被克隆后，其数据空间可能会被重新分配——具体是哪段代码导致的，暂时没有深究。

这个bug带来了一个深刻的教训：内核编程中，你不可能熟悉Linux内核的所有代码。因此，编程时必须牢记，除非是内核明确定义的行为，否则不能放心使用。不能仅仅依靠简单的测试，就认为某些未定义的行为是安全可靠的。就像上面的例子，内核从未保证两个hook点之间的skb是相同的，也从未保证skb的数据空间（skb->data）是一致的。

在Linux内核中实现网关类功能时，还有一个体会：虽然Linux提供了大量现成组件，能加速开发进程，但内核本身的架构是为通用计算设计的，并非专为网络处理优化。其网络模块的架构存在不少固有的弊端和不便之处，尤其是对比笔者之前公司的产品架构——那个架构看上去简单，但越深入体会，越能感受到“简单即是美”的真谛！这种美体现在两方面：一是产品效率（即性能），二是开发效率。

Note: 其实，做网络设备做到高性能的产品，其底层架构大多有相似之处。但正是那些细微之处的不同，最终造就了产品性能的差异。