上一篇我们把按键驱动从轮询改成了中断。响应快了、CPU开销没了,但你在insmod的时候有没有一丝不安——底半部线程和用户态 read/ioctl 如果同时访问设备结构体里的变量,会不会抢出 bug? 答案是:一定会。 不处理并发,轻则数据错乱,重则内核oops。今天,我们用spin_lock、mutex和atomic_t给驱动加上安全装甲。
unsetunset一、先看一个真实的竞态案例unsetunset
还是上一篇的中断版按键驱动。现在加一个需求:记录按键被按了几次,允许用户态通过sysfs读取。
structgpio_key_dev {int gpio;int irq;int press_count; /* 按键按了多少次 */structinput_dev *input;};
在底半部里累加计数:
staticirqreturn_tgpio_key_threaded(int irq, void *dev_id){structgpio_key_dev *dev = dev_id;int level; level = gpio_get_value(dev->gpio);if (level) {/* 按键按下 → 计数 +1 */ dev->press_count++; } input_report_key(dev->input, KEY_1, level); input_sync(dev->input);return IRQ_HANDLED;}
添加一个sysfs属性让用户态读计数:
staticssize_tpress_count_show(struct device *d, struct device_attribute *attr,char *buf){structgpio_key_dev *dev = dev_get_drvdata(d);returnsprintf(buf, "%d\n", dev->press_count); }
问题来了:底半部在写press_count,用户态cat sysfs在读press_count,它们可能运行在不同的 CPU 核上,同时访问同一个变量。
竞态到底怎么发生的?
press_count++在ARM64上展开后是三条指令:读 → 加1 → 写回。如果CPU1在"读"和"写回"之间插进来读,就拿到了中间状态。而且这不是理论上的"可能"——按键驱动运行在产品上,几天就会触发一次。
unsetunset二、什么时候用哪一把锁unsetunset
Linux 内核提供了多种同步机制,对驱动开发者来说,掌握三把就够:
unset三、atomic_t:最简单的并发保护unsetunset
对于press_count这种"只有一个整数变量"的场景,atomic_t是最优解:
#include<linux/atomic.h>structgpio_key_dev {int gpio;int irq;atomic_t press_count; /* 原子计数器 */structinput_dev *input;};/* 底半部:原子递增 */staticirqreturn_tgpio_key_threaded(int irq, void *dev_id){structgpio_key_dev *dev = dev_id;if (gpio_get_value(dev->gpio)) atomic_inc(&dev->press_count); /* 原子的 ++,一条指令搞定 *//* ... */return IRQ_HANDLED;}/* sysfs 读:原子读 */staticssize_tpress_count_show(struct device *d, struct device_attribute *attr,char *buf){structgpio_key_dev *dev = dev_get_drvdata(d);return sprintf(buf, "%d\n", atomic_read(&dev->press_count));}/* probe 中初始化 */atomic_set(&dev->press_count, 0);
常用 atomic_t 操作
atomic_t v;atomic_set(&v, 0); /* v = 0 */atomic_read(&v); /* return v */atomic_inc(&v); /* v++(返回 void) */atomic_dec(&v); /* v-- */atomic_inc_return(&v); /* return ++v(返回值是新值) */atomic_dec_return(&v); /* return --v */atomic_add(5, &v); /* v += 5 */atomic_sub(3, &v); /* v -= 3 *//* 条件操作(常用于状态标志) */atomic_cmpxchg(&v, old, new); /* if (v == old) v = new; return old */atomic_xchg(&v, new); /* tmp = v; v = new; return tmp */
ARM64 上atomic_inc展开后是一条ldadd指令——硬件保证原子性,不存在"读了又被别人改"的中间态。
unsetunset四、spin_lock:中断与进程之间的墙unsetunset
当临界区不止一行代码时,atomic_t不够用了。比如:
/* 底半部:不是只改一个变量,而是三步操作 */dev->key_state = KEY_PRESSED;input_report_key(dev->input, KEY_1, 1);input_sync(dev->input);dev->press_count++;
这四行要作为一个整体——要么全做完,要么全没做。于是spin_lock登场:
4.1 基本用法
#include<linux/spinlock.h>structgpio_key_dev {int gpio;int irq;int press_count;int key_state;spinlock_t lock; /* 自旋锁 */structinput_dev *input;};/* probe 中初始化 */spin_lock_init(&dev->lock);/* 底半部中 */staticirqreturn_tgpio_key_threaded(int irq, void *dev_id){structgpio_key_dev *dev = dev_id;unsignedlong flags;/* * spin_lock_irqsave:关了本地 CPU 的中断再拿锁。 * 为什么要关中断?——如果底半部拿了锁,顶半部(硬中断)又抢同一个锁, * 顶半部会死等(自旋),但顶半部不释放 CPU,底半部永远没机会释放锁 → 死锁。 */ spin_lock_irqsave(&dev->lock, flags); {/* === 临界区:拿了锁,放心改 === */ dev->key_state = KEY_PRESSED; input_report_key(dev->input, KEY_1, 1); input_sync(dev->input); dev->press_count++; } spin_unlock_irqrestore(&dev->lock, flags);return IRQ_HANDLED;}
4.2 spin_lock四个变体的选择
| | | |
|---|
spin_lock | | | 仅进程上下文 |
spin_lock_irq | | | |
spin_lock_irqsave | | | 最安全——不确定中断开关状态时用这个 |
spin_lock_bh | | | |
一句话口诀:驱动开发中,不确定用什么就选spin_lock_irqsave。 它最安全,代价最小(只多了几个指令保存/恢复 CPU 状态寄存器)。
unsetunset五、mutex:进程之间的排队锁unsetunset
如果两个路径都在进程上下文(比如两个sysfs写操作),而且临界区里可能有休眠操作(如copy_from_user、kmalloc(GFP_KERNEL)),那就用mutex:
#include<linux/mutex.h>structgpio_key_dev {int gpio;int irq;int debounce_ms; /* sysfs 可配置的去抖时间 */structmutexmutex;/* 互斥锁 */structinput_dev *input;};/* probe 中初始化 */mutex_init(&dev->mutex);/* sysfs 写:设置去抖时间(进程上下文,可以休眠) */staticssize_tdebounce_store(struct device *d, struct device_attribute *attr,constchar *buf, size_t count){structgpio_key_dev *dev = dev_get_drvdata(d);int val;if (kstrtoint(buf, 0, &val) < 0)return -EINVAL;/* * mutex_lock 会休眠等待锁——调用它的进程在锁被占用时 * 会被调度走,CPU 可以运行其他进程。这和 spin_lock * 的"死等"完全不同。 */ mutex_lock(&dev->mutex); dev->debounce_ms = val; mutex_unlock(&dev->mutex);return count;}
spin_lock vs mutex的本质区别
unsetunset六、常见的死锁场景unsetunset
场景一:拿了spin_lock又去拿mutex
/* ❌ 死锁套餐 */spin_lock_irqsave(&lock, flags);mutex_lock(&mutex); // mutex_lock 会休眠!但在自旋锁保护下不能休眠// ... 临界区 ...mutex_unlock(&mutex);spin_unlock_irqrestore(&lock, flags);/* ✅ 正确:spin_lock 和 mutex 不要套在一起 */
规则:持有spin_lock期间绝对不能调可能休眠的函数。mutex_lock会休眠 → 违反了spin_lock的规则 → 内核WARNING或者死锁。
场景二:两个锁,交叉拿
/* CPU0 */spin_lock(&lockA);spin_lock(&lockB);/* ... */spin_unlock(&lockB);spin_unlock(&lockA);/* CPU1 */spin_lock(&lockB); // ← 拿到 lockBspin_lock(&lockA); // ← 在等 lockA,但 lockA 被 CPU0 拿着// CPU0 又在等 lockB → 两个 CPU 互相等待 → 死锁/* ✅ 正确:所有地方按相同顺序拿锁 *//* CPU0 和 CPU1 都先 lockA 再 lockB,就不会死锁 */
场景三:拿了锁忘记释放
/* ❌ 某些分支会漏掉 unlock */spin_lock_irqsave(&lock, flags);if (ret < 0)return ret; // ← 直接 return,锁没释放!spin_unlock_irqrestore(&lock, flags);/* ✅ 正确:每个 return 前都要释放 */spin_lock_irqsave(&lock, flags);if (ret < 0) { spin_unlock_irqrestore(&lock, flags);return ret;}spin_unlock_irqrestore(&lock, flags);
unsetunset七、实战:给中断版按键驱动加上完整的并发保护unsetunset
#include<linux/module.h>#include<linux/platform_device.h>#include<linux/of_gpio.h>#include<linux/gpio.h>#include<linux/interrupt.h>#include<linux/input.h>#include<linux/spinlock.h>#include<linux/atomic.h>structgpio_key_dev {int gpio;int irq;atomic_t press_count; /* atomic:简单计数 */spinlock_t lock; /* spinlock:保护下面的字段 */int key_state;int debounce_ms;structinput_dev *input;};/* ============ 底半部 ============ */staticirqreturn_tgpio_key_threaded(int irq, void *dev_id){structgpio_key_dev *dev = dev_id;int level;unsignedlong flags; level = gpio_get_value(dev->gpio);/* * 用 spin_lock_irqsave 保护多行临界区。 * 注意:这里不需要保护 input_report_key(它本身是线程安全的), * 但 key_state 和 press_count 的读写需要原子性。 */ spin_lock_irqsave(&dev->lock, flags); { dev->key_state = level ? KEY_PRESSED : KEY_RELEASED; dev->press_count++; /* 这里不用 atomic_t,因为有锁保护 */ } spin_unlock_irqrestore(&dev->lock, flags);/* input_report_key 在锁外面调用——它内部有自己的同步机制 */ input_report_key(dev->input, KEY_1, level); input_sync(dev->input);return IRQ_HANDLED;}/* ============ sysfs: 读取按键次数 ============ */staticssize_tpress_count_show(struct device *d, struct device_attribute *attr,char *buf){structgpio_key_dev *dev = dev_get_drvdata(d);int count;unsignedlong flags;/* 读也要加锁——保证不会读到"写到一半"的值 */ spin_lock_irqsave(&dev->lock, flags); count = dev->press_count; spin_unlock_irqrestore(&dev->lock, flags);return sprintf(buf, "%d\n", count);}staticDEVICE_ATTR(press_count, 0444, press_count_show, NULL);/* ============ probe ============ */staticintgpio_key_probe(struct platform_device *pdev){structgpio_key_dev *dev;int ret; dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);if (!dev)return -ENOMEM;/* 初始化同步原语 */ spin_lock_init(&dev->lock); /* 自旋锁初始化 */ dev->gpio = of_get_named_gpio(pdev->dev.of_node, "key-gpios", 0);if (dev->gpio < 0)return dev->gpio; ret = gpio_request(dev->gpio, "key");if (ret)return ret; gpio_direction_input(dev->gpio); dev->irq = gpio_to_irq(dev->gpio);if (dev->irq < 0) { ret = dev->irq;goto fail_gpio; } dev->input = devm_input_allocate_device(&pdev->dev);if (!dev->input) { ret = -ENOMEM;goto fail_gpio; } dev->input->name = "gpio_key"; dev->input->phys = "gpio-keys/button0"; dev->input->id.bustype = BUS_HOST; input_set_capability(dev->input, EV_KEY, KEY_1); ret = input_register_device(dev->input);if (ret)goto fail_gpio; ret = request_threaded_irq(dev->irq, NULL, gpio_key_threaded, IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,"gpio_key", dev);if (ret)goto fail_input;/* 创建 sysfs 属性 */ ret = device_create_file(&pdev->dev, &dev_attr_press_count);if (ret)goto fail_irq; platform_set_drvdata(pdev, dev); pr_info("gpio_key: probed, irq=%d\n", dev->irq);return 0;fail_irq: free_irq(dev->irq, dev);fail_input: input_unregister_device(dev->input);fail_gpio: gpio_free(dev->gpio);return ret;}/* ============ remove ============ */staticintgpio_key_remove(struct platform_device *pdev){structgpio_key_dev *dev = platform_get_drvdata(pdev); device_remove_file(&pdev->dev, &dev_attr_press_count); free_irq(dev->irq, dev); input_unregister_device(dev->input); gpio_free(dev->gpio);return 0;}static const structof_device_idgpio_key_of_match[] = { { .compatible = "qian,gpio-key" }, { }};MODULE_DEVICE_TABLE(of, gpio_key_of_match);static structplatform_drivergpio_key_driver = { .driver = { .name = "gpio-key", .of_match_table = gpio_key_of_match, }, .probe = gpio_key_probe, .remove = gpio_key_remove,};module_platform_driver(gpio_key_driver);MODULE_LICENSE("GPL");MODULE_AUTHOR("qian");MODULE_DESCRIPTION("IRQ-driven GPIO key with spinlock and sysfs");
这套模板拿走就能用
以后写任何驱动,只要涉及中断 + 共享数据,套用这三个步骤:
1. 设备结构体里加 spinlock_t / mutex / atomic_t2. _init 函数在 probe 里调用(spin_lock_init / mutex_init / atomic_set)3. 所有读写共享数据的地方,用对应的 lock/unlock 包围
unsetunset八、Linux 4.19 / 5.10 / 6.1 版本差异unsetunset
并发同步原语是内核最稳定的部分,三个版本中 API 几乎无变化:
| | | |
|---|
spin_lock_init | | | |
mutex_init | | | |
atomic_t操作 | | | |
device_create_file | | | ⚠️ 推荐改用 sysfs_create_group |
DEVICE_ATTR宏 | | | |
本文代码在三个版本上完全兼容。 唯一的提醒:本文 sysfs 示例用的是 device_create_file,这是传统的单属性创建方式。在 6.1 上,内核社区推荐用 sysfs_create_group 一次性创建一组属性,但 device_create_file 仍然可以正常使用。
unsetunset本文你学到了什么unsetunset
- 竞态条件的本质 —— C 语言一行代码(如
count++)在 CPU 上是多条指令,多核同时访问会出中间态 atomic_t —— 单个变量的原子操作,ARM64 上编译成单条 ldadd 指令,硬件保证原子性spin_lock —— 自旋等待,适合微秒级临界区,可在中断上下文使用spin_lock_irqsave —— 关本地中断 + 拿锁 + 保存标志位,驱动开发中最安全的用法mutex —— 可休眠的互斥锁,只能在进程上下文中使用,适合毫秒级临界区- 死锁三场景 —— spin_lock 里调 mutex、交叉拿锁、忘记释放
- 驱动并发安全模板 ——
spin_lock_init 初始化 → spin_lock_irqsave 保护临界区 → spin_unlock_irqrestore 释放
unsetunset接下来unsetunset
中断、并发、同步——驱动开发的三大核心机制我们已经走了一遍。但还有一个"看不见的帮手"我们没有好好利用:内核定时器。在之前的两篇文章中,我们先用轮询定时器驱动按键,再用中断替代了轮询。但定时器不止能做轮询——它还能做去抖、定时上报、超时检测、周期性任务。
下一篇,我们系统整理 Linux 内核定时器:timer_list、mod_timer、hrtimer,以及如何用定时器给按键去抖(不用 msleep 的优雅方案)。
关注「钱途无量嵌入式」,专注 Linux 驱动与 BSP 开发,每周硬核输出。