Linux设备驱动单进程访问控制：open加锁close未加锁的竞态疑问

嘿，这个问题问得特别关键——驱动里的竞态简直是隐形坑，尤其是你这种要求设备独占访问的场景，稍不留神就会触发硬件故障！咱们一步步拆解：

首先明确scull示例里的核心点 #

在《Linux Device Drivers》的scull示例中，scull_s_count是用**原子类型atomic_t**实现的，它的递减操作atomic_dec()是内核提供的原子指令，完全不需要额外加锁就能保证操作的原子性——也就是说，多个进程同时调用close时，count的递减不会出现“半完成”的中间态，数值一定是准确的。

为什么open需要锁，而close在原子操作下不需要？ #

• open里的锁是为了保护复合操作：open函数里通常会做「判断当前设备是否可被打开（比如count是否为0，符合你的独占要求） + 递增count」这两步，这是一个典型的“读-修改-写”复合操作，必须用锁（比如mutex）把这两步包裹成一个原子执行的逻辑，否则多个进程会同时绕过判断，导致count超过限制（比如你的场景里就会出现多个进程同时打开设备）。
• close里的单纯递减是原子的：如果close里只做atomic_dec(&scull_s_count)这一件事，原子操作本身就能保证安全，不会出现竞态。但这里要注意一个例外：

你的独占场景需要额外注意的点 #

如果你的驱动在最后一个进程close时需要释放硬件资源（比如断电、重置硬件），那仅仅用原子递减就不够了，必须给close也加锁！举个例子：

进程A在close时，先完成原子递减，count从1变为0，正准备执行硬件关闭操作；同时进程B在open里加锁读取count，发现已经是0，于是允许打开并递增count到1，此时A开始关闭硬件，而B已经在访问设备，直接触发硬件混乱。

所以这种场景下，close的逻辑应该是：

mutex_lock(&dev_mutex);
atomic_dec(&scull_s_count);
if (atomic_read(&scull_s_count) == 0) {
    // 执行硬件资源释放操作
    hw_shutdown();
}
mutex_unlock(&dev_mutex);

同时open里的逻辑也要用同一个锁：

mutex_lock(&dev_mutex);
if (atomic_read(&scull_s_count) != 0) {
    mutex_unlock(&dev_mutex);
    return -EBUSY;
}
atomic_inc(&scull_s_count);
mutex_unlock(&dev_mutex);

这样才能保证“硬件释放”和“允许新进程打开”这两个操作不会交叉执行。

总结 #

• 如果scull_s_count是原子类型，单纯的atomic_dec没有竞态；
• open必须加锁是为了保护“判断+递增”的复合操作；
• 你的独占访问场景，若涉及硬件资源的释放/初始化，close也需要加锁，避免出现资源释放与新进程访问的竞态。

内容的提问来源于stack exchange，提问作者It'sPete