On 02/02/2017 02:19 AM, Paolo Valente wrote: > The scheme is clear. One comment, in case it could make sense and > avoid more complexity: since put_rq_priv is invoked in two different > contexts, process or interrupt, I didn't feel so confusing that, when > put_rq_priv is invoked in the context where the lock cannot be held > (unless one is willing to pay with irq disabling all the times), the > lock is not held, while, when invoked in the context where the lock > can be held, the lock is actually held, or must be taken. If you grab the same lock from put_rq_priv, yes, you must make it IRQ disabling in all contexts, and use _irqsave() from put_rq_priv. If it's just freeing resources, you could potentially wait and do that when someone else needs them, since that part will come from proces context. That would need two locks, though. As I said above, I would not worry about the IRQ disabling lock. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
