在 make_request 中使用什么样的自旋锁？答案

【问题标题】：What kind of spinlock to use in make_request?在 make_request 中使用什么样的自旋锁？
【发布时间】：2011-11-17 14:53:13
【问题描述】：

我正在编写一个提供（虚拟）块设备的 linux 内核模块（因此不执行实际的硬件 IO）。

目前我正在使用 spin_lock_irqsave / spin_unlock_irqrestore 来处理锁。

只有一个函数在非进程上下文中运行，这就是块设备的make_request函数。

使用 spin_lock_bh / spin_unlock_bh 处理锁是否安全？我想简单的 spin_lock 是不够的，因为 make_request 不是由进程运行的（这是正确的吗？）。

提前致谢。

【问题讨论】：

一点更新：我使用了 irqsave / restore 类型的锁，在某些系统上，irq 处理程序被饿死了，所以我终于尝试了 _bh 函数。现在一切看起来都很漂亮。我仍然需要一些专家说这样不会出问题。

标签： c linux-kernel kernel-module

【解决方案1】：

您的 make_request 函数实际上确实在进程上下文中运行。 q->make_request_fn 的唯一调用者是块层的generic_make_request()，它假定进程上下文（例如，查看它对current 的使用）。再举一个例子，drivers/md/md.c 有md_make_request()，它显式地在等待队列中休眠。

因此，只要您的所有其余代码也是进程上下文，那么使用纯 spin_lock()/spin_unlock() 是完全安全的。

【讨论】：

感谢您的回复，我会按照您的建议检查 md.c 和块层代码。
见鬼，如果你所有的代码都是进程上下文，那么你应该安全地使用mutex_lock() / mutex_unlock()
嗯，你是对的。我只是陷入了认知陷阱。 :) 我会试一试。我想到自旋锁不仅仅是因为看似可能的中断上下文，还因为这些锁的持有时间很短。无论如何，感谢您的启发性评论。
再次感谢您的笔记，您对我的帮助很大。