KFiFo 这个名字第一次见到时，我以为是某个新框架的缩写，后来在驱动调试现场翻了半天源码，才发现它其实是内核里一个老资格的 FIFO 队列实现。那个场景很典型：一边是硬中断飞快地往缓冲区里塞数据，一边是内核线程慢悠悠地往外取数据，没有稳定可靠的队列，丢数据几乎是必然的。kfifo 就是专门为这种“单生产者、单消费者”场景设计的无锁环形缓冲区，够简单、够快，也够“刁钻”——很多看似合理的用法，踩到它隐藏的约束条件后，会让你动辄丢数据、乱序、甚至 panic。这篇文章不打算贴一堆源码就完事，我会结合自己实际读代码和调驱动的经历，把 kfifo 的原理、关键实现、踩坑记录和排查思路一次讲透。
1. kfifo 到底是什么：从一次数据丢失事故说起
1.1 一个非常典型的丢数据现场
去年我在帮某开发者调试一块采集板卡的驱动，中断频率很高，每次中断产生 16 字节的状态数据，用户态程序通过设备节点周期性读取。最初的实现是自制的链表加自旋锁，中断上下文里把数据插入链表尾部，读线程从头部取。逻辑上看着没问题，实际跑起来高压场景下却不断丢中断。
后来把问题拆开看，发现根子不在锁，而在链表本身：每次插入都要分配内存，中断上下文里kmalloc如果走到慢速路径，延迟完全不可控；再加上链表节点分散在内存各处，CPU 缓存命中率低，读写双方频繁争用同一把锁，吞吐量一上去就崩。那段时间我翻内核源码，才认真把 kfifo 摸了一遍。它本质上就是一个用数组实现的先进先出队列，数据块连续存放，头尾指针只在数组边界做环绕，不需要动态分配节点，也不需要搬移数据。对那个采集驱动来说，换成 kfifo 之后，中断处理路径只剩一次内存拷贝，延迟一下子就稳住了。
1.2 所谓 FIFO，在这个场景里指的是什么
FIFO 大家都知道是先进先出。kfifo 在内核里的定位，就是一块固定大小的环形缓冲区，配上两个游标：一个记录写入位置，一个记录读取位置。数据从写游标位置放入，从读游标位置取出。区别在于，它不用%运算来求真实数组下标，而是要求缓冲区大小必须为 2 的幂，用与运算替代取模。这个设计看似只是性能优化，实际是整个无锁模型的地基。
很多内核子系统依赖它：串口驱动用它缓存收发字节，网络收包路径用它做临时队列，音频和 DMA 相关的驱动用它搬运数据块。你在/proc下面看到的某些内核统计，底层也是类似结构。与其把它当成某个具体驱动的一部分，不如理解成一个“内核自带的通用缓冲区组件”。凡是单写者单个读者、希望避免锁竞争的数据搬运场景，它都合适。
1.3 它适合谁来用
如果你是做内核驱动、嵌入式底层开发、或者需要自己维护一个高性能无锁队列，kfifo 绝对值得吃透。就算你只写用户态代码，kfifo 的设计思路也很有参考价值：环形数组、幂次大小、计数器不做回绕、用&替代%、读写屏障的放置顺序——这些思想放到任何高并发队列里都是通用的。
反过来说，kfifo 不是万能药。它默认的并发模型非常苛刻：单生产者、单消费者。如果违背了这个前提，比如多个 CPU 同时往同一个 kfifo 里写，那么无锁模型立刻失效，数据错乱只是时间问题。我见过不止一个新手在这个坑里翻车，后面我会专门讲怎么处理。
2. 从数学原理看懂 kfifo 为什么这么快
2.1 环形缓冲区：一条首尾相接的单行道
普通队列用数组实现时，每次出队如果都搬移剩余元素，复杂度是 O(n)。环形缓冲区的思路是：数据不动，动的是游标位置。把一块线性内存想象成一条环形跑道，写入者沿逆时针方向往前放数据，读取者跟在后面取数据。只要读者和写者的间距不超过跑道长度，就可以一直转圈跑，永远不用把数据从一头搬到另一头。
环形缓冲区带来的直接收益是 O(1) 的入队和出队时间复杂度，而且数据块内部连续，memcpy可以利用 CPU 的批量拷贝指令，效率远高于链表逐个节点操作。但环形缓冲区有个隐藏麻烦：数组下标的环绕运算。如果你用pos % size来折算位置，整数除法在 CPU 上很贵，尤其在内核热路径里，一次取模可能就要几十个周期。kfifo 的做法，就是从数学上彻底绕开这个除法。
2.2 size 为什么必须是 2 的幂
这是 kfifo 最经典的约束：缓冲区大小必须是 2 的幂。原因在于位运算：
index = pos & (size - 1);当size = 2^n时，size - 1的低 n 位全是 1，高位全是 0。对任意pos做按位与，等价于把pos对size取模。举个例子，size = 8，那么mask = 7。pos = 13时，13 & 7 = 5，而13 % 8 = 5，两者完全一致。
如果size不是 2 的幂，比如size = 9，mask = 8，pos = 11时，11 & 8 = 8，但11 % 9 = 2，完全不相等。这也是为什么很多人在手动调用初始化函数时，传入一个非 2 幂的大小，程序会直接报错或者表现诡异。新版 kfifo 会在初始化时自动把大小向上对齐到 2 的幂，但老版本要求调用者自己保证。这个细节，后面我会在踩坑部分再展开。
2.3 指针模型：in 与 out 只增不减
很多第一次读 kfifo 源码的人都会困惑：struct kfifo里只有in和out两个计数器，没有直接的“当前位置”，数组下标都是现算的，而且这两个计数器一直在增加，从不见它们回绕。这恰恰是 kfifo 的巧妙之处。
in表示累计写入的字节数，out表示累计读取的字节数。它们用无符号整数表示，当数值超过上限后会自然溢出回到 0。由于unsigned int的回绕行为在 C 语言里是明确定义的，整个累计模型的数学关系不会乱。判断队列状态也变得格外简单：
- 空队列：
in == out - 满队列：
in - out == size - 已用空间：
in - out - 剩余空间：
size - (in - out)
这种“只增不减”的计数器设计，配合 2 的幂取模，使得读写双方各自只需要维护一个计数器，互相之间不修改对方的数据。这一点为无锁奠定了基础。
2.4 为什么单生产者单消费者可以无锁
并发编程里，锁的引入是为了保护共享数据的竞争。kfifo 的巧妙之处在于，它把竞争范围压缩到了最小：生产者只更新in，消费者只更新out。生产者会读取out来判断是否有空间，消费者会读取in来判断是否有数据，但双方都不去写对方拥有的计数器。
真正的数据竞争发生在“数据本身”和“指针更新”的先后顺序上。如果生产者先更新了in，消费者看到新in后立刻去读缓冲区，但此时数据还没真正写入内存，读到的就是垃圾。反之，如果生产者把数据写好了，但消费者读到了旧的in，又会认为没有新数据。这两个问题靠的是内存屏障和编译屏障来解决：数据先落内存，再发布in；消费者先读入in，再读数据内存。
注意，这套逻辑只有在“一个写者、一个读者”时才是安全的。一旦有两个生产者，它们会同时修改in，产生写写竞争，无锁前提直接崩塌。两个消费者同理。所以用到 kfifo 时，第一件事就是确认你的并发模型是否匹配。
3. 源码级拆解：从初始化到入队、出队
3.1 核心结构体，其实只有三个字段
不同内核版本的 kfifo 结构体有所不同，但核心模型稳定。你可以把它简化成这样：
struct kfifo { unsigned char *buffer; /* 环形缓冲区内存 */ unsigned int size; /* 缓冲区大小，一定是 2 的幂 */ unsigned int in; /* 累计写入量 */ unsigned int out; /* 累计读取量 */ };新版内核把 kfifo 封装成了更多宏和辅助结构，但底层还是这套逻辑。读源码时别被宏定义吓住，先抓住buffer、size、in、out这四个核心字段，后面那些 record 变体、模板宏都只是在这上面的扩展。buffer指向实际的内存块，size是这块内存的字节数，in和out是永远不会主动回绕的计数器。
3.2 初始化：静态定义和动态分配两条路
使用 kfifo 的第一步是初始化。内核提供两种方式。静态定义用宏：
DEFINE_KFIFO(my_fifo, unsigned char, 1024);这个宏在编译期就会定义好结构体并分配数组，同时会把 1024 自动处理成 2 的幂。如果传入的不是 2 的幂，宏内部会做向上取整，但 1024 本身就是 2 的幂，所以不会改变。
动态分配用函数：
struct kfifo fifo; int ret; ret = kfifo_alloc(&fifo, 4096, GFP_KERNEL); if (ret) return -ENOMEM;kfifo_alloc会分配一块size字节的内存，并把in、out清零。注意它的入参 size 也会被强制向上对齐到 2 的幂，所以实际分配出来的内存可能比你传入的略大。释放时调用kfifo_free(&fifo)即可。如果在中断上下文或持锁路径上初始化，GFP_KERNEL要换成GFP_ATOMIC，因为前者可能睡眠。
3.3 入队路径：数据先落内存，指针最后移动
入队函数的核心逻辑如下（我按常见内核版本的逻辑缩写，细节可能因为版本调整略有不同）：
static unsigned int kfifo_in(struct kfifo *fifo, const void *from, unsigned int len) { unsigned int off, part; unsigned int unused = fifo_unused(fifo); if (len > unused) len = unused; off = fifo->in & (fifo->size - 1); part = min(len, fifo->size - off); memcpy(fifo->buffer + off, from, part); memcpy(fifo->buffer, from + part, len - part); smp_wmb(); WRITE_ONCE(fifo->in, fifo->in + len); return len; }这段代码有几个关键点。
第一，fifo_unused算出剩余空间。如果用户要写入的长度比剩余空间还大，实际只会写入剩余空间大小的数据，返回实际写入字节数。调用方必须检查这个返回值，否则你以为写入了全部数据，实际却丢了一部分。
第二，off = fifo->in & (fifo->size - 1)算出写入位置的数组下标。由于数据可能跨过数组尾部，需要分成两段拷贝：第一段从off到缓冲区末尾，第二段从缓冲区头部继续。两次memcpy保证了环形语义，也利用了连续内存的拷贝性能。
第三，smp_wmb()是写内存屏障。它保证前面的数据写入一定先于后面的WRITE_ONCE(fifo->in, ...)被其他 CPU 看到。WRITE_ONCE则避免编译器把对in的写入优化成暂时的中间值。这两者搭配，才让消费者能够安全地“先看到 in 更新，再回头读数据”。
3.4 出队路径：读指针最后动，peek 与 out 的区别
出队函数和入队是对称的：
static unsigned int kfifo_out(struct kfifo *fifo, void *to, unsigned int len) { unsigned int off, part; unsigned int available = kfifo_len(fifo); if (len > available) len = available; off = fifo->out & (fifo->size - 1); part = min(len, fifo->size - off); memcpy(to, fifo->buffer + off, part); memcpy(to + part, fifo->buffer, len - part); smp_rmb(); WRITE_ONCE(fifo->out, fifo->out + len); return len; }这里多了一个类似kfifo_len的计算：in - out。它直接从配对计数器算出当前已用空间。拷贝完数据后，用读内存屏障smp_rmb()保证“读取 in”的操作不会被乱序成“读取缓冲数据”的后面，然后再更新out。注意，消费者更新out不会影响生产者继续写入的可用空间计算，只有当生产者读取到新的out后，被消费掉的空间才能重新使用。
有一个和kfifo_out很像的接口叫kfifo_peek，它只拷贝数据，不更新out。这类接口很有用：比如你要先看看队列头部的数据是否完整，够了再真正消费；或者你想在不丢数据的前提下，查一下队列水位。实现上就是少写最后一次WRITE_ONCE(fifo->out, ...)。
3.5 内存屏障：多核世界的游戏规则
单核 CPU 上，代码顺序天然就是执行顺序，障碍只在编译器优化这一层，barrier()就够。但多核系统里，每个 CPU 有自己的缓存，写操作可能被局部缓存住，另外的 CPU 必须通过缓存一致性协议才能看到。如果不在恰当位置插入内存屏障，就可能出现“数据明明已经写了，读者却看不到”的极端情况。
kfifo 在这套模型里的约定很明确：
- 生产者：先写 buffer，再写 in。
- 消费者：先读 in，再读 buffer。
任何一方只要打乱这个顺序，要么消费者读到旧数据，要么生产者在原地打转。用smp_wmb()和smp_rmb()是其中一个实现方式。新版内核也在逐步引入smp_store_release/smp_load_acquire这类更细粒度的屏障，语义上表达得更清楚，但底层的顺序约定没有变。理解 kfifo 时，先把握住这个“发布-读取”顺序，比记住某个具体 API 更重要。
4. 实战应用：在内核模块里用好 kfifo
4.1 一个真正的可编译示例
下面这个示例虽然简单，但确实是我调试时常用的骨架：定时器模拟中断产生数据，内核线程负责消费。先看主流程：
#include <linux/module.h> #include <linux/kfifo.h> #include <linux/kthread.h> #include <linux/delay.h> DEFINE_KFIFO(g_fifo, unsigned char, 1024); static struct task_struct *g_task; static int reader_thread(void *arg) { unsigned char buf[64]; while (!kthread_should_stop()) { unsigned int n = kfifo_len(&g_fifo); if (n > 0) { unsigned int got = kfifo_out(&g_fifo, buf, sizeof(buf)); /* 这里处理 got 字节 */ } ssleep(1); } return 0; } static int __init demo_init(void) { g_task = kthread_run(reader_thread, NULL, "kfifo-demo"); return 0; } static void __exit demo_exit(void) { kthread_stop(g_task); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE("GPL");调用kfifo_out时，第二个参数是接收缓冲区，第三个参数是一次最多读取的字节数。返回的是实际读出的字节数，可能比请求的少，所以后续的数据处理要严格按返回值来。生产者的入口，通常在中断处理函数或某个高分辨率定时器回调里，调用：
unsigned int written = kfifo_in(&g_fifo, data, len); if (written < len) /* 队列满，数据被丢弃，需要计数或处理 */4.2 中断上下文使用要点
kfifo 入队路径里没有锁，没有kmalloc，只有纯内存拷贝，理论上可以在中断上下文安全执行。实际使用时，有几个细节要注意。
第一，如果传入缓冲区很大，memcpy本身也会占用不少时间。在中断处理里，尤其是硬中断中，要预估拷贝耗时，不要让中断处理过长。可以考虑把大块数据拆成分片，或者用 tasklet/softirq 来搬运。
第二，生产者入队时如果发现队列满，kfifo_in直接截断写入，不会阻塞。这是好消息也是坏消息：好消息是中断路径绝对安全，不会睡眠；坏消息是掉数据非常安静，不检查返回值根本感知不到。所以生产端最好统计一下“写失败”的总次数，或者记录kfifo_avail的最小值，便于事后判断队列容量是否够用。
第三，如果你在中断里的确需要保证每一笔数据都不丢，就得在硬件层面做 flow control，或者把队列 size 设置到足够覆盖中断峰值和消费端最慢时延的乘积。这个经验值只能压测得到，别靠拍脑袋。
4.3 按字节流还是按记录来
kfifo 有两条使用路线。普通kfifo_in/kfifo_out是字节流语义，适合串口数据、日志输出这种没有固定边界的场景。消费者读多读少都行，读取长度由调用者决定。但有些场景里，数据是一条一条的“记录”，比如网络报文或者固定结构体，如果消费者一次只读了一半，那就把记录切碎了。
新版内核专门有 record 系列接口，比如kfifo_in_rec和kfifo_out_rec，要求传入元素大小和数量，保证一次操作完整读写整数个记录。选择哪种，取决于你的数据模型。我自己的习惯是：只要数据有固定结构，一律用记录模式，省得自己维护“剩余字节”状态机。字节流模式虽然灵活，但记录边界的处理非常容易出错。
4.4 与用户态交互的工程细节
把 kfifo 拿给用户态读取时，一般流程是：用户在设备节点上发起read，驱动在内核里先kfifo_out到一块临时 buffer，再copy_to_user出去。这里面有几个容易踩的点。
第一个坑：直接在 kfifo 的 buffer 上做copy_to_user。copy_to_user可能因为用户态页错误而睡眠，而 kfifo 的 buffer 通常来自kmalloc，本身没有并行访问保护，多个读者同时拷贝就有问题。正确做法是先拷贝到栈上或驱动私有 buffer，再切到用户态。
第二个坑：用户态多线程同时read，等效于多个消费者。对 kfifo 来说，这破坏了单消费者前提。你需要在外围加一把互斥锁，把整个“从 kfifo 读出 + copy 到用户态”的过程串行化。注意不要再给 kfifo 本身加锁，那样会把无锁优势全部丢掉。
第三个坑：copy_to_user被信号打断返回-ERESTARTSYS时，已经kfifo_out掉的数据不会自动回来。你的驱动需要在拷贝失败时决定是重新入队还是直接丢弃。通常更稳妥的办法是先kfifo_peek读取但不弹数据，确认用户态缓冲区可写时，再kfifo_out真正消费。这样即使拷贝失败，队列里的数据还在。
5. 常见问题速查与排障实例
5.1 数据乱序或者内容错位
现象：偶尔读到一段数据，前半段是这次中断的，后半段是上一次的；或者同一个数据块被拆得七零八落。
排查思路：先确认生产端是否只有一个写者。如果多个 CPU 核都可能调用同一个入口函数写 kfifo，那就不是单生产者场景，而是在并发写in。解决办法有两个：要么在生产者一侧加自旋锁，把整个kfifo_in过程锁住；要么改成每个 CPU 一个独立 kfifo，消费端分别读取再按序合并。前者简单，但中断里加锁要小心；后者更符合无锁哲学，代价是消费逻辑变得复杂。
我实际调试时遇到过一个隐蔽版本：某个驱动开了中断亲和性，理论上是单 CPU 写，但另一个线程也会偶尔调用同一个入队函数做测试，结果高压时偶发乱序。最后加了个DEBUG统计写者的cpu编号，才抓到这个偶发调用。
5.2 高压下不定期丢数据
表现很直接：用户态读到的数据数量明显小于硬件产生数量。这种问题大部分不是 kfifo 本身损坏，而是队列容量不够，入队时被截断了。参考第 4.2 节的做法，在入队失败分支里累加一个“丢弃计数”，观察能跑多久、丢多少。
另一个常见原因来自读端：消费者线程优先级太低，或者被其他任务抢占太长时间，导致队列满的时间窗口过长。改善办法包括：提高消费线程优先级、用中断线程化 + 高优先级、把消费逻辑放到 softirq 里，以及增大 kfifo 容量做缓冲。有一次我把 kfifo 从 4KB 调到 64KB，丢包率直接归零，可见“容量不够”才是高频第一原因。
5.3 初始化非 2 幂大小导致的 panic
老版本 kfifo 有一类极其经典的崩溃：调用kfifo_init或kfifo_alloc时传入一个非 2 幂的 size，比如 1000，内核里某个BUG_ON被触发，或者后续所有位置计算都不对。新版内核通常会在初始化宏里自动 roundup，但你自己调用底层接口时依然要小心。
排查方法很简单：初始化后立刻打印fifo.size和请求 size，如果两者不一致，说明宏帮你做了二次修正；如果 panic，就要查代码路径里是否直接用了老接口。这个坑在“把早年内核版本的驱动迁移到新版内核”时尤其常见，因为旧版源码到处是手写的kfifo_init(&fifo, buf, size)，迁移时漏掉了 size 对齐。
5.4 新旧 API 迁移引发的编译问题
内核 kfifo 接口经历过一次比较大的重构，老版 API 的函数名和参数形式与新版不完全一样。很多人把老代码直接复制到新内核下编译，会出现“函数未定义”“结构体字段不存在”之类的错误。好在大多数常用操作在语义上一一对应，简单对照一下就行。
下面是我常用的对应关系表：
| 操作 | 老版本常见写法 | 新版本常见写法 |
|---|---|---|
| 动态初始化 | kfifo_alloc(&fifo, size, gfp) | kfifo_alloc(&fifo, size, gfp) |
| 静态初始化 | DECLARE_KFIFO | DEFINE_KFIFO |
| 入队 | kfifo_in(&fifo, buf, len) | kfifo_in(&fifo, buf, len) |
| 出队 | kfifo_out(&fifo, buf, len) | kfifo_out(&fifo, buf, len) |
| 只读不弹 | kfifo_peek(&fifo, buf, len) | kfifo_peek(&fifo, buf, len) |
| 队列长度 | kfifo_len(&fifo) | kfifo_len(&fifo) |
函数名看起来一样，但新版内部参数类型更严格，比如 record 系列和元素类型相关的宏，需要按新 API 的函数签名逐个调整。最笨但最有效的迁移办法是：打开新内核头文件里 kfifo 相关宏定义，对着老代码逐个核对参数类型和返回类型，不要凭记忆改。
5.5 我的排障经验清单
处理 kfifo 相关问题时，我通常按这个顺序排查：
- 先确认并发模型，用
cpu编号和调用栈统计生产者和消费者的实际执行核。 - 再确认返回值，所有
kfifo_in和kfifo_out的返回值是否都做了检查。 - 然后看水位，加一个周期性的
kfifo_len采样，观察队列是否经常跑满。 - 确认初始化时 size 是否为 2 的幂，以及实际分配到的 size 和你以为的是否一致。
- 最后再怀疑内存屏障问题，不过这一般只会在非标准架构或极端优化下出现，普通 x86 和 arm64 上概率很低。
这套流程帮我解决过不少稀奇古怪的丢数据问题。绝大多数时候，问题不是 kfifo 坏了，而是使用方式超出了它的设计约束。
5.6 两条最想告诉大家的实操体会
第一，kfifo 的“无锁”是有前提的，不是无脑去掉锁就更快。你必须在设计层面坐实单生产者单消费者这个模型，否则后面所有优化都是空中楼阁。第二，入队返回值一定要检查。kfifo 在队列满时不会阻塞，而是直接丢掉多余数据。驱动开发里最怕的就是这种“优雅失败”——系统一切正常，就是数据少了一段，没有任何日志，排查起来极其费力。
我个人在使用 kfifo 的过程中，最大的体会是：好的数据结构往往不是炫技，而是把约束条件前置，然后在约束内把简单的事情做到极致。2 的幂次大小、计数器不回绕、读写屏障的顺序，这些看似不起眼的决定，组合起来就是一个又小又快的无锁队列。下次你在代码里再看到 kfifo，不妨按今天我讲的这条线去读一遍源码，把入队、出队、空满判断一个个对上号，你会发现它比想象中简单得多。
