拿着自旋锁自动返回不安全吗？

Question

受人尊敬的书 Linux Driver Development 这么说

传递给spin_unlock_irqrestore 的flags 参数必须与传递给spin_lock_irqsave 的变量相同。 您还必须在同一函数中调用spin_lock_irqsave 和spin_unlock_irqrestore；否则您的代码可能会在某些架构上中断。

但我找不到the official documentation bundled with the kernel code itself 要求的任何此类限制。我找到了driver code that violates this guidance。

显然，从单独的函数调用spin_lock_irqsave 和spin_unlock_irqrestore 不是一个好主意，因为您应该在持有锁的情况下最大限度地减少完成的工作（禁用中断，不少！）。但是，如果谨慎完成，内核的更改是否可以实现，它实际上从未违反 API 合同，还是仍然禁止这样做？

如果限制在某个时候被删除，它是否适用于版本 3.10.17？

Answer 1

这只是一个猜测，但如果您尝试对 flags 使用 nonlocal 变量或存储位置，可能会不清楚地指代可能发生的潜在错误。

基本上，flags 必须对当前执行上下文是私有的，这就是为什么spin_lock_irqsave 是一个采用flags 名称的宏。在保存 flags 时，您还没有自旋锁。

这与不同功能中的锁定和解锁有何关系：

考虑一些驱动程序开发人员可能编写的两个函数：

void my_lock(my_object *ctx)
{
  spin_lock_irqsave(&ctx->mylock, ctx->myflags);  /* BUG */
}

void my_unlock(my_object *ctx)
{
  spin_unlock_irqrestore(&ctx->mylock, ctx->myflags);
}

这是一个错误，因为在写入ctx->myflags 时，尚未持有锁，它是其他上下文和处理器可见的共享变量。本地标志必须保存到堆栈上的私有位置。然后，当调用者拥有锁时，可以将标志的副本保存到独占拥有的对象中。换句话说，可以这样修复：

void my_lock(my_object *ctx)
{
  unsigned long flags;
  spin_lock_irqsave(&ctx->mylock, flag);
  ctx->myflags = flags;
}

void my_unlock(my_object *ctx)
{
  unsigned long flags = ctx->myflags; /* probably unnecessary */
  spin_unlock_irqrestore(&ctx->mylock, flags); 
}

如果不能这样修复，实现需要包装 IRQ 自旋锁的高级原语将非常困难。

它如何依赖于架构：

假设spin_lock_irqsave 扩展为将当前标志保存在某个寄存器中的机器代码，然后获取锁，然后然后将该寄存器保存到指定的flags目的地。在这种情况下，错误代码实际上是安全的。如果扩展代码将标志保存到调用者指定的实际flags 对象中，然后尝试获取锁，那么它就坏了。

Answer 2

除了这本书，我从未见过这种约束。可能是因为书中的信息已经过时了，或者.. 完全是错误的。

在当前内核中（至少从我开始使用的 2.6.32 开始）实际锁定是通过来自spin_lock_irqsave 的多层嵌套调用完成的（参见，例如__raw_spin_lock_irqsave，在中间）。因此，lock 和 unlock 的不同功能上下文可能很难成为功能错误的原因。