1. 中断处理机制：上半部与下半部的精妙设计
中断处理是Linux驱动开发中最核心也是最容易出问题的部分。我记得刚接触驱动开发时，最困惑的就是为什么要把中断分成两半来处理。后来在实际项目中踩过几次坑才真正明白这种设计的必要性。
中断上半部（硬中断）要求快速执行，通常只做最紧急的硬件操作。比如当网卡收到数据包时，上半部只是简单地读取硬件状态并将数据转移到安全区域，然后就立即返回。如果在上半部做太多处理，会导致其他中断被长时间屏蔽，系统响应性能急剧下降。
中断下半部则处理那些可以延迟执行的任务。Linux提供了多种下半部机制：软中断（softirq）、tasklet和工作队列（workqueue）。我在实际项目中最常用的是tasklet和工作队列，因为它们使用起来相对简单。
/* 中断上半部示例 */
irqreturn_t interrupt_handler(int irq, void *dev_id)
{
/* 读取硬件状态 */
uint32_t status = readl(reg_base + STATUS_REG);
/* 清除中断标志 */
writel(status, reg_base + STATUS_REG);
/* 调度下半部 */
tasklet_schedule(&my_tasklet);
return IRQ_HANDLED;
}
/* tasklet下半部示例 */
void tasklet_function(unsigned long data)
{
/* 处理耗时操作 */
process_data();
/* 唤醒等待进程 */
wake_up_interruptible(&wait_queue);
}
在实际编码中，我发现很多开发者容易犯的一个错误是在上半部使用可能睡眠的函数。切记：中断上下文不能睡眠！我曾经调试过一个诡异的系统卡死问题，最后发现就是在中断处理函数中调用了kmalloc而没有使用GFP_ATOMIC标志。
1.1 软中断与tasklet的选择策略
软中断和tasklet都是运行在中断上下文的下半部机制，但它们有着重要的区别。软中断是可重入的，同一个软中断可能在多个CPU上同时运行，因此需要做好同步保护。而tasklet在设计上就保证了同一tasklet不会在多个CPU上并发执行，使用起来更简单安全。
在我的经验中，除非你要处理非常高频率的中断（比如千兆网卡驱动），否则优先选择tasklet。它的API更简单，不容易出错。只有当性能成为瓶颈时，才需要考虑使用软中断。
/* tasklet使用示例 */
DECLARE_TASKLET(my_tasklet, tasklet_function, 0);
/* 在工作队列中使用 */
struct work_struct my_work;
void work_function(struct work_struct *work)
{
/* 可以睡眠的操作 */
process_data_sleepable();
}
/* 初始化 */
INIT_WORK(&my_work, work_function);
1.2 工作队列的适用场景
工作队列是唯一可以睡眠的下半部机制，因为它运行在进程上下文中。当你需要执行可能阻塞的操作（如申请大量内存、进行文件I/O等）时，工作队列是唯一选择。
我记得在一个视频采集驱动项目中，需要在中断中保存图像数据到文件。最初错误地使用了tasklet，结果系统时不时就死锁。后来改用工作队列，问题就迎刃而解了。
关键选择准则：如果操作需要睡眠 -> 用工作队列；如果操作很简短但可能并发 -> 用软中断；如果操作简短且希望简单安全 -> 用tasklet。
2. 并发控制：自旋锁与信号量的实战应用
并发问题是驱动开发中最常见的bug来源。在多核CPU普及的今天，即使你没有刻意创建多个线程，内核本身的各种异步机制（中断、下半部、内核线程等）也会导致并发访问。
自旋锁（spinlock）和信号量（semaphore）是两种最常用的互斥机制，但它们的使用场景完全不同。用错地方会导致性能问题甚至死锁。
2.1 自旋锁的使用场景与注意事项
自旋锁的特点是：当获取不到锁时，当前CPU会忙等待而不是睡眠。这意味着自旋锁只能在不能睡眠的上下文使用，比如中断处理函数、软中断、tasklet等。
DEFINE_SPINLOCK(my_lock);
/* 在中断上下文中使用 */
void interrupt_handler(void)
{
unsigned long flags;
spin_lock_irqsave(&my_lock, flags);
/* 访问共享资源 */
spin_unlock_irqrestore(&my_lock, flags);
}
这里有个重要细节：spin_lock_irqsave会在加锁的同时禁用本地CPU中断，这是为了防止中断处理函数与下半部之间的死锁。我见过很多开发者错误地使用spin_lock而不是spin_lock_irqsave，在SMP系统上引发难以调试的竞态条件。
自旋锁的持有时间必须极短，因为忙等待会浪费CPU资源。如果临界区执行时间较长，应该使用信号量。
2.2 信号量的适用场景
信号量允许获取不到锁的进程睡眠，因此它适合保护那些可能执行较长时间的临界区。但是切记：不能在中断上下文使用信号量，因为中断上下文不允许睡眠。
DECLARE_MUTEX(my_mutex);
/* 在进程上下文中使用 */
void process_context_function(void)
{
down(&my_mutex);
/* 访问共享资源，可能睡眠 */
up(&my_mutex);
}
在实际项目中，我经常看到开发者混淆这两种锁的使用场景。最常见的错误是在中断处理函数中尝试获取信号量，这会导致内核崩溃。另一个常见错误是在进程上下文中使用自旋锁来保护长时间操作，这会造成CPU资源的极大浪费。
2.3 读写锁的选择策略
当你需要保护一个读多写少的共享资源时，读写锁（rwlock）是更好的选择。它允许多个读者同时访问，但写者需要独占访问。
DEFINE_RWLOCK(my_rwlock);
/* 读者 */
read_lock(&my_rwlock);
/* 读取操作 */
read_unlock(&my_rwlock);
/* 写者 */
write_lock(&my_rwlock);
/* 写入操作 */
write_unlock(&my_rwlock);
在我的经验中，使用读写锁时需要特别注意：读者在持有锁期间不能睡眠，否则如果写者在等待，会导致死锁。同时，要避免读者升级为写者（先读锁后写锁），这也会导致死锁。
3. 中断处理中的并发问题与解决方案
中断处理带来了特殊的并发问题，因为中断可以在任何时间点发生，打断正在执行的代码。这意味着即使你在进程上下文中已经使用了锁保护，中断处理函数仍然可能并发访问共享数据。
3.1 中断与进程的并发控制
当进程上下文和中断上下文需要访问同一共享数据时，简单的自旋锁或信号量都不够用。你需要使用spin_lock_irqsave来同时禁用本地中断并获取锁。
/* 进程上下文中的访问 */
void process_context_access(void)
{
unsigned long flags;
spin_lock_irqsave(&shared_lock, flags);
/* 访问共享数据 */
spin_unlock_irqrestore(&shared_lock, flags);
}
/* 中断上下文中的访问 */
void interrupt_handler(void)
{
unsigned long flags;
spin_lock_irqsave(&shared_lock, flags);
/* 访问共享数据 */
spin_unlock_irqrestore(&shared_lock, flags);
}
这种模式确保了无论是进程还是中断访问共享数据，都会正确地禁用中断并获取锁，避免了竞态条件。
3.2 多个中断之间的并发
如果多个中断处理函数可能访问同一共享数据，你还需要考虑中断之间的并发。即使你在一个中断处理函数中使用了spin_lock_irqsave，另一个中断仍然可能在另一个CPU上运行并访问共享数据。
在这种情况下，你需要确保所有可能访问该共享数据的中断处理函数都使用同一个锁，并且都使用spin_lock_irqsave变体。
/* 中断处理函数1 */
irqreturn_t irq_handler1(int irq, void *dev_id)
{
unsigned long flags;
spin_lock_irqsave(&shared_lock, flags);
/* 访问共享数据 */
spin_unlock_irqrestore(&shared_lock, flags);
return IRQ_HANDLED;
}
/* 中断处理函数2 */
irqreturn_t irq_handler2(int irq, void *dev_id)
{
unsigned long flags;
spin_lock_irqsave(&shared_lock, flags);
/* 访问共享数据 */
spin_unlock_irqrestore(&shared_lock, flags);
return IRQ_HANDLED;
}
4. 实战案例：网卡驱动中的并发控制
让我们通过一个真实的网卡驱动案例来看看这些概念如何应用。网卡驱动通常需要处理大量的并发问题：中断处理、数据包接收、数据包发送、统计信息更新等。
4.1 接收路径的并发控制
当网卡接收到数据包时，会触发中断。中断处理函数将数据包从硬件缓冲区转移到内核的sk_buff队列中。这个过程需要非常高效，所以通常在上半部只做最少的工作，然后调度下半部进行进一步处理。
/* 网卡驱动中的并发控制示例 */
DEFINE_SPINLOCK(rx_lock);
struct sk_buff_head rx_queue;
irqreturn_t netdev_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct sk_buff *skb;
unsigned long flags;
/* 读取中断状态 */
u32 status = readl(dev->base_addr + STATUS_REG);
if (status & RX_COMPLETE) {
/* 分配sk_buff */
skb = netdev_alloc_skb(dev, packet_length);
/* 从硬件读取数据 */
read_packet_from_hardware(dev, skb);
/* 保护性地将数据包加入队列 */
spin_lock_irqsave(&rx_lock, flags);
skb_queue_tail(&rx_queue, skb);
spin_unlock_irqrestore(&rx_lock, flags);
/* 调度下半部处理 */
tasklet_schedule(&rx_tasklet);
}
/* 清除中断 */
writel(status, dev->base_addr + STATUS_REG);
return IRQ_HANDLED;
}
在这个例子中，我们使用自旋锁来保护sk_buff队列的访问。因为中断处理函数和下半部都可能访问这个队列，所以使用spin_lock_irqsave来同时禁用中断和获取锁。
4.2 发送路径的并发控制
发送路径通常由用户进程触发，通过系统调用最终调用到驱动的发送函数。这里可能需要使用信号量，因为发送过程可能涉及内存分配等可能睡眠的操作。
DEFINE_MUTEX(tx_mutex);
int netdev_xmit(struct sk_buff *skb, struct net_device *dev)
{
int ret;
/* 获取发送锁 */
mutex_lock(&tx_mutex);
/* 检查硬件资源 */
if (hardware_busy(dev)) {
/* 等待硬件就绪 */
ret = wait_for_hardware(dev);
if (ret) {
mutex_unlock(&tx_mutex);
return ret;
}
}
/* 发送数据 */
send_to_hardware(dev, skb);
mutex_unlock(&tx_mutex);
return NETDEV_TX_OK;
}
这里使用互斥锁（mutex）而不是自旋锁，因为等待硬件就绪可能涉及睡眠。如果在发送路径中使用自旋锁，当硬件忙时CPU会忙等待，浪费大量资源。
4.3 统计信息的并发访问
网卡驱动还需要维护各种统计信息（发送包数、接收包数、错误计数等）。这些统计信息可能被多个上下文同时访问：中断处理函数、下半部、用户进程通过ioctl等。
对于统计信息的保护，通常使用原子操作而不是锁，因为原子操作更轻量级且不会睡眠。
atomic64_t tx_packets;
atomic64_t rx_packets;
/* 在中断中更新统计 */
void update_stats(void)
{
atomic64_inc(&rx_packets);
}
/* 在用户上下文中读取统计 */
void get_stats(struct net_device *dev, struct ethtool_stats *stats)
{
stats->tx_packets = atomic64_read(&tx_packets);
stats->rx_packets = atomic64_read(&rx_packets);
}
使用原子操作避免了锁的开销，对于这种简单的计数操作是非常合适的选择。
通过这个完整的网卡驱动案例，我们可以看到不同的并发控制机制如何在实际项目中配合使用。关键是要根据具体的场景选择最合适的同步机制：中断上下文用自旋锁，可能睡眠的进程上下文用信号量，简单计数用原子操作。
在实际开发中，我建议在代码中添加详细的注释说明为什么选择某种同步机制，这有助于后续维护和代码审查。同时，使用锁验证工具如lockdep可以帮助发现潜在的锁顺序问题，避免死锁的发生。
扫一扫
424
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
