自动持有自旋锁时返回是否不安全？

受人尊敬的书说

The flags参数传递给spin_unlock_irqrestore必须与传递给的变量相同spin_lock_irqsave. 您还必须致电spin_lock_irqsave and spin_unlock_irqrestore在同一功能中；否则你的代码可能会在某些架构上崩溃。

但我找不到任何此类限制与内核代码本身捆绑在一起的官方文档 https://www.kernel.org/doc/Documentation/locking/spinlocks.txt。我发现违反本指南的驱动程序代码 https://github.com/ToshibaSemiconductor/TJET/blob/master/tjet-driver/src/os/linux/syscall/cmn_lock.c#L231.

显然打电话不是一个好主意spin_lock_irqsave and spin_unlock_irqrestore来自单独的函数，因为您应该最大限度地减少持有锁时完成的工作（禁用中断，同样如此！）。但是，如果小心翼翼地进行的话，对内核的更改是否可以实现这一点，它实际上从未违反 API 合同，还是仍然禁止这样做？

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

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

基本上，flags必须是当前执行上下文私有的，这就是为什么spin_lock_irqsave是一个宏，其名称为flags. While 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扩展为机器代码，将当前标志保存在某个寄存器中，then获取锁，并且then将该寄存器保存到指定的flags目的地。在这种情况下，有错误的代码实际上是安全的。如果扩展代码将标志保存到实际的flags调用者指定的对象，然后尝试获取锁，然后它就被破坏了。